A Profile for Autonomous System Relationship Authorization (ASRA)

This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI) . An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA) . ASRA-based verification is complementary to ASPA-based verification. BGP relationships that an Autonomous System (AS) may have with eBGP neighbors are discussed in . ASPA object is used to register the set of provider ASes that the subject (signing) AS has. ASRA object is used to register the set of ASes with which the subject AS has customer and/or lateral peering relationships. There are three subcategories of ASRAs defined: ASRA1, ASRA2, and ASRA3. They are distinguished by a subcategory field by setting its value to 1, 2, or 3, respectively. ASRA1 and ASRA2 are used to register the lists of customers and lateral peers, respectively. Alternatively, if the subject AS does not wish to separately disclose customers and lateral peers, it has the option to register an ASRA3 to register the combined list of customers and lateral peers. The details of ASRA registration requirements for ASes in different scenarios are specified in Section 3 of . In addition, the procedures for verifying AS_PATHs in BGP UPDATE messages using validated ASRA objects (in conjunction with the ASPA objects) are described in that document. This CMS protected content type definition conforms to the template for RPKI signed objects. In accordance with Section 4 of , this document defines: The object identifier (OID) that identifies the ASRA signed object. This OID appears in the eContentType field of the encapContentInfo object as well as the content-type signed attribute within the signerInfo structure. The ASN.1 syntax for the ASRA content, which is the payload signed by the signer (subject) AS. The ASRA content is encoded using the ASN.1 Distinguished Encoding Rules (DER) . The steps required to validate an ASRA beyond the validation steps specified in .

The content-type for an ASRA is defined as id-ct-ASRA, which has the numerical value of 1.2.840.113549.1.9.16.1.TBD. This OID MUST appear both within the eContentType in the encapContentInfo structure as well as the content-type signed attribute within the signerInfo structure (see ).

The content of an ASRA identifies the signer (subject) AS as well as the Set of ASes that are authorized by the signer AS to be its customers and/or lateral peers. A user registering ASRA(s) must be cognizant of Section 3 of and the user (or their software tool) must comply with the ASRA registration recommendations in that section. In the case of the transition process between different CA registries, the ASRA records SHOULD be kept identical in all registries in terms of their authorization contents. The eContent of an ASRA is an instance of ASRelationshipAttestation, formally defined by the following ASN.1 module:

RPKI-ASRA-2024 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpki-asra-2024(TBD) } 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) } ; id-ct-ASRA OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) asra(TBD) } ct-ASRA CONTENT-TYPE ::= { TYPE ASRelationshipAttestation IDENTIFIED BY id-ct-ASRA } ASRelationshipAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, SignerASID ASID, ASRAsubcategory subcategory, Relationships RelationshipASSet } ASID ::= INTEGER (0..4294967295) subcategory ::= OCTET STRING (SIZE (1)) RelationshipASSet ::= SEQUENCE (SIZE(1..MAX)) OF ASID END Note that this content appears as the eContent within the encapContentInfo as specified in .

The version number of the ASRelationshipAttestation that complies with this specification MUST be 0 and MUST be explicitly encoded.

The SignerASID field contains the AS number of the Autonomous System that is the authorizing entity (Signer AS).

ASRAsubcategory can have values 0 to 255. The values 1, 2, and 3 are assigned to represent ASRA1, ASRA2, and ASRA3, respectively. As explained in , ASRA1 means that the Relationships (see ) field contains ASIDs of only the customer ASes of the Signer AS; ASRA2 means that the Relationships field contains ASIDs of only the lateral peer ASes; ASRA3 means that the Relationships field contains the combined list of ASIDs of customer and lateral peer ASes. Section 3 of for details of registration requirements for ASRA1, ASRA2, and ASRA3.

Each element contained in the Relationships field is an instance of ASID. The Relationships field contains the listing of ASIDs of ASes that are authorized as customers and/or lateral peers (per ASRA1, ASRA2, and ASRA3 subcategory definitions). In addition to the constraints described by the formal ASN.1 definition, the contents of the Relationships field MUST satisfy the following constraints: The SignerASID value MUST NOT appear in any ASID in the Relationships field. The elements of Relationships MUST be ordered in ascending numerical order (ASIDs). Each value of ASID MUST be unique (with respect to the other elements of Relationships).

Before a relying party can use an ASRA to validate a routing announcement, the relying party MUST first validate the ASRA object itself. To validate an ASRA, the relying party MUST perform all the validation checks specified in as well as the following additional ASRA-specific validation steps. The Autonomous System Identifier Delegation Extension MUST be present in the end-entity (EE) certificate (contained within the ASRA), and the SignerASID in the ASRA eContent MUST be contained within the set of AS numbers specified by the EE certificate's Autonomous System Identifier Delegation Extension. The EE certificate's Autonomous System Identifier Delegation Extension MUST NOT contain any "inherit" elements. The IP Address Delegation Extension MUST be absent.

Please add the id-mod-rpki-asra-2024 to the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-0) as follows:

Decimal | Description | Specification ---------------------------------------------------------- TBD2 | id-mod-rpki-asra-2024 | [RFC-to-be] ----------------------------------------------------------

Please add the ASRA to the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry (https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#security-smime-1) as follows:

Decimal | Description | Specification ---------------------------------------------------------- TBD | id-ct-ASRA | [RFC-to-be] ----------------------------------------------------------

Please add Autonomous System Relationship Authorization to the RPKI Signed Object registry (https://www.iana.org/assignments/rpki/rpki.xhtml#signed-objects) as follows:

Name | OID |Specification --------------------------------------------------------------------- Autonomous System | 1.2.840.113549.1.9.16.1.TBD|[RFC-to-be] Relationship Authorization| | ---------------------------------------------------------------------

Please add an item for the Autonomous System Relationship Authorization file extension to the "RPKI Repository Name Scheme" registry created by as follows:

The IANA is requested to register the media type application/rpki-asra in the "Media Type" registry as follows: Intended usage: COMMON Restrictions on usage: None Change controller: IETF ]]>

The security considerations of , , and also apply to ASRAs.

The authors would like to thank the authors of since that document was used as a template.