What is BGP prefix hijacking? (Part 1)

By Tiziano Tofoni, CEO of Reiss Romoli, Flavio Luciani, CTO of Namex (Roma IXP) & MANRS ambassador, and Hiba Eltigani, MANRS fellow

BGP (Border Gateway Protocol) has been at the core of routing in the Internet for more than 25 years and, just like the Internet, it was founded on the principle of trust in your peers and in other networks. But, as the Internet has grown, so have issues with security and bad practice, and routing incidents have increased.

Many of these incidents are caused by incorrect routing information, the most common of which are prefix hijacking and route leaks. These take advantage of BGP’s basic vulnerability: that it cannot verify which autonomous systems (AS) sending announcements are legitimately permitted to do so.

Prefix hijacking happens when a network, whether intentionally or mistakenly, originates a prefix that belongs to another network without its permission. Instances of prefix hijacking are more frequent than it may first seem – the following graph shows the number of prefix hijacks from mid-January to July 2020, equating to an average of 14 a day.

Number of prefix hijacks from January-July 2020 (Source: BGPStream)

In many cases, hijacking causes minimal disruptions to traffic, but in others the impact is tremendous. For example, in February 2008 Pakistan Telecom (AS 17557) injected an unauthorised BGP announcement of the more specific prefix 208.65.153.0/24, part of the prefix 208.65.152.0/22 that was assigned to YouTube. One of Pakistan Telecom’s upstream providers, PCCW Global (AS3491), then propagated the prefix to the rest of the Internet, allowing Pakistan Telecom to attract part of YouTube’s global traffic.

The incident continued for around two hours – it took YouTube roughly an hour to detect and partially mitigate the problem, and then PCCW Global stopped the announcement. During this time YouTube was unreachable for most of the Internet. If you were serving more than 100 million videos daily, imagine what an hour’s outage could do to your revenues, not to mention the subsequent loss for network providers.

Despite the best efforts to minimise prefix hijacks, the issue continues to prevail. In April 2020, as many as 8,800 prefixes were hijacked by AS12389 (Rostelecom), according to BGPmon. The incident affected several providers, including Amazon and Akamai.

Here’s an example of prefix hijacking. AS1 receives the prefix 198.51.100.0/22 from a Regional Internet Registry (RIR), and is therefore the only autonomous system authorised to originate 198.51.100.0/22 on the Internet. Let’s suppose that AS5 sends a BGP announcement with the same prefix. A generic AS on the Internet will then receive two announcements of 198.51.100.0/22, and is at the mercy of the BGP selection process. AS2, for example, could still see the announcements from AS1 as the best path, while AS4 could choose AS5. If the unauthorised illegal announcement is chosen as the best path, the traffic directed towards this prefix would be hijacked into a black hole and potentially analysed.

Case 1: Unauthorized announcement of the same prefix1

An even more dangerous situation could happen if AS5 creates a subnet of the prefix – such as 198.51.100.0/23, in the example below. In such a case the whole Internet, including AS2, will see AS5 as the best path. This type of prefix hijacking is precisely the one that caused the incident with YouTube in 2008.1

Case 2: Unauthorized announcement of more specific prefix

These two cases show the inherent vulnerability within BGP: there is no way of confirming whether or not an entity is authorised to originate a specific prefix.

Fortunately, there is a way to mitigate this problem. Information about holdership and allocation of Internet resources, such as AS numbers and prefixes, is contained within public databases managed by RIRs. In addition, some RIRs host other databases known as Internet Routing Registries (IRRs), where network operators can store information about their routing policies and routed prefixes – which they can also use to generate filters to prevent prefix hijacking.

For filters to work successfully, network operators must build them using the specific IRR information and always keep this information up to date. They also need to collaborate with each other to prevent major breakdowns and quickly resolve any issues. The routing and contact information within the IRR databases is especially crucial these days, given the magnitude of networks on the Internet.

Unfortunately, however, the IRR system is far from accurate, either because content isn’t updated, or it contains errors. A more robust and solid mechanism to help prevent prefix hijacking is Resource Public Key Infrastructure (RPKI). This is based on digital certification, which allows anyone consulting its repository to validate that an association between a prefix and autonomous system is correct.

In the second part of this article, we’ll explain the benefits of RPKI in more detail and look at how it helps to preserve the resilience and security of the Internet.

Stay tuned!

[1]NOTE: IP addresses used in the following examples are provided for use in documentation as described in the RFC 5737. The concepts however don’t change.

Leave a Comment