Preventing and Detecting BGP Route Leaks With the Help of RFC 9234

Existing approaches to prevent route leaks rely on operators marking routes with no check that the configuration corresponds to that of the eBGP neighbor, or enforcement of the two eBGP speakers agreeing on their peering relationship.

RFC 9234 reduces this lack of coordination between neighboring autonomous systems (ASes) by adding a new configuration parameter (BGP Role) and check function (Only to Customer, OTC) to BGP OPEN messages, providing greater context and agreement as to the peering relationship on each eBGP session, and improving the prevention and detection of route leaks.

Below is an adaption of a post by the folks at Qrator Labs on the RFC and its significance in improving routing security.

What is a BGP Role? 

BGP Role is a new configuration parameter that is negotiated using the BGP Role Capability in the BGP OPEN message to prevent and detect BGP route leaks caused by errors/misconfigurations.

Your BGP Role describes the peering relationship — provider, customer, peer, route server, and route server client — you have with your neighbor.

When you update your Role it’s translated into BGP capability code, which is negotiated during the BGP session establishment process.

Combining it With OTC

During a BGP OPEN message exchange, there is an automatic check that the provider-customer pair is the correct pair. If one side configures the provider role and its counterpart peer role, or if someone misclicks, the BGP session won’t establish.

This OTC check prevents ASes from creating leaks and detects leaks created by the ASes in the middle of an AS path.

When a provider sends a prefix to its customer, it sets the OTC attribute with the value of its own AS. If this attribute is not set, the customer also adds it with the value of its neighbor’s AS. Note, it doesn’t matter who sets the attribute, the value is the same.

As per Figure 1, there are two checkpoints for the provider and customer to see if OTC is set. If a customer fails to configure their filters, nothing will happen because the provider can instantly detect any route leaks.

The RFC is quite precise about what to do when you detect a route leak — reject the route.

Limiting Factors

There are some limiting factors associated with using BGP Role and OTC to detect and prevent route leaks. Specifically, BGP Roles are not intended to deal with any hacking activity — they are focused on preventing and detecting errors/misconfigurations.

To prevent hacking-related leaks, we suggest deploying ASPA in combination with ROA. Note, ASPA is complementary to BGPSec, although both have a way to go before we see a wide adoption among Internet Service Providers.

However, given that the majority of route leaks are associated with errors/misconfigurations, it’s our view that BGP Roles can sufficiently prevent and detect 80% of BGP route leaks for major Internet Exchanges and the world’s largest operators (Tier-1s).

Try it for Yourself

If you’re using open-source tools try setting up BGP Roles for yourself. In Figure 2 you can see how to configure BGP Roles on BIRD and FRR. The yellow part is what you need to configure BGP roles with, and OTC will do all the work for you. The bottom screenshot shows what happens if the roles are configured with mistakes — when a corresponding role does not match the BGP session won’t come up.

Figure 3 shows what is happening behind the scenes — An OTC attribute is emerging in the route, but you are not configuring it – it’s done in the code for you.

Note. Currently, we are aware that there are patches applied to the three major open-source implementations (Table 1) — an effect of its relative novelty at this point.

If you’re using vendor software, send a request for BGP Roles support. And if you’re a developer, there is a lot of opportunity to contribute to other BGP implementations, including BMP parsers, TCP dump implementation, and BGP dumps.

Let’s hope that with the help of RFC 9234, we can get at least started with eliminating BGP anomalies for a better Internet.

We wish to thank the RFC’s authors for all their work: A. Azimov (Qrator Labs & Yandex), E. Bogomazov (Qrator Labs), R. Bush (IIJ & Arrcus), K. Patel (Arrcus), K. Sriram.

This post is an adaption of the original post, which appeared on the Qrator Labs Blog.

Alexander Kozlov is a writer at Qrator Labs.