Blog Post

One Year of BGP (In)security

Published
April 9, 2020
#
 mins read
By 

in this blog post

On April 1, 2020, nearly 9,000 networks were victims of BGP hijack. Unfortunately, BGP security issues such as hijacks have the power to bring businesses to their knees. We’ve written a five-blog series to help companies better prepare for such incidents.

The series will define BGP security issues like hijacks and route leaks, and deep-dive into real-world examples. All of these examples featured in this series, taken from 2019, gave huge headaches to network administrators all around the world.

Primer on BGP Security

The Border Gateway Protocol (BGP) is one of the protocols that played a key role in sustaining the internet growth after its commercialization in the early 90s. Despite turning 30 years old last June, its current version (4, RFC 4271) is still recognized as the de-facto standard inter-domain routing protocol used by autonomous systems (AS’s) to exchange routing information with each other.

The key feature of BGP is its flexibility. BGP allows network administrators to implement the most variegated import/export policies to reflect traffic engineering decisions or economic agreements between BGP neighbors.

This flexibility, however, comes with a cost. It is a well-known fact that BGP is not immune to routing incidents. BGPStream estimated that hundreds of incidents happened in each month of last year, with a peak during the month of June when the famous leak involving the Cloudflare network occurred.

BGP Security Hijacks and leaks 2019

Figure 1: 2019 Hijacks and leaks (source: bgpstream.com/)

At the heart of all of these issues is this fact: BGP was designed without any focus on security. According to the original BGP author’s admission, “security wasn’t even on the table” and “there was no concept that people would use this to do malicious things.”

Because of this, BGP lacks an intrinsic mechanism to secure routing – i.e. to authenticate the content of BGP updates – and therefore it is prone to attacks and misconfigurations such as hijacks and route leaks.

Measuring the Impact of BGP Hijacks and Leaks

This blog series focuses on three major BGP security issues from 2019:

  • A June BGP route leak originating at a Swiss data center
  • A May origin hijack
  • A June provider-to-provider BGP route leak

However, these are just a few of the 2019 hijacks and leaks. For example, BGPStream numbers show:

  • 600+ AS’s were victims of a hijack
  • 800+ AS’s were victims of a leak

Classifying the BGP incidents based on size by using the CAIDA AS Rank helps us to better understand them. The CAIDA AS Rankings classify AS’s on the basis of their customer cone size, which includes the number of direct and indirect customers.

In this ranking, the larger cones have a higher rank. Figure 2 and Figure 3 show the AS rank distribution of AS’s victim of a hijack and leak. These figures showcase that AS’s of all sizes, large to small, have been victims of BGP security incidents.

BGP Hijacks in 2019 by AS size

BGP Hijack chart

Figure 2: Rank by size of AS’s victim of BGP hijacks

BGP Route Leaks in 2019 by AS size

BGP route leak chart

Figure 3: Rank by size of AS’s victim of BGP route leaks

As far-reaching as these figures seem, they still might not be revealing the extent of the issue. These numbers are very likely to be an underestimation for various reasons.

First, it is well-known that only a few hundred AS’s are currently sharing a full routing table with public route collectors, so data is largely incomplete.

Second, a peer connected to a route collector may not announce to the collector everything it receives. An AS could receive an invalid route (e.g. a leak) but not advertise it to the collector simply because it is not selected as the best route by the decision process, or because it is filtered by some mechanism, e.g. RPKI validation, peer-lock, or import policies.

Figure 4 captures this concept by showing the distribution of the number of BGPStream peers which detected a routing incident according to what is reported by on the BGPStream. As can be seen, about 50% of the hijacks were perceived by more than 50 peers and 40% of the leaks were perceived by more than 20 peers.

Distribution of Peers Detecting BGP Routing Incident

BGP routing incident chart

Figure 4: Distribution of BGPStream peers which detected a BGP routing incident

Furthermore, it is possible that a routing anomaly could have been constrained in a given routing region (e.g. a country) without being noticed by any route collector. This could be due to the poor amount of data sources in that given region and existing import/export routing policies.

For example, take into consideration Figure 5 and assume that E is the only AS that applied the tight import policies. If F triggers a malicious hijack attack, it will most likely affect A, B, C, and D due to their loose import policies, while E will most likely drop the announcement.

Now assume that a route collector R is connected to E, and that E is a FRT peer of R. In this case, R will never see the hijack attempt, but the hijack will still create headaches to the legitimate owner in that particular region with several complaints from his/her clients.

For this reason, it is of fundamental importance that every BGP monitoring infrastructure collects BGP data from the most diversified data sources as possible.

Route Collector Placement Importance

Figure 5: Route collector placement importance

Taking A Closer Look at BGP Security Incidents

Given the inherent vulnerabilities of BGP routing, and that issues affect companies of all sizes, in this blog series we’ll take a deep-dive into three examples.

We’ll also cover security mechanisms that have been adopted in order to overcome BGP routing’s insecurity.

Next in the series is a look at route hijacks and BGP leaks, then a look at preventing both.

Visit our product page to learn more about finding and fixing BGP issues fast with Catchpoint, and download our ebook, The Comprehensive Guide to BGP.

On April 1, 2020, nearly 9,000 networks were victims of BGP hijack. Unfortunately, BGP security issues such as hijacks have the power to bring businesses to their knees. We’ve written a five-blog series to help companies better prepare for such incidents.

The series will define BGP security issues like hijacks and route leaks, and deep-dive into real-world examples. All of these examples featured in this series, taken from 2019, gave huge headaches to network administrators all around the world.

Primer on BGP Security

The Border Gateway Protocol (BGP) is one of the protocols that played a key role in sustaining the internet growth after its commercialization in the early 90s. Despite turning 30 years old last June, its current version (4, RFC 4271) is still recognized as the de-facto standard inter-domain routing protocol used by autonomous systems (AS’s) to exchange routing information with each other.

The key feature of BGP is its flexibility. BGP allows network administrators to implement the most variegated import/export policies to reflect traffic engineering decisions or economic agreements between BGP neighbors.

This flexibility, however, comes with a cost. It is a well-known fact that BGP is not immune to routing incidents. BGPStream estimated that hundreds of incidents happened in each month of last year, with a peak during the month of June when the famous leak involving the Cloudflare network occurred.

BGP Security Hijacks and leaks 2019

Figure 1: 2019 Hijacks and leaks (source: bgpstream.com/)

At the heart of all of these issues is this fact: BGP was designed without any focus on security. According to the original BGP author’s admission, “security wasn’t even on the table” and “there was no concept that people would use this to do malicious things.”

Because of this, BGP lacks an intrinsic mechanism to secure routing – i.e. to authenticate the content of BGP updates – and therefore it is prone to attacks and misconfigurations such as hijacks and route leaks.

Measuring the Impact of BGP Hijacks and Leaks

This blog series focuses on three major BGP security issues from 2019:

  • A June BGP route leak originating at a Swiss data center
  • A May origin hijack
  • A June provider-to-provider BGP route leak

However, these are just a few of the 2019 hijacks and leaks. For example, BGPStream numbers show:

  • 600+ AS’s were victims of a hijack
  • 800+ AS’s were victims of a leak

Classifying the BGP incidents based on size by using the CAIDA AS Rank helps us to better understand them. The CAIDA AS Rankings classify AS’s on the basis of their customer cone size, which includes the number of direct and indirect customers.

In this ranking, the larger cones have a higher rank. Figure 2 and Figure 3 show the AS rank distribution of AS’s victim of a hijack and leak. These figures showcase that AS’s of all sizes, large to small, have been victims of BGP security incidents.

BGP Hijacks in 2019 by AS size

BGP Hijack chart

Figure 2: Rank by size of AS’s victim of BGP hijacks

BGP Route Leaks in 2019 by AS size

BGP route leak chart

Figure 3: Rank by size of AS’s victim of BGP route leaks

As far-reaching as these figures seem, they still might not be revealing the extent of the issue. These numbers are very likely to be an underestimation for various reasons.

First, it is well-known that only a few hundred AS’s are currently sharing a full routing table with public route collectors, so data is largely incomplete.

Second, a peer connected to a route collector may not announce to the collector everything it receives. An AS could receive an invalid route (e.g. a leak) but not advertise it to the collector simply because it is not selected as the best route by the decision process, or because it is filtered by some mechanism, e.g. RPKI validation, peer-lock, or import policies.

Figure 4 captures this concept by showing the distribution of the number of BGPStream peers which detected a routing incident according to what is reported by on the BGPStream. As can be seen, about 50% of the hijacks were perceived by more than 50 peers and 40% of the leaks were perceived by more than 20 peers.

Distribution of Peers Detecting BGP Routing Incident

BGP routing incident chart

Figure 4: Distribution of BGPStream peers which detected a BGP routing incident

Furthermore, it is possible that a routing anomaly could have been constrained in a given routing region (e.g. a country) without being noticed by any route collector. This could be due to the poor amount of data sources in that given region and existing import/export routing policies.

For example, take into consideration Figure 5 and assume that E is the only AS that applied the tight import policies. If F triggers a malicious hijack attack, it will most likely affect A, B, C, and D due to their loose import policies, while E will most likely drop the announcement.

Now assume that a route collector R is connected to E, and that E is a FRT peer of R. In this case, R will never see the hijack attempt, but the hijack will still create headaches to the legitimate owner in that particular region with several complaints from his/her clients.

For this reason, it is of fundamental importance that every BGP monitoring infrastructure collects BGP data from the most diversified data sources as possible.

Route Collector Placement Importance

Figure 5: Route collector placement importance

Taking A Closer Look at BGP Security Incidents

Given the inherent vulnerabilities of BGP routing, and that issues affect companies of all sizes, in this blog series we’ll take a deep-dive into three examples.

We’ll also cover security mechanisms that have been adopted in order to overcome BGP routing’s insecurity.

Next in the series is a look at route hijacks and BGP leaks, then a look at preventing both.

Visit our product page to learn more about finding and fixing BGP issues fast with Catchpoint, and download our ebook, The Comprehensive Guide to BGP.

This is some text inside of a div block.

You might also like

Blog post

Preparing for the unexpected: Lessons from the AJIO and Jio Outage

Blog post

Learnings from ServiceNow’s Proactive Response to a Network Breakdown

Blog post

DNS misconfiguration can happen to anyone - the question is how fast can you detect it?