Secure Inter-Domain Routing K. Xu Internet-Draft X. Wang Intended status: Informational Z. Liu Expires: 10 December 2025 Q. Li Tsinghua University Y. Guo Zhongguancun Laboratory 8 June 2025 Transition to Full BGPsec Deployment: Transitive-BGPsec is Incompatible with BGPsec draft-wang-sidrops-bgpsec-transition-00 Abstract This document elaborates on the reasons why it is unfeasible to reconstruct the native-BGPsec as a transitive approach, such that a BGP update with a correctly signed BGPsec_PATH attribute can traverse legacy areas and afterwards it can still be properly processed by subsequent native-BGPsec speakers. 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/BGPsec-Transition/draft-wang-sidrops-bgpsec- transition.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wang-sidrops-bgpsec- transition/. Source for this draft and an issue tracker can be found at https://github.com/FCBGP/BGPsec-Transition. 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 10 December 2025 [Page 1] Internet-Draft BGPsec Transition 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 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. Transitive BGPsec Modifications . . . . . . . . . . . . . . . 3 2.1. Transitive BGPsec Negotiation . . . . . . . . . . . . . . 3 2.2. The Transitive BGPsec_PATH Attribute . . . . . . . . . . 4 2.3. Updating and Receiving BGP UPDATE message . . . . . . . . 4 3. Question: Compatibility with Native BGPsec . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Border Gateway Protocol (BGP) [RFC4271] is vulnerable to route leaks and hijacking attacks. Native BGPsec, as defined in [RFC8205], extends BGP to enhance the security of AS path information. Nevertheless, native BGPsec encounters challenges in achieving incremental deployment. It utilizes an optional non-transitive BGP path attribute to deliver digital signatures. Yet, when BGPsec messages traverse BGPsec- Xu, et al. Expires 10 December 2025 [Page 2] Internet-Draft BGPsec Transition June 2025 unemployed, the last BGPsec-aware router falls back to native BGP protocol to ensure backward compatibility, by completely removing the BGPsec-related path attribute (i.e., the BGPsec_PATH attribute). The principal objectives are to make BGPsec transit transparently over BGPsec-unemployed areas, instead of completely falling back to legacy BGP. In order to transit across areas where BGPsec has not been deployed, the most straightforward approach is to transform the native BGPsec into transitive BGPsec. However, this document will illustrate that it is unfeasible to render BGPsec as a transitive approach for traversing undeployed areas while still being compatible with native BGPsec. In other words, transitive BGPsec is not compatible with BGPsec. 1.1. 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. BGP: BGP, native BGP, and/or legacy BGP are the BGP version 4 defined in [RFC4271] and/or multiprotocol BGP defined in [RFC4760]. It does not support BGPsec or native BGPsec. BGPsec: BGPsec, native BGPsec, and/or traditional BGPsec are the BGPsec approach defined in [RFC8205]. T-BGPsec: T-BGPsec or transitive BGPsec means that the transitive BGPsec approach is defined in this document. 2. Transitive BGPsec Modifications Transitive BGPsec, in essence, describes that the BGPsec_PATh must be transitive and compliant with native BGPsec. 2.1. Transitive BGPsec Negotiation As stated in Section 2.2 of [RFC8205], for a BGPsec router to successfully negotiate with its peer, it must transmit the BGPsec Capabilities that are in accordance with those of its peers in the BGP OPEN message. A transitive path attribute, instead, does not require the negotiation of capabilities with peers. In the event that a peer fails to comprehend the transitive path attribute, it simply forwards it to downstream BGP speakers. Xu, et al. Expires 10 December 2025 [Page 3] Internet-Draft BGPsec Transition June 2025 In transitive BGPsec, negotiating the BGPsec capability is not required. However, a BGPsec router is obligated to inform its peer that it supports transitive BGPsec. In this case, the reuse of the BGPsec capability is essential. Nevertheless, there is no requirement to utilize the Dir field and the AFI field. Transitive BGPsec reuses the native BGPsec capability format. Consequently, the version field of the BGPsec capability must be updated to 1, while the remaining fields should be filled with 0. If a BGPsec router negotiates with its peers and the version value of the BGPsec capability is set to 1, this implies that the router supports transitive BGPsec. In this scenario, the BGPsec capability serves two purposes. Firstly, it notifies the peer that this particular BGP speaker is capable of supporting transitive BGPsec. Secondly, it differentiates transitive BGPsec from native BGPsec. For the sake of compatibility, this document designates that it still supports native BGPsec in this version. 2.2. The Transitive BGPsec_PATH Attribute Given that the objective is to expedite the incremental deployment of BGPsec, this document considers the least possible modifications to BGPsec. Consequently, all of the packet formats of the BGPsec_PATH attribute defined in [RFC8205] are reutilized in the establishment of transitive BGPsec, including the BGPsec_PATH attribute format, Secure_Path format, Secure_Path Segment format, Signature_Block format, and Signature_Block Segment format. In native BGPsec, the BGPsec_PATH attribute is an optional non- transitive BGP path attribute. However, within this document, the BGPsec_PATH attribute is defined as an optional transitive BGP path attribute. It is important to note that the attribute code should remain the same as that of the native BGPsec_PATH attribute. 2.3. Updating and Receiving BGP UPDATE message TBD. 3. Question: Compatibility with Native BGPsec Taking the topology presented in Figure 1 as an example: * AS A, AS B, and AS C are regions with continuous native BGPsec deployments. Specifically, AS A, AS B, and AS C implement native BGPsec. Additionally, AS C also implements transitive BGPsec. Xu, et al. Expires 10 December 2025 [Page 4] Internet-Draft BGPsec Transition June 2025 * AS D and AS E are areas with legacy BGP deployments. These areas do not implement native BGPsec, transitive BGPsec, or any other related security mechanisms. * AS F deploys native BGPsec. +---+ +---+ +---+ +---+ +---+ +---+ | A | --> | B | --> | C | --> | D | --> | E | --> | F | --> ... +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | \ / \ / | BGPsec Continuous Area Non-BGPsec Area BGPsec Figure 1: Example: Mix Deployment Scenario AS A is capable of negotiating the BGPsec Capability with AS B. AS A disseminates a route prefix through a BGPsec UPDATE message to AS B. AS B can negotiate the BGPsec Capability independently with both AS A and AS C. It receives the BGPsec UPDATE message from AS A and validates it in accordance with the BGPsec specification. Subsequently, it modifies the BGPsec UPDATE message by incorporating its own information and forwards it to AS C. AS C obtains the BGPsec UPDATE message from AS B. AS C validates the BGPsec UPDATE message and makes the necessary modifications. In this scenario, because AS D is a legacy AS, AS C converts this message into a transitive BGPsec UPDATE message. AS D and AS E refrain from processing this transitive BGPsec message and instead forward it to the subsequent hop. AS F receives this transitive BGPsec UPDATE message from AS E. Because AS F deploys the native BGPsec, it will conduct a syntax check. However, the verification will fail because the message is not correctly formatted as a BGPsec UPDATE message. In summary, any native BGPsec speaker on the downstream of an undeployed region cannot properly process the transitive BGPsec UPDATE messages sent by upstream ASes. Thus, we conclude that the transitive BGPsec is not a viable option to make BGPsec incrementally deployable. A new intermediate protocol is required in the transition to full BGPsec deployment. Xu, et al. Expires 10 December 2025 [Page 5] Internet-Draft BGPsec Transition June 2025 4. Security Considerations There are no security considerations in this document. 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC9774] Kumari, W., Sriram, K., Hannachi, L., and J. Haas, "Deprecation of AS_SET and AS_CONFED_SET in BGP", RFC 9774, DOI 10.17487/RFC9774, May 2025, . 6.2. Informative References [RFC8374] Sriram, K., Ed., "BGPsec Design Choices and Summary of Supporting Discussions", RFC 8374, DOI 10.17487/RFC8374, April 2018, . Xu, et al. Expires 10 December 2025 [Page 6] Internet-Draft BGPsec Transition June 2025 Acknowledgments TODO acknowledge. Authors' Addresses Ke Xu Tsinghua University Email: xuke@tsinghua.edu.cn Xiaoliang Wang Tsinghua University Email: wangxiaoliang0623@foxmail.com Zhuotao Liu Tsinghua University Email: zhuotaoliu@tsinghua.edu.cn Qi Li Tsinghua University Email: qli01@tsinghua.edu.cn Yangfei Guo Zhongguancun Laboratory Email: guoyangfei@zgclab.edu.cn Xu, et al. Expires 10 December 2025 [Page 7]