BGP Route Leaks

Route leaks occur when BGP prefixes are propagated in a way that goes against the expected topology relationships of BGP. For example, this can happen when a route learned from one transit provider is announced to another transit provider or a lateral peer (peer-peer-peer), or when a route learned from one lateral peer is announced to another lateral peer or a transit provider (see RFC7908). These leaks often result from misconfiguration or the absence of BGP route filtering, or from inadequate coordination between autonomous systems (ASes).

I have worked closely on detecting route leaks and we shipped a route-leak detection system under the Cloudflare Radar platform for free public consumption. In short, the system detects potential route leaks by first inferring the inter-AS relationships on a per-prefix-basis, and examines each AS path being announced to detect valley-free violations. However, the detection of route leaks can only help operators so much, where prevention should be the ultimate solution.

RFC9234

RFC9234 documents an active route-leak prevention approach where it defines new BGP capacities (BGP Roles) exchanged during the eBGP session open time and allows the BGP routers to understand AS relationships between local and remote ASes, and thus prevent the propagation of route leaks. RFC9234 also defines a new BGP attributes type, only-to-customer, which tells the receiving BGP routers whether some routes should never be announced to another provider.

When a pair of eBGP routers both implement RFC9234, they will first confirm the BGP role of each other.

With roles defined, it handles the only-to-customer attributes as follows.

In essence, RFC9234 uses BGP roles and OTC attributes to make sure routes received from a provider or a peer can only be propagated to customers.

Only-to-customer Attribute in the Wild

RFC9234 graduated as an official RFC in May 2022, almost one year ago. There have not been many discussions about the deployment of RFC9234, not to mention actual measurements of how widely it is deployed on the Internet.

To observe the deployment of RFC9234, I added the support for RFC9234 to the BGPKIT parser a while back and wrote a quick example code to demonstrate how to parse a RIB file and look for messages that contain only-to-customer attributes.

Here is what I see from parsing one single RIB dump file from route-views2 RIB dump (file link).

From this output, we can see that at least 4 ASes (AS6939, AS15562, AS20555, AS212068) implement RFC9234 and the messages containing OTC attributes propagated to the route collector and got preserved into MRT files.

The code that generates this result is also very simple. It's pretty much just a loop of messages and checking if only_to_customer attribute is present in the message.

use bgpkit_parser::BgpkitParser;

fn main() {
    for elem in BgpkitParser::new(
        "http://archive.routeviews.org/bgpdata/2023.03/RIBS/rib.20230316.0200.bz2",
    )
    .unwrap()
    {
        if let Some(otc) = elem.only_to_customer {
            println!(
                "OTC found: {} for path {}\n{}\n",
                &otc,
                &elem.as_path.as_ref().unwrap(),
                &elem
            );
        }
    }
}

If you would like to try out this example yourself, you can run the following command (assuming you have Rust toolchain installed):

git clone https://github.com/bgpkit/bgpkit-parser
cd bgpkit-parser
cargo run --release --example only-to-customer

---

EDIT on Mar. 16, 2023: Job Snijders shed some more light on the source of OTC attributes. I did not know YYCIX before, pretty cool exchange point!