Cloudflare's OTC tracking reveals two Tier-1 networks stripping BGP route leak prevention
Cloudflare's adoption tracking for RFC 9234's OTC attribute uncovered two Tier-1 networks that strip the attribute, hindering route leak prevention. The post explains BGP Roles, OTC mechanics, and the path to wider deployment.

Route leaks are a persistent BGP problem: traffic gets pushed down paths it was never meant to take, often because a network misinterprets its relationships with neighbors. For years, the fix has been manual—operators hand-write prefix filters and IRR-derived policies on every session, a process that's error-prone and hard to scale.
RFC 9234 changes the game by moving route leak prevention into the protocol itself. It introduces a BGP Role capability that lets two neighbors agree on their relationship when the session comes up, and an Only to Customer (OTC) path attribute that marks routes which must not propagate beyond customers. A router that understands OTC can reject a leaked route on its own, without operator-written policy.
How BGP Roles and OTC work
BGP Roles declare where you sit relative to a neighbor on an eBGP session. There are five roles: Provider, Customer, Peer, RS, and RS-Client. Only five pairings are valid: Provider-Customer, Customer-Provider, RS-RS-Client, RS-Client-RS, and Peer-Peer. If both sides send a Role and the pair isn't valid, the session is rejected with a Role Mismatch notification (code 2, subcode 11).
This rejection is a feature: a Role mismatch means the two networks disagree about their relationship, which is exactly the kind of latent misunderstanding that later surfaces as a route leak. Failing the handshake is better than failing as an incident.
OTC is an optional transitive path attribute (type code 35) that records the AS that first sent the route sideways or downward. Once set, RFC 9234 requires it to be preserved unchanged. Because it's optional transitive, even routers without RFC 9234 support are expected to pass it along rather than discard it.
The measurement and the surprise
Cloudflare developed a method to track RFC 9234 adoption by monitoring which peer ASes send the OTC attribute to them. The results were encouraging—adoption is happening—but they also found something unexpected: two large Tier-1 networks strip the OTC attribute from routes they forward.
This stripping matters because it breaks the chain of trust that OTC relies on. If a Tier-1 removes the attribute, downstream networks lose the ability to detect and reject leaked routes that originated beyond that Tier-1. Cloudflare has been engaging with these Tier-1s to allow OTC propagation, which would enable route leak prevention for early adopters.
Why this matters
The discovery highlights a key challenge in incremental deployment of BGP security mechanisms. Even if you adopt RFC 9234, your protection is only as good as the weakest link in the path. If a Tier-1 strips OTC, your network may not receive the attribute on routes that need it, leaving you vulnerable to leaks you thought you were protected against.
Cloudflare's post walks through how to enable BGP Roles on your own network, and the importance of configuring Roles together with ASPA validation. The two mechanisms complement each other: Roles tell the router which ASPA algorithm to apply, so they should be deployed together on routers that support both.
The full post includes detailed analysis of the adoption numbers and the specific Tier-1s involved, but the takeaway is clear: RFC 9234 is a solid step forward, but its real-world effectiveness depends on universal propagation of OTC. Until the Tier-1s stop stripping it, early adopters are flying with one wing.
A Role mismatch fails the handshake instead of failing later as an incident.
| Local AS Role | Remote AS Role |
|---|---|
| Provider | Customer |
| Customer | Provider |
| RS | RS-Client |
| RS-Client | RS |
| Peer | Peer |
Discussion
0 Comments
Be the first to start the discussion.