]> Liberty Global Ltd.

Netherlands kabraet@libertyglobal.com

Routing sidrops Internet-Draft 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

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 . Operational experience with RPKI-based origin validation, as specified in , 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 , which defines a Cryptographic Message Syntax (CMS) wrapper for a generic validation procedure for RPKI signed objects. Therefore, to complete the specification of the SPA (see Section 4 of ), 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) . Additional steps required to validate SPAs (in addition to the validation steps specified in ). This document is part of the Source-Selective BGP mechanism , which consists of RPKI Source Authorization objects and a BGP Path Attribute used to reference them.

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 . 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 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 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 series. Distinguished Encoding Rules (DER): A set of encoding rules defined in ITU-T that produces a unique, deterministic binary representation of ASN.1 structures, essential for cryptographic consistency.

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 ).

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:

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.

The version Element The version number of the SourcePrefixAttestation entry MUST be 0.

The protectedIpAddrBlock Element The protectedIpAddrBlock element contains the Holder's IP address prefix or a designated subprefix of that prefix.

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.

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.

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).

SPAIPAddress This element is of type BIT STRING and represents a single IP address prefix . 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.

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.

SPA Filename convention

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.

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 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 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.

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 as well as the following additional SPA-specific validation steps: The IP address delegation extension 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 . 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.

Security Considerations The security considerations of , , , and 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.

IANA Considerations Note: Allocation of the SOURCE_SELECTIVE BGP Path Attribute referenced in this document is handled exclusively within .

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

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 Authorization 1.2.840.113549.1.9.16.1.TBD1 draft-braet-sidrops-spa-profile

File Extension IANA is requested add an item for the SPA file extension to the "RPKI Repository Name Scheme" registry created by as follows: Filename extension RPKI Object Reference .spa Source Prefix Authorization draft-braet-sidrops-spa-profile

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

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. 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 , 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

Intended usage: COMMON Restrictions on usage: None Change controller: IETF

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.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Liberty Global Ltd. Liberty Global Ltd. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]