sidrops K. Braet Internet-Draft Liberty Global Ltd. Intended status: Standards Track 16 June 2026 Expires: 18 December 2026 A Profile for Source Prefix Authorizations (SPAs) draft-braet-sidrops-spa-profile-00 Abstract This document defines a standard profile for Source Prefix Authorizations (SPAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A SPA is a digitally signed object that allows the holder of an IP address prefix assigned by a Regional Internet Registry (RIR) to publish a list of source IP address prefixes authorized to send IP packets to that destination prefix or its subprefixes. To enforce these policies, a BGP speaker may include a SOURCE_SELECTIVE Path Attribute referencing the SPAs. This distributes policy references, enabling routing systems to incorporate source-based constraints into local forwarding policies and trigger control plane enforcement 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. Braet Expires 18 December 2026 [Page 1] Internet-Draft RPKI-SPA June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The SPA Content Type . . . . . . . . . . . . . . . . . . . . 4 3. The SPA eContent . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The SourcePrefixAttestation address family . . . . . . . 7 3.2. The version Element . . . . . . . . . . . . . . . . . . . 7 3.3. The protectedIpAddrBlock Element . . . . . . . . . . . . 7 3.3.1. ProtectedSPAIPAddressFamily . . . . . . . . . . . . . 7 3.4. The srcIpAddrBlocks Element . . . . . . . . . . . . . . . 7 3.4.1. SPAIPAddressFamily . . . . . . . . . . . . . . . . . 7 3.4.2. SPAIPAddress . . . . . . . . . . . . . . . . . . . . 7 3.5. The policyType Element . . . . . . . . . . . . . . . . . 8 3.6. SPA Filename convention . . . . . . . . . . . . . . . . . 8 3.6.1. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 8 3.6.2. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 8 4. SPA Publication and Validation . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . . 10 6.2. RPKI Signed Objects Registry . . . . . . . . . . . . . . 10 6.3. File Extension . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . 11 6.3.2. Media Type Registry . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Braet Expires 18 December 2026 [Page 2] Internet-Draft RPKI-SPA June 2026 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. Braet Expires 18 December 2026 [Page 3] Internet-Draft RPKI-SPA June 2026 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. * Source Prefix Authorization (SPA) CMS: A set of Source IP address prefixes authorized to send packets to a destination prefix published in RPKI as specified in this document. * Source Authorization (SA) CMS: An RPKI Source Authorization object type category. This category includes the Source Prefix Authorization (SPA) object defined in this document. * SOURCE_SELECTIVE: The BGP Path Attribute that references one or more RPKI Source Authorization (SA) objects, including the SPA object type, as specified in [I-D.braet-idr-bgp-source-selective-attr] * Relying Party (RP): An entity that validates RPKI objects. * Source Address Validation (SAV): Techniques that prevent packets with spoofed source addresses from entering or traversing a network. * Cryptographic Message Syntax (CMS): The format defined in [RFC5652] used to encapsulate ASN.1 DER-encoded RPKI payloads along with their digital signatures and the certificates required for validation. * Abstract Syntax Notation One (ASN.1): A standard notation for defining platform-independent data structures, as specified in the ITU-T [X.680] series. * Distinguished Encoding Rules (DER): A set of encoding rules defined in ITU-T [X.690] that produces a unique, deterministic binary representation of ASN.1 structures, essential for cryptographic consistency. 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]). Braet Expires 18 December 2026 [Page 4] Internet-Draft RPKI-SPA June 2026 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}) Braet Expires 18 December 2026 [Page 5] Internet-Draft RPKI-SPA June 2026 } 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 Braet Expires 18 December 2026 [Page 6] Internet-Draft RPKI-SPA June 2026 END 3.1. The SourcePrefixAttestation address family The IP address family MUST be of the same type for all IP address prefixes in a single RPKI Signed Object. 3.2. The version Element The version number of the SourcePrefixAttestation entry MUST be 0. 3.3. The protectedIpAddrBlock Element The protectedIpAddrBlock element contains the Holder's IP address prefix or a designated subprefix of that prefix. 3.3.1. ProtectedSPAIPAddressFamily Within the ProtectedSPAIPAddressFamily structure, the addressFamily element contains the Address Family Identifier (AFI) of an IP address family. Each addressFamily MUST be either '0001'H or '0002'H. The address element contains a single IP prefix of type SPAIPAddress. 3.4. The srcIpAddrBlocks Element The srcIpAddrBlocks element encodes the set of IP address prefixes that are authorized to send IP packets to the IP Prefix encoded in protectedIpAddrBlock element. 3.4.1. SPAIPAddressFamily Within the SPAIPAddressFamily structure, the addressFamily element contains the Address Family Identifier (AFI) of an IP address family. Each addressFamily MUST be either '0001'H or '0002'H. The addresses element contains IP prefixes as a sequence of type SPAIPAddress. The savSource element is an ENUMERATED type that indicates if Source Address Validation (SAV) controls should be applied to traffic originating from the specified source IP prefixes. It MUST be set to either no(0) or yes(1). 3.4.2. SPAIPAddress This element is of type BIT STRING and represents a single IP address prefix [RFC3779]. Braet Expires 18 December 2026 [Page 7] Internet-Draft RPKI-SPA June 2026 For IPv4, the maximum prefix length (ub-IPv4) MUST be 32 bits. For IPv6, the maximum prefix length (ub-IPv6) MUST be limited to 64 bits to mitigate hardware resource exhaustion. 3.5. The policyType Element The policyType element is an ENUMERATED type specifying the operational rule governing the associated source prefixes. It MUST be set to allow(0) for allowlist-based policies, deny(1) for denylist-based policies, or future(2) for prospective policy expansions. 3.6. SPA Filename convention 3.6.1. IPv4 Prefixes For SPAs associated with IPv4 prefixes, the filename MUST be derived from the authorized destination IPv4 prefix and MUST consist of a prefix-specific label followed by a hyphen ("-"), the decimal representation of the prefix length in bits, and the ".spa" file extension. The prefix-specific label MUST be encoded using dotted-decimal notation and MUST include only those octets that are fully or partially covered by the prefix. Any octets entirely untouched by the prefix length MUST be omitted. Any bits beyond the prefix length within a partially covered octet MUST NOT be represented. For octets that are only partially covered by the prefix, all bits not covered by the prefix MUST be set to zero. The prefix length component MUST correspond exactly to the length in bits of the authorized prefix. For example, an authorization for the prefix 192.0.2.0/24 would be encoded as 192.0.2-24.spa, and an authorization for the prefix 203.0.113.0/25 would be encoded as 203.0.113.0-25.spa. 3.6.2. IPv6 Prefixes For SPAs associated with IPv6 prefixes, the filename MUST be derived from the authorized destination IPv6 prefix and MUST consist of a prefix-specific label followed by a hyphen ("-"), the decimal representation of the prefix length in bits, and the ".spa" file extension. The prefix-specific label MUST be encoded using the canonical hexadecimal representation defined in [RFC5952] and MUST include only those 16-bit segments that are fully or partially covered by the prefix. Any octets entirely untouched by the prefix length MUST be omitted. Any bits beyond the prefix length within a partially Braet Expires 18 December 2026 [Page 8] Internet-Draft RPKI-SPA June 2026 covered octet MUST NOT be represented. For segments that are only partially covered by the prefix, all bits not covered by the prefix MUST be set to zero. Hexadecimal digits MUST be represented in lowercase. The colon (":") separator defined in RFC5952 MUST be replaced by a period (".") in the filename to ensure compatibility with common operating system file systems. Zero compression ("::") MUST NOT be used. The prefix length component MUST correspond exactly to the length in bits of the authorized prefix. For example, an authorization for the IPv6 prefix 2001:0db8:abcd::/48 would be encoded as 2001.db8.abcd-48.spa, and an authorization for the IPv6 prefix 2001:0db8:abcd:ef00::/56 would be encoded as 2001.db8.abcd.ef00-56.spa. 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. Braet Expires 18 December 2026 [Page 9] Internet-Draft RPKI-SPA June 2026 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]. 6.1. SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) IANA is requested to allocate the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry: +=========+=============+=================================+ | Decimal | Description | Reference | +=========+=============+=================================+ | TBD1 | id-ct-SPA | draft-braet-sidrops-spa-profile | +---------+-------------+---------------------------------+ Table 1 6.2. RPKI Signed Objects Registry IANA is requested add an item for the SPA file extension to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/ rpki.xhtml#signed-objects) as follows: +===============+==============================+==============+ | Name | OID | Reference | +===============+==============================+==============+ | Source Prefix | 1.2.840.113549.1.9.16.1.TBD1 | draft-braet- | | Authorization | | sidrops-spa- | | | | profile | +---------------+------------------------------+--------------+ Table 2 Braet Expires 18 December 2026 [Page 10] Internet-Draft RPKI-SPA June 2026 6.3. File Extension IANA is requested add an item for the SPA file extension to the "RPKI Repository Name Scheme" registry created by [RFC6481] as follows: +===========+===============+=================================+ | Filename | RPKI Object | Reference | | extension | | | +===========+===============+=================================+ | .spa | Source Prefix | draft-braet-sidrops-spa-profile | | | Authorization | | +-----------+---------------+---------------------------------+ Table 3 6.3.1. SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) IANA is requested to allocate the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry: +=========+=================+=================================+ | Decimal | Description | Reference | +=========+=================+=================================+ | TBD2 | id-mod-spa-2026 | draft-braet-sidrops-spa-profile | +---------+-----------------+---------------------------------+ Table 4 6.3.2. Media Type Registry The IANA is requested to register the media type application/rpki-spa in the "Media Type" registry as follows: Type name: application Subtype name: rpki-spa Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: Carries an RPKI SPA. This media type contains no active content. See Section 5 of draft-braet-sidrops- spa-profile for further information. Braet Expires 18 December 2026 [Page 11] Internet-Draft RPKI-SPA June 2026 Interoperability considerations: None Published specification: draft-braet-sidrops-spa-profile Applications that use this media type: RPKI operators Additional information: Content: This media type is a signed object, as defined in [RFC6488], which contains a payload of a list of Source Prefixes and an associated IP Prefix assigned to the publisher of the object as defined in draft-braet-sidrops-spa-profile. Magic number(s): None File extension(s): .spa Macintosh file type code(s): None Person & email address to contact for further information: Kamiel Braet kabraet@libertyglobal.com (mailto:kabraet@libertyglobal.com) Intended usage: COMMON Restrictions on usage: None Change controller: IETF 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 8.1. Normative References [I-D.braet-idr-bgp-source-selective-attr] Braet, K., "BGP Source-Selective Attribute", Work in Progress, Internet-Draft, draft-braet-idr-bgp-source- selective-attr, 2026, . Braet Expires 18 December 2026 [Page 12] Internet-Draft RPKI-SPA June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . [X.680] "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T , 2021. [X.690] "Information Technology - ASN.1 encoding rules: pecification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T , 2021. 8.2. Informative References Braet Expires 18 December 2026 [Page 13] Internet-Draft RPKI-SPA June 2026 [I-D.braet-idr-source-selective-bgp-framework] Braet, K., "Source-Selective BGP Framework", Work in Progress, Internet-Draft, draft-braet-idr-source- selective-bgp-framework, 2026, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . Author's Address Kamiel Braet Liberty Global Ltd. Netherlands Email: kabraet@libertyglobal.com Braet Expires 18 December 2026 [Page 14]