Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Danny McPherson, Arbor Networks: Internet Routing Insecurity: Pakistan Nukes YouTube?

March 2008 by Danny McPherson, Chief Research Officer, Arbor Networks

So, assume you’re an ISP in Pakistan and, for whatever reason, you receive an order such as this (PDF) from the Pakistan Telecommunication Authority (PTA). The letter is from the Deputy Director of Enforcement with the PTA, and is requiring that you immediately block access to a YouTube URL, or more specifically (actually, less specifically, but that’s a different issue), that you block access to 3 specific IP addresses: 208.65.153.238, 208.65.153.253 and 208.65.153.251.

These three IP addresses correspond to the DNS A resource records associated with www.youtube.com:

danny@rover% host -t a www.youtube.com

www.youtube.com has address 208.65.153.238

www.youtube.com has address 208.65.153.251

www.youtube.com has address 208.65.153.253

So, avoiding all discussion about whether or not said censorship is appropriate, and just focusing on how you’d actually go about blocking access to these IPs, or YouTube in general, you have a few options. Realistically, as a network engineer you could either:

deploy access-control lists (ACLs) on all your router interfaces dropping packets to or from these IPs

OR statically route the three IPs, or perhaps the covering prefix (208.65.153.0/24), to a null or discard interface on all the routers in your network

OR employ something akin to a BGP blackhole routing function that results in all packets destined to those three specific IPs, or the covering prefixes, being discarded as a result of null or discard next hop packet forwarding policies, as discussed here

The first of which would require that you augment all existing ACL filtering policies on all router interfaces in your network, the second would require that you add static routes to every router in your network, and the last of which typically requires only that you announce a route for 208.65.153.0/24 to all your routers, tagged with a BGP community that maps to a “blackhole” policy on routers in your network.

So, assume you pick option 2. However, what you fail to recall is that your routing policies currently result in redistribution of all configured static routes into your set of globally advertised BGP routes. The net result is that you start announcing to the world that you provide destination reachability for the YouTube 208.65.153.0/24. Or, assume you pick option 3 above but your policies are broken such that you inadvertently announce reachability for 208.65.153.0/24 to your upstream provider, who happily conveys this to the global Internet. Same effect…

Either way, the net-net is that you’re announcing reachability to your upstream for 208.85.153.0/24, and your upstream provider, who is obviously not validating your prefix announcements based on Regional Internet Registry (RIR) allocations or even Internet Routing Registry (IRR) objects, is conveying to the rest of the world, via the Border Gateway Protocol (BGP), that you, AS 17557 (PKTELECOM-AS-AP Pakistan Telecom), provide reachability for the Internet address space (prefix) that actually belongs to YouTube, AS 36561.

To put icing on the cake, assume that YouTube, who owns 208.65.153.0/24, as well as 208.65.152.0/24 and 208.65.154.0/23, announces a single aggregated BGP route for the four /24 prefixes, announced as 208.65.152.0/22. Now recall that routing on the Internet always prefers the most specific route, and that global BGP routing currently knows this:

208.65.152.0/22 via AS 36561 (YouTube)

208.65.153.0/24 via AS 17557 (Pakistan Telecom)

And you want to go to one of the YouTube IPs within the 208.65.153.0/24. Well, bad news.. YouTube is currently unavailable because all the BGP speaking routers on the Internet believe Pakistan Telecom provides the best connectivity to YouTube. The result is that you’ve not only taken YouTube offline within your little piece of the Internet, you’ve single-handedly taken YouTube completely off the Internet.

A complete denial of service (DoS), intentional or not.

Even uglier is that even if the folks at YouTube begin announcing the /24 as well, and the global routing table looks like this:

208.65.152.0/22 via AS 36561 (YouTube)

208.65.153.0/24 via AS 36561 (YouTube)

208.65.153.0/24 via AS 17557 (Pakistan Telecom)

YouTube reachability will still be half-broken, as the prefix length for the route via Pakistan Telecom is the same length as the prefix length for the YouTube announced route, and so BGP will [usually] next consider the shortest BGP path as the optimal route to the destination based solely on number of AS ‘hops’, resulting in a large portion of the Internet still preferring the /24 via Pakistan Telecom. You’re probably asking yourself now, then why doesn’t YouTube announce two /25s for the /24 in question? The reality is that most providers on the Internet don’t accept anything longer than a /24 BGP route announcement, so it’d be filtered and not installed in their routing tables.

So, what’s the root problem here? Let’s see, where to start:

no authoritative source for who owns and/or is permitted to provide transit services for what IP address spaces on the Internet

little or no explicit BGP customer prefix filters on the Internet

little or no inter-provider prefix filtering on the Internet

no route authentication and authorization update mechanism (eg., SBGP, soBGP, etc..) in today’s global routing system

I fully suspect that the announcements from Pakistan Telecom for YouTube address space were the result of a misconfiguration or routing policy oversight, and seriously doubt impact to YouTube reachability [beyond Pakistan’s Internet borders] was intentional. The route announcements from Pakistan Telecom have long since been withdrawn (or filtered). We had a similar event at an ISP I worked for in 1998 (YES, a decade ago) - obviously, nothing has changed regarding this extremely fragile and vulnerable piece of Internet infrastructure since that time.

Some pointers to different discussions regarding prefix filtering on the Internet are available here, and here (search for ‘filter’). Our friends at Renesys, who blogged in parallel about some of the routing aspects of the event here, the Prefix Hijack Alert System (PHAS), a few various features in our very own Arbor Peakflow, and some other products do help detect hijackings of this sort. As far as prevention, well, as unbelievable as it may seem, you’re mostly out of luck today, unfortunately.

Interestingly, in the latest edition of the Infrastructure Security Report, BGP route hijacking yet again took a back seat to pretty much everything else in the list (in the world?). I suspect until the next event, it will again…


See previous articles

    

See next articles


Your podcast Here

New, you can have your Podcast here. Contact us for more information ask:
Marc Brami
Phone: +33 1 40 92 05 55
Mail: ipsimp@free.fr

All new podcasts