@jeekajoo shaarlinks 12/06/2015 Bortzmeyer revient sur la boulette de Telecom Malaysia (et de Level 3) dans un article clair et dûment référencé.
Si vous voulez réviser BGP :
http://pub.jeekajoo.eu/videos/IEUFI/IEUFI_BGP_nataf_conference-360p.webm
http://pub.jeekajoo.eu/videos/IEUFI/IEUFI_BGP_nataf_questions-360p.webm
Source:
http://www.iletaitunefoisinternet.fr/bgp-sarah-nataf/
Slides:
http://data.confs.fr/bgp_nataf/IEUFI_bgp_slides_sarah_nataf.pdf(
Permalink)
GuiGui's Show - Liens 15/06/2015 « C'est un accident qui, à cette ampleur, se produit tous les... quoi... trois ou quatre ans sur l'Internet. Un opérateur, en l'occurrence Telekom Malaysia, a laissé fuiter des centaines de milliers de routes Internet, attirant ainsi une quantité de trafic qu'il n'a pas su gérer. Le problème a duré environ deux heures.
D'abord, les observations brutes : les premières observations publiques qu'il y avait un problème ont été divers tweets comme celui de Nathalie Rosenberg à 0855 UTC. Une bonne partie de l'Internet semblait injoignable, et des gens ont commencé à accuser Free ou CloudFlare. En fait, on pouvait voir à plusieurs endroits que la source du problème était dans une crise BGP. Par exemple, les fichiers stockant les annonces BGP à RouteViews augmentaient brusquement de taille, montrant une forte activité BGP, ce qui n'est pas en général bon signe. De fichiers de moins d'un Mo en temps normal, on est passé à 2,2 Mo à 0845 puis à 14 Mo à 0900 et 19 Mo à 0915. L'examen du contenu de ces fichiers montre la cause du problème : l'AS 4788 (Telekom Malaysia) a laissé fuiter dans les 200 000 routes BGP (au lieu de 1 300 en temps normal, ce qui est déjà beaucoup)...
Aucune de ces préfixes n'est géré par Telekom Malaysia ou ne devrait être annoncé par eux. C'est à tort que leur transitaire Level 3/GlobalCrossing (AS 3549) a accepté ces annonces. (Rappelez-vous qu'un chemin d'AS se lit de droite à gauche, ici 23969 est l'origine.) Normalement, on filtre les annonces de ses clients ou de ses pairs BGP, à partir des IRR. Même si on ne filtre pas sur les données des IRR (souvent mal maintenues), on devrait, au minimum, mettre un nombre maximal de préfixes annoncé et couper la session autrement (si Free l'avait fait, ses clients auraient eu moins de problèmes, voir plus loin). Mais personne ne veut prendre le risque de mécontenter un client. Et puis filtrer demande davantage de travail, alors que la sécurité ne rapporte rien.
Level 3 relayant ce grand nombre de routes, bien des routeurs qui avaient configuré un nombre maximum de préfixes BGP annoncés ont coupé leur session.
[...]
Notons que tout n'est pas passé par Level 3. Les gens qui peeraient avec Telekom Malaysia et qui, bien à tort, ne filtraient pas les annonces, ont également reçu les annonces fausses. C'est le cas de Free, ce qui explique l'ampleur de la crise pour les abonnés de Free.
[...]
Résultat de ces annonces, le trafic filait effectivement en Malaisie
[...]
Notez que Telekom Malaysia n'a annoncé que 200 000 routes, sur les environ 600 000 qu'on trouve dans l'Internet donc environ les deux tiers des sites connectés n'ont pas eu de problème. On voit ici, via DNSmon, l'effet sur les serveurs DNS de .fr : deux des serveurs perdent environ 1 % des paquets au plus fort de la crise, c'est tout
Les annonces erronnées ont été supprimées vers 1030 UTC mais le trafic BGP n'est complètement revenu à la normale que vers 1200 UTC.
Une des originalités de cette fuite est que l'origine du chemin d'AS n'était pas le fuiteur, Telekom Malaysia. La plupart du temps, le fuiteur émet les routes comme s'il en était l'origine et des techniques comme RPKI+ROA détectent l'usurpation. Ici, au contraire, l'origine... originelle a été préservée et RPKI+ROA n'auraient donc rien vu. On voit ici une annonce Telekom Malaysia sur un routeur qui valide et on note qu'il a validé l'annonce. »
(
Permalink)
