]> Tsinghua University

Beijing China xuke@tsinghua.edu.cn

ZGC Laboratory

Beijing China jiangshl@zgclab.edu.cn

ZGC Laboratory

Beijing China guoyangfei@zgclab.edu.cn

Tsinghua University

Beijing China wangxiaoliang0623@foxmail.com

SIDR Operations The Forwarding Commitment (FC) is an RPKI object that attests to the complete routing intents description which an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an FC-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 FC can help address and provides operational considerations associated with FC deployment. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SIDR Operations mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Border Gateway Protocol (BGP) is vulnerable to route hijacks and route leaks . Some existing BGP extensions can partially solve or alleviate these problems. Resource Public Key Infrastructure (RPKI) based route origin validation (RPKI-ROV) and Signed Prefix List-based Route Origin Verification (SPL-ROV) can be used to detect and filter accidental mis-originations. BGPsec is designed to provide security for the AS-path attribute in the BGP UPDATE message . and Autonomous System Provider Authorization (ASPA) aim at detecting and mitigating accidental route leaks. However, there are still some issues that need to be addressed. ASPA is a genius mechanism to verify BGP AS-path attribute content, which only stores customer-to-provider information in RPKI. Autonomous System Relationship Authorization (ASRA) has listed several security problems with ASPA in . Though the validity of the ASPA/ASRA objects is verified, the relationship between two BGP neighbors cannot be attested. When two ASes announce mutually exclusive relationships, for example, AS A says AS B is its Provider and AS B says AS A is its Provider, no other ASes can verify their real relationships. The Forwarding Commitment (FC) is a Resource Public Key Infrastructure (RPKI) object that attests to the complete routing intents description an Autonomous System (AS) would obey in Border Gateway Protocol (BGP) route propagation. This document specifies an FC-based AS Path Verification methodology to prevent AS path forgery in the BGP AS-path attribute of advertised routes. FC-based AS_PATH verification also detects and mitigates route leaks.

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.

Definition of Commonly Used Terms The definitions and semantics of Forwarding Commitment (FC) provided in are applied here.

• Route is ineligible: The term has the same meaning as in , i.e., "route is ineligible to be installed in Loc-RIB and will be excluded from the next phase of route selection."
• AS-path: This term defines a sequence of ASes listed in the BGP UPDATE AS_PATH or AS4_PATH attribute. In this document, the terms AS-path, AS_PATH, and AS4_PATH are interchangeably used.
• TotallyValid: This is one of the verification results of using FC objects to verify AS_PATH. This means the FCs of each AS in AS_PATH are all with the 'originASes' field.
• VFP: Validated FC Payload (see ).

Forwarding Commitment (FC) Forwarding Commitment (FC) objects encapsulate the routing intent description of an Autonomous System (AS). Unlike most RPKI-signed objects, FC objects possess a distinct design regarding verification results. Since FC objects reference Route Origin Authorizations (ROAs) within their content, the verification outcomes for FC are categorized into four distinct states: TotallyValid, Valid, Invalid, and Unknown. It is RECOMMENDED that all routing intents be explicitly enumerated within a single FC object. However, due to the inherent complexity of routing intents, providing a comprehensive list can be challenging. Consequently, it is RECOMMENDED to include routing intents with the originASes field designated as 'NONE' when the issuer is unable to specify which routes will be propagated from previousASes to nexthopASes. It may have a few of these routingIntents with the originASes field set as 'NONE'. In general, there exists a singular valid FC object corresponding to a specific asID. However, in instances where multiple valid FC objects containing the same asID are present, the union of the resulting routingIntent members constitutes the comprehensive set of members. This complete set, which may arise from either a single or multiple FCs, is locally maintained by a Relying Party (RP) or a compliant router. Such an object is referred to as the Validated FC Payload (VFP) for the asID. Except for the empty originASes, there would also be empty previousASes and nexthopASes in a routing intent. It is NOT RECOMMENDED to describe routing intent without nexthopASes as this does not help verify BGP AS_PATH. It is REQUIRED at least one routing intent description in an FC object. Otherwise, the empty FC object means no routes can be transited or transformed from this asID.

BGP AS_PATH Verification Algorithm Using FC FCs describe the local routing intents of an AS. It can be used to verify the AS-path attribute in the BGP UPDATE message. Before the AS_PATH verification procedure, it can first perform prefix origin verification with ROA-ROV defined in or SPL-ROV defined in . An eBGP router that conforms to this specification MUST implement FC-based AS_PATH verification procedures specified below. For each received BGP route:

1. Query all the FCs that are issued by the ASes that are in the AS-path attribute;
2. If all ASes on the AS-path have their FCs with the BGP AS-path conforming to all ASes routing intents and the route is also specified in the originASes field, the verification result is TotallyValid;
3. Else, if the originASes field is missing but all ASes on the AS-path have their FCs with the BGP AS-path conforming to all ASes routing intents, the verification result is Valid;
4. Else, if none of the AS on the AS path has its FC, the verification result is Unknown;
5. Else, if some of the ASes on the AS path have their FCs but others ASes do not have their FCs, the verification result is Invalid.

Mitigation Policy The specific configuration of a mitigation policy based on AS_PATH verification using FC is at the discretion of the network operator. However, the following mitigation policy is highly recommended. Invalid: If the AS_PATH is determined to be Invalid, then the route SHOULD be considered ineligible for route selection and MUST be kept in the Adj-RIB-In for potential future re-evaluation (see ). TotallyValid, Valid, or Unknown: When a route is evaluated as Unknown (using FC-based AS_PATH verification), it SHOULD be treated at the same preference level as a route evaluated as Valid. But TotallyValid has the highest priority in BGP route selection while Valid has a second priority.

Operational Considerations 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.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References 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] 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. 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 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 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. Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. Zhongguancun Laboratory Tsinghua University Tsinghua University Tsinghua University Tsinghua University This document defines a Cryptographic Message Syntax (CMS) protected content type for Forwarding Commitments (FCs) objects used in Resource Public Key Infrastructure (RPKI). An FC 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 FC's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. Yandex JetLend Internet Initiative Japan Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA 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 providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. Fastly 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. USA National Institute of Standards and Technology Fastly USA National Institute of Standards and Technology The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. Huawei NIST Zhongguancun Laboratory This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA 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 customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA. 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 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 recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. This document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and RPKI-based Route Origin Validation (RPKI-ROV) in the context of destination-based Remotely Triggered Discard Route (RTDR) (elsewhere referred to as "Remotely Triggered Black Hole") filtering are also highlighted. A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.

Acknowledgments TODO acknowledge.