]> Tsinghua University

Beijing China xuke@tsinghua.edu.cn

Tsinghua University

Beijing China wangxiaoliang0623@foxmail.com

Tsinghua University

Beijing China zhuotaoliu@tsinghua.edu.cn

Tsinghua University

Beijing China qli01@tsinghua.edu.cn

Tsinghua University

Beijing China jianping@cernet.edu.cn

Zhongguancun Laboratory

Beijing China guoyangfei@zgclab.edu.cn

Tsinghua University

wjs24@mails.tsinghua.edu.cn

Routing Inter-Domain Routing next generation unicorn sparkling distributed ledger This document specifies a mechanism for embedding a new path attribute, known as the FC path attribute, into BGP UPDATE messages. The FC (Forwarding Commitment) is a cryptographically signed object to certify an AS's routing intent on its directly connected hops. By incorporating the FC path attribute into BGP UPDATE messages. This mechanism provides enhanced route authenticity and lays the groundwork for improved data-plane forwarding verification. This mechanism is backward compatible, which means a router that supports the attribute can interoperate with a router that doesn't, allowing partial deployment across the Internet. 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 This document describes the FC path attribute, a new attribute for providing path security for Border Gateway Protocol (BGP) route advertisements. That is, a BGP speaker who receives a valid BGP UPDATE message with FC path attribute has the following property: every Autonomous System (AS) on the path of ASes listed in the UPDATE message with a corresponding FC has explicitly authorized the advertisement of the route from the former AS to the subsequent AS in the path. This allows verification of the AS path in the BGP UPDATE messages and data-plane forwarding. The FC path attribute is an optional and transitive BGP path attribute. This attribute can be used by a BGP speaker supporting it to generate, propagate, and validate BGP UPDATE messages containing this attribute to obtain the above assurances. An FC path attribute consists mainly of one or multiple Forwarding Commitments (FC). The FC path attribute is intended to be used to supplement BGP origin validation . As the AS_PATH attribute is preserved, and each Forwarding Commitment (FC) is a publicly Verifiable code certifying the correctness of a three-hop pathlet, the FC path attribute can provide More security than BGPsec in the case of partial deployment. The FC path attribute needs to be associated with an additional mechanism for providing the distribution of AS numbers and managing keys. The Resource Public Key Infrastructure (RPKI) is one of the options.

Conventions and Definitions 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 FC Path Attribute The FC path attribute is an optional and transitive BGP path attribute within the BGP UPDATE message. BGP speakers do not recognize the FC path attribute SHOULD still transmit this attribute to their neighbors. AS a result, there is no need to establish a new BGP capability as defined in . The FC path attribute consists mainly of one or multiple Forward Commitments (FC). The FC carries the secured information regarding the intent of an AS to propagate the route between neighboring ASes, and includes the digital signature used to protect the information. The FC path attribute is independent and doesn't affect other attributes in the BGP UPDATE message. Although the FC path attribute would not modify the AS_PATH path attribute, it is REQUIRED to never use the AS_SET or AS_CONFED_SET according to .

Forwarding Commitment A detailed description of the Forwarding Commitment information in the FC path attribute is provided here. The specification for the Forwarding Commitment is provided in .

The structure of Forwarding Commitment(FC)

In the FC path attribute, all ASs MUST use 4-byte AS numbers in FC segments. Existing 2-byte AS numbers are converted into 4-byte AS numbers by setting the two high-order octets of the 4-octet field to 0 . FC segment includes the following parts.

Previous Autonomous System Number (PASN, 4 octets):

The PASN is the AS number of the previous hop AS from which the BGP speaker receives the BGP UPDATE message. If the current AS has no previous AS hop, it MUST be filled with 0.

Current Autonomous System Number (CASN, 4 octets):

The CASN is the AS number of the BGP speaker that added this FC segment to the FC path attribute.

Nexthop Autonomous System Number (NASN, 4 octets):

The NASN is the AS number of the next hop AS to which the BGP speaker will send the BGP UPDATE message.

Subject Key Identifier (SKI, 20 octets):

The SKI is a unique identifier for the public key used for signature verification. If the SKI length exceeds 20 octets, it should retrieve the leftmost 20 octets.

Algorithm ID (1 octet):

The current assigned value is 1, indicating that SHA256 is used to hash the content to be signed, and ECDSA is used for signing. It follows the algorithm suite defined in and its updates. Each FC segment has an Algorithm ID, so there is no need to worry about sudden changes in its algorithm. The key in FC-BGP uses the BGPsec Router Key, so its generation and management follow .

Flags (1 octet):

Several flag bits. The leftmost bit of the Flags field is the Confed_Segment flag (Flags-CS). The Flags-CS flag is set to 1 to indicate that the BGP speaker that constructed this FC segment is sending the UPDATE message to a peer AS within the same AS confederation . In all other cases, the Flags-CS flag is set to 0. The second leftmost bit (i.e., the second highest) of the Flags field is the Route_Server flag (Flags-RS). The Flags-RS flag is set to 1 to indicate that a route server adds this FC segment, but the AS number will never appear in the AS_PATH attribute. If the AS number of a router server is inserted into AS_PATH, this Flags-RS flag MUST be set to 0. The third leftmost bit (i.e., the third highest) of the Flags field is the Only_to_Customer flag (Flags-OTC). The Flags-OTC flag is set to 1 to indicate that the FC segment's issuer AS sends routes to its customer or peer. If this Flags-OTC flag is set, the next route propagation will only be permitted to the following customers. The remaining 5 bits of the Flags field are unassigned. They MUST be set to 0 by the sender and ignored by the receiver.

Signature Length (2 octets):

It only contains the length of the Signature field in octets, not including other fields.

Signature (variable length):

The signature content and order are Signature=ECDSA(SHA256(PASN, CASN, NASN, Prefix, Prefix Length)), where the Prefix is the IP address prefix which is encapsulated in the BGP UPDATE, i.e., NLRI, and only one prefix is used each time. When hashing and signing, the full IP address and IP prefix length are used, i.e., IPv4 uses 4 octets and IPv6 uses 16 octets.

FC Path Attribute A detailed description of the FC Path Attribute is provided here. The FC path attribute is in Type-Length-Value format. The specification for the FC Path Attribute is provided in .

FC Path Attribute Structure

Flags (1 octet):

The FC path attribute is an optional, transitive, and extended-length path attribute.

Type (1 octet):

The current value is TBD.

FCList Length (2 octets):

The value is the total length of the FCList in octets.

FCList (variable length):

The value is a sequence of FC segments in order.

The FC Path Attribute in BGP UPDATE Messages specifies how a BGP speaker supporting the FC path attribute generates or modifies the FC path attribute in a BGP UPDATE message. specifies how a BGP speaker supporting the FC path attribute processes a BGP UPDATE message containing the FC path attribute upon receiving it.

Constructing the FC Path Attribute A BGP speaker supporting the FC path attribute SHOULD generate a new FC segment or even a new FC path attribute when it propagates a route to its external neighbors. For internal neighbors, the FC path attribute message remains unchanged. The information protected by the signature on an FC path attribute includes the AS number of the peer to whom the UPDATE message is being sent. Therefore, if a BGP speaker supporting FC wishes to send a BGP UPDATE message to multiple BGP peers, it MUST generate a separate BGP UPDATE message containing the FC path attribute for each unique peer AS to whom the UPDATE message is sent. The BGP speaker supporting the FC path attribute follows a specific process to create the attribute for the ongoing UPDATE message. Firstly, it generates a new FC segment. If there is already an existing FC path attribute, the speaker MUST prepend the new FC segment to the FCList. Otherwise, the speaker generates the FC path attribute and inserts it into the UPDATE message. There are three AS numbers in one FC segment. The Previous AS number (PASN) is typically set to the AS number from which the UPDATE message receives. However, if the speaker is located in the origin AS, the PASN SHOULD be filled with 0. The Nexthop AS number (NASN) is set to the AS number of the peer to whom the route is advertised. So if there are several neighbors, the speaker SHOULD generate separate FCs for different neighbors. But it would never develop a new FC segment for the iBGP neighbor. The Subject Key Identifier field (SKI) within the new FC segment is populated with the identifier found in the Subject Key Identifier extension of the router certificate associated with the speaker. This identifier enables others to identify the appropriate certificate to employ when verifying signatures in FC segments attached to the router advertisement. Typically, the Flags field is set to 0, but the speaker SHOULD modify it based on section 3.1. The Algorithm ID field is set to 1, and the Signature Length field is populated with the length (in octets) of the value in the Signature field. The Signature field in the new FC segment is a variable-length field. It contains a digital signature encapsulated in DER format that binds the prefix, its length, and triplet (PASN, CASN, NASN) to the RPKI router certificate corresponding to the FC-BGP speaker. The digital signature is computed as follows: Signature=ECDSA(SHA256(PASN, CASN, NASN, Prefix, Prefix Length)).

Processing the FC Path Attribute AS supporting FC path attribute MUST additionally follow the instructions in this section for processing BGP UPDATE messages containing the FC path attribute, after which the speaker can continue advertising the BGP route. As a prerequisite, the recipient SHOULD have access to certificates. First, the integrity of the UPDATE message containing the FC path attribute MUST be checked. The speaker SHOULD check the FC path attribute to ensure that the entire FC path attribute is syntactically correct, the triplet (PASN, CASN, NASN) fields in each FC segment follow the order in AS_PATH, and each FC segment contains one signature with the supported Algorithm ID. If any of the checks for the FC path attribute fail, indicating a syntactical or protocol error, it is considered an error. In such cases, FC speakers are REQUIRED to handle these errors using the "treat-as-withdraw" approach as defined in . Otherwise, the speaker iterates through the FC segments. It SHOULD proceed to validate the signature using the supported algorithm suites. In detail, it SHOULD locate the public key needed to verify the signature in the current segment, compute the digest function, and use the signature validation algorithm to verify the signature in the current segment. If all FC segments are marked as 'Valid', then the validation algorithm terminates and the UPDATE message is deemed 'Valid'. Otherwise, the UPDATE message is deemed 'Not Valid'.

Security Considerations When the FC path attribute is used in conjunction with origin validation, the following security guarantees can be achieved: The source AS in a route announcement is authorized; BGP speakers on the AS path are authorized to propagate the route announcements; The forwarding path of packets is consistent with the routing path announced by the BGP speakers. The FC path attribute is designed to enhance the security of control plane routing in the Internet at the network layer. Specifically, it allows an AS to independently prove its BGP routing decisions with publicly verifiable cryptography commitments, based on which any on-path AS can verify the authenticity of a BGP path. More crucially, the above security guarantees offered by the FC path attribute are binary, i.e., secure or non-secure. Instead, the security benefits are strictly monotonically increasing as the deployment rate of the FC path attribute increases.

Mitigation of Denial-of-Service Attacks The FC path attribute involves numerous cryptographic operations, which makes BGP speakers supporting it vulnerable to Denial-of-Service (DoS) attacks. This section addresses the mitigation strategies tailored for the specific DoS threats. To reduce the impact of DoS attacks, speakers SHOULD employ an UPDATE validation algorithm that prioritizes inexpensive checks (such as syntax checks) before proceeding to more resource-intensive operations (like signature verification). Moreover, the transmission of UPDATE messages with the FC path attribute, which entails a multitude of signatures, is a potential vector for denial-of-service attacks. To counter this, implementations of the validation algorithm must cease signature verification immediately upon encountering an invalid signature. This prevents prolonged sequences of invalid signatures from being exploited for DoS purposes. Additionally, implementations can further mitigate such attacks by limiting validation efforts to only those UPDATE messages that, if found to be valid, would be chosen as the best path. In other words, if an UPDATE message includes a route that would be disqualified by the best path selection process for some reason (such as an excessively long AS path), it is OPTIONAL to include its FC path attribute validity status.

Route Server When the Route Server populates its FC Segment into the FC path attribute, it is secure as the path is fully deployed. When the Route Server fails to insert the FC Segment, no matter whether its ASN is listed in the AS path, it is considered a partial deployment, which poses a risk of path forgery.

Three AS Numbers An FC segment contains only partial path information, and FCs in the FCList are independent. To prevent BGP Path Splicing attacks, we propose to use the triplet (Previous AS Number, Current AS Number, Nexthop AS Number) to locate the pathlet information. But if there is no previous hop, i.e., this is the origin AS that tries to add its FC segment to the BGP UPDATE message, the Previous AS Number SHOULD be populated with 0. But, carefully, AS 0 SHOULD only be used in this case. In the context of BGP , to detect an AS routing loop, it scans the full AS path (as specified in the AS_PATH attribute) and checks that the autonomous system number of the local system does not appear in the AS path. As outlined in , Autonomous System 0 was listed in the IANA Autonomous System Number Registry as "Reserved - May be used to identify non-routed networks". So, there should be no AS 0 in the AS_PATH attribute of the BGP UPDATE message. Therefore, AS 0 could be used to populate the PASN field when no previous AS hops in the AS path.

IANA Considerations This document requires the following IANA actions: This document requests the assignment of a new attribute code described in Section 1 in the "FC Path Attributes" registry. The attribute code for this new path attribute, "FC_PATH", is to provide consistency between the control and data planes. This document is the reference for the new attribute.

Normative 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] The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. This document obsoletes RFC 3065. [STANDARDS-TRACK] This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. [STANDARDS-TRACK] This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice. This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK] To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message. This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure"). This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven. 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.

Acknowledgments TODO acknowledge.