Forwarding Commitment BGP Testbed and Deployment Experience
draft-li-sidrops-fcbgp-experiment-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ke Xu , Xiaoliang Wang , Zhuotao liu , Li Qi , Jianping Wu , Ziwei Li , Yangfei Guo | ||
| Last updated | 2025-06-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-sidrops-fcbgp-experiment-00
Network Working Group K. Xu
Internet-Draft X. Wang
Intended status: Experimental Z. Liu
Expires: 12 December 2025 Q. Li
J. Wu
Tsinghua University
Z. Li
Y. Guo
Zhongguancun Laboratory
10 June 2025
Forwarding Commitment BGP Testbed and Deployment Experience
draft-li-sidrops-fcbgp-experiment-00
Abstract
Forwarding Commitment BGP (FC-BGP) enables the establishment of a
secure inter-domain routing system by providing security for the path
of Autonomous Systems (ASs) through which a BGP UPDATE message
passes. In an effort to enhance the validation of FC-BGP, a
prototype implementation of the FC-BGP was developed and an
evaluation was conducted on the FITI high-performance IPv6 backbone
network. This document reports on the prototype implementation and
the results of the evaluation.
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://FCBGP.github.io/FCBGP-experiment/draft-li-fcbgp-
experiment.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-li-sidrops-fcbgp-
experiment/.
Source for this draft and an issue tracker can be found at
https://github.com/FCBGP/FCBGP-experiment.
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/.
Xu, et al. Expires 12 December 2025 [Page 1]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
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 12 December 2025.
Copyright Notice
Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. A Prototype FC-BGP Implementation . . . . . . . . . . . . . . 3
3.1. FC Generation at the Originating AS . . . . . . . . . . . 4
3.2. FC Verification at the Receiving AS . . . . . . . . . . . 4
3.3. FC Generation at Intermediate ASes . . . . . . . . . . . 5
4. FC-BGP Testbed . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FITI . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. FC-BGP Testbed on FITI Infrastructure . . . . . . . . . . 6
5. Test Experience and Results . . . . . . . . . . . . . . . . . 7
5.1. Test Experience . . . . . . . . . . . . . . . . . . . . . 7
5.2. Test Results . . . . . . . . . . . . . . . . . . . . . . 9
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Xu, et al. Expires 12 December 2025 [Page 2]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
1. Introduction
The current inter-domain routing system lacks a mechanism in BGP to
ensure the authenticity of path attributes announced by an Autonomous
System (AS). This deficiency exposes a broad attack surface and
enables risks such as traffic interception, denial-of-service, and
man-in-the-middle attacks[RFC4272].Forwarding Commitment BGP (FC-BGP)
is a novel forwarding-path verification framework designed to address
these security challenges inherent in today's inter-domain routing
system. By introducing a Forwarding Commitment (FC), FC-BGP offers a
solution that integrates seamlessly with the existing routing
infrastructure. Through the use of FCs to provide a verifiable view
of routing intent, FC-BGP ensures that the actual forwarding path
conforms to declared routing policies.
As part of the development of the Forwarding Commitment BGP (FC-BGP)
framework, we implemented a FC-BGP prototype and deployed the
prototype in the operational networks of 40 Autonomous Systems (ASes)
within the Future Internet Technology Infrastructure (FITI). The
evaluation demonstrates that FC-BGP achieves significant performance
improvements in large-scale network deployments and that even limited
deployment yields substantial security benefits. This document first
describes a FC-BGP prototype solution, then outlines the experimental
environment, and finally presents the experimental results. It is
anticipated that this document will provide useful insights for those
interested in this subject and serve as preliminary input for future
IETF work in this area.
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. A Prototype FC-BGP Implementation
AS(65536) --> AS(65537) --> AS(65538)
\
\--> AS(65539)
Figure 1: An FC-BGP UPDATE propagation example.
This section describes a prototype implementation of FC-BGP, using a
simplified topology as illustrated in Figure 1. Only the essential
operations are highlighted here; readers are referred to
[FC-BGP-Protocol] for the complete protocol specification.
Xu, et al. Expires 12 December 2025 [Page 3]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
In this example, all Autonomous Systems (ASes) are standard ASes;
Route Servers (RSes) and AS Confederations are not considered.
Additionally, no AS Path Protection (ASPP) mechanisms are applied.
For the purposes of discussion, it is assumed that:
1. AS 65536 owns the prefix 192.0.2.0/24.
2. AS 65537 receives an FC-BGP UPDATE message for the prefix
192.0.2.0/24 from AS 65536.
3. AS 65537 then propagates the route to AS 65538 and AS 65539.
An FC-BGP speaker SHOULD propagate an FC-BGP UPDATE message to
downstream ASs only after completing the validation and best route
path selection.
3.1. FC Generation at the Originating AS
When preparing to propagate a route, the FC-BGP speaker in AS 65536
performs the following steps:
1. Constructs the FC segment:
Sets the Previous AS Number (PASN) to 0 (NULL).
Sets the Current AS Number (CASN) to 65536.
Sets the Next AS Number (NASN) to 65537.
2. Computes the signature as follows: Signature=ECDSA(SHA256(PASN,
CASN, NASN, Prefix, Prefix Length)).
3. Constructs the FC Path attribute by embedding the newly generated
FC segment.
4. Encapsulates the route announcement in a BGP UPDATE message and
transmits it to AS 65537.
3.2. FC Verification at the Receiving AS
Upon receiving the UPDATE message, the FC-BGP speaker in AS 65537:
1. Extracts the FC Path attribute.
2. Retrieves the list of FC segments.
3. Identifies the FC segment where CASN == 65536.
Xu, et al. Expires 12 December 2025 [Page 4]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
4. Verifies that:
PASN == 0.
NASN == 65537.
5. Retrieves the corresponding public key using the Subject Key
Identifier (SKI) field.
6. Verifies the signature using the algorithm indicated by the
Algorithm ID field.
If the signature matches, the AS hop from 65536 to 65537 is
considered verified. This process repeats for each FC segment
corresponding to the AS_PATH entries if applicable.
If AS 65537 does not support FC-BGP, its BGP speaker MUST propagate
the UPDATE message without validating the FC Path attribute.
3.3. FC Generation at Intermediate ASes
An FC-BGP speaker MUST generate a distinct UPDATE message for each
downstream neighbor. Each UPDATE message MUST announce only a single
IP prefix and MUST NOT aggregate multiple prefixes.
This restriction is necessary because different prefixes may follow
different routing policies, resulting in different Forwarding
Commitments. Aggregating prefixes could cause errors in FC
generation and validation.
Thus, AS 65537 generates:
An UPDATE message for AS 65538 with NASN set to 65538.
A separate UPDATE message for AS 65539 with NASN set to 65539.
For each UPDATE to a downstream neighbor (e.g., AS 65538), the FC-BGP
speaker in AS 65537:
1. Encapsulates the route prefix into a single UPDATE message.
2. Constructs a new FC segment:
Sets the Previous AS Number (PASN) to 65536.
Sets the Current AS Number (CASN) to 65537.
Sets the Next AS Number (NASN) to 65538.
Xu, et al. Expires 12 December 2025 [Page 5]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
Computes the SHA-256 digest over (PASN, CASN, NASN, IP Prefix
Address, IP Prefix Length).
Signs the digest using ECDSA.
Fills in the Signature and other required FC fields.
3. Prepends the newly created FC segment to the existing FC List.
4. Completes the FC Path attribute.
5. Continues with standard BGP UPDATE processing and transmission.
4. FC-BGP Testbed
4.1. FITI
The prototypes of our solutions for FC-BGP are implemented and tested
on Future Internet Technology Infrastructure(FITI). FITI is a major
scientific and technological infrastructure project in China,
constructed and operated by the National Development and Reform
Commission, the Ministry of Education, Tsinghua University, and other
participating universities. The FITI high-performance backbone
network connects 40 universities across 35 cities in 31 provinces,
autonomous regions, and municipalities, with backbone links
supporting bandwidths of up to 1.2 Tbps. FITI has been assigned 4096
Autonomous System Numbers (ASNs) by APNIC, along with a
240a:a000::/20 IPv6 address block. With geographically distributed
sites across China, FITI provides a genuine internet environment
suitable for large-scale network experimentation.
4.2. FC-BGP Testbed on FITI Infrastructure
The FC-BGP testbed was deployed on the FITI backbone network, as
illustrated in Figure 2. FITI provides a network environment
comprising 40 interconnected ASes located in cities such as Beijing,
Shanghai, Nanjing, and Shenzhen. These ASes are capable of running
the BGP protocol, support customizable routing policies, and reflect
realistic physical and geographical topologies. Each AS can host
multiple routers. The FC-BGP mechanism was implemented in 31 of the
ASes, including deployment on commercial H3C CR16000 or CR19000
routers in a subset of them. After software updates, these 31 ASes
were fully FC-BGP-enabled, supporting route exchange as well as FC
attribute transmission and reception. The remaining 9 ASes did not
deploy FC-BGP and were used to construct a partial deployment
scenario.The testbed is fully capable of supporting the evaluation
requirements for the FC-BGP solution.
Xu, et al. Expires 12 December 2025 [Page 6]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
GitHub repository: https://github.com/fcbgp/fcbgp-implementation
5. Test Experience and Results
The prototype implementation of FC-BGP, as described in Section 2,
was deployed on the testbed outlined in Section 3. The functionality
of the FC-BGP prototype and its compatibility under partial
deployment scenarios were evaluated. All features were successfully
tested, as detailed in the experimental results presented in this
section.
5.1. Test Experience
1. Functional testing of FC-BGP is conducted to verify the
protocol's compliance with its specification in terms of message
construction and operational behavior. The evaluation focuses on
verifying that a BGP speaker is able to correctly construct BGP
UPDATE messages containing the FC path attribute and that the
message format conforms to the FC-BGP specification. In
addition, the tests validate that the FC-BGP implementation
correctly performs AS path validation procedures.
+--------------+
| Urumqi | ...
| +----------+ | |
| | FC-BGP | |----+ +--------------+
| +----------+ | | | Shenyang |
+--------------+ | ... | +----------+ |
| | +--| | FC-BGP | |
| +-------+------+ | | +----------+ |
/ | Beijing | | +--------------+
+----------\------------| +----------+ |--+
| | +----------+ | FC-BGP | +---...---+
| | | | +----------+ | |
| | | +-------+------+ |
| | | | |
| | | | ...
| +-----+-+------+ +-------+------+ |
| | Xi'an | | Zhengzhou | |
| . | +----------+ | | +----------+ | |
| .--| | FC-BGP | | | | FC-BGP | | +------+-------+
| . | +----------+ | | +----------+ | | Shanghai |
| +------+-------+ +-------+------+ | +----------+ | .
| | | | |Legacy-BGP| |-- .
| | | | +----------+ | .
| | +-------+------+ +------+-------+
+-------+------+ | | Wuhan | |
| Lhasa | | | +----------+ | |
Xu, et al. Expires 12 December 2025 [Page 7]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
| +----------+ | ... ---------| |Legacy-BGP| |------- ...
| | FC-BGP | | | +----------+ | |
| +----------+ | +-------+------+ |
+--------------+ | |
| |
+-------+------+ |
| Changsha | |
| +----------+ | |
| | FC-BGP | | |
| +----------+ | ...
+-------+------+ |
| |
| |
+--------------+ +-------+------+ |
| Nanning | | Guangzhou | |
| +----------+ | | +----------+ | |
| | FC-BGP | |--| | FC-BGP | |---------+
| +----------+ | | +----------+ |
+--------------+ +----+----+----+
+--------------+ | | +--------------+
| Haikou | | | | Shenzhen |
| +----------+ | | | | +----------+ |
| | FC-BGP | |-------+ +-----| | FC-BGP | |
| +----------+ | | +----------+ |
+--------------+ +--------------+
Figure 2: FC-BGP Testbed on FITI Infrastructure.
1. To assess the effectiveness and compatibility of FC-BGP in
partial deployment scenarios, a testbed is constructed consisting
of routers that support the FC-BGP mechanism and intermediate
routers that do not support it. The goal of the testing is to
confirm that routers without FC-BGP mechanism support can
transparently forward BGP UPDATE messages containing FC path
attributes without discarding or altering them. This ensures
that FC path attributes are preserved even when traversing BGP
routers that do not support the FC-BGP mechanism.
2. Evaluate the compatibility of the FC-BGP prototype device in a
variety of network scenarios. Verify the routing processing
capabilities of the FC-BGP device under different address
families, including IPv4 and IPv6. Test the compatibility of the
FC-BGP prototype device, when functioning as a BGP route
reflector (RR) and RR client, in networks composed of commercial
routers from different vendors.
Xu, et al. Expires 12 December 2025 [Page 8]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
5.2. Test Results
1. The test results indicated that the FC-BGP prototype correctly
implemented the functionalities as defined in the protocol
specification [FC-BGP-Protocol]. All FC-BGP-enabled BGP speakers
were able to successfully generate FC-BGP UPDATE messages that
conformed to the protocol specification, and the receiving AS was
able to correctly perform the path validation procedure. The FC
path validation mechanism functioned as intended, verifying each
hop in the AS_PATH sequentially. In scenarios where the
receiving AS did not support FC-BGP, the system was still able to
forward FC-BGP UPDATE messages without disruption.
2. Under partial deployment conditions, FC-BGP demonstrated good
compatibility with legacy BGP routers. Commercial routers from
different vendors that do not support FC-BGP (such as Huawei and
Ruijie) were able to transparently forward UPDATE messages
containing FC path attributes, and the integrity of these
messages was preserved throughout the forwarding process. These
results suggest that FC-BGP supports incremental deployment and
remains compatible with existing BGP implementations. With
respect to partial deployment, Section 5.1.1 of [FC-ARXIV]
demonstrates that an adversary cannot forge a valid AS path when
FC-BGP is fully deployed. Furthermore, Section 5.1.2 of
[FC-ARXIV] analyzes the advantages of FC-BGP in partial
deployment scenarios. The analysis shows that FC-BGP offers
greater security benefits than BGPsec under partial deployment
conditions.
3. The test results indicated that the FC-BGP prototype device was
capable of correctly receiving and processing routing information
for all supported address families. When operating as a BGP RR,
the FC-BGP prototype device correctly reflected both IPv4 and
IPv6 routes to its clients. Additionally, when acting as a BGP
RR client, the FC-BGP prototype device was able to properly
receive routes from the RR. These results demonstrate that the
FC-BGP prototype device exhibits strong compatibility across a
variety of network scenarios.
6. Conclusion
In conclusion, experimental results demonstrate that:
1. FC-BGP offers efficient and scalable AS path verification while
preserving compatibility and stability with existing routing
protocols. These advantages are achieved without the need for
modifications to the current Internet architecture.
Xu, et al. Expires 12 December 2025 [Page 9]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
2. Incremental deployment is a key design principle that was used in
the experiment. The results indicate that, even with partial
deployment, FC-BGP provides significant security benefits in
protecting routing information, encouraging early adoption of the
solution by service providers.
7. Security Considerations
The purpose of this document is to report FC-BGP testbed and
experimental results. Security considerations related to the
solution mechanisms are discussed in [FC-BGP-Protocol] and [FC-ARXIV]
for details.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[FC-BGP-Protocol]
Xu, K., Wang, X., liu, Z., Qi, L., Wu, J., and Y. Guo,
"FC-BGP Protocol Specification", Work in Progress,
Internet-Draft, draft-wang-sidrops-fcbgp-protocol-03, 6
April 2025, <https://datatracker.ietf.org/doc/html/draft-
wang-sidrops-fcbgp-protocol-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
[ASPP] McBride, M., Madory, D., Tantsura, J., Raszuk, R., Li, H.,
Heitz, J., and G. S. Mishra, "AS Path Prepending", Work in
Progress, Internet-Draft, draft-ietf-grow-as-path-
prepending-15, 23 April 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-
path-prepending-15>.
Xu, et al. Expires 12 December 2025 [Page 10]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
[FC-ARXIV] "Secure Inter-domain Routing and Forwarding via Verifiable
Forwarding Commitments", September 2023,
<https://arxiv.org/abs/2309.13271>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/rfc/rfc4272>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/rfc/rfc5065>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014,
<https://www.rfc-editor.org/rfc/rfc7132>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Ke Xu
Tsinghua University
Beijing
China
Email: xuke@tsinghua.edu.cn
Xiaoliang Wang
Tsinghua University
Beijing
China
Email: wangxiaoliang0623@foxmail.com
Zhuotao Liu
Tsinghua University
Beijing
China
Email: zhuotaoliu@tsinghua.edu.cn
Qi Li
Tsinghua University
Beijing
China
Xu, et al. Expires 12 December 2025 [Page 11]
Internet-Draft fcbgp-testbed-and-deployment-experience June 2025
Email: qli01@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Ziwei Li
Zhongguancun Laboratory
Beijing
China
Email: lizw@zgclab.edu.cn
Yangfei Guo
Zhongguancun Laboratory
Beijing
China
Email: guoyangfei@zgclab.edu.cn
Xu, et al. Expires 12 December 2025 [Page 12]