A Profile for Source Prefix Authorizations (SPAs)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Resource Public Key Infrastructure (RPKI) enables cryptographically verifiable assertions about routing authorization using a distributed trust model rooted in the Internet number resource allocation hierarchy, as described in [RFC6480]. Operational experience with RPKI-based origin validation, as specified in [RFC6811], has demonstrated that cryptographically verifiable routing intent can be incrementally deployed without disrupting BGP routing semantics.¶

While RPKI enables assertions about routing authorization, it does not currently allow prefix holders assigned by a Regional Internet Registry (RIR) to publish a signed list for authorized source prefixes.¶

This document defines a standard profile for Source Prefix Authorization (SPA), which enables a prefix holder to publish a cryptographically signed list of authorized source prefixes via RPKI.¶

The Source Prefix Authorization (SPA) makes use of the template for RPKI digitally signed object [RFC6488], which defines a Cryptographic Message Syntax (CMS) wrapper [RFC5652] for a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the SPA (see Section 4 of [RFC6488]), this section defines:¶

• The OID that identifies the signed object as being a SPA. (This OID appears within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object.)¶

• The SPA eContent is ASN.1 syntax, encoded using the Distinguished Encoding Rules (DER) [X.690].¶

• Additional steps required to validate SPAs (in addition to the validation steps specified in [RFC6488]).¶

This document is part of the Source-Selective BGP mechanism [I-D.braet-idr-source-selective-bgp-framework], which consists of RPKI Source Authorization objects and a BGP Path Attribute used to reference them.¶

2. The SPA Content Type

The content-type for a SPA is defined as id-ct-SPA and has the numerical value of 1.2.840.113549.1.9.16.1.TBD1.¶

This OID MUST appear within both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object (see [RFC6488]).¶

3. The SPA eContent

The content of a SPA binds a destination IP prefix or a designated subprefix of that prefix to a set of authorized source IP prefixes with a policy type. Only the legitimate holder of the destination prefix may publish the object. A single SPA object instance MUST only contain prefixes from a single address family. A SPA is formally defined as:¶

RPKI-SPA-2026
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) mod(0) id-mod-spa-2026(TBD2) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010 -- RFC 6268
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

ct-sourcePrefixAttestation CONTENT-TYPE ::=
  { TYPE SourcePrefixAttestation
    IDENTIFIED BY id-ct-SPA }

id-ct-SPA OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) id-smime(16) id-ct(1) spa(TBD1) }

SourcePrefixAttestation ::= SEQUENCE {
  version               [0] INTEGER DEFAULT 0,
  protectedIpAddrBlock  ProtectedSPAIPAddressFamily,
  srcIpAddrBlocks       SEQUENCE (SIZE(0..100)) OF SPAIPAddressFamily,
  policyType            PolicyType
}

ProtectedSPAIPAddressFamily ::= SEQUENCE {
  addressFamily  ADDRESS-FAMILY.&afi ({AddressFamilySet}),
  address        ADDRESS-FAMILY.&Address
                                ({AddressFamilySet}{@addressFamily})}

SPAIPAddressFamily ::= SEQUENCE {
  addressFamily  ADDRESS-FAMILY.&afi ({AddressFamilySet}),
  addresses      ADDRESS-FAMILY.&Addresses
                                ({AddressFamilySet}{@addressFamily}),
  savSource      ADDRESS-FAMILY.&savSource
                                ({AddressFamilySet}{@addressFamily})
}

ADDRESS-FAMILY ::= CLASS {
  &afi         OCTET STRING (SIZE(2)) UNIQUE,
  &Address,
  &Addresses,
  &savSource
} WITH SYNTAX {
  AFI             &afi
  ADDRESS         &Address
  ADDRESSES       &Addresses
  SAV-SOURCE-TYPE &savSource
}

AddressFamilySet ADDRESS-FAMILY ::=
  { addressFamilyIPv4 | addressFamilyIPv6 }

addressFamilyIPv4 ADDRESS-FAMILY ::= {
  AFI             afi-IPv4
  ADDRESS         SPAAddressIPv4
  ADDRESSES       SEQUENCE (SIZE(0..MAX)) OF SPAAddressIPv4
  SAV-SOURCE-TYPE ENUMERATED { no(0), yes(1) }
}

addressFamilyIPv6 ADDRESS-FAMILY ::= {
  AFI             afi-IPv6
  ADDRESS         SPAAddressIPv6
  ADDRESSES       SEQUENCE (SIZE(0..MAX)) OF SPAAddressIPv6
  SAV-SOURCE-TYPE ENUMERATED { no(0), yes(1) }
}

SPAIPAddress {INTEGER:ub} ::= BIT STRING (SIZE(0..ub))

SPAAddressIPv4 ::= SPAIPAddress{ub-IPv4}
SPAAddressIPv6 ::= SPAIPAddress{ub-IPv6}

PolicyType ::= ENUMERATED {
  allow  (0),
  deny   (1),
  future (2)
}

afi-IPv4 OCTET STRING ::= '0001'H
afi-IPv6 OCTET STRING ::= '0002'H

ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 64

END

4. SPA Publication and Validation

• SPA objects MUST be published in the RPKI repository of the destination prefix holder.¶

• Entities holding Provider Aggregatable (PA) space assigned by a Local Internet Registry (LIR) do not hold the necessary Resource Certificates to sign these objects directly; consequently, they must request their LIR to create and sign SPA objects on their behalf.¶

Before a Relying Party can use a SPA, the Relying Party MUST first validate the SPA. To validate a SPA, the Relying Party MUST perform all the validation checks specified in [RFC6488] as well as the following additional SPA-specific validation steps:¶

• The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the SPA), and the protectedIpAddrBlock IP address prefix in the SPA payload is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.¶

• The EE certificate's IP address delegation extension MUST NOT contain "inherit" elements as described in [RFC3779].¶

• The SPA content fully conforms with all requirements specified in Sections 2 and 3.¶

If any of the above checks fail, the SPA in its entirety MUST be considered invalid and an error SHOULD be logged.¶

5. Security Considerations

The security considerations of [RFC6481], [RFC7935], [RFC6488], and [RFC9582] also apply to the Source Prefix Authorization (SPA) RPKI object.¶

Failure to validate Source Prefix Authorization (SPA) objects correctly, or to apply consistent policy across enforcement points, may result in unintended traffic drops or acceptance of unauthorized traffic.¶

6. IANA Considerations

Note: Allocation of the SOURCE_SELECTIVE BGP Path Attribute referenced in this document is handled exclusively within [I-D.braet-idr-bgp-source-selective-attr].¶

7. Acknowledgments

The author would like to thank the individual reviewers from the IETF community for their valuable feedback and contributions during the development of this document.¶

The design of Source Prefix Authorization (SPA) builds on decades of work in BGP, RPKI, and secure routing. The author gratefully acknowledges the contributions of the IETF IDR, SIDROPS, and GROW working groups.¶

8. References

Author's Address