A Profile for Autonomous System Provider Authorization

The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve security in the global Internet routing system. As part of this infrastructure, a mechanism is needed for Autonomous Systems (AS) operators, in their capacity as customers, to designate and authorize other ASes as their provider(s). A Provider AS (PAS) is a network providing connectivity between networks - it provides transit services to customers. That is: The provider may propagate Border Gateway Protocol (BGP) routes received from any direction to their customers. For example, routes that the provider learned from its own providers, lateral peers, and other customers. The provider may also announce a default route to their customers. The provider may propagate BGP routes received from a customer in any direction. For example, to the provider's providers, lateral peers, and other customers. This document specifies a digitally signed Autonomous System Provider Authorization (ASPA) object. An ASPA object is a cryptographically verifiable attestation signed by the holder of an Autonomous System identifier, hereafter called the "Customer AS", or CAS. An ASPA object contains a list of one or more Provider ASes each of which is authorized to be a provider network for the Customer AS. This specification provides the authorization mechanism mentioned above and can be used to facilitate detection and mitigation of route leaks (see ). The procedures for verifying AS_PATHs in BGP UPDATE messages using ASPAs are described in . When a Customer AS makes use of multiple providers, all Provider ASes are to be listed in the ASPA object, including any non-transparent Internet Exchange Point (IXP) Route Server (RS) ASes. Note that the common case for RS ASes at IXPs is to operate transparently (see ), and transparent IXP Route Servers do not need to be listed as PAS in ASPAs. When the Customer AS does not use any providers for transit, a PAS value of 0 is used. 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 ASPA 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 ASPA content, which is the payload signed by the CAS. The ASPA content is encoded using the ASN.1 Distinguished Encoding Rules (DER) . The steps required to validate an ASPA beyond the validation steps specified in . This document also provides implementation guidance in .

The content-type for an ASPA is defined as id-ct-ASPA, which has the numerical value of 1.2.840.113549.1.9.16.1.49. 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 ASPA identifies the Customer AS (CAS) as well as the set of Provider ASes (SPAS) that are authorized by the CAS to be its providers. The eContent of an ASPA is an instance of ASProviderAttestation, formally defined by the following ASN.1 module: RPKI-ASPA-2026 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-rpki-aspa-2026(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- From 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-ASPA OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) aspa(49) } ct-ASPA CONTENT-TYPE ::= { TYPE ASProviderAttestation IDENTIFIED BY id-ct-ASPA } ASProviderAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, customerASID CAS, providers ProviderASSet } CAS ::= INTEGER (1..4294967295) ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS PAS ::= INTEGER (0..4294967295) END This content appears as the eContent within the encapContentInfo as specified in .

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

The customerASID field contains a positive integer that represents the AS number of the Customer AS that is the authorizing entity.

The providers field contains the listing of ASes that are authorized as providers. Each element contained in the providers field is an instance of PAS. Each PAS element contains the AS number of an AS that has been authorized by the Customer AS as its provider or non-transparent RS. In addition to the constraints described by the formal ASN.1 definition, the contents of the providers field MUST satisfy the following constraints: The customerASID value MUST NOT appear in any PAS in the providers field. The elements of providers MUST be ordered in ascending numerical order. Each value of PAS MUST be unique (with respect to the other elements of providers). A PAS value of 0 can only be encoded in the providers field as a single item list, i.e., an element for AS 0 MUST NOT appear alongside any other elements.

Before a Relying Party can use an ASPA to validate a routing announcement, a Relying Party MUST first validate the ASPA object itself. To validate an ASPA, a Relying Party MUST perform all the validation checks specified in as well as the following additional ASPA-specific validation steps: The Autonomous System Identifier Delegation Extension () MUST be present in the end-entity (EE) certificate (contained within the ASPA), and the Customer AS in the ASPA eContent MUST match the ASId specified by the EE certificate's Autonomous System Identifier Delegation Extension. The Autonomous System Identifier Delegation Extension MUST contain exactly one "id" element () and MUST NOT contain any "inherit" elements () or "range" elements (). The IP Address Delegation Extension () MUST be absent. The ASPA content fully conforms with all requirements specified in .

One ASPA Object per Customer AS For any given Customer AS, only a single ASPA object SHOULD be maintained which contains all providers (including any non-transparent RS ASes). The practice of maintaining a single object per Customer AS avoids race conditions during ASPA updates that might impact BGP route propagation. For the same reason, when an ASPA record is being migrated between different Certification Authority registries, the authorization contents of its instances at those registries SHOULD be identical (remain unchanged) for the duration of the migration. See for additional ASPA registration recommendations.

Merging of ASPA objects for the same CAS Multiple ASPA objects for the same CAS can be merged by combining all SPAS values into a union set of Provider ASes (U-SPAS). If the U-SPAS contains two or more values, and one of those values is AS 0, then AS 0 must be removed from the U-SPAS. In other words, the U-SPAS for a given CAS contains AS 0 if and only if all ASPA objects for that CAS have a SPAS containing only AS 0. See on avoiding multiple ASPAs for the same CAS.

Use of One-Time Use End Entity Certificates Certification Authorities are RECOMMENDED to generate a new key pair for each new ASPA and only sign one ASPA with each EE certificate. This type of EE certificate is termed a "one-time-use" EE certificate (see ). The newly generated keypair can be used as entropy for the filename for the new ASPA, see .

ASPA Object Filenames For optimal ASPA object propagation, Certification Authorities SHOULD follow the guidelines for naming ASPA objects based on , i.e., convert the 160-bit hash of the EE's public key value into a 27-character string using Base 64 Encoding with the URL and Filename Safe Alphabet (see ). See for more information and considerations.

Upper Bound on the Number of Providers per CAS While the ASN.1 profile specified in does not imposes any limit on the number of Provider ASes that can be listed for a given CAS, consideration will need to be given to limitations existing in validators and elsewhere in the RPKI ecosystem. For example, the number of Provider ASes that can be listed in a single RPKI-To-Router protocol ASPA PDU following the Length field constraints in is 16,380 providers. In addition to limitations in the various protocols used within the ecosystem, locally defined restrictions could exist for the maximum file size of signed objects a Relying Party implementation is willing to accept as well as limits to the maximum filesize a publication engine is willing to accept. Limiting the number of providers per CAS also is useful to reduce denial-of-service attack vectors aimed at exhausting RPs and BGP routers. For the above reasons, Relying Parties SHOULD support limiting the number of Provider ASes in the U-SPAS for a given CAS. At the time of writing, operational considerations suggest an upper bound value between 4,000 and 10,000 Provider ASes per CAS as default threshold. If this threshold is exceeded for a given CAS, Relying Party implementations MUST treat all ASPA objects related to that CAS as invalid, i.e., not emit a partial list of Provider ASes for that CAS. Additionally, an error SHOULD be logged in the local system, indicating the CAS for which the threshold was exceeded. The recommended threshold range was determined following careful observations on the state at the time of writing and projected state of the global Internet routing system. Specifically, the range is selected to provide ample room for growth, while also reducing the potential for DoS. Implementers and operators are RECOMMENDED to periodically review whether imposed upper bounds are aligned with the growth curve of the global Internet routing system.

The purpose of an ASPA is to convey authorization for a Provider AS to provide transit for the Customer AS in the ASPA. Thus, the integrity of an ASPA MUST be established. This ASPA specification makes use of the RPKI signed object format; thus, all security considerations discussed in also apply to ASPAs. Additionally, the signed object profile uses the CMS signed message format for integrity; thus, ASPAs inherit all security considerations associated with that data structure. The security considerations of also apply to ASPAs. The right of the ASPA signer to authorize a Provider AS to provide transit to the Customer AS is established through the use of the address space and AS number PKI as described in . Specifically, a Relying Party MUST verify the signature on the ASPA using an X.509 certificate issued under this PKI and check that the Customer AS in the ASPA is contained in the certificate's Autonomous System Identifier Delegation extension. There is no assumption of confidentiality for the data in an ASPA. There is no explicit authentication associated with an ASPA, since the PKI used for ASPA validation provides authorization but not authentication. Although the ASPA is a signed, application-layer object, there is no intent to convey non-repudiation via an ASPA. Large ASPA objects might cause strain within the ecosystem, therefore relying parties are advised to limit the number of providers per CAS in order to lessen the impact of exhaustion (see ).

IANA is requested to allocate for id-mod-rpki-aspa-2026 in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry under the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group as follows:

Decimal	Description	Specification
TBD	id-mod-rpki-aspa-2026	[RFC-to-be]

IANA is requested to make permanent in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry under the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group as follows:

Decimal	Description	Specification
49	id-ct-ASPA	[RFC-to-be]

IANA is requested to make permanent in the "RPKI Signed Object" registry under the "Resource Public Key Infrastructure (RPKI)" registry group as follows:

Name	OID	Specification
Autonomous System Provider Authorization	1.2.840.113549.1.9.16.1.49	[RFC-to-be]

IANA is requested to make permanent in the "RPKI Repository Name Scheme" registry under the "Resource Public Key Infrastructure (RPKI)" registry group as follows:

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

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

Implementation status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

A validator implementation written in C was provided by Job Snijders.
A validator implementation written in Rust was provided by Martin Hoffman from NLnet Labs.
A validator implementation written in Haskell was provided by Mikhail Puzanov.
A signer implementation written in Perl was provided by Tom Harrison from APNIC.
A signer implementation in Java was reported on by Ties de Kock from RIPE NCC.
A signer implementation in Rust was reported on by Tim Bruijnzeels.

Deployment Status As of November 2026, roughly 4,000 ASPA objects have been published in the global RPKI. See https://console.rpki-client.org/aspa.html for an up-to-date overview.

The authors would like to thank for helping kick-start the ASPA profile project, & for suggesting that the ProviderASSet be in a canonical form, and , , , , , , , , , , , , , and , for review and several suggestions for improvements.

The following people made significant contributions to this document:

Key words for use in RFCs to Indicate Requirement Levels 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. X.509 Extensions for IP Addresses and AS Identifiers 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] Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] A Profile for Resource Certificate Repository Structure 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] Signed Object Template for the Resource Public Key Infrastructure (RPKI) 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] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects Yandex Qrator Labs Internet Initiative Japan & Arrcus, Inc. Arrcus BSD Software Development USA National Institute of Standards and Technology This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation ITU-T Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services RIPE NCC RIPE NCC ARIN APNIC BSD Software Development This document describes best current practices for operating an RFC 8181 (A Publication Protocol for the Resource Public Key Infrastructure (RPKI)) Publication Engine and its associated publicly accessible rsync (RFC 5781) and RPKI Repository Delta Protocol (RRDP) (RFC 8182) repositories. A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] An Infrastructure to Support Secure Internet Routing 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. A Profile for X.509 PKIX Resource Certificates This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] Problem Definition and Classification of BGP Route Leaks A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community. Internet Exchange BGP Route Server This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers. The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Arrcus, DRL, & IIJ Research Dragon Research Labs Asia Pacific Network Information Centre In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-to-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. OpenBSD rpki-client rpki-aspa-demo APNIC rpki-commons RIPE NCC krill NLnet Labs rpki-prover routinator NLnet Labs

Example ASPA eContent Payload Below an example of a DER encoded ASPA eContent is provided with annotation following the '#' character. Below is a complete Base64 encoded RPKI ASPA Signed Object. The above should decode as following: