A Profile for Route Path Authorizations (RPAs)

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 11 December 2025.¶

Copyright Notice

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

The Border Gateway Protocol (BGP) [RFC4271] 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 [RFC7908], that plague Internet security.¶

The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve route security. (See [RFC6480] 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.¶

This propagation model uses a Web of Trust, i.e., the issuer AS trusts its upstream ASes and authorizes its downstream ASes to propagate its received routes. 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, which can be certified as a trusted path.¶

The RPA uses the template for RPKI digitally signed objects [RFC6488] for the definition of a Cryptographic Message Syntax (CMS) [RFC5652] 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 [RFC6485] or its successor.¶

To complete the specification of the RPA (see Section 4 of [RFC6488]), 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 [X.680] Distinguished Encoding Rules (DER) [X.690].¶

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

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

3. 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 [X.680] module:¶

RPKI-RPA-2025
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
     pkcs-9(9) smime(16) modules(0) id-mod-rpki-RPA-2025(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) } ;

  IPAddressFamily
  FROM IPAddrAndASCertExtn -- In [RFC3779]
    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ;

id-ct-RPA OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
    rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) rpa(TDB) }

ct-RPA CONTENT-TYPE ::=
    { TYPE RoutePathAuthorization IDENTIFIED BY id-ct-RPA }

RoutePathAuthorization ::= SEQUENCE {
    version [0]         INTEGER DEFAULT 0,
    asID                ASID,
    routePathBlocks     SEQUENCE (SIZE(1..MAX)) OF RoutePathDescription }

RoutePathDescription ::= SEQUENCE {
    previousHops        SEQUENCE (SIZE(0..MAX)) OF ASID,
    nextHops            SEQUENCE (SIZE(0..MAX)) OF ASID,
    origins             SEQUENCE (SIZE(0..MAX)) OF ASID OPTIONAL,
    prefixes            SEQUENCE (SIZE(0..MAX)) OF IPAddressFamily OPTIONAL }

ASID ::= INTEGER (0..4294967295)

END

Note that this content appears as the eContent within the encapContentInfo (see [RFC6488]).¶

4. RPA Validation

To validate an RPA, the relying party MUST perform all the validation checks specified in [RFC6488] 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 Section 3.¶

• The Autonomous System Identifier Delegation Extension described in [RFC3779] 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 [RFC3779] is not used in RPA, and MUST NOT be present in the EE certificate.¶

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

6. Security Considerations

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

7. IANA Considerations

Decimal  |  Description                 | Specification
----------------------------------------------------------------
TBD      | id-mod-rpki-rpa-2025          | [RFC-to-be]

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

Name          | OID                         | Specification
----------------------------------------------------------------
Route Path    |                             |
Authorization | 1.2.840.113549.1.9.16.1.TBD | [RFC-to-be]

Filename  |
Extension | RPKI Object                   | Reference
-----------------------------------------------------------------
     .rpa | Route Path Authorization      | [RFC-to-be]

  Type name: application
  Subtype name: rpki-rpa
  Required parameters: N/A
  Optional parameters: N/A
  Encoding considerations: binary
  Security considerations: Carries an RPKI RPA [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): .rpa
    Macintosh file type code(s):
  Person & email address to contact for further information:
    Yangfei Guo <guoyangfei@zgclab.edu.cn>
  Intended usage: COMMON
  Restrictions on usage: None
  Change controller: IETF

8. References

Acknowledgments

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

Authors' Addresses