first, awesome, thanks... On Tue, Nov 26, 2013 at 4:09 PM, Stephane Bortzmeyer <bortzmeyer@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 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).