SIDR Operations Working Group J. Zhang Internet-Draft Zhongguancun Laboratory Intended status: Standards Track 24 July 2024 Expires: 25 January 2025 ASPA-based AS_PATH Validation for BGP Export draft-zhang-sidrops-aspa-egress-00 Abstract This document describes that a BGP speaker may perform AS_PATH verification on the routes it sends to BGP neighbors at external BGP (eBGP) egress based on Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI). Before BGP speakers advertise routes to external peers at eBGP egress, performing ASPA-based AS_PATH verification can prevent route leaks to external peers. 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/. 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 25 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang Expires 25 January 2025 [Page 1] Internet-Draft ASPA validation for BGP Export July 2024 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. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 3. ASPA-based AS_PATH Verification at eBGP Egress . . . . . . . 3 3.1. Procedure of Verification . . . . . . . . . . . . . . . . 3 3.2. Scenarios that do not require egress verification . . . . 4 4. Operational Considerations . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Autonomous System Provider Authorization (ASPA) objects in the RPKI can be used to verify BGP AS_PATH for detection and mitigation of route leaks and certain prefix hijacks involving forged origins or forged path-segments with some improbable AS paths. The ASPA object profile is defined in [I-D.ietf-sidrops-aspa-profile]. In the procedures of ASPA-based BGP AS_PATH verification defined in [I-D.ietf-sidrops-aspa-verification], ingress external BGP (eBGP) router of an AS receives routes from its BGP peers, and perform ASPA- based BGP AS_PATH verification and mitigation at eBGP ingress, as recomendations specified in Section 8.1 in [I-D.ietf-sidrops-aspa-verification]. BGP AS_PATH verification at eBGP ingress can detect and prevent the route leaks in the routes received from BGP neighbors, but route leaks could occur at the local AS where a BGP speaker exports routes to its external peer at eBGP egress. It lacks the ability to prevent route leaks from occuring at the local AS. This document describes ASPA-based BGP AS_PATH verification at eBGP egress. It does not change the semantics or procedures of ASPA-based BGP AS_PATH verification defined in Zhang Expires 25 January 2025 [Page 2] Internet-Draft ASPA validation for BGP Export July 2024 [I-D.ietf-sidrops-aspa-verification]. It explains an important use case and specifics of correct implementation of ASPA-based path verification in eBGP egress policies, as [RFC8893] did with RPKI origin validation for BGP export. ASPA-based BGP AS_PATH verification at eBGP egress is a little bit different from the process at the eBGP ingress. By AS_PATH verification before sending routes to BGP neighbors at eBGP egress, a BGP speaker can detect and prevent imporper route propagation of route leaks. 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. Suggested Reading It is assumed that the reader understands BGP[RFC4271], RPKI[RFC6480], ASPA object profile[I-D.ietf-sidrops-aspa-profile], ASPA-based BGP AS_PATH verification[I-D.ietf-sidrops-aspa-verification], and RPKI-ROV for BGP export[RFC8893]. 3. ASPA-based AS_PATH Verification at eBGP Egress When a BGP speaker advertises a route to an external peer through eBGP egress, the BGP speaker prepends its own AS number to the AS_PATH of the route, and performs ASPA-based AS_PATH verification before sending the route to the external peer. 3.1. Procedure of Verification Suppose the BGP speaker is at AS X, and its external peer is at AS Y, and the AS_PATH P of the route to be advertised to external peer by the BGP speaker is represented by {AS X, AS(N), ..., AS(2), AS(1)}, where AS(1) is the origin AS, and AS X is the local AS number added by the BGP speaker of AS X at eBGP egress. Zhang Expires 25 January 2025 [Page 3] Internet-Draft ASPA validation for BGP Export July 2024 +------------------------+ | AS X | | | +-------+ eBGP | +----+ iBGP +----+ | eBGP +--------+ | AS(N) |-------->>| R1 |------>>| R2 |-------->>| AS Y | +-------+ | +----+ +----+ \| +--------+ | \ +------------------------+\ \ eBGP egress Figure 1: Illustration of the eBGP egress. The method of ASPA-based AS_PATH verification at the eBGP egress of the BGP speaker is described as follows: 1. Regard the external neighbor AS Y as the virtual receiving/ validating AS point. 2. The BGP roles of AS X and AS Y, including Customer, Provider, Route Server (RS), Route Server Client (RS-client) and Peer, are defined in [RFC9234], and they can be configured locally and used for the path verification. 3. If AS X is the Customer or Peer to AS Y, or, AS Y is a (transparent or non-transparent) Route Server (RS) and AS X is a RS- client, use the upstream path verification algorithm (described in [I-D.ietf-sidrops-aspa-verification]) to verify the AS_PATH P. 4. If AS X is the Provider to AS Y, use the downstream path verification algorithm (described in [I-D.ietf-sidrops-aspa-verification]) to verify the AS_PATH P. 3.2. Scenarios that do not require egress verification In some scenarios, there is no requirement to perform egress ASPA- based path verification. 1. Mutual-transit. If the relation between two ASes is mutual- transit, they MAY export all kinds of routes to each other ([I-D.ietf-sidrops-aspa-verification]). There is no route leak violating valley-free route policy. 2. A Route Server exports to a RS-client. The functionality of a Route Server is to exchange routes among member ASes at an Internet Exchange Provider (IXP) according to pre-configured rules. The responsibility of route leak happened at an IXP is at member ASes, not at Route Servers. Therefore, there is no need to do path Zhang Expires 25 January 2025 [Page 4] Internet-Draft ASPA validation for BGP Export July 2024 verification at RS egress, regardless of whether the RS is a transparent RS or a non-transparent RS. Additionally, even if verification is performed at the egress, as shown in Figure 2, both the egress and ingress verification are upstream. Therefore, if the verification result at the ingress is not "Invalid", the verification result at the egress should also not be "Invalid". Therefore, ASPA verification is not performed at the egress of the Route Server to the RS-client. RS Client RS RS Client AS(N) -> AS X -> AS Y | | | | +-----------------------------------------+ +-----------------------+ | R1(Ingress) -IBGP-> R2(Egress) | | R3(Ingress) | +-----------------|-----------------------+ +-----------------------+ | AS_PATH | AS_PATH | | AS_PATH | | AS(N) ... AS(1) | AS X AS(N) ... AS(1) | | AS X AS(N) ... AS(1) | +-----------------|-----------------------+ +-----------------------+ | Upstream | Upstream | | Upstream | +-----------------------------------------+ +-----------------------+ Figure 2: The verification at both the egress and ingress are upstream. 4. Operational Considerations The peering relationships between the local AS and its external neighbor ASes, including Customer-Provider/Provider-Customer, Peer- Peer, Route Server (RS) and RS-client, mutual-transit, are used in path verification procedures to determine whether upstream or downstream procedures should be applied. There are the following possible ways to know the relations between the local AS and its external neighbor AS: (1) The first way is to use the BGP Role Capabilities exchanged in the BGP OPEN message as specified in [RFC9234]. (2) The second way is to use ASPA objects registered by the local AS and its external neighbor AS. (3) Another possible way is to use local configuration. When the relation of two neighboring ASes is mutual-transit, they are Customers of each other in BGP roles. It can be confirmed by BGP roles advertised in the BGP OPEN message, or configuration in local file. If a mutual-transit relation is identified as Cutomer-Provider, a false positive of route leak may be generated in path verification. Zhang Expires 25 January 2025 [Page 5] Internet-Draft ASPA validation for BGP Export July 2024 5. Security Considerations The security considerations that apply to ASPA-based AS_PATH verification (see [I-D.ietf-sidrops-aspa-verification]) also apply to the procedure described in this document. 6. IANA Considerations This document has no IANA actions 7. References 7.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [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, . [RFC8893] Bush, R., Volk, R., and J. Heitz, "Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export", RFC 8893, DOI 10.17487/RFC8893, September 2020, . [RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, . 7.2. Informative References [I-D.ietf-sidrops-aspa-profile] Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, R., and B. Maddison, "A Profile for Autonomous System Zhang Expires 25 January 2025 [Page 6] Internet-Draft ASPA validation for BGP Export July 2024 Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-18, 25 June 2024, . [I-D.ietf-sidrops-aspa-verification] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa- verification-17, 29 February 2024, . Author's Address Jia Zhang Zhongguancun Laboratory Beijing China Email: zhangj@mail.zgclab.edu.cn Zhang Expires 25 January 2025 [Page 7]