| Internet-Draft | Strict OTC Verification on RS Sessions | August 2026 |
| Herdes & Azimov | Expires 1 March 2027 | [Page] |
RFC 9234 specifies how an AS receiving a route from a lateral Peer can check if route was lekaed, but doesn't specify any checks for routes received from Route Server (RS). This makes quility of filtering dependent on whether the RS implements RFC 9234.¶
This document updates RFC 9234 by adding complimentary ingress check by RS-Client.¶
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 1 March 2027.¶
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 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.¶
The [RFC9234] specifies OTC attribute and Peering Roles: Cusromer, Provider, Peer, RS, and RS-Client. Section 5 of [RFC9234], specifies ingress filtering based on OTC value for routes received from 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 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.¶
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.¶
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].¶
A RS exists to redistribute routes between RS-Clients that peer laterally through it. The [RFC9234] states that if route receved by RS has OTC attribute, its a route leak. But if RS is non-compiant, it will accept the route without checking OTC value and redistribute it to its RS-Clients.¶
If RS is implementing [RFC9234], it will reject received routes if OTC is present and will add OTC attribute with value equal to its own AS (the RS's AS number) when advertising routes to its RS-Clients.¶
From the point of 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.¶
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 a RS (i.e., remote AS with a 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.¶
The above update in OTC processing is fully backwards compatible with [RFC9234]. It doesn't require new version or BGP capability negotiations between implementations.¶
This document has no IANA actions.¶
TODO.¶