BGP security: announcing prefixes without authorization

In our last post, we looked at protecting the TCP session that carries BGP information between two routers, mainly against spoofed TCP resets. However, a much more important BGP security issue is the unauthorized advertisement of prefixes. This post will look at that issue specifically.

In 1997, a small ISP in Virginia caused a major disruption to the internet, known as the “AS 7007 incident”. What happened was that AS 7007 started to take prefixes from other autonomous systems and split those up into /24s and propagate those “more specifics” to its ISP Sprint. The reason for this seems to have been a software bug in the AS 7007 router. To add insult to injury, the Sprint routers wouldn’t purge those more specifics from their BGP tables even after AS 7007 was disconnected. As we’ll see again later, two things contribute greatly to such incidents: the longest match first rule and lack of filtering on both sides of the customer-ISP connection.

With the introduction of Classless Inter-Domain Routing (CIDR, RFC 1519), IP address blocks can have any size that’s a power of two. So it’s possible to advertise the address range 192.168.0.0 – 192.168.0.255 in BGP as 192.168.0.0/24, or 192.168.0.0 – 192.168.15.255 as 192.168.0.0/20. But what if both are advertised? In that case, the rule is longest match first: the match for the longest prefix, with the largest number after the slash, is the one that’s used.

So if there’s a route for 192.168.0.0/24 pointing to New York City and a route for 192.168.0.0/20 pointing to Chicago, a packet with destination 192.168.0.31 will be forwarded to New York. Even if the /20 route has a higher local preference, shorter AS path and lower MED than the /24: the BGP best path algorithm is only considered for prefixes that are an exact match.

The advantage of the longest match system is that it makes it easy and efficient to “shoot holes” in a prefix: maybe an ISP in Chicago has 4096 addresses but only uses 3500, so they are in the position to make 256 addresses available to the network in New York. Without the longest match first rule, the Chicago network would have to announce a series of non-overlapping prefixes: 192.168.1.0/24, 192.168.2.0/23, 192.168.4.0/22 and 192.168.8.0/21.

Unfortunately, the longest match first rule also allows for the possibility that a more specific announcement (an announcement of a longer prefix or deaggregate) is announced from the wrong place by accident or maliciously and traffic is routed away from its real destination. Usually, this is avoided by networks making sure they only announce the correct prefixes in the first place, and then ISPs applying filters of their own to make sure that their customers don’t make mistakes; see an earlier blog post. However, the internet is a big place, and mistakes happen.

A notorious example is the Pakistan Telecom-YouTube incident from 2008. At that time, the Pakistani government required ISPs operating in the country to block YouTube. Pakistan Telecom did this by installing a “null route” for the /24 prefix that hosted YouTube’s streaming servers. So any packets Pakistan Telecom customers would send to YouTube would be sent to the router’s null interface instead and dropped, making YouTube’s servers unreachable for those customers. However, Pakistan Telecom also had a configuration in effect that automatically advertised static routes in BGP. So Pakistan Telecom advertised YouTube’s /24 towards its upstream ISP, PCCW in Hong Kong. PCCW didn’t have a filter that limited Pakistan Telecom’s BGP advertisements to just their own prefixes, and propagated the advertisement to the rest of the world.

The rest of the world now saw a /24 route towards YouTube’s servers through Hong Kong, while YouTube’s own advertisement was a /22. So as per the longest match first rule, traffic was sent to Pakistan where it was dropped and YouTube was effectively unreachable. YouTube quickly broke up its own advertisement into /24s, which restored connectivity to some degree as BGP would now consider both the real and the incorrect /24s, sending traffic to the advertisement with the best properties (such as the shortest AS path).

It’s not unheard of for networks to advertise all their address space as /24s to avoid problems like this. /24 is the longest prefix length that is generally accepted for IPv4 BGP advertisements, so this way, it’s not possible for someone else to redirect traffic by advertising a more specific. (With IPv6, things haven’t definitively settled yet, but generally /48s are the longest prefixes that are accepted.) However, the problem with advertising everything as /24s is that this allows for a BGP table with 14 million prefixes, which current routers can’t handle.

Another well-known incident is one where in 2010, 15% of all the internet’s traffic was redirected through China Telecom for 18 minutes—including traffic to some US government and military destinations. Some people assumed a malicious act, but it looks like what happened here is that inside the China Telecom network, BGP prefixes were redistributed into an internal routing protocol such as OSPF and then back into BGP—stripping off the AS path in the process. So the affected prefixes had very short AS paths through China Telecom, often shorter than the AS path towards the source of the legitimate advertisement. And thus traffic flowed through China Telecom, even though there was no deaggregation into more specific prefixes involved in this incident.

And that’s just mistakes. It’s also possible for malicious parties to purposefully advertise a more specific in order to intercept and inspect traffic. Suppose AS 1 advertises 192.168.0.0/20 and has ASes 2 and 3 as ISPs. AS 4 is interested in intercepting AS 1’s traffic. So AS 4 advertises (for instance) 192.168.3.0/24 towards AS 3 with an AS path that includes ASes 1 and 2. AS 3 will propagate this announcement to ASes 1 and 2, but those will ignore the announcement because BGP thinks there’s a loop: AS 1 and AS 2 both see their own AS number already present in the AS path. So ASes 1 and 2 are completely unaware of the malicious /24 advertisement that the rest of the world sees. However, AS 3 will deliver the traffic for 192.168.3.0/24 to AS 4. AS 4 inspects and possibly even modifies the packets, and then forwards them to AS 2 which delivers them to AS 1, which is none the wiser.

There are several services out there that allow you to monitor the advertisement of your prefixes and detect the issues discussed above. One is RIPE’s BGPlay widget, that visually shows how prefixes are propagated in BGP and makes it possible to go back and look at changes over time.

It has been apparent for more than a decade that improvements in BGP are necessary to protect against these security issues. Next week we’ll look at the RPKI system, and the week after that we’ll finish our “BGP security month” with a look at the BGPSEC work that’s currently underway in the IETF.