Inter-Domain Routing B. Herdes Internet-Draft Cloudflare Updates: 9234 (if approved) A. Azimov Intended status: Standards Track Yandex Expires: 21 March 2027 A. Chariton Cisco 17 September 2026 Strict Only to Customer (OTC) Verification on Route Server Sessions draft-herdes-idr-otc-rs-verification-01 Abstract RFC 9234 specifies how an AS receiving a route from a lateral Peer can check if a route was leaked, but doesn't specify any checks for routes received from a Route Server (RS). This makes the quality of filtering dependent on whether the RS implements RFC 9234. This document updates RFC 9234 by adding a complementary ingress check by an RS-Client. 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 21 March 2027. Copyright Notice Copyright (c) 2026 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 Herdes, et al. Expires 21 March 2027 [Page 1] Internet-Draft Strict OTC Verification on RS Sessions September 2026 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 . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Update to the OTC Ingress Procedure . . . . . . . . . . . . . 3 4. Operational Considerations . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction [RFC9234] specifies OTC attribute and Peering Roles: Customer, Provider, Peer, RS, and RS-Client. Section 5 of [RFC9234] specifies ingress filtering based on the OTC value for routes received from a Peer. It says: | If a route with the OTC Attribute is received from a Peer (i.e., | remote AS with a Peer Role) and the Attribute has a value that is | not equal to the remote (i.e., Peer's) AS number, then it is a | route leak and MUST be considered ineligible. | | -- RFC 9234 For the routes received from an RS, [RFC9234] doesn't specify any checks, though an RS basically provides service for indirect peering, thus the same procedure to a Peer should be applied. Section 3 extends the OTC check on RS-Clients to verify that if OTC is present, its value matches the RS's AS number. 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. Herdes, et al. Expires 21 March 2027 [Page 2] Internet-Draft Strict OTC Verification on RS Sessions September 2026 1.2. Terminology Terminology follows [RFC9234]: the BGP Roles Provider, Customer, RS, RS-Client, and Peer are as defined in its Sections 3.1 and 4, and "local AS" and "remote AS" are the two ends of an eBGP session. "Route is ineligible" is as in [RFC4271]. A transparent RS does not insert its own AS number into the AS_PATH of routes it redistributes [RFC7947]; most production route servers are transparent. Example AS numbers are from the documentation range [RFC5398]. 2. Problem Statement An RS exists to redistribute routes between RS-Clients that peer laterally through it. [RFC9234] states that if a route received by an RS has the OTC attribute, it is a route leak. But if the RS is non-compliant, it will accept the route without checking the OTC value and redistribute it to its RS-Clients. If the RS is implementing [RFC9234], it will reject received routes if OTC is present and will add the OTC attribute with the value equal to its own AS (the RS's AS number) when advertising routes to its RS- Clients. From the point of the RS-Client, a correct route received from an RS must carry either no OTC Attribute or one equal to the RS's AS number. Otherwise, it's a route leak. That is true of transparent and non-transparent route servers alike, since transparency affects only whether the RS appears in the AS_PATH. 3. Update to the OTC Ingress Procedure This section updates Section 5 of [RFC9234] by adding a new rule for RS-Client. If a route with the OTC Attribute is received from an RS (i.e., remote AS with an RS Role) and the Attribute has a value that is not equal to the remote (i.e., RS's) AS number, then it is a route leak and MUST be considered ineligible. 4. Operational Considerations The above update in OTC processing is fully backwards compatible with [RFC9234]. It doesn't require a new version or BGP capability negotiations between implementations. Herdes, et al. Expires 21 March 2027 [Page 3] Internet-Draft Strict OTC Verification on RS Sessions September 2026 There are IXPs that may provide additional L3 connectivity services. For example, they may provide connectivity for remote IXP using a dedicated L3 gateway. If other IXP members send prefixes through this L3 gateway, it becomes their Provider in terms of peering relationships. To solve this ambiguity, the document suggests the following routing policy: * If an L3 connectivity service gateway is present at an IXP, it should not receive or advertise prefixes to the RS; otherwise, they can be considered route leaks. * An IXP member who wants to use an L3 service SHOULD establish a direct BGP session with the L3 gateway through the IXP's L2 matrix. If BGP Roles are used in this BGP session, they MUST be set to Customer and Provider, respectively. * The L3 gateway is not an RS, so it MUST NOT strip its ASN from the AS_PATH. 5. IANA Considerations This document has no IANA actions. 6. Security Considerations The security considerations of [RFC9234] Section 8 apply. 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, . [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, . [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, . Herdes, et al. Expires 21 March 2027 [Page 4] Internet-Draft Strict OTC Verification on RS Sessions September 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, . Authors' Addresses Bryton Herdes Cloudflare, Inc. Champaign, Illinois United States of America Email: bryton@cloudflare.com Alexander Azimov Yandex Ulitsa Lva Tolstogo 16 Moscow 119021 Russian Federation Email: a.e.azimov@gmail.com Antonis Chariton Cisco CH-8000 Zurich Switzerland Email: acharito@cisco.com Herdes, et al. Expires 21 March 2027 [Page 5]