* Stephane Bortzmeyer - 08-01-2013 à 16h42: > POur une fois, ce ne sont pas les chinois qui font du détournement > BGP ! Cocorico, le Redressement Productif est en route : > > http://www.bgpmon.net/accidentally-stealing-the-internet/ > > Sérieusement, l'originalité de ce détournement est que l'origine n'a > *pas* été changée et que donc les techniques d'authentification de la > l'origine (comme les ROA) n'auraient pas aidé.
Donc l'idée ici c'est d'utiliser des filtres sur les préfixes reçus du peer ? HE.net a visiblement accepté une annonce erronée et n'aurait pas de filtering en place vis à vis de ses peers (mais je suppose que la grande majorité des AS n'ont pas de filtering en place). Dès lors, comment peut-on faire pour éviter d'être impacté quand on est un (petit) AS peeré avec un mastodonte comme HE ? (via un peering je les vois annoncer 40k préfixes v4 et plus de 7000 préfixes v6). Au niveau prefix-limit le leak de 500 préfixes v4 n'auraient pas été détecté et au niveau génération d'une config de filtre on dirait qu'HE fait office de mauvais élève avec import: from AS-ANY accept ANY export: to AS-ANY announce AS-HURRICANE export: to AS-ANY announce AS-HURRICANEv6 je suppose que la macro AS-HURRICANE(v6)? référence leurs clients transit (ou alors elle n'est pas à jour, l'AS 35625 référencé dans l'incident n'en faisant pas partie). Et même s'ils remplissaient cette DB correctement ils ont plusieurs centaines de peering en place et qques dizaines de milliers de préfixes collectés, des config potentiellement gigantesques à générer et traiter. Sans compter le cas où on aurait HE comme fournisseur de transit, cas où l'on peut encore moins facilement mettre en place ces filtres. (en espérant ne pas poser des questions de néophyte) -- Rémi Laurent Phone: +352 26 10 30 61 General Support: supp...@conostix.com GPG FP: 27F4 6810 2B0E 1AA0 CDAE 7C7B 3DC9 085A 0FA0 0601 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
