Why don't we see more routing attacks?

So, who remembers the whole "Pakistan kills YouTube" debacle from February last year? Here's an article on the topic to refresh your memory:

Insecure routing redirects YouTube to Pakistan

The gist of the story is that Pakistan intended to block YouTube for their national network. They tried to accomplish this by advertising routing information with a higher priority than YouTube's own information, and which mapped YouTube's IP addresses into their network. This route advertisement propagated onto the internet, causing every server in the world to think that the way to get to YouTube was through Pakistan.

My question is: if something like that can happen accidentally through incompetence, could a malicious party do this deliberately? What safeguards are in place to prevent an attack like this? If Pakistan can do this to YouTube by accident, why can't Iran do this to Twitter on purpose?

Solution 1:

Currently, not much stands in the way of rogue advertisements other than trying to be responsible and filtering your BGP announcements outbound to the your upstreams, and hoping they do the same.

The Internet routing table is so large (~290,000 routes at this very moment), that it's generally hard to build filters to lock down every single route (either: the device isn't capable of having an access list with a large number of routes, or if it happens to be, your performance would degrade so significantly due to CPU usage that you'd go back to no filtering).

While some ISPs do perform filtering on what they receive from customers (and others may require customers to register their routes in the RADB, a global routing registry), this works perfectly for you and me with say, 1 to 25 routes. In the cases of large customers (cable companies, state-run ISPs, etc.) it becomes a bit difficult to build and maintain an access list for these folks who will carry 500, 600, and sometimes even 2,000 routes, so you choose not to filter and it becomes a matter of trust and assumptions:

"You run a large enough network, so you must have done something right in the past, and we've all learned from the AS7007/SprintLink debacle, right? So please don't send me evil routes."

Long-winded and humorous history aside, this is commercial Internet in its adolescence, where people have different agendas, so without some more advancements in control plane horsepower from network equipment vendors, there's not much to do at the moment without taking the security-performance trade-off into account:

• Deal with YouTube route hijacking if and when it happens for a momentary inconvenience? Or penalize all your customers' performance to make sure keyboard cat keeps playing?

Solution 2:

While a malicious party could do this, they'd have to have a working BGP session that was passing unfiltered routes to a major ISP. That said, Renesys do say that a certain (tiny) amount of similar activity does occur (see here) whether malicious, or accidental.

The reason Iran can't do this to twitter on purpose is essentially that ISPs peered with BGP almost certainly filter routes from Iran, especially for ASes that are politically sensitive. That said, Iran could easily block twitter internally like this.

Solution 3:

We don't see if very often because way back in '97 it happened in the US, but only much worse. Here's the story though you need to know a bit about how BGP works to really understand what happened.

http://merit.edu/mail.archives/nanog/1997-04/msg00380.html

As a network engineer in '99-01 I setup a number of BGP peering sessions. In order to do so you as the smaller network weres asked a number of questions:

1. What's your IP space?
2. Do you need to announce /24s for your space? If so which ones?
3. Have you registered this IP with radb?
4. What's your ASN?
5. Do you have other ASNs?
6. Are all those registered with radb? and so on.

These were used to filter the routes I announced to my upstreams. I would also filter martian IPs, unassigned IPs, any route with more significant bits than /24, and a few other safety things. This gets harder to do at the NSP level where you're actually peering rather than multihoming and taking full BGP feeds from our upstreams like we were.

This is a good resource for building a Cisco BGP template with some of the basic filtering all BGP users should have. http://www.cymru.com/Documents/secure-bgp-template.html

Solution 4:

+1 for Cian. But just to add on the topic of filtering.

All responsible providers should and do place ingress filters on their peering sessions to ensure that they only receive and redistribute route annoucements within a given range (prefix length) for a each peer.

This goes most of the way in preventing such mistakes and maliciousness from propagating.