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, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, . [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [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, . 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]