| Internet-Draft | fcbgp-framework | March 2025 |
| Xu, et al. | Expires 11 September 2025 | [Page] |
This document describes a security framework based on Forwarding Commitment BGP (FC-BGP). FC serves as a versatile and extensible verification primitive, seamlessly integrating with existing hop-by-hop forwarding architectures, using a chain-based verification mechanism to ensure both end-to-end authenticity and operational validity across Autonomous Systems (ASes). By combining topological information and operational actions, FC-based framework provides a foundation for robust inter-domain routing and forwarding security.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the SIDR Operations mailing list (sidrops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sidrops/.¶
Source for this draft and an issue tracker can be found at https://github.com/FCBGP/framework-of-fcbgp.¶
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 11 September 2025.¶
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.¶
The Internet inter-domain routing relies on hop-by-hop mechanism of Border Gateway Protocol (BGP) [RFC4271] to achieve inter-AS cooperation and global connectivity, providing significant scalability and flexibility. However, this paradigm also introduces security challenges such as route hijacking and forwarding path manipulation. The root cause lies in the mismatch between verification capabilities and information propagation range, which prevents end-to-end security while maintaining the flexibility of hop-by-hop processing. Due to "indirect" nature of hop-by-hop mechanism, the authenticity and integrity of information cannot be verified.¶
The existing representative mechanism BGPsec [RFC8205] aims to provide end-to-end verification by propagating onion-style signatures in BGP update messages. Nevertheless, this design conflicts with Internet's distributed governance and hop-by-hop processing philosophy, resulting in substantial deployment hurdles. Resource Public Key Infrastructure (RPKI) [RFC6480] is another key technology that reduces risk of route hijacking through cryptographic authentication of IP addresses and AS numbers, primarily by enabling Route Origin Validation (ROV). However, RPKI mainly focuses on verifying route origins rather than path security. Consequently, there is a lack of a unified and scalable verification mechanism.¶
This document specifies a security framework based on Forwarding Commitment BGP (FC-BGP). FC is a cryptographic signature code employed to validate an AS's routing intentions at its directly connected hop points. The incrementally deployable framework based on a universal verification primitive FC, is designed to be compatible with existing hop-by-hop forwarding architectures, while overcoming the limitations of current verification capabilities. By utilizing chain-based validation, it establishes an end-to-end verification mechanism across Autonomous Systems (ASes), ensuring authenticity and operational validity of information across ASes. This strategy enables enhanced trust propagation across the global Internet while maintaining the existing hop-by-hop forwarding paradigm, providing a secure and compatible framework to address the security dilemmas caused by mismatch between verification scope and information propagation range.¶
The framework based on FC-BGP relies on the Resource Public Key Infrastructure (RPKI) certificates that attest to 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 [RFC8209] that corresponds to the BGP speaker's AS number.¶
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.¶
The key element of FC-BGP security framework is a transferable universal verification primitive-Forwarding Commitment (FC). The goal of FC is to achieve end-to-end verification within routing and forwarding system while maintaining compatibility with hop-by-hop processing paradigm.¶
+----+---+ +----+---+ +----+---+ +--------+
| AS A +-------->+ AS B +-------->+ AS C +-------->+ AS D |
+----+---+ FC(A) +----+---+ FC(A) +----+---+ FC(A) +----+---+
^ ^ FC(B) ^ FC(B) ^
| | | FC(C) |
| | | |
| | | |
FC(A) FC(B) FC(C) FC(D)
The integration of FC with routing and forwarding path is shown in Figure 1. During hop-by-hop processing, each AS generates an FC based on its routing intent. The FC provides a verifiable proof through cryptographic signatures, encapsulating routing behavior committed at directly connected hop, including information about previous hop AS, current AS, next hop AS and IP prefix, ensuring the authenticity and trustworthiness of provided routing information. Subsequent AS receiving this information can verify FC from previous AS through a chain-based validation mechanism before appending its own FC information, ensuring authenticity and validity of information. The design of chain-based validation ensures security of information during hop-by-hop propagation, preventing tampering by intermediate nodes or inconsistencies in policies from compromising end-to-end security.¶
FC based on hop-by-hop verification mechanism, enables chain-based validation across multiple ASes. Each FC generated by an AS can be independently verified without relying on updates from other ASes or cooperation from global network. It also supports end-to-end verification across the entire network. By constructing FC chains composed of multiple FCs between ASes, it can be used not only for individual hop-by-hop verification but also for building path chains that support global path validation, providing a foundation for end-to-end security.¶
FC provides flexible propagation methods within FC-based framework, which can be achieved by extending existing BGP messages, proposing new propagation protocols, or leveraging existing network infrastructures such as RPKI for propagation. This flexibility and universality allows FC to be compatible with existing network infrastructures, enabling gradual deployment and adoption. Additionally, it can adapt to future network architectures, supporting emerging paradigms such as intent-based networking.¶
+------------------+------------------+------------------+ \ |Route Announcement| Forwarding Path | Routing Policy |... >Operation +------------------+------------------+------------------+ / +-----------------------------------------------------------+\ | BGP Peering | | +-----------------------------------------------------------+ >Topology +-----------------------------------------------------------+ | | Link Statement | | +-----------------------------------------------------------+/
The uniqueness of FC-based framework lies in FC semantic design, as shown in Figure 2, which encompasses two main types of information: topological information and operational information. This design makes FC not just a supplement to existing security mechanisms, but a fundamental primitive that supports construction of comprehensive security frameworks.¶
Topological Information: Topological information forms core of FC and is divided into two layers:¶
Link Statement: FC expresses physical connections between ASes through a link statement, which records direct physical links such as fiber connections or dedicated lines. This information provides direct evidence of validity of BGP peering relationships. If there is no physical connection between two ASes, they should not establish a BGP peering relationship. The link statement ensures objectivity and verifiability of physical connections, eliminating routing announcements based on false connections.¶
BGP Peering: Based on physical connection states, FC further captures logical BGP peering relationships established over these connections. By including previous hop, current AS, and next hop, FC describes inter-AS routing relationships in detail, enabling fine-grained, topology-based chained validation. This helps verify whether an AS's routing announcement aligns with its BGP peering relationship, ensuring that AS has genuinely learned route information from a neighboring AS, preventing route hijacking attacks.¶
Operational Information: FC encapsulates rich operational semantics that describe specific actions performed by an AS in routing and forwarding processes. It mainly includes the following:¶
Route Announcement: An AS announces its routing prefixes and path information to external peers. FC can represent these route announcements within directly connected hop range and provide verifiable commitments to global network, helping prevent route hijacking.¶
Forwarding Path Designation: FC defines transmission path that packets should follow, which is critical for data plane security. By embedding forwarding path information, FC ensures that packets are forwarded as expected, preventing path manipulation or malicious redirection.¶
Routing Policy: FC captures policies of an AS regarding how to select and propagate paths, ensuring the consistency of routing policies and helping to identify and prevent route leaks and configuration errors.¶
By integrating topological and operational information, FC expresses behaviors ranging from AS level to global level. Each FC represents routing and forwarding actions that occur within directly connected hop range, and by linking multiple FCs, chained validation can be achieved across scope of multiple ASes. This mechanism ensures comprehensive verification of network operations, guaranteeing consistency and authenticity of information across entire network interaction range.¶
In chain-based validation, FC is linked into a chain using cryptographic signatures, with each AS verifying the previous FC before appending its own information. This creates a trust chain that spans multiple ASes. This mechanism ensures end-to-end verification while maintaining decentralized nature of Internet. By leveraging FC as a foundational structure, the FC-based framework strengthens routing information and enhances security and reliability of network communication.¶
By introducing universal verification primitive FC, FC-based security framework combines independence of hop-by-hop forwarding with end-to-end security verification capability. Below are some security mechanisms and application scenarios enabled by FC:¶
Routing Verification of Incremental Deployment: FC supports gradual deployment, allowing verification within networks that are not fully deployed. Through hop-by-hop and chain-based verification, FC adapts to partial deployment scenarios, reducing overhead of global verification.¶
Consistency Between Control Plane and Data Plane: By combining BGP peering relationships with physical link information, FC significantly enhances data plane security. For instance, embedding forwarding path information within FC ensures that packets are forwarded along expected routes, preventing path manipulation or malicious detours.¶
Route Leak Prevention and Policy Transparency: FC's operational information allows ASes to define and validate their routing policies, effectively preventing route leaks caused by misconfigurations or malicious policy violations.¶
Dynamic Defense Mechanisms Against Emerging Attacks: FC's flexibility allows it to adjust to new attack scenarios, dynamically optimizing granularity of FC information to address evolving security challenges.¶
This document has no security risks to consider.¶
This document has no IANA actions.¶
TODO acknowledge.¶