]> 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

Routing Secure Inter-Domain Routing BGP Security Inter-Domain Forwarding This document defines a standard profile for the framework of Forwarding Commitment BGP (FC-BGP). Forwarding Commitment（FC）is a cryptographically signed code to certify an AS's routing intent on its directly connected hops. Based on FC, the goal of FC-BGP is to build a secure inter-domain system that can simultaneously authenticate AS_PATH attribute in BGP-UPDATE and validate network forwarding on the dataplane. 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 Secure Inter-Domain Routing Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The fundamental cause of the path manipulation attacks in Internet inter-domain routing is that the de facto Border Gateway Protocol (BGP) does not have built-in mechanisms to authenticate routing announcements. As a result, an adversary can announce virtually arbitrary paths to a prefix while the network cannot effectively verify the authenticity of the route announcements. In addition to the lack of control plane authentication, ensuring that the actual forwarding paths in the dataplane comply with the control plane decisions is also missing in today's inter-domain routing system. This fundamentally limits ASes from filtering unwanted traffic which takes an unauthorized AS path. The representative schemes to secure inter-domain routing are RPKI and BGPsec . RPKI provides a foundation for validating the origins of BGP routes. Meanwhile, BGPsec directly builds the path authentication of BGP routes into the BGP path construction itself, where an AS is required to iteratively verify the signatures of each prior AS hop before extending the verification chain with its own approval. As a result, a single legacy or malicious AS can terminate the verification chain, preventing the downstream ASes from reinstating the verification process. This creates the well-known chicken-and-egg problem where the early adopters receive no deployment benefits which further limits new adoption. Finally, due to the lack of practical protocols to check the consistency between the dataplane forwarding and control-plane decisions, enforcing path authorization in the inter-domain forwarding has been not possible to date. This document specifies a framework named FC-BGP, an incrementally deployable security augment to the Internet inter-domain routing and forwarding. FC-BGP relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to the allocation of AS number and IP address resources. To support FC-BGP, a BGP speaker needs to possess a private key associated with an RPKI router certificate that corresponds to the BGP speaker's AS number.

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.

Overview

Overview of FC-BGP. | Control | ^ | | Plane | 1.1 | | 1.2 | | Generation | v Validation | +----+---+ +-+----------+ +----+---+ | | | Forwarding | | | | AS A | | Commitment | | AS B | | | | (FC) | | | +----+---+ +----------+-+ +----+---+ | ^ | | Data | 2.2 | | 2.1 | Plane | Validation | | Binding | | | v | |<-----------+-----------------------+ | 2.Forwarding Path | ]]>

Overview of FC-BGP is shown in . The key primitive in FC-BGP is the Forwarding Commitment (FC), which is a publicly verifiable code that certifies an AS's routing intent on one of its directly connected hops, i.e., an FC indicates whether the AS is willing to carry traffic for a specific prefix over the hop. Upon receiving a BGP announcement, if AS A decides to accept the route and extends the path to its (selected) neighbors AS B, the AS A commits its routing intent by generating a cryptographically-signed FC. Therefore, downstream on-path ASes (such as AS B) can validate the correctness of a BGP update by checking the FCs associated with the individual hops on the AS-path. Because the FCs are designed to be hop-specific and path-agnostic, a deployed AS can immediately certify its routing intent regardless of the deployment status of other ASes. This is fundamentally different from existing path-level BGP authentication protocol (e.g., BGPsec) where an on-path AS cannot approve any form of routing intent unless all on-path ASes are upgraded. FC-BGP is not bound to a specific FC propagation method and can use, but is not limited to, the following mechanisms:

1. Extend BGP Update Message. Assign a new BGP Update Path Attribute to carry FCs.
2. Propose a new propagation protocol that guarantees consistent FC propagation.
3. Use existing network infrastructure, such as extending RPKI to add a new signed object to store FCs.

Meanwhile, the flexibility of FCs further enables efficient forwarding validation on the dataplane. Specifically, because the FCs are self-proving, an AS can conceptually construct a certified AS-path using a list of consecutive per-hop FCs, and then binds its network traffic (identified by < src-AS, dst-AS, prefix >) to the path, such as < AS B, AS A, P(B) >, where P(B) is the prefix owned by AS B destined to AS A. This binding information essentially defines the authorized forwarding path for the traffic < AS B, AS A, P(B) >. Therefore, by advertising the binding information globally, both on-path and off-path ASes are aware of the desired forwarding paths so that they can collaboratively discard unwanted traffic that takes unauthorized paths. Similar to FC propagation, the propagation of binding messages in FC-BGP is not restricted to specific methods and can be, but is not limited to, the following:

1. Propose a new propagation protocol that guarantees the consistency of binding messages.
2. Use existing network infrastructure, such as extending RPKI to add a new signed object to store binding messages.

Forwarding Commitment FC-BGP enhances the security of inter-domain routing and forwarding by building a publicly verifiable view on the forwarding commitments. At a high-level, a routing commitment (FC) of an AS is a cryptographically-signed primitive that binds the AS's routing decisions (e.g. willing to forward traffic for a prefix via one of its directly-connected hops). With this view, ASes are able to:

1. Evaluate the authenticity (or security) of the control plane BGP announcements based on committed routing decisions from relevant ASes.
2. Ensure that the dataplane forwarding is consistent with the routing decisions committed in the control plane.

Upon receiving a BGP announcement, an upgraded AS generates a corresponding FC that contains the core information of the announcement, such as prefixes, sending AS and receiving AS, and will be signed with the sender's private key for security. See draft XXX for specific structure of FC.

BGP Path Validation

Example of FC-BGP. +-------------------->+-------------------->| | | | | | | | | | | | | +----+---+ +----+---+ +----+---+ +----+---+ | AS A +-------------+ AS B +------------+ AS C +------------+ AS D | +----+---+ +----+---+ +----+---+ +----+---+ | | | | | F(B,C,D,P)-(src:P(D),dst:P(A))+<--------------------+ | | | | | | | | | +<--------------------+---------------------+ | | F(A,B,C,P)-(src:P(D),dst:P(A)) | | | | | | | | | |<---------------------+---------------------+---------------------+ F(Null,A,B,P)-(src:P(D),dst:P(A)) ]]>

Consider an illustrative example using the four-AS topology shown in . In this process, FC-BGP generates the corresponding FC and propagates to downstream ASes (e.g., adding it to the Path Attributes of the BGP updates), so that the receiving AS can validate the authenticity of the announcement. Suppose AS C receives a BGP announcement P(A): A->B->C from its neighbor B. If AS C decides to further advertise this path to its neighbor D based on its routing policy, it generates a FC F(B,C,D,P), propagates it to AS D, and forwards the BGP update message to D. When AS D receives the route from C, it can determine the authenticity of the current AS path by verifying the list of FCs correctly reflects the AS path.

Forwarding Validation AS shown in , to enable forwarding validation, ASes need to announce the traffic-FCs binding relationships. Specifically, suppose AS D confirms that the AS-path C->B->A for reaching prefix P(A) is legitimate, it binds the traffic (src:P(D),dst:P(A)) (where P(D) is the prefix owned by AS D) with the FC list F(B,C,D,P)-F(A,B,C,P)-F(Null,A,B,P), and then publicly announces the binding relationship. Upon receiving the relationship, other ASes can build traffic filtering rules based on the relationship to enable forwarding validation on dataplane. For instance, by interpreting the binding relationship produced by AS D, AS C confirms that the traffic (src:P(D), dst:P(A)) shall be forwarded over the link L(CD), and AS B confirms that the traffic shall be forwarded on link L(BC). Network traffic violating these binding rules is considered to take unauthorized paths. To enable network-wide forwarding verification, these binding rules may be further broadcast globally (instead of just informing the ASes on the AS-path) so that off-path ASes can also discard unauthorized flows.

Security Considerations TBD

IANA Considerations This document has no IANA actions.

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 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 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. 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). 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.