A Profile for Forwarding Commitments (FCs)

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 23 August 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], plague Internet security.¶

The primary purpose of the Resource Public Key Infrastructure (RPKI) is to improve routing 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 Forwarding Commitment (FC) provides this function.¶

A Forwarding Commitment (FC) 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 nexthop ASes, mean that the issuer AS would advertise the BGP route to these ASes.¶

In this propagation model, it uses a Web of Trust, i.e., the issuer AS trusts its previous ASes and authorizes nexthop ASes to propagate its received routes. Then, all nexthop ASes would also accept the routes and proceed to send them to their next hops. The relationship among them is the signed FC, which attests that a downstream AS has been selected by the directly linked upstream AS to announce the routes.¶

Initially, all ASes on the propagation path should sign one or more FCs independently if they want to propagate the route to its downstream ASes, and then be able to detect and filter malicious routes (e.g., route leaks and route hijacks). In addition, the FC 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 FC uses the template for RPKI digitally signed objects [RFC6488] for the definition of a Cryptographic Message Syntax (CMS) [RFC5652] wrapper for the FC content as well as a generic validation procedure for RPKI signed objects. As RPKI certificates issued by the current infrastructure are required to validate FC, we assume the mandatory-to-implement algorithms in [RFC6485] or its successor.¶

To complete the specification of the FC (see Section 4 of [RFC6488]), this document defines:¶

1. The object identifier (OID) that identifies the FC-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 FC content, which is the payload signed by the BGP speaker. The FC content is encoded using the ASN.1 [X.680] Distinguished Encoding Rules (DER) [X.690].¶

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

2. The FC Content-Type

The content-type for an FC is defined as ForwardingCommitment 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 FC eContent

The content of an FC identifies a forwarding commitment that represents an AS's routing intent. Upon receiving a BGP-UPDATE message, other ASes can perform AS-path verification according to the validated FCs. An FC is an instance of ForwardingCommitmentAttestation, formally defined by the following ASN.1 [X.680] module:¶

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

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

ct-FC CONTENT-TYPE ::=
    { TYPE ForwardingCommitmentAttestation IDENTIFIED BY id-ct-FC }

ForwardingCommitmentAttestation ::= SEQUENCE {
    version [0]         INTEGER DEFAULT 0,
    asID                ASID,
    routingIntents      SEQUENCE (SIZE(1..MAX)) OF ROUTING-INTENT }

ROUTING-INTENT ::= SEQUENCE {
    previousASes        SEQUENCE (SIZE(1..MAX)) OF ASID,
    nexthopASes         SEQUENCE (SIZE(1..MAX)) OF ASID,
    originASes          SEQUENCE (SIZE(0..MAX)) OF ASID OPTIONAL }

ASID ::= INTEGER (0..4294967295)

END

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

4. Forwarding Commitment Validation

To validate an FC, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional FC-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 Forwarding Commitment and MUST be present in the EE certificate contained in the CMS certificates field.¶

• The AS identifier present in the ForwardingCommitmentAttestation eContent 'asID' field MUST be contained in the AS Identifiers present 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 Forwarding Commitment, and MUST NOT be present in the EE certificate.¶

5. Operational Consideration

Multiple valid Forwarding Commitment objects which contain the same asID could exist. In such a case, the union of these objects forms the complete routing intent set of this AS. For a given asID, it is RECOMMENDED that a CA maintains a single Forwarding Commitment. If an AS holder publishes a Forwarding Commitment, 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 which cannot match any routing intents 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 FCs.¶

7. IANA Considerations

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

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

Name       | OID                         | Specification
----------------------------------------------------------------
Forwarding |                             |
Commitment | 1.2.840.113549.1.9.16.1.TBD | [RFC-to-be]

Filename  |
Extension | RPKI Object                   | Reference
-----------------------------------------------------------------
     .for | Forwarding Commitment         | [RFC-to-be]

  Type name: application
  Subtype name: rpki-fc
  Required parameters: N/A
  Optional parameters: N/A
  Encoding considerations: binary
  Security considerations: Carries an RPKI FC [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): .for
    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

TODO acknowledge.¶

Authors' Addresses