BGP Route Leak Incident Review

This blog analyzing real-world examples of border gateway protocol (BGP) route leak incidents is part of a BGP security blog series. The first blog overviewed the built-in risks associated with BGP while this blog takes a closer look.

What is a BGP Route Leak?

A route leak is formally defined as the “propagation of a BGP announcement(s) beyond their intended scope_”_ [RC7908]. The scope is defined by BGP import and export policies that AS’s use to regulate the set of routes exchanged over a BGP session.

These policies are usually implemented through commercial agreements between AS’s. They can be roughly classified into two main categories: provider-to-customer and peer-to-peer. In a provider-to-customer relationship, the provider announces to the customer the routes to reach all the internet destinations, while the customer announces to the provider the routes to reach its networks and the networks of its customers. On the other hand, in a peer-to-peer relationship the two AS’s exchange the routes to reach their respective networks and their respective customers’ networks.

More concretely, a leak happens when an AS announces a route received from another provider or peer to a provider or to a peer.

Figure 1 illustrates a BGP route leak. Suppose that AS 5 is a customer of AS 4 and a peer of AS 3. AS 4 announces to AS 5 the reachability of prefix P and AS 5 propagates this route to its peer AS 3, causing a provider-to-peer leak. If AS 3 accepts the leaked route, then other AS’s may be affected (AS 1), but more importantly, AS 5 becomes a transit between a peer (AS 3) and a provider (AS 4) for the traffic directed to P coming from AS 3.

One of the most common consequences of a BGP route leak is performance degradation. The AS causing the leak needs to handle an unexpected amount of traffic and its network may be under-provisioned to handle it.

A leak could also be caused intentionally with the purpose to inspect the traffic before it gets directed to the legitimate destination.

A Closer Look at a Route Leak: Big Trouble in Little Switzerland

The SafeHost incident on June 6, 2019 illustrates a BGP route leak. The media widely covered this incident involving the Swiss data center co-location. One reason for the media attention is China Telecom’s involvement, although they were not the root cause of the leak.

This route leak began when SafeHost (AS21217) announced more than forty-thousand IPv4 routes that had been learned from other peers and providers to its provider China Telecom (AS 4134).

The leaked routes involved prefixes already present in the global BGP table as well as prefixes not already present. In turn, China Telecom accepted these routes and propagated them to its neighbors, contributing to the global spread of the leak.

Route Leak Diagram and Summary

Eventually, leaked routes reached AS’s connected to public route collectors (collector peers) deployed by the University of Oregon Route Views Project and by RIPE NCC (Routing Information Service). Both dumped the routes in MRT format and made them publicly available on their respective websites.

Table 1 reports three examples of the leaked routes announced to the collectors by three different collector peers.

Routes Involved in the SafeHost BGP Leak

You can see the presence of China Telecom (AS4134) followed by SafeHost (AS21217), followed in turn by Level3 (AS3356) and other providers of SafeHost.

Observing the AS_PATH attribute of the leaked routes, notice the AS path prepending done by SafeHost, as if SafeHost’s AS administrator wanted to discourage China Telecom to use that BGP link at all. It is also worth noticing that when public BGP data from before the leak is analyzed, there is no evidence of a BGP connection between AS4134 and AS21217.

To have an idea of how much the leak spread all over the internet, we can analyze how many peers announced to the collector at least one leaked route.

Since it is well known that not all the peers announce the same amount of BGP routing data to the collector, only those peers announcing the full routing table (FRT peers) were taken into consideration.

FRT Peers Announcing Leaked Routes

As can be seen from Figure 3, almost every FRT peer announced at least one leaked route to the collector. Analyzing the distribution of those peers among the Internet regions (figure 4), we see that the leak didn’t spare any region, affecting the routing of the FRT peers independently from their region of membership. The mapping between AS and the related Regional Internet Registry (RIR) was done via the IP to ASN mapping provided by Team Cymru.

Internet region distribution of FRT peers announcing

Note that this piece of information does not say anything about the number of leaked routes that each peer announced to a route collector. To know this, we must look at how many leaked routes each FRT peer announced to the respective collector. This allows us to distinguish peers whose routing was heavily affected from peers whose routing was affected by just a few routes.

Figure 5 shows the distribution of the number of origins, while Figure 6 shows the distribution of the number of subnets that each peer perceived as involved in a leaked route.

As these distributions show, only 20% of FRT peers announced to the collector leaked routes involving more than 100 different origin AS’s and more than 2,000 different subnets.

In particular, the FRT peers closer or even directly connected to China Telecom were the peers announcing the highest number of leaked routes to the collectors. One of these China Telecom clients announced leaked routes involving more than 3,000 different origins and more than 25,000 different subnets.

Number of Origins Per FRT Peer

Number of Subnets per FRT Peer

The leak lasted almost four hours and affected more than 6,000 different origin AS’s.

Figure 7 shows the evolution of the number of affected origins during this time. We see that there are various peaks. For example, at 10:40 am more than 2,500 different origins were affected.

Among the affected origins there were AS’s hosting famous services like WhatsApp and Microsoft, as well as ISPs, banks, and content delivery networks.

Number of Origins Affected

Learn More About BGP and Route Leaks

This SafeHost route leak is not the only type of BGP route leak. Read the next blog in the series to learn more about another route leak incident.

Can’t wait for the next blog? Visit our product page to learn more about finding and fixing BGP issues fast with Catchpoint, and read Comprehensive Guide to BGP Monitoring for a deeper look into BGP routing.