On Tue, Nov 26, 2013 at 4:31 PM, Christopher Morrow <morrowc.li...@gmail.com> wrote: > first, awesome, thanks... > > On Tue, Nov 26, 2013 at 4:09 PM, Stephane Bortzmeyer <bortzme...@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).
