A Profile for Autonomous System Relationship Authorization (ASRA)

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 16 April 2025.¶

Copyright Notice

Copyright (c) 2024 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

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) [RFC6480]. 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) [I-D.ietf-sidrops-aspa-profile] [I-D.ietf-sidrops-aspa-verification]. ASRA-based verification is complementary to ASPA-based verification.¶

BGP relationships that an Autonomous System (AS) may have with eBGP neighbors are discussed in [I-D.ietf-sidrops-aspa-verification]. 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 [I-D.sriram-sidrops-asra-verification]. 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 [RFC5652] protected content type definition conforms to the [RFC6488] template for RPKI signed objects. In accordance with Section 4 of [RFC6488], this document defines:¶

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

2. 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 [X.680] Distinguished Encoding Rules (DER) [X.690].¶

3. The steps required to validate an ASRA beyond the validation steps specified in [RFC6488].¶

2. ASRA Content Type

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 [RFC6488]).¶

3. ASRA eContent

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 [I-D.sriram-sidrops-asra-verification] 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 [X.680] 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 [RFC6488].¶

4. ASRA Validation

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 [RFC6488] as well as the following additional ASRA-specific validation steps.¶

• The Autonomous System Identifier Delegation Extension [RFC3779] 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 [RFC3779] MUST be absent.¶

5. IANA Considerations

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

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

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

Filename  |
Extension | RPKI Object                                  | Reference
-----------------------------------------------------------------------
     .asa | Autonomous System Relationship Authorization | [RFC-to-be]

   Type name: application
   Subtype name: rpki-asra
   Required parameters: N/A
   Optional parameters: N/A
   Encoding considerations: binary
   Security considerations: Carries an RPKI ASRA [RFC-to-be].
       This media type contains no active content. See
       Section xxx of [RFC-to-be] for further information.
   Interoperability considerations: None
   Published specification: [RFC-to-be]
   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
         AS identifiers (ASIDs) as defined in [RFC-to-be].
     Magic number(s): None
     File extension(s): .asa
     Macintosh file type code(s):
   Person & email address to contact for further information:
     Nan Geng <gengnan@huawei.com>
   Intended usage: COMMON
   Restrictions on usage: None
   Change controller: IETF

6. Security Considerations

The security considerations of [RFC6481], [RFC6485], and [RFC6488] also apply to ASRAs.¶

7. Acknowledgments

The authors would like to thank the authors of [I-D.ietf-sidrops-aspa-profile] since that document was used as a template.¶

Authors' Addresses