[renesys] The New Threat: Targeted Internet Traffic Misdirection

Wed Nov 27 04:03:37 UTC 2013

On Tue, Nov 26, 2013 at 4:31 PM, Christopher Morrow
<morrowc.lists at gmail.com> wrote:
> first, awesome, thanks...
>
> On Tue, Nov 26, 2013 at 4:09 PM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> <snip>
>>   68.164.80.0/20
>>   68.164.96.0/21
>>   68.164.126.0/23
>>   68.164.160.0/21
>>   68.164.192.0/21
>>   68.164.208.0/23
>>
>> These addresses have no relationship with Iceland so we can say it's a
>> hijacking. But do note there is no AS prepending in the announce (the
>> trick described by Kapela & PIlosov to create a clean return path).
>
> yea.. so this smells, to me, like a leak from a 'route optomization'
> box (netvmg or whatever they eventually became). These are all pretty

So, I was thinking over dinner that there's a simpler explanation
(that fails if this was a more full-table-ish leak) that the Icelandic
provider could have done something like putting external-bgp data into
their IGP then pulling back out to bgp ... which is a lot more like
AS7007-like problems than netvmg-like problems.

I would expect that ospf/isis would barf with ~400k paths though, so
i'm still betting on netvmg-ish issues.

> small prefixes and there are covering routes for these as well: (for
> one: 68.164.24.0/21  - from the RV data)
>
> 18566   | 68.164.0.0/14       | MEGAPATH5-US - MegaPath Corporation
> 18566   | 68.164.24.0/21      | MEGAPATH5-US - MegaPath Corporation
>
>
> so... err... potentially:
>   1) route-optomization-box sends routes into iBGP with local origin-as
>   2) routes aren't properly managed (community/etc) from local ISP ->
> transits/peers
>   3) peers/transits didn't filter (some of them did apparently)
>   4) routes make it into the larger DFZ (or parts of the dfz at least, clearly)
>
> Traffic comes to 68.164.24.1 along a 'false path' in the dfz, in to
> the icelandic ISP and follows the iBGP learned path exiting
> (fortunately) out the isp that filtered...
>
> I'm sure you could construct lots of other pathological cases, but
> this seems plausible enough to me...
>>
>> Finding the other announces in RouteViews is left as an exercice
>> (hint: use a RouteViews collector close from the announce, here in
>> England, because the hijacking announce did not propagate everywhere).