RIPE NCC publishes case study of youtube.com hijack

Fri Feb 29 17:32:03 UTC 2008

On Feb 29, 2008, at 7:46 AM, David Ulevitch wrote:

>
>
> The report states:
>
>> Sunday, 24 February 2008, 20:07 (UTC): AS36561 (YouTube) starts  
>> announcing 208.65.153.0/24. With two identical prefixes in the  
>> routing system, BGP policy rules, such as preferring the shortest  
>> AS path, determine which route is chosen. This means that AS17557  
>> (Pakistan Telecom) continues to attract some of YouTube's traffic.
>
> It's worth noting that from where I sit, it appears as though none  
> of Youtube's transit providers accepted this announcement.  Only  
> their peers.

A simple artifact of shortest AS path route selection.  In addition,  
many
providers employ policies that apply preference for prefixes learned  
from
customers over those learned from peers, assuming they're of the same
length.

Had those same providers explicitly not accepted the /24 announcement
from AS 17557 via their peers you wouldn't have been affected at all.

> The point is -- Restrictive customer filtering can also bite you in  
> the butt.  Trying to require your providers to do a "ge 19 le  
> 25" (or whatever your largest supernet is), rather than filters for  
> specific prefix sizes seems a worthwhile endeavor so you can de- 
> aggregate on the fly, as necessary.

Deaggregation in order to mitigate less specific route hijacking is a  
hack
that in most cases only half fixes the problem, if that.  If providers  
didn't
have those policies in place it'd be /32s that were being hijacked and
route table growth and churn would be far worse than it already is.

You prevent this by ubiquitous deployment of explicit customer and  
inter-
provider prefix filters, you don't open things up more so that when  
problems
occur, folks can try to hack around them.

-danny