Route leaks push traffic down paths it was never meant to take. We have written and spoken publicly in the past about route leaks in Border Gateway Protocol (BGP) , depicting these events as impactful incidents that cause misdirection of traffic through unintended network paths. BGP routing is driven by the relationships between Autonomous Systems (ASes), i.
e. , customer-provider and peer-peer. Customers pay providers for access to the rest of the Internet, while peers exchange traffic with one another typically under a “settlement-free” arrangement where no money changes hands.
These relationships help define routing rules that form plausible paths. For example, the rules form a “valley-free” hierarchy of how routes should propagate: a route learned from a provider or a peer should be announced only downward to customers, never back up to another provider or peer. Rules like this express an intent or expectation about Internet routes.
A route leak is what happens when that intent is violated. Historically, each network has had to implement this intent on its own, using complex, error-prone routing policies . RFC 9234 ( Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages ) simplifies this by expressing intent within the protocol itself.
It introduces a new “BGP Role” capability , which requires that two BGP neighbors agree on their relationship when the session comes up, and an “Only to Customer” (OTC) path attribute, which marks routes that must not propagate beyond customers. A router that understands OTC can reject a leaked route on its own, without an operator-written policy. We set out to evaluate how well RFC 9234 works on the Internet and how widely it has been adopted.
Relying on our global peering presence, we developed a unique method for tracking the adoption of BGP Role configurations by monitoring which peer ASes send the OTC attribute to Cloudflare. Along the way we found something we did not expect: two large Tier-1 networks strip the OTC attribute from routes they forward. We have been engaging with these Tier-1s to allow OTC attribute propagation through their networks, which aids in enabling route leak prevention capabilities for early adopters of RFC 9234.
Below, we walk through our analysis, why the OTC stripping matters, and how to enable BGP Roles in your own network. Route leak prevention using BGP Roles and the OTC attribute Before the measurements, let’s talk about how BGP Roles and the OTC attribute actually work. Route leaks Route leaks are the “propagation of routing announcements beyond their intended scope,” as defined in RFC 7908 .
The intended scope is determined by AS relationships: provider-to-customer or peer-to-peer. The rules are asymmetric, and it comes down to direction. Routes propagate freely downward: a provider may hand a customer anything in its table.
Propagating routes upward or sideways is restricted to ‘local’ information. Specifically, an AS may send in the upwards or sideways directions only the routes it originates and that are learned from its own customers. The figure below shows what B does with a route it learns from A, depending on A’s relationship to B.
Putting it simply, a route leak happens when an AS takes a route learned from a provider or a peer and announces it to another provider or peer. The route travels down the hierarchy and then back up, creating a “valley” in the hierarchy that the underlying relationships never authorized. Routing paths are required to be valley-free .
Violations of the valley-free property come in many forms. A common shape is a customer announcing a route between two of its providers, also known as a hairpin turn . This scenario is bad for everyone: the customer (AS64504) is not being paid to send traffic between its providers, and it also may not have the capacity to absorb the traffic flowing between the two upstream networks, resulting in increased latency or drops.
Route leaks impact everyone, and they happen often . That’s why we built the Cloudflare Radar route leak detection system to help track routing anomalies continuously. However, despite the frequency and the impact, existing defenses put the burden on network operators who must rely on prefix filters and IRR-derived policies.
Such mechanisms require every AS to express its own relationships correctly, by hand , on every session. RFC 9234 moves that burden into the BGP routing protocol. BGP Roles A BGP Role declares where you sit relative to a neighbor on the given eBGP (External BGP) session.
The Role describes each side of the neighbor relationship: on a session with your transit provider, you configure the Role customer , and they configure the Role provider . There are five options: Provider, Customer, Peer, RS, and RS-Client. The first three are the transit and lateral-peering relationships described above.
RS and RS-Client involve Internet Exchange (IX) route servers , where a route server acts like a provider to all of its clients, re-announcing prefixes between IX members transparently. Only five pairings of the five roles are valid: RFC 9234 states a Role should be configured at the local AS on every eBGP session. During partial deployment, most sessions will have a Role on one side only.
RFC 9234 handles that by default: if you send the Role capability and your neighbor does not, the session still comes up, and your locally configured Role still drives partial route leak prevention. An operator who wants a stronger guarantee can enable "strict mode," which rejects any session where the neighbor sends no Role capability. Strict mode is opt-in, and as the adoption numbers later in this post show, it is not yet realistic for most networks.
When both sides send a Role and the pair is not one of the five above (e. g. , one end says customer and the other says peer), the session is rejected with a Role Mismatch notification (code 2, subcode 11).
Originally published at blog.cloudflare.com
