FC-BGP Protocol Specification
draft-sidrops-wang-fcbgp-protocol-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ke Xu , Xiaoliang Wang , Zhuotao liu , Li Qi , Jianping Wu , Yangfei Guo | ||
| Last updated | 2024-02-23 | ||
| 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-sidrops-wang-fcbgp-protocol-00
sidrops K. Xu
Internet-Draft X. Wang
Intended status: Standards Track Z. Liu
Expires: 26 August 2024 Q. Li
J. Wu
Tsinghua University
Y. Guo
Zhongguancun Laboratory
23 February 2024
FC-BGP Protocol Specification
draft-sidrops-wang-fcbgp-protocol-00
Abstract
This document describes Forwarding Commitment BGP (FC-BGP), an
extension to the Border Gateway Protocol (BGP) that provides security
for the path of Autonomous Systems (ASes) through which a BGP UPDATE
message passes. Forwarding Commitment（FC）is a cryptographically
signed code to certify an AS's routing intent on its directly
connected hops. Based on FC, FC-BGP aims to build a secure inter-
domain system that can simultaneously authenticate the AS_PATH
attribute in BGP UPDATE and validate network forwarding on the data
plane.
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://BasilGuo.github.io/fcbgp-protocol/draft-sidrops-wang-fcbgp-
protocol.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-sidrops-wang-fcbgp-protocol/.
Source for this draft and an issue tracker can be found at
https://github.com/BasilGuo/fcbgp-protocol.
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 26 August 2024 [Page 1]
Internet-Draft FC-BGP February 2024
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 26 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. FC Attribute . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Processing a Received FC-BGP UPDATE Message . . . . . . . . . 5
3.1. Verify the AS-Path Attribute . . . . . . . . . . . . . . 6
3.2. BGP Best Path Selection . . . . . . . . . . . . . . . . . 6
3.3. Update the FC path attributes and continue to advertise the
BGP route . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The FC-BGP control plane mechanism described in this document is to
verify the authenticity of BGP advertised routes. FC-BGP is fully
compatible with BGP and provides more security benefits in case of
partial deployment compared with BGPsec. FC-BGP extends the BGP
UPDATE message with a new optional, transitive, and extended path
attribute called FC (Forwarding Commitment). When the BGP UPDATE
message traverses an FC-BGP enabled AS, it adds a new FC according to
Xu, et al. Expires 26 August 2024 [Page 2]
Internet-Draft FC-BGP February 2024
the AS order in AS_PATH. Subsequent ASes can then use the list of
FCs in the UPDATE message to verify that the advertised path is
consistent with the AS_PATH attribute.
Similar to BGPsec defined in [RFC8205], FC-BGP relies on RPKI to
perform route origin validation. Additionally, any FC-enabled BGP
speaker that wishes to generate and propagate FC along with BGP
UPDATE messages MUST use a router certificate from RPKI that is
associated with its AS number. The router key generation here
follows [RFC8635].
It is worth noting that the FC-BGP framework can be extended to
verify data plane forwarding paths, ensuring that these paths are
honoring the control plane BGP paths. However, the description of
these mechanisms is outside the scope of this document.
1.1. Requirements Language
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.
2. FC Attribute
Unlike BGPsec, FC-BGP does not modify the AS_PATH. Instead, FC is
enclosed in a BGP UPDATE message as an optional, transitive, and
extended length path attribute. Thus, it is unnecessary to negotiate
this feature in the BGP OPEN message.
Although FC-BGP would not modify the AS_PATH path attribute, it is
REQUIRED to ever use the AS_SET or AS_CONFED_SET in FC-BGP according
to what [RFC6472] says.
The format of the FC path attribute is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type | FCList Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ FCList ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of FC path attribute.
FC path attribute includes the following parts:
Xu, et al. Expires 26 August 2024 [Page 3]
Internet-Draft FC-BGP February 2024
Flags (1 octet): The current value is 0b11010000, representing the
FC attribute as optional, transitive, partial, and extended-
length.
Type (1 octet): The current value is TBD, which is waiting for the
IANA assignment. Refer to Section 5.
FCList Length (2 octets): The value is the total length of the
FCList in bytes.
FCList (variable length): The value is a sequence of FCs, in order.
The definition of the FC signed code format is shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nexthop Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Subject Key Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID | Flags | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of FC.
In FC-BGP, all ASes MUST use 4-byte AS numbers. Existing 2-byte AS
numbers are converted into 4-byte AS numbers by setting the two high-
order octets of the 4-octet field to 0 [RFC6793].
FC signed code includes the following parts.
Previous Autonomous System Number (PASN, 4 octets): The AS number of
the previous AS. If the current AS has no previous AS hop, it
MUST be filled with 0.
Current Autonomous System Number (CASN, 4 octets): The AS number of
the current AS.
Nexthop Autonomous System Number (NASN, 4 octets): The AS number of
the next hop AS to whom the current AS will send the BGP UPDATE
message.
Subject Key Identifier (SKI, 20 octets): It exists in the RPKI
Xu, et al. Expires 26 August 2024 [Page 4]
Internet-Draft FC-BGP February 2024
router certificate, used to uniquely identify the public key for
signature verification.
Algorithm ID (1 octet): The current assigned value is 1, indicating
that SHA256 is used to hash the content to be signed, and ECDSA is
used for signing. It follows the algorithm suite defined in
[RFC8208] and its updates. As each FC has its Algorithm ID, so no
need to worry about that one suddenly changing its algorithm
suite.
Flags (1 octet): Its value MUST be 0. None of these bits are
assigned values.
Signature Length (2 octets): It indicates the signature length in
bytes.
Signature (variable length): The signature content and order are
Signature=ECDSA(SHA256(PASN, CASN, NASN, Prefix)), where the
Prefix is the IP address prefix which is encapsulated in the BGP
UPDATE, and only one prefix is used each time. For hashing and
signing, it uses the full IP address and IP prefix length. The
full IP address uses 4 bytes for IPv4 and 16 bytes for IPv6.
3. Processing a Received FC-BGP UPDATE Message
Upon receiving a BGP UPDATE message carrying FC path attributes, an
AS will perform the following three steps:
1. Verify the AS-Path attribute.
2. BGP best path selection.
3. Update the FC path attributes and continue advertising the BGP
route.
The AS that originates a BGP UPDATE message with the FC path
attributes only performs the third step. An AS which no longer
propagates a BGP UPDATE only completes the first two steps. For the
sake of discussion, we assume that AS 65537 receives an FC-BGP UPDATE
message for prefix 192.0.0/24, with an originating AS of 65536 and a
next hop of 65538. All three ASes support FC-BGP.
Xu, et al. Expires 26 August 2024 [Page 5]
Internet-Draft FC-BGP February 2024
3.1. Verify the AS-Path Attribute
The FC-BGP speaker in AS 65537, upon receiving an UPDATE message,
retrieves the FC path attribute and extracts the FC list. It then
finds the FC with CASN = 65536 and checks if NASN is equal to 65537.
If so, it uses the SKI field to find the public key and calculates
the signature using the algorithm specified in the Algorithm ID. If
the calculated signature matches the signature in the message, then
the AS-Path hop associated with the AS 65536 is verified. This
process repeats for all FCs and AS-Paths in the FC list. If AS 65537
does not support FC-BGP, it simply forwards the BGP UPDATE to its
neighbors when propagating this BGP route.
3.2. BGP Best Path Selection
Based on the AS-Path verification, it is recommended that AS 65537
prioritize route selection as follows:
1. Local preference. Local preference is the highest priority,
regardless of the verification results.
2. Full path validation. All AS hops in the AS-Path attribute from
the source AS to the current AS have successfully passed the
aforementioned FC validation.
3. Partial path validation. There is a contiguous AS subsequence in
the AS-Path attribute starting from the source AS. All AS hops
in the subsequence have successfully passed the FC validation.
However, there is at least one AS between the last AS in the
subsequence and the current AS whose associated FC is either
missing or invalid. We denote the number of ASes included in the
subsequence as N, and the total number of ASes from the source AS
to the current AS as M. This path should be considered to be
secure in the following two conditions: N = 1 and M <= 4 or N > 1
and M <= N + 3.
4. Shorter AS-Path. The current AS selects the route with the
shorter AS_PATH.
5. Other attributes with lower priority than the AS-path length.
The addition of FCs in this case should not affect path
selection.
Xu, et al. Expires 26 August 2024 [Page 6]
Internet-Draft FC-BGP February 2024
3.3. Update the FC path attributes and continue to advertise the BGP
route
FC-BGP speakers need to generate different UPDATE messages for
different peers. Each UPDATE announcement contains only one route
prefix and cannot be aggregated. This is because different route
prefixes may have different announcement paths due to different
routing policies. Multiple aggregated route prefixes may cause FC
generation and verification errors. When multiple route prefixes
need to be announced, the FC-BGP speaker needs to generate different
UPDATE messages for each route prefix.
When the AS-PATH uses AS_SEQUENCE in the BGP UPDATE, the FC-BGP
function will not be enabled. In other cases, the FC-BGP speaker
router will enable the FC-BGP function and update the FC path
attribute after verifying AS-Path Attribute and selecting the
preferable BGP path. All FC-BGP UPDATE messages must comply with the
maximum BGP message size. If the final message exceeds the maximum
message size, then it must follow the processing of Section 9.2 of
[RFC4271].
The FC-BGP speaker in AS 65537 will encapsulate each prefix to be
sent to AS 65538 in a single UPDATE message, add the FC path
attribute, and sign the path content using its private key.
Afterwards, AS65537 will prepend its own FC on the top of the FC
List. The FC path attribute uses the message format shown in
Figure 1 and Figure 2 and should be signed with the RPKI router
certificate. When signing the FC attribute, the FC-BGP speaker
computes the SHA256 hash in the order of (PASN ( 0 if absent), CASN,
NASN, IP Prefix Address, and IP Prefix Length) firstly. Afterwards,
the FC-BGP speaker should calculate the digest information Digest,
sign the Digest with ECDSA, and then fill the Signature field and FC
fields. At this point, the processing of FC path attributes by the
FC-BGP speaker is complete. The subsequent processing of BGP
messages follows the standard BGP process.
4. Security Considerations
The security considerations of [RFC8205] and [RFC4272] also apply to
FC-BGP.
5. IANA Considerations
TBD: Wait for IANA to assign FC-BGP-UPDATE-PATH-ATTRIBUTE-TYPE.
6. References
6.1. Normative References
Xu, et al. Expires 26 August 2024 [Page 7]
Internet-Draft FC-BGP February 2024
[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,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/rfc/rfc6793>.
[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 Processing", RFC 7607,
DOI 10.17487/RFC7607, August 2015,
<https://www.rfc-editor.org/rfc/rfc7607>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/rfc/rfc8205>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208,
DOI 10.17487/RFC8208, September 2017,
<https://www.rfc-editor.org/rfc/rfc8208>.
[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for
BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,
<https://www.rfc-editor.org/rfc/rfc8635>.
[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>.
6.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/rfc/rfc4272>.
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
DOI 10.17487/RFC6472, December 2011,
<https://www.rfc-editor.org/rfc/rfc6472>.
Xu, et al. Expires 26 August 2024 [Page 8]
Internet-Draft FC-BGP February 2024
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
Email: qli01@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Yangfei Guo
Zhongguancun Laboratory
Beijing
China
Email: guoyangfei@zgclab.edu.cn
Xu, et al. Expires 26 August 2024 [Page 9]