]> Zhongguancun Laboratory

Beijing China guoyangfei@zgclab.edu.cn

Tsinghua University

Beijing China wangxiaoliang0623@foxmail.com

Tsinghua University

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China zhuotaoliu@tsinghua.edu.cn

Tsinghua University

Beijing China qli01@tsinghua.edu.cn

This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Border Gateway Protocol (BGP) was designed with no mechanisms to validate the security of BGP attributes. There are two types of BGP security issues, BGP Hijacks and BGP Route Leaks , that plague Internet security. The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve route security. (See for more information.) As part of this system, a mechanism is needed to allow entities to verify that an IP address holder has permitted an AS to advertise a route along the propagation path. A Route Path Authorization (RPA) provides this function. An RPA 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 upstream ASes or one or more other ASes as its downstream ASes. The upstream ASes, or previous ASes, mean that the issuer AS can receive BGP route updates from these ASes. The downstream ASes, or next ASes, mean that the issuer AS would advertise the BGP route to these ASes. Validation algorithms, conflict resolution procedures, and path verification logic are outside the scope of this document and are specified separately; one can get more information at . The issuer AS trusts its upstream ASes and authorizes its downstream ASes to propagate the routes it receives. Then, all downstream ASes would also accept the routes and proceed to send them to their next hops. The relationship among them is the signed RPA, which attests that a downstream AS has been selected by the directly linked upstream AS to announce the routes. This introduces an ingress policy. Initially, all ASes on the propagation path should sign one or more RPAs independently if they want to propagate the route to their downstream ASes, and then be able to detect and filter malicious routes (e.g., route leaks and route hijacks). In addition, the RPA can also attest that all ASes on a propagation path have received and selected this AS_PATH. The RPA uses the template for RPKI digitally signed objects for the definition of a Cryptographic Message Syntax (CMS) wrapper for the RPA content as well as a generic validation procedure for RPKI signed objects. As RPKI certificates issued by the current infrastructure are required to validate RPA, we assume the mandatory-to-implement algorithms in or its successor. To complete the specification of the RPA (see ), this document defines:

1. The object identifier (OID) that identifies the RPA-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 RPA content, which is the payload signed by the BGP speaker. The RPA content is encoded using the ASN.1 Distinguished Encoding Rules (DER) .
3. The steps required to validate an RPA beyond the validation steps specified in .

The sole purpose of this document is to define a signed RPKI object that can be used to express route path authorization information. This document does not attempt to:

• define a complete AS_PATH validation procedure;
• define routing policy evaluation procedures;
• replace ASPA;
• determine routing relationship types;
• prove the operational existence of routing relationships.

Requirements Language 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

The RPA Content-Type The content-type for an RPA is defined as RoutePathAuthorization and 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 object as well as the content-type signed attribute in the signerInfo object (see ).

The RPA eContent The content of an RPA identifies feasible AS's route paths. Upon receiving a BGP-UPDATE message, other ASes can perform AS-path verification according to the validated RPAs. An RPA is an instance of RoutePathAuthorization, formally defined by the following ASN.1 module: Note that this content appears as the eContent within the encapContentInfo (see ).

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

The asID Element The asID field contains the AS number of the issuer AS associated with this RPA.

The routePathBlocks Element The routePathBlocks field comprises a list of feasible route paths associated with the issuing asID. Each feasible route path generally includes an upstream AS, a downstream AS, and a set of IP prefix blocks. This field may aggregate route paths that share the same IP prefix blocks to optimize space. Therefore, the routePathBlocks field indicates that for an IP prefix blocks represented by origins or prefixes, the issuing asID can receive routes from any AS in previousASes and subsequently forward them to any AS in nextASes. The origins and prefixes fields both indicate a set of IP prefix blocks. Both of them can be None; in that case, it means all IP prefix blocks can be forwarded according to the feasible route paths.

The previousASes Element The previousASes field contains the upstream AS Number (ASN) of the issuer AS that can advertise the routes to the issuer AS.

The nextASes Element The nextASes field contains the downstream AS Number (ASN) of the issuer AS that can receive advertised routes from the issuer AS.

The origins Element The origins field contains a set of ASes and is associated with Route Origin Authorization (ROA) or Signed Prefix List (SPL) . This is an optional field. If populated, it indicates that all routes belonging to the specified origin ASes can be received from the upstream ASes in the previousASes field and advertised to the downstream ASes in the nextASes field.

The prefixes Element The prefixes field contains IP prefix blocks. It is an optional field. If populated, it indicates that all routes specified can be received from the upstream ASes listed in the previousASes field and advertised to the downstream ASes in the nextASes field.

RPA Validation To validate an RPA, the relying party MUST perform all the validation checks specified in as well as the following additional RPA-specific validation steps.

• The contents of the CMS eContent field MUST conform to all the constraints described in .
• The Autonomous System Identifier Delegation Extension described in is also used in RPA and MUST be present in the EE certificate contained in the CMS certificates field.
• The AS identifier in the RoutePathAuthorization eContent 'asID' field MUST be contained in the AS Identifiers in the certificate extension.
• The Autonomous System Identifier Delegation extension MUST NOT contain "inherit" elements.
• The IP Address Delegation Extension is not used in RPA, and MUST NOT be present in the EE certificate.

Operational Consideration Multiple valid RPA objects that contain the same asID could exist. In such a case, the union of these objects forms the complete route path set of this AS. For a given asID, it is RECOMMENDED that a CA maintains a single RPA object. If an AS holder publishes an RPA object, then relying parties SHOULD assume that this object is complete for that issuer AS. If one AS receives a BGP UPDATE message with the issuer AS in the AS_PATH attribute that cannot match any route paths of this issuer AS, it implies that there is an AS-path forgery in this message. RPA is designed to support incremental deployment within the existing RPKI ecosystem. The publication of an RPA object by one AS does not require simultaneous deployment by all ASes appearing in an AS path. An RPA issuer MAY publish RPA objects independently of whether other ASes have deployed RPA. Relying parties MAY encounter routing information for which corresponding RPA objects are partially available or entirely absent. The handling of such deployment states is intentionally outside the scope of this document. This document only defines the syntax and semantics of RPA objects. Procedures for processing incomplete deployment states, including path validation behavior and routing policy decisions, are specified by separate validation procedures at .

Security Considerations The security considerations of , , , and also apply to RPAs.

IANA Considerations

SMI Security for S/MIME Module Identifier registry Please add the id-mod-rpki-rpa-2025 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:

SMI Security for S/MIME CMS Content Type registry Please add the RPA 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:

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

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

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

References Normative References 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] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 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, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK] 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] 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] Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Tsinghua University The Route Path Authorizations (RPA) is an RPKI object that attests to the routing paths description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an RPA-based AS Path Verification methodology to mitigate, even solve, AS Path forgery and route leaks. This document also explains the various BGP security threats that RPA can help address and provides operational considerations associated with RPA deployment. BSD Software Development APNIC This document defines a "Signed Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (the subject AS) may originate to all or any of its routing peers. The validation of a Signed Prefix List confirms that the holder of the subject AS produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by the subject AS. 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. 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. Informative References 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] 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 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. 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.

Comparison

ASPA This document does not modify, replace, or deprecate ASPA. RPA and ASPA serve different purposes. ASPA authorizes customer-provider relationships and provides information that can be used to validate the plausibility of an AS_PATH. RPA authorizes routing path segments associated with specific routing resources. ASPA expresses business relationship information. RPA expresses route propagation authorization information. Consequently:

• ASPA validation is relationship-oriented;
• RPA validation is authorization-oriented.

ASPA and RPA are complementary mechanisms and can be deployed independently. An implementation MAY utilize ASPA, RPA, or both, depending on the validation objectives and deployment requirements. The validity of an RPA object only demonstrates that:

• the object was issued by the legitimate holder of the associated RPKI resources;
• and the issuer asserts the path authorization information contained in the object.

An RPA object does not independently prove the existence, correctness, or operational status of any inter-domain routing relationship described in the object. Specifically, the presence of an RPA object does not prove that:

• the referenced neighboring ASes currently maintain a routing relationship with the issuer;
• the referenced routing relationship is mutually acknowledged;
• the routing relationship is operationally active.

The objective of RPA is therefore analogous to ROA and ASPA; it provides authenticated routing assertions that can be consumed by external validation procedures.

Acknowledgments The authors would like to thank Tobias Fiebig, Kotikalapudi Sriram, Jeffery Hass, and Alexander Azimov for their valuable comments and suggestions.