Résumé

  • Le 25 avril 1997, un routeur AS7007 reçut environ 23 000 routes sans filtre entrant, puis produisit des dizaines de milliers de préfixes plus spécifiques avec AS7007 comme origine apparente.
  • La panne changea d’échelle parce que des voisins acceptèrent et relayèrent ces annonces ; le plus long préfixe l’emporta ensuite sur les agrégats légitimes.
  • La réponse durable sépara le registre qui fournit des éléments de preuve de l’opérateur qui configure les filtres et répond de ce que ses routeurs acceptent.

Le matin où un AS sembla être l’origine de l’Internet

Vers 11 h 30, heure de l’Est, le vendredi 25 avril 1997, le routeur frontal de MAI Network Services dans l’AS7007 reçut d’un client aval une vue presque complète, soit quelque 23 000 routes. Le récit publié ensuite par l’entreprise reconnaît l’absence de liste de distribution limitant ce voisin aux préfixes attendus.

Le routeur ne se contenta pas de retransmettre cette table. Selon MAI, il la désagrégea et supprima les chemins AS existants. Un autre routeur de l’entreprise vit plus de 73 000 entrées. Pour le reste du réseau, une multitude de préfixes plus étroits paraissaient désormais provenir d’AS7007.

Les chiffres décrivent des points d’observation différents. Avi Freedman évoqua environ 60 000 routes dans ses routeurs de cœur ; un autre relevé parla de 72 000 ; MAI en compta plus de 73 000. Il n’existe aucune raison méthodologique de fondre ces mesures en un total mondial.

La cause interne demeure, elle aussi, incertaine. MAI affirma qu’aucun protocole de routage intérieur ne fonctionnait sur l’équipement et soupçonna un défaut logiciel. D’autres opérateurs discutèrent redistribution, configuration et maîtrise du matériel. La transformation des routes et l’absence de filtre sont mieux établies que le déclencheur précis.

Pourquoi les routes plus spécifiques gagnèrent

Les routes légitimes n’avaient pas toutes disparu. AS7007 annonçait des chemins plus précis. Dans le transfert IPv4, la correspondance au préfixe le plus long précède les autres préférences. Un /24 erroné peut donc attirer le trafic destiné à sa plage même si un /16 valide reste présent.

Cette règle permet normalement le multihoming et l’ingénierie de trafic. Ce jour-là, elle amplifia le défaut. Les annonces étroites prirent le pas sur les agrégats, et l’effacement du chemin antérieur empêchait de retrouver dans l’AS_PATH le client qui avait fourni la table.

Un chemin AS n’est d’ailleurs pas un titre de propriété. Il décrit la propagation que des routeurs ont acceptée. L’incident montra moins une attribution centrale frauduleuse qu’une succession de réseaux décidant localement de croire puis de répéter une information hors périmètre.

Éteindre l’origine ne suffit pas

MAI indique avoir coupé la session vers 11 h 45, redémarré le routeur à midi, ajouté des filtres puis débranché ses équipements vers 12 h 15. Pourtant, les routes réapparurent par d’autres fournisseurs. Une annonce déjà propagée possède une vie distribuée.

Les opérateurs vidèrent des sessions BGP, ajoutèrent des filtres d’urgence et, pour certains clients, annoncèrent leurs propres routes plus spécifiques. L’amortissement des oscillations ajouta une mémoire : après des retraits répétés, une route pouvait rester supprimée même lorsque la source s’était stabilisée.

Le 15 mai, Curtis Villamizar donna une comparaison révélatrice. Certains fournisseurs filtrèrent en quinze à vingt minutes ; d’autres ne le firent jamais ; le fournisseur amont mit, selon lui, plus de deux heures et demie à bloquer les annonces à la source. Il n’existait pas de bouton global. Chaque frontière avait son état, son personnel et son délai.

Transformer les excuses en limites exécutables

MAI reconnut une faute précise : ne pas avoir borné les annonces entrantes du client. L’entreprise imposa ensuite des listes complètes. C’est une réponse plus vérifiable qu’une promesse générale de vigilance.

Les pratiques ultérieures formulèrent la règle simplement : sur une session client, seuls les préfixes du client devraient être acceptés. Des plafonds de préfixes peuvent arrêter une table soudaine ; les filtres de chemin et de préfixes spéciaux ajoutent d’autres défenses ; la supervision doit comparer les annonces reçues au contrat et à la topologie attendue.

Ce pouvoir reste local. Un fournisseur ne gouverne pas son client : il contrôle son propre routeur et doit répondre du coût imposé aux tiers lorsqu’il relaie une annonce invraisemblable. La légitimité vient ici d’une capacité technique bornée et d’une responsabilité identifiable.

Le registre utile, mais incomplet

La réponse de 1997 donna aussi du poids à l’Internet Routing Registry distribué. Des objets de route et d’AS pouvaient décrire les origines et les politiques attendues, puis servir à produire des filtres.

ANS annonça qu’il utiliserait les objets des bases ANS, CANET, MCI, RIPE et RADB. Son inventaire révéla toutefois 2 829 préfixes annoncés qui n’étaient ni enregistrés ni couverts par un agrégat. Des notifications purent être envoyées à 312 AS d’origine pour 2 108 préfixes ; aucun contact ne fut trouvé pour 151 AS couvrant 721 autres préfixes.

Après les corrections, il restait 2 096 préfixes non enregistrés provenant de 333 AS. Filtrer strictement un registre lacunaire risquait donc de supprimer une route légitime. Ne rien filtrer laissait passer l’erreur. Appeler la base « autorité » ne résolvait pas ce dilemme.

RFC 2622 donna à RPSL un langage plus riche pour décrire routes et politiques. RFC 2725 renforça l’autorisation des modifications, tout en constatant la persistance de données périmées après agrégation, renumérotation ou changement de fournisseur. Authentifier une écriture protège le registre ; cela ne le complète pas et ne programme aucun routeur.

Rendre le rôle bilatéral explicite

Longtemps, la prévention reposa sur une configuration correcte des relations commerciales : client, fournisseur ou pair. RFC 9234 ajouta en 2022 un échange de rôles BGP et l’attribut Only-to-Customer. Deux voisins peuvent ainsi déclarer leur relation et transporter une limite de propagation vérifiable.

Ce mécanisme n’était pas présent en 1997, n’est pas universel et ne bloque pas toutes les fausses origines. Il traduit néanmoins la bonne direction : une confiance sûre possède un objet, un périmètre et un test au point d’exécution.

AS7007 reste important parce qu’il sépare décentralisation et crédulité. L’Internet n’avait pas besoin d’un ministre mondial des routes. Il avait besoin que chaque participant refuse de transformer une session ouverte en mandat illimité.

Sources et limites

La chronologie vient de l’explication de MAI, complétée par le récit opérationnel d’Avi Freedman et l’avis de filtrage d’ANS. Le mécanisme est documenté par RFC 1812, RFC 2439, RFC 2622, RFC 2725, RFC 7454 et RFC 9234.

Aucun dénominateur mondial complet ne subsiste. Les causes du défaut, les volumes et la durée varient selon les témoins. Les sources établissent une fuite accidentelle de grande ampleur, un filtre manquant et une réparation distribuée, non un nombre exact de victimes ni un déploiement universel des protections ultérieures.