Framework of Forwarding Commitment BGP

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 18 October 2024.¶

Copyright Notice

Copyright (c) 2024 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 fundamental cause of the path manipulation attacks in Internet inter-domain routing is that the de facto Border Gateway Protocol (BGP) [RFC4271] 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 data plane comply with the control plane decisions is also missing in today's inter-domain routing system. This fundamentally limits ASs from filtering unwanted traffic that takes an unauthorized AS-Path.¶

The representative schemes to secure inter-domain routing are RPKI [RFC6480] and BGPsec [RFC8205]. RPKI provides a foundation for validating the origins of BGP routes by Route Origin Authorization [RFC6482]. The Validated ROA Payload will be sent to the BGP router by RTR protocol [RFC6810]. The details can refer to BGP Prefix Origin Validation [RFC6811]. Meanwhile, BGPsec directly builds the path authentication of BGP routes into the BGP path construction itself, where an AS must 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 ASs from reinstating the verification process. This creates the well-known chicken-and-egg problem where early adopters receive no deployment benefits, further limiting new adoption.¶

Finally, due to the lack of practical protocols to check the consistency between the data plane forwarding and control-plane decisions, enforcing path authorization in the inter-domain forwarding has been not possible to date.¶

This document specifies the framework of a mechanism named FC-BGP, an incrementally deployable security augment to the Internet inter-domain routing and forwarding. The FC-BGP protocol specification is out of the scope of this document.¶

2. Overview

Overview of FC-BGP is shown in Figure 1. The key primitive in FC-BGP is the Forwarding Commitment (FC), which is a publicly verifiable segment 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.¶

          |   1. BGP Route Announcement Path   |
          +---------------------+------------->|
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. Traffic Forwarding Path     |

FC-BGP relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to the allocation of AS number and IP address resources, as well as ASs' public keys or BGP router certificates, which we have omitted in Figure 1. To support FC-BGP, a BGP speaker MUST possess a private key associated with an RPKI router certificate that corresponds to the BGP speaker's AS number. That means FC-BGP will directly use the key/certificate generation, management, rollover, and revocation from BGPsec [RFC8209] [RFC8608] [RFC8634] [RFC8635].¶

But for simplification, we treat the AS as a single entity in this document, regardless of the number of BGP routers it contains. This means that the internal operations of the AS, such as the number of BGP routers and the specific paths within the AS, are not relevant to the FC processing. Namely, the FC is not intended to be processed within the AS itself (intra-domain).¶

Take the Figure 1 as an example, upon receiving a BGP route announcement, if AS A decides to accept the route and extends the path to its (selected) neighbor AS B, AS A commits its routing intent by generating a cryptographically signed FC. Therefore, downstream on-path ASs (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 ASs. 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 ASs are upgraded.¶

FC-BGP is not bound to a specific FC propagation method and can use, but is not limited to, the following mechanisms:¶

• Extend BGP UPDATE Message. Assign a new BGP UPDATE Path Attribute to carry FCs.¶

• Propose a new propagation protocol that guarantees consistent FC propagation.¶

• 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 data plane. 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 bind 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 ASs 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:¶

• Propose a new propagation protocol that guarantees the consistency of binding messages.¶

• Use existing network infrastructure, such as extending RPKI to add a new signed object to store binding messages.¶

3. Forwarding Commitment

FC-BGP enhances the security of inter-domain routing and forwarding by building a publicly verifiable view on the forwarding commitments (FC).¶

At a high level, an 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, ASs are able to:¶

• evaluate the authenticity (or security) of the control plane BGP announcements based on committed routing decisions from relevant ASs;¶

• and ensure that the data plane forwarding is consistent with the routing decisions committed in the control plane.¶

At a low level, upon receiving a BGP announcement, an upgraded AS generates a corresponding FC that contains the core information of the announcement, such as prefixes, previous AS number, current AS number, nexthop AS number, etc., and will be signed with the sender's private key for security. We will discuss the design of three AS numbers in Section 6.2.¶

4. BGP Path Validation

                                                     FClist:F(B,C,D,P)
                                  FClist:F(A,B,C,P)   F(A,B,C,P)
       FClist:F(Null,A,B,P)       F(Null,A,B,P)       F(Null,A,B,P)
     | AS Path:A            |     AS Path:A-B     |    AS Path:A-B-C    |
     +--------------------->+-------------------->+-------------------->|
     |                      |                     |                     |
     |                      |                     |                     |
     |                      |                     |                     |
+----+---+             +----+---+            +----+---+            +----+---+
|  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 Figure 2. In this process, FC-BGP generates the corresponding FC and propagates it to downstream ASs (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 an 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.¶

5. Forwarding Validation

As shown in Figure 2, to enable forwarding validation, ASs 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(k) is the prefix owned by AS k) 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 the data plane. 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.¶

6. Security Considerations

7. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses