]> Strict Only to Customer (OTC) Verification on Route Server Sessions Cloudflare, Inc.
Champaign Illinois United States of America bryton@cloudflare.com
Yandex
Ulitsa Lva Tolstogo 16 Moscow 119021 Russian Federation a.e.azimov@gmail.com
Routing Inter-Domain Routing BGP route leak OTC route server IXP 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.
Introduction The specifies OTC attribute and Peering Roles: Cusromer, Provider, Peer, RS, and RS-Client. Section 5 of , 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.
For the routes received from an RS, doesn't specify any checks, though an RS basically provides service for indirect peering, thus same procedure to a Peer should be applied. extends the OTC check on RS-Clients to verify that if OTC is present, its value matches the RS's AS number.
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 when, and only when, they appear in all capitals, as shown here.
Terminology Terminology follows : 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 . A transparent RS does not insert its own AS number into the AS_PATH of routes it redistributes ; most production route servers are transparent. Example AS numbers are from the documentation range .
Problem Statement A RS exists to redistribute routes between RS-Clients that peer laterally through it. The 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 , 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.
Update to the OTC Ingress Procedure This section updates Section 5 of 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.
Operational Considerations The above update in OTC processing is fully backwards compatible with . It doesn't require new version or BGP capability negotiations between implementations.
IANA Considerations This document has no IANA actions.
Security Considerations TODO.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Exchange BGP Route Server This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. A Border Gateway Protocol 4 (BGP-4) This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Informative References Autonomous System (AS) Number Reservation for Documentation Use To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community.