Internet-Draft FCDP Verification November 2024
Huang, et al. Expires 19 May 2025 [Page]
Workgroup:
WG Working Group
Internet-Draft:
draft-huang-fc-dataplane-latest
Published:
Intended Status:
Informational
Expires:
Authors:
H. Huang
Tsinghua University
K. Xu
Tsinghua University
X. Wang
Tsinghua University

Forwarding Commitment for Data Plane Verification

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.

▲

Table of Contents

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 <src:Pd,dst:P> 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 <src:Pd,dst:P> to AS A, it implies to all on-path and upgraded ASes (i.e., A and C) that the network traffic <src:Pd,dst:P> (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 <src:Pd,dst:P> 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 <src:Pd,dst:P> to off-path ASes. As a result, all off-path ASes only learn that they should not expect to serve traffic <src:Pd,dst:P>, instead of learning the actual forwarding path for the traffic. off-path ASes may receive traffic <src:Pd,dst:P> 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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/rfc/rfc4271>.
[RFC6480]
Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, , <https://www.rfc-editor.org/rfc/rfc6480>.
[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, , <https://www.rfc-editor.org/rfc/rfc6483>.
[RFC6811]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, , <https://www.rfc-editor.org/rfc/rfc6811>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Hanlin Huang
Tsinghua University
Beijing
China
Ke Xu
Tsinghua University
Beijing
China
Xiaoliang Wang
Tsinghua University
Beijing
China