WG Working Group H. Huang Internet-Draft K. Xu Intended status: Informational X. Wang Expires: 19 May 2025 Tsinghua University 15 November 2024 Forwarding Commitment for Data Plane Verification draft-huang-fc-dataplane-latest Abstract Based on the draft IDxx, Forwarding Commitment (FC) can provide the ability to verify BGP routing updates at the control plane. Meanwhile, the flexibility of FC further enables efficient forwarding validation at the data plane. 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 to the path. Therefore, by advertising the binding message globally, both on-path and off-path ASes are aware of the desired forwarding paths. They can collaboratively discard the unwanted traffic that takes an unauthorized path. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-huang-fc- dataplane/. Discussion of this document takes place on the WG Working Group mailing list (mailto:WG@example.com), which is archived at https://example.com/WG. Source for this draft and an issue tracker can be found at https://github.com/USER/REPO. 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 19 May 2025. 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 2. Conventions and Definitions 3. Data Plane Validation 3.1. Overview 3.2. Binding Message 3.2.1. Version 3.2.2. Flags 3.2.3. FC Version 3.2.4. FC Subversion 3.2.5. FC List Size 3.2.6. Reserved 3.2.7. Source AS Number and Destination AS Number 3.2.8. FC List 3.2.9. Source Prefix and Destination Prefix 3.3. Filtering Table 3.4. On-path And Off-path Validation 4. Security Considerations 5. IANA Considerations 6. Normative References Acknowledgments Authors' Addresses 1. Introduction Based on the FC list received at the control plane, the source AS, which is the destination of the BGP-UPDATE message and the start point of the traffic, notifies the on-path ASes, which are on the propagation path of the BGP-UPDATE message, with the established traffic and forwarding path mappings through binding messages before forwarding traffic. With binding messages, on-path nodes establish corresponding filtering tables for traffic and forwarding paths, completing the verification of the forwarding path while filtering out illegal traffic. In addition, the source AS MUST broadcast binding messages to off-path ASes. These off-path ASes SHOULD collaboratively filter out traffic that is not allowed according to the binding messages and this traffic may be performed with source spoofing or path manipulation. Through the collaboration of on-path and off-path nodes, the verification of traffic forwarding paths is completed together. The key advantage of this off-path collaborative filtering is that it is completely location-independent, i.e., the off-path filtering is effective no matter how far is it between the filtering AS and the actual on-path ASes, and no matter how many legacy regions are between them. This document primarily explains how a BGP speaker that supports FC- BGP can utilize the FC list to finish path verification. It mainly elaborates on the process of generating binding messages, establishing filtering tables based on the FC list, and verifying the forwarding path. Similar to forming FC in the control plane, we still assume the existence of an RPKI repository [RFC6480] that contains ownership relationships between AS number and valid IP prefixes. The public key of each AS can be fetched from the repository. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Data Plane Validation 3.1. Overview Although FC was initially designed to verify BGP announcement in the control plane, the key insight into the applicability of FCs in the data plane is that the correctness of a forwarding path can be verified based on the carried FC list. Before forwarding traffic, the source AS needs to send binding messages containing the FC list to on-path ASes. The nodes deployed FC-BGP will establish filtering tables based on the FC list and filter out illegal traffic. In addition, the source also broadcasts the source and destination prefixes of traffic verified by FC to off-path nodes to facilitate their collaborative verification. As shown in Figure 1, the source AS C needs to forward traffic to AS A. AS C sends binding messages containing the FC list to on-path nodes AS A and AS B, and A and B establish filtering tables. AS C sends a binding message that does not carry the FC list to the off- path node AS E. Thus AS E SHOULD drop received traffic from AS C to AS A. But if AS E is in another AS-path which corresponds traffic from AS C to AS A, e.g. to do load balance or as a backup link, AS E MUST keep forwarding this traffic. off-binding AS E----<----- \ \ AS A-----------AS B-----------AS C ^ ^ | | on-binding | on-binding v ------<---------------<------+ Figure 1: Overview 3.2. Binding Message As mentioned in the previous section, both on-path and off-path nodes receive binding messages as credentials for verification and filtering, with the difference being the presence of an FC list. Based on the FC information received at the control plane, we construct the binding message formats as shown in Formulas (1) and (2), respectively. Monpath = {Psrc,Pdst,FClist, Ver,Versub}_Sigsrc --- (1) Moffpath = {Psrc,Pdst,Ver,Versub}_Sigsrc --- (2) TODO AS A PROTOCOL SPECIFICATION, IT SHOULD USE THE ASCII FORMAT TO DESCRIBE BINDING MESSAGES AND FORWARDING COMMITMENT INSTEAD OF FORMULA. And with these formats, one can implement FC and BM mechanisms independently. The following is a sample and many many details are ignored. Need to be reviewed and discussed. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Prefix Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Prefix Format AFI: 8-bit field. Address Family Identifier. The value is 1 for IPv4 and 2 for IPv6. Prefix Size: 8-bit field. It indicates the number of prefixes with the following Length and Prefix format. Length: 8-bit field. The length of the IP prefix with Prefix. Prefix: variable length field. It defines the IP prefix owned by one AS. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | FC Version | FC Subversion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FC List Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FC List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Binding Message Format 3.2.1. Version The Version is an 8-bit field. It defines the version of the Binding Message Format. Here the version is 0. 3.2.2. Flags The Flags is an 8-bit field. The first bit of Flags indicates whether this is an on-path Binding Message or an off-path Binding Message. If it is 0, it means this is an on-path Binding Message and it MUST carry the FC List field. Otherwise, it means this is an off- path Binding Message and it MUST NOT carry the FC List field and the FC List size MUST be 0. Other bits of Flags are not defined and MUST be 0. 3.2.3. FC Version TODO The FC Version is an 8-bit field. It defines the major version of this Binding Message. 3.2.4. FC Subversion TODO The FC Subversion is an 8-bit field. It defines the minor version of this Binding Message. 3.2.5. FC List Size The number of FC in the FC List. It occupies 2-octet. 3.2.6. Reserved It occupies 2-octet and MUST be 0. 3.2.7. Source AS Number and Destination AS Number This indicates the direction of traffic. They are all 4-octet fields. 3.2.8. FC List This is a list of ASes that are all on-path nodes that deployed FCBGP and chosen to forward the traffic from Source AS to Destination AS. So it is a variable field and the length is dependent on FC List Size. 3.2.9. Source Prefix and Destination Prefix They are both variable fields. These are the prefixes belonging to source AS and destination AS separately. They are using the format defined in Figure 2. They both include source and destination prefixes to distinguish different flows. In the on-path binding message, the FC list received at the control plane is included, representing the valid path for the current flow. In addition, both binding messages also include version number information to keep binding messages consistent, referring to draft IDxx. Each binding message is signed using the private key of the source AS and decrypted by the receiving node. 3.3. Filtering Table For an AS that has deployed FC-BGP, when it receives a binding message and completes the verification, it will establish a filtering table. For example, if AS A receives the following binding message: Monpath = {Psrc,Pdst,F{A,B,P}--F{B,C,P}, Ver,Versub}_Sigsrc --- (3) AS A will bind the filtering message at the inbound of the link and construct the filtering table in the following form, specifying traffic with the source belonging to Psrc and the destination belonging to Pdst to enter the A-B link. ------------------------- ------------------------- | traffic | port | | traffic | port | ------------------------- ------------------------- | src->dst | port1(A-B) | | src->dst | port1(B-C) | ------------------------- ------------------------- filtering table for AS A filtering table for AS B Figure 4: On-path AS filtering table Please note that in a filter table, the port indicated is the one that received the binding message, assuming that the FC propagation path and the traffic forwarding path are symmetric. For an off-path AS, it will directly discard the traffic, regardless of which entrance it comes from. ----------------------- | traffic | action | ----------------------- | src->dst | drop | ----------------------- Figure 5: Off-path AS filtering table 3.4. On-path And Off-path Validation TODO YOU SHOULD EXPLAIN THE FORMAT OF and {F{C,D,P};F{B,C,P};F{A,B,P}}. For the purpose of illustration, we provide a comprehensive example to explain the entire process described above. Suppose that the source AS D needs to forward traffic to AS A, it implies to all on-path and upgraded ASes (i.e., A and C) that the network traffic (Pd represents the prefix owned by D) shall take the forwarding path D->C->B->A. To make this implicated forwarding path explicit, AS D can send the FC list (i.e., {F{C,D,P};F{B,C,P};F{A,B,P}}) to AS A and C. Afterwards, AS C confirms that the traffic must inbound using the hop D->C, and AS A confirms the traffic must inbound via the hop B->A. The forward binding can be extended to off-path ASes to enable large- scale traffic filtering. In particular, in Figure 4, AS D can broadcast the binding relationship for traffic to off- path ASes. As a result, all off-path ASes only learn that they should not expect to serve traffic , instead of learning the actual forwarding path for the traffic. off-path ASes may receive traffic due to either source spoofing or path manipulation. In both cases, they can discard these flows based on the binding message received from AS D. ---------------------------- | Bing Message Broadcast | | Moffpath | ---------------------------- | Psrc:20.0.0.0/24 | | Pdst:10.0.0.0/24 | | Ver:1.0 | | Versub:0 | ---------------------------- off-path ASes <------<-----+ collaborative defense \ ^ | | | v ^ +-------------------+ | 10.0.0./24 | Undeployed | 20.0.0.0/24 AS A -----------|--AS B Zone --|--AS C-----AS D | | | | | ^ +-------------------+ ^ | | | | +----------<---------------<---------------<------+ ---------------------------- | Bing Message Broadcast | | Monpath | ---------------------------- | Psrc:20.0.0.0/24 | | Pdst:10.0.0.0/24 | | FClist:F{A,B,P}-F{C,D,P} | | Ver:1.0 | | Versub:0 | ---------------------------- Figure 6: A comprehensive example for path validation 4. Security Considerations TODO Security 5. IANA Considerations This document has no IANA actions. TODO If you need a TCP port to transfer/receive these binding messages, you would need IANA to assign one. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgments TODO acknowledge. Authors' Addresses Hanlin Huang Tsinghua University Beijing China Email: hhl21@mails.tsinghua.edu.cn Ke Xu Tsinghua University Beijing China Email: xuke@tsinghua.edu.cn Xiaoliang Wang Tsinghua University Beijing China Email: wangxiaoliang0623@foxmail.com