AS7007 1997: la fuite de routes comme test de responsabilité

Résumé

Périmètre de l’incident figé:Cet article examine les routes initiées par l’AS7007 le 25 avril 1997 et la disruption de joignabilité qui en a résulté. Il ne regroupe pas cet événement avec des fuites de routes postérieures, des détournements malveillants ou des pannes non liées sur des échanges de nom similaire. Les archives NANOG contemporaines montrent des opérateurs observant leur propre espace d’adressage sous forme de routes plus spécifiques avec l’AS7007 comme origine. [3][4]
Reconstruction technique bornée:Un compte APNIC ultérieur décrit des routes eBGP classless entrant dans un système, redistribuées vers RIPv1, perdant l’information de longueur de préfixe, puis réinjectées dans BGP comme routes déagrégées avec une information d’origine réécrite. [1] C’est une reconstruction explicative robuste, pas une autorisation pour inventer une séquence exacte de commandes internes.
Pourquoi ces routes ont prévalu:Le routage Internet applique la correspondance par le préfixe le plus long. Une route plus spécifique peut capter du trafic avant la comparaison de nombreux attributs de chemin BGP. Les routes fuyardes ont donc créé une réalité opérationnelle en conflit avec les limites de propriété des ressources et l’information d’origine attendue.
La responsabilité suit le contrôle:L’AS7007 maîtrisait la redistribution, la politique d’export, la validation des changements, la surveillance et le retrait. Ses fournisseurs en amont maîtrisaient les filtres client, les limites de préfixes et la propagation. Les pairs importateurs maîtrisaient leur propre politique d’acceptation et leur réponse d’urgence. Les utilisateurs finaux pouvaient signaler les pannes, mais pas corriger l’état de route interdomaines.
Les preuves de registre ne constituent pas l’exécution:ASN, registre d’adresses, IRR et systèmes RPKI ultérieurs peuvent conserver des preuves sur les détenteurs attendus des ressources et les origines autorisées. Les routeurs continuent d’appliquer les routes et politiques chargées dans les systèmes actifs. L’incident illustre donc clairement la primauté du code en exécution: l’autorité écrite n’a d’effet que lorsque la politique opératoire l’impose.
Les contrôles modernes sont en couches:La validation d’origine RPKI, les politiques explicites d’import et d’export, BGP Roles, les filtres par customer cone, les limites de préfixes, la surveillance indépendante et un rollback testé couvrent des modes de défaillance différents. Aucun mécanisme ne doit être présenté comme une cure rétrospective universelle.
La reprise doit être démontrée:Déconnecter ou corriger le routeur d’origine ne clôt pas la responsabilité. Les opérateurs doivent fournir des preuves de retraits, de vidage d’états obsolètes, de normalisation des tables de routes, de coordination entre pairs et de restauration de la commutation depuis plusieurs points de vue.

La délimitation de l’événement est le 25 avril 1997

Une histoire technique responsable commence par figer le périmètre de l’événement. Le 25 avril 1997, les opérateurs Internet ont rapporté un ensemble extraordinaire de routes plus spécifiques associées à l’AS7007, opérée par MAI Network Services. Les messages NANOG du jour fournissent des preuves contemporaines de ce que les opérateurs ont vu: des blocs d’adresses censés être annoncés ailleurs sont apparus sous des préfixes plus petits avec l’AS7007 comme origine, et le trafic a suivi ces annonces vers des chemins qui ne pouvaient pas le transporter correctement. [3][4]

L’événement est souvent décrit dans des synthèses ultérieures comme l’"incident AS7007" ou une grande fuite de routes internet précoce. Cette étiquette est utile si elle reste liée aux preuves. Elle ne doit pas devenir un raccourci pour toute erreur de routage de l’époque, ni impliquer une intention hostile. Les sources publiques les plus fortes soutiennent une panne de propagation accidentelle avec des effets graves. Elles ne soutiennent pas l’affirmation selon laquelle l’AS7007 aurait voulu intercepter le trafic ou revendiqué sciemment la propriété de chaque bloc affecté.

Les récits techniques ultérieurs décrivent couramment des milliers de routes /24 et une perturbation aiguë d’environ deux heures. Le rétrospectif APNIC donne un nombre approximatif de 6 000 annonces /24 et reconstruit la façon dont le comportement classful pouvait transformer une grande table externe en routes plus spécifiques. [1] Le catalogue d’incidents de Secure Routing consigne également l’événement comme un échec de routage de référence.

[2] Ces sources tardives aident à organiser l’historique, mais les messages opérateurs contemporains restent essentiels car ils reflètent l’état de route visible depuis l’extérieur pendant le déroulement de l’incident.

Le nombre exact d’annonces, l’heure exacte de début et de fin visible à chaque emplacement, ainsi que la configuration interne complète, ne sont pas établis par un seul document public. Les vues BGP dépendent du point de collecte. Une route peut apparaître sur un pair avant un autre, rester obsolète dans une table après retrait ailleurs, ou être supprimée par un filtre qu’un autre réseau ne possède pas. Un récit défendable attribue donc des estimations numériques sans transformer la vue d’un collecteur unique en horloge universelle.

Le rôle de la Florida Internet Exchange exige aussi prudence. Des récits ultérieurs relient parfois l’événement à l’infrastructure d’échange ou utilisent le nom de l’échange comme repère de localisation commode. Les preuves publiques examinées ici ne justifient pas d’attribuer l’échec complet à l’échange lui-même. Le raisonnement de responsabilité repose sur la transformation de route, l’export, l’acceptation par pair et la reprise. Il n’a pas besoin d’une affirmation non étayée d’une propriété de l’incident par une seule infrastructure.

Ces limites importent car le diagnostic oriente la remédiation. Si l’événement est qualifié à tort de détournement volontaire, la réponse peut se focaliser sur les identifiants et la détection d’origine malveillante. S’il est réduit à une panne générique, la réponse peut se limiter à la disponibilité. Les preuves orientent plutôt vers une transformation de politique de route qui a franchi une frontière interne et a été acceptée à travers plusieurs frontières externes.

Le BGP sans classes a rencontré un protocole intérieur classful

Le mécanisme technique est suffisamment singulier pour exiger une explication précise. Le BGP transporte entre systèmes autonomes des informations de joignabilité au niveau réseau. Les routes BGP modernes incluent un préfixe et sa longueur, comme un /16 ou un /24, plus des attributs de chemin utilisés par les opérateurs pour la sélection et la politique d’export. La RFC 4271 décrit le protocole de base et le processus de décision. [8]

RIPv1 a été conçu pour un modèle classful antérieur. Il ne transportait pas les masques de sous-réseau dans les annonces de route. Dans une interprétation classful, une adresse pouvait être traitée selon de grandes classes historiques de réseau plutôt que selon la longueur de préfixe explicite présente dans une route BGP classless. Lorsqu’une route passe entre protocoles avec des modèles d’information différents, la redistribution n’est pas une opération de copie neutre. C’est une transformation.

La reconstruction APNIC décrit des routes apprises via eBGP classless redistribuées vers RIPv1. Parce que RIPv1 ne pouvait pas préserver les longueurs de préfixe classless d’origine, les routes ont été représentées de manière à provoquer une déagrégation. Lorsqu’elles ont été redistribuées vers BGP, les annonces résultantes sont apparues comme de nombreuses routes plus spécifiques, et l’information AS-path historique externe n’a plus été conservée. [1]

Cette reconstruction explique simultanément deux observations. D’abord, elle explique le volume d’annonces /24. Un nombre plus faible de routes plus larges peut produire de nombreuses routes plus étroites quand la sémantique des préfixes est transformée. Ensuite, elle explique pourquoi l’AS7007 est apparu comme origine pour des espaces d’adresses que les opérateurs associaient à d’autres réseaux. Si l’information externe du chemin est supprimée pendant la redistribution et si la route est réintroduite dans BGP, le système réintroduisant peut devenir l’origine visible.

Le dossier public ne révèle pas chaque version logicielle, objet routeur, commande de redistribution ou action administrative. Il serait irresponsable de transformer la reconstruction en transcription terminale fabriquée. Les preuves soutiennent une classe de mécanisme: de l’information a été perdue ou transformée à travers une frontière de protocole, et ces routes transformées ont été exportées vers le BGP interdomaines.

Cette distinction est importante pour la responsabilité. Un retour d’incident ne doit pas s’arrêter à RIP était ancien ou redistribution était risquée. Il doit identifier qui a autorisé la frontière de protocole, quels attributs devaient logiquement être conservés, quel ensemble de routes générées devait être testé, quel invariant d’export devait rejeter le résultat, et quelle alerte aurait dû se déclencher lorsque volume de route et origine ont changé.

La traduction de protocole est un risque d’infrastructure récurrent. Les deux protocoles peuvent fonctionner correctement chacun de leur côté tandis que la composition viole l’intention du système. Une route valide dans une représentation peut devenir substantiellement différente une fois importée dans une autre. Le propriétaire du contrôle doit valider la sortie de la transformation, pas seulement la syntaxe de chaque côté.

Les routes plus spécifiques ont transformé une mauvaise information en réalité de commutation

La sélection de chemin BGP compte, mais la spécificité de commutation est prioritaire. Les routeurs transfèrent des paquets par correspondance au préfixe le plus long dans la table de transit. Une route /24 couvre une plage d’adresses plus étroite qu’un /16 couvrant la même zone. Quand les deux existent, le trafic des adresses incluses dans le /24 suit la route /24 même si la route couvrante reste disponible.

Ce comportement facilite l’ingénierie de trafic et le multihoming. Il rend aussi la déagrégation accidentelle très puissante. Si l’AS7007 a initié des milliers de routes plus spécifiques, ces routes ont pu détourner le trafic hors des routes plus larges légitimes. L’internet n’avait pas besoin de considérer que l’AS7007 possédait légalement l’espace d’adresses. Il lui fallait suffisamment de routeurs acceptant ces annonces et installant les chemins les plus spécifiques.

La distinction entre propriété et joignabilité est centrale. Les registres d’adresses peuvent noter quelle organisation a reçu un bloc. Les registres de routage peuvent noter la politique attendue. Les systèmes RPKI ultérieurs peuvent autoriser un ASN de ressource à initier un préfixe. Aucun de ces enregistrements ne modifie automatiquement une table de forwarding. Le réseau actif suit les routes acceptées selon la politique configurée.

Pendant l’incident, des opérateurs ont rapporté des chemins pour leurs propres réseaux affichant l’AS7007 comme origine. [3][4] Si le trafic suivait ces routes plus spécifiques vers un réseau incapable de le délivrer vers les destinations attendues, le résultat fut un grand trou noir. Certains chemins ont pu se comporter différemment parce que les réseaux ont appliqué des filtres, préféré d’autres routes ou n’avaient pas encore reçu les annonces. Cette variation n’affaiblit pas le mécanisme; elle montre que l’ampleur de l’incident était déterminée par la politique distribuée.

Le terme fuite est plus précis que détournement dans ce cas. La RFC 7908 a plus tard proposé une taxonomie des route leaks comme propagations au-delà du périmètre attendu. [9] L’événement de 1997 est antérieur à cette norme, et sa déagrégation inhabituelle n’a pas besoin d’être forcée dans une catégorie moderne unique pour que la question de responsabilité reste claire. Les routes ont échappé à la frontière opérationnelle attendue, ont porté une spécificité et une origine trompeuses, et ont été propagées assez largement pour perturber la joignabilité.

Les discussions sécurité traitent parfois toute route d’origine erronée comme preuve d’un attaquant. Cette inférence n’est pas étayée ici. Les contrôles opérationnels doivent détecter l’état de route nocif indépendamment de l’intention. Une alarme de limite de préfixe, une vérification d’origine autorisée ou une comparaison d’ensemble d’export n’ont pas besoin de déterminer si l’opérateur est négligent, compromis ou malveillant avant de bloquer l’annonce.

C’est pourquoi la preuve de route est utile. Elle permet d’établir ce que le réseau a affirmé et accepté sans spéculer sur la motivation. La responsabilité suit alors les systèmes et organisations qui ont contrôlé ces affirmations et ces décisions d’acceptation.

La responsabilité était répartie, mais n’était pas sans titulaire

Le routage interdomaines est décentralisé. Cela ne signifie pas que la responsabilité disparaît. Cela signifie que la responsabilité doit être assignée aux contrôles que chaque organisation peut gérer.

L’AS7007 maîtrisait la frontière de redistribution interne. Il maîtrisait si les routes BGP externes entraient dans un protocole intérieur, si les attributs et la sémantique de préfixe étaient préservés, si les routes transformées pouvaient revenir vers BGP, et quelles annonces étaient exportées vers les fournisseurs en amont. Il maîtrisait également l’approbation des changements, le déploiement, la surveillance, le rollback et la communication d’incident.

Les fournisseurs en amont ayant accepté les routes de l’AS7007 maîtrisaient une frontière différente. Ils pouvaient maintenir une liste des préfixes clients attendus, rejeter des origines hors d’un ensemble autorisé, plafonner le nombre de préfixes, limiter la spécificité acceptée, ou exiger une exception pour des annonces inhabituelles. Ils contrôlaient également si les routes acceptées étaient ensuite exportées vers des pairs et clients.

Les pairs importateurs et réseaux aval maîtrisaient leurs propres politiques. Certains ont pu appliquer des filtres qui ont contenu des parties de l’événement. D’autres ont pu s’appuyer sur une confiance large dans une relation amont. Leur responsabilité n’est pas identique à celle de l’émetteur, puisqu’ils n’ont pas créé les routes transformées. Mais l’acceptation de route est un acte opérationnel.

Les opérateurs de services critiques et les réseaux d’entreprise maîtrisaient la résilience autour du système de routage. Ils pouvaient surveiller l’état de route externe, utiliser plusieurs fournisseurs, conserver une communication hors bande et tester si la diversité de chemins supposée partageait les mêmes dépendances en amont. Ces contrôles pouvaient réduire l’impact ou améliorer la détection, mais ne pouvaient pas corriger le jeu de routes global à la source.

Les utilisateurs finaux et clients ordinaires avaient très peu de contrôle pratique. Ils pouvaient réessayer, changer de réseau d’accès si une alternative existait, ou signaler les pannes. Ils ne pouvaient pas inspecter chaque chemin BGP, modifier les filtres fournisseur ou forcer des retraits. Blâmer les utilisateurs pour ne pas avoir rerouté l’incident confond l’exposition et la responsabilité.

La répartition du contrôle suggère un constat en couches:

Le réseau d’origine avait le devoir principal d’empêcher qu’une transformation interne devienne une affirmation externe.
Les upstreams directs avaient un devoir fort de contention, car ils connaissaient la relation client et pouvaient définir les routes attendues.
Les autres réseaux avaient le devoir général de maintenir une politique d’import défendable et de surveiller les anomalies.
Les opérateurs de services avaient le devoir de continuité pour comprendre les dépendances de route et détecter les échecs externes.
Les fournisseurs de preuve publics avaient un rôle d’observation, pas de rôle de contrôle de production.

Ce modèle évite deux erreurs. Il évite de placer toutes les conséquences sur un ingénieur unique qui a pu exécuter un changement dans un système faible. Il évite aussi de conclure qu’Internet est trop décentralisé pour la responsabilité. La question centrale est toujours le contrôle pratique: qui pouvait prévenir, contenir, détecter, retirer ou vérifier?

La modélisation d’export doit tester l’ensemble de routes généré

Une règle écrite disant ne pas annoncer les préfixes d’autres réseaux n’est pas suffisante. Le système doit disposer d’une représentation vérifiable automatiquement des exportations attendues et d’une comparaison avec les routes que la configuration génèrera réellement.

Pour un réseau client ou de bordure, un modèle d’export peut définir:

les préfixes que le réseau est autorisé et attendu d’annoncer;
le nombre maximum de routes en états normal et d’urgence;
les longueurs de préfixe autorisées;
quelles routes peuvent être annoncées pour chaque relation;
si les routes clients, pairs et providers apprises peuvent être réexportées;
quels chemins AS et quels communities sont attendus;
quelles exceptions existent, qui les approuve et quand elles expirent.

La configuration générée doit être testée avant déploiement. Un test ne doit pas se limiter à confirmer qu’une route-map existe. Il doit faire transiter des routes représentatives dans la politique et examiner les annonces résultantes. Lorsque des routes classless traversent une représentation classful ou compressive, le test doit comparer le nombre de préfixes, la longueur des préfixes, l’origine et le chemin avant et après la transformation.

L’événement AS7007 illustre un invariant à forte valeur: un processus de routage ne doit pas exporter une route plus spécifique pour un préfixe externe si cette route n’est pas explicitement autorisée. Un autre invariant peut limiter l’écart entre la table attendue et celle générée. Un saut d’un ensemble de client ordinaire vers des milliers de /24 doit interrompre le déploiement, même si chaque route individuelle est syntaxiquement valide.

Les limites de préfixes fournissent une deuxième couche. Un fournisseur en amont peut configurer un nombre maximal de préfixes acceptés d’un client. Un seuil raisonnable inclut une marge opérationnelle mais reste suffisamment bas pour détecter une fuite majeure. Le seuil doit être spécifique à la relation: un transit provider, un réseau de contenu et un petit accès client ont des jeux de routes normaux différents.

Les limites de préfixes ne suffisent pas seules. Une fuite peut causer des dommages graves tout en restant sous un maximum généreux. Un client peut annoncer le nombre de routes attendu mais les mauvaises routes. Les limites doivent donc être combinées avec l’autorisation de préfixe et d’origine.

Les filtres clients peuvent être dérivés des registres, contrats, IRR et RPKI, mais ces sources comportent des lacunes. Un système défendable enregistre quelle source autorise chaque route, quand elle a été actualisée et comment les conflits sont traités. Les exceptions d’urgence doivent être explicites et temporaires plutôt que des contournements invisibles.

La RFC 7454 fournit un guide opérationnel pour BGP, y compris le filtrage et les limites de préfixe. [13] Le MANRS présente des pratiques apparentées comme actions d’opérateurs. [14] BITAG et le NIST décrivent aussi des contrôles de sécurité de routage et leurs réalités de déploiement. [15][16] Ces documents doivent enrichir un système de contrôle, pas remplacer la preuve que le contrôle était actif sur la session concernée.

La preuve la plus forte est un enregistrement de test: l’ensemble de routes attendu, l’ensemble de routes généré, la décision de politique pour chaque différence, la liste d’exceptions approuvée, le résultat canari et l’observation de route en direct après déploiement.

La doctrine de Heng.lu sépare les registres de l’exécution

L’incident AS7007 est un cas direct de contrôle réseau pour la doctrine Heng.lu. Les numéros de ressources exigent unicité, registres exacts, historique de transfert, métadonnées de sécurité et continuité opérationnelle. Ces registres sont essentiels, mais le registre est un registre comptable et gardien, pas un contrôleur souverain des routeurs actifs.

Un enregistrement ASN peut identifier l’AS7007. Des données de registre d’adresses peuvent identifier les détenteurs attendus des préfixes observés sous AS7007. Un objet de route IRR peut décrire la politique d’origine attendue. Une ROA peut autoriser un ASN à initier un préfixe. Ce sont des surfaces de preuve.

La couche opérationnelle est la route acceptée par un routeur et installée pour la commutation. Le 25 avril 1997, la vérité opérationnelle n’était pas seulement ce que disaient les registres. Elle était que des routes plus spécifiques avec AS7007 comme origine avaient été acceptées et propagées, et que le trafic les suivait.

Cela ne rend pas les registres non pertinents. Sans registres, un pair dispose d’une preuve moins fiable pour construire ses filtres et un enquêteur d’une preuve moins fiable pour repérer les anomalies. Le point est qu’une preuve de registre ne devient protection opérationnelle que lorsque la politique la consomme, que les exceptions sont contrôlées et que le déploiement est vérifié.

La primauté du code en exécution s’applique aussi aux procédures écrites. Une procédure peut imposer revue par les pairs et filtrage de préfixes. Si une configuration générée contourne le filtre, le système en production définit le résultat. Un audit ne vérifiant que la procédure rapporte un contrôle qui n’a pas réellement contenu l’incident.

La doctrine renvoie ainsi à trois exigences opérationnelles:

Registre exact:Les ressources et politiques doivent identifier les préfixes, origines et opérateurs responsables attendus.
Politique appliquée:Les routeurs et serveurs de routes doivent transformer ces preuves en décisions d’import et d’export.
Continuité opérationnelle:La surveillance et le rollback doivent montrer qu’un état erroné peut être retiré et que la joignabilité correcte est rétablie.

L’article n’a pas besoin de convertir ces principes en plaidoyer pour une organisation de registre ou un produit unique. Les preuves sont plus ciblées. L’incident montre que les registres d’unicité et de propriété n’empêchent pas les dommages lorsque la politique de routage accepte un état contradictoire en exécution.

Supprimer la redistribution BGP, la spécificité de préfixe, l’origine AS, les faits de filtrage pair et de retrait détruirait la thèse de l’article. C’est pourquoi ce n’est pas un récit générique de risque d’entreprise avec une terminologie réseau ajoutée ensuite. C’est une analyse de responsabilité de l’infrastructure réseau elle-même.

RPKI, RFC 8212 et BGP Roles traitent de problèmes différents

Les discussions de sécurité de routage modernes demandent souvent si la RPKI aurait empêché un ancien incident. La réponse responsable est conditionnelle.

La validation de l’origine de route compare un préfixe observé et un ASN d’origine avec les Route Origin Authorizations. La RFC 6811 définit les états de validation utilisés par les routeurs. [12] Si un préfixe possède une ROA valide autorisant une autre origine et que l’AS7007 annonce une route plus spécifique conflictuelle, la route peut être classée invalide, selon la couverture du préfixe et la longueur maximale.

De nombreux annonces de type AS7007 auraient donc été plus faciles à identifier et à rejeter dans un environnement RPKI pleinement couvert et correctement configuré. C’est une amélioration opérationnelle réelle. Cela ne prouve pas que toutes les routes de l’incident de 1997 auraient été rejetées.

La couverture est déterminante. Une route sans ROA couvrante n’est pas trouvée invalide simplement parce qu’un observateur la juge suspecte. Les réglages de longueur maximale importent. Une autorisation couvrante peut rendre une route plus spécifique invalide si elle dépasse la longueur autorisée, mais une autorisation trop large peut autoriser une spécificité nocive. Le mode de politique de déploiement importe aussi, car un réseau peut calculer l’état de validation sans rejeter les routes invalides.

La validation d’origine ne reconstruit pas non plus l’intention relationnelle. Une route avec une origine autorisée peut encore fuir d’un client vers un provider ou un peer en violation de la politique d’export attendue. La RFC 7908 décrit plusieurs formes de fuite où l’origine peut être légitime mais la propagation incorrecte. [9]

La RFC 8212 modifie la posture par défaut de l’eBGP en exigeant une politique d’import et d’export explicites. [10] Cela réduit la propagation accidentelle due à une acceptation implicite de type tout accepter. Cela ne garantit pas que la politique explicite est correcte. Un opérateur peut écrire une politique permissive, autoriser une transformation non sûre ou rattacher un objet de politique erroné.

La RFC 9234 introduit BGP Roles et un attribut OTC destinés à aider les réseaux à identifier et prévenir certains fuites de routes selon les relations. [11] Elle traite de la prévention des propagations conscientes des relations. Elle ne remplace pas l’autorisation d’origine, le test de politique générée, les limites de préfixes ou le rollback.

Les approches de type customer cone infèrent ou maintiennent l’ensemble des routes attendues d’un client et de ses descendants. Les filtres de type peerlock contraignent les chemins impliquant des réseaux majeurs. La recherche montre qu’un déploiement partiel peut fournir une protection utile, tout en documentant limites et complexité opérationnelle. [17]

La leçon en couches est:

La RPKI et la validation d’origine de route traitent de l’origine autorisée.
Les IRR et données de registre soutiennent des registres de préfixe et de politique attendus.
La RFC 8212 impose une politique explicite.
Les BGP Roles et l’attribut OTC traitent de la prévention de fuites sensible aux relations.
Les approches customer cone et les filtres de chemin contraignent la propagation.
Les limites de préfixes contraignent le volume.
La modélisation de configuration détecte les défauts de politique générée.
La surveillance indépendante détecte les écarts en production.
Le rollback et la coordination restaurent le service.

Considérer un contrôle comme réponse complète crée un nouveau vide de responsabilité. Les opérateurs doivent indiquer quels modes de défaillance sont couverts par chaque contrôle, ce qui se passe quand les données manquent, comment les exceptions sont revues, et comment le contrôle est testé contre une panne représentative.

La reprise ne s’achève pas quand le routeur d’origine est déconnecté

La preuve contemporaine la plus éclairante concerne la reprise. Un message d’excuse publié sur NANOG décrivait la difficulté de purger les routes fautives même après la déconnexion du routeur d’origine. [4] Cette observation transforme la reprise d’un simple récit de coupure en un problème d’état distribué.

Les routes BGP se propagent par de nombreux systèmes autonomes. Quand l’origine retire une route ou qu’une session tombe, les voisins traitent le changement, mettent à jour les chemins sélectionnés et annoncent les changements résultants. Minuteries, amortissement de flapping, état de session, comportement d’implémentation et politique locale peuvent influencer la vitesse de normalisation des tables.

La source peut cesser d’émettre de mauvaises routes alors que des informations obsolètes restent ailleurs. Un pair peut conserver temporairement un chemin, un route reflector peut traiter les changements à un rythme différent, ou un opérateur peut devoir réinitialiser une session pour effacer un état inattendu. Les rapports d’un seul point de vue ne peuvent pas prouver que chaque routeur a convergé.

Un journal de reprise comptable devrait donc inclure:

quand l’origine a cessé de générer ou d’exporter les mauvaises routes;
quand chaque upstream direct a observé les retraits;
si des sessions ont été réinitialisées et pourquoi;
si l’amortissement de flapping ou des mécanismes de routes obsolètes ont affecté le nettoyage;
quand les collecteurs ont cessé de voir les mauvaises origines;
quand les origines légitimes et les routes couvrantes ont retrouvé leur visibilité attendue;
quand les tests de transit ont atteint les destinations prévues;
quand les pairs majeurs ont confirmé des tables normalisées;
quelles routes sont restées anormales et pendant quelle durée;
qui a déclaré le service restauré et sur quelle preuve.

L’incident montre aussi pourquoi les plans de rollback doivent inclure la validation de l’état de route. Restaurer une configuration antérieure n’est pas suffisant si les mauvaises routes restent installées au-delà de la source. Une checklist de rollback doit inclure retraits attendus, comparaison de table et confirmation externe.

Le BGPStream de CAIDA rend accessibles des données routage historiques et live pour analyse. [18] Les collecteurs de routes sont précieux pour une confirmation indépendante, mais ils ne sont qu’échantillons. Un processus de reprise mature combine RIB/FIB internes, rapports pairs directs, collecteurs publics et sondes de transit.

La communication de reprise doit séparer le confinement de la source et la restauration globale. Le "routeur a été déconnecté" est un événement de confinement. "Toutes les routes concernées ont été retirées des pairs directs" est une étape de propagation. "Les points de vue indépendants ne voient plus ces routes et la commutation est normale" se rapproche d’une preuve de restauration.

Cette structure évite une clôture prématurée. Elle aide aussi les organisations à mesurer ce qu’elles contrôlent directement et ce qui dépend de la coordination.

Les preuves de route publiques sont fortes, mais incomplètes

Le dossier public pour un incident de routage de 1997 est utile de façon inhabituelle, mais il a encore des limites. Les messages NANOG fournissent des observations opératoires directes et une demande d’excuse. [3][4] La couverture contemporaine saisit l’échelle et le caractère soudain de la panne. [5] Des comptes techniques ultérieurs expliquent l’interaction des protocoles. [1][2][6] Les standards et guides décrivent les contrôles que peuvent appliquer les opérateurs. [8]-[17]

Aucune source publique ne révèle chaque table de routage privée, diff de configuration, ticket de support, contrat de peering ou journal de décision. Les preuves ne peuvent pas identifier le premier équipement exact qui a accepté chaque route ou le nombre exact d’utilisateurs touchés. Elles ne peuvent pas montrer quels filtres ont fonctionné silencieusement et ont empêché une propagation plus large.

La reconstruction historique rencontre aussi une dérive terminologique. En 1997, les opérateurs décrivaient l’incident avec le langage et les outils disponibles. Les récits ultérieurs parlent de route leak, détournement, déagrégation et validation d’origine dans un cadre influencé par des standards plus récents. Un article rigoureux ne doit pas faire apparaître un opérateur de 1997 comme ayant suivi ou violé une norme qui n’existait pas alors.

Les standards modernes sont des leçons pour la conception de contrôles actuels, pas des exigences rétroactives de conformité. La RFC 4271 a été publiée après l’événement, même si elle documente le modèle BGP-4 mature. Les RFC 7908, 8212 et 9234 sont bien postérieures. [8]-[11] Elles aident à expliquer les classes de défaillance et les couches de prévention, sans prouver ce qu’AS7007 ou ses upstreams étaient contractuellement tenus de déployer en 1997.

Les preuves soutiennent plusieurs constats à forte confiance:

L’AS7007 a initié un grand nombre de routes plus spécifiques pour des espaces associés à d’autres réseaux.
L’état de route a causé une perturbation substantielle de la joignabilité.
L’événement était accidentel selon le dossier disponible.
La redistribution interne vers externe était centrale dans la reconstruction technique ultérieure.
L’acceptation et la propagation par les pairs ont étendu l’impact.
Le retrait et le nettoyage n’ont pas été instantanés.

Il soutient plusieurs constats à confiance modérée:

La redistribution de classless vers classful explique plausiblement la déagrégation et la réécriture d’origine.
Un filtrage ou une limite de préfixe en upstream direct aurait pu contenir une large partie du jeu de routes.
Un meilleur modèle d’export aurait mis en évidence une différence majeure entre les annonces attendues et générées.

Il laisse des inconnues importantes:

la séquence de configuration exacte;
la topologie complète des équipements et logiciels;
l’état complet des filtres de chaque pair direct;
la chronologie complète de l’incident;
la propriété des décisions et les validations d’approbation;
l’effet complet par réseau et géographie;
la remédiation mise en œuvre après l’événement.

La responsabilité est plus robuste quand ces niveaux de confiance restent visibles. Exagérer les affirmations rendrait l’article plus facile à critiquer et moins utile comme standard d’audit.

Un programme de remédiation vérifiable

Le dossier public n’établit pas quels contrôles MAI Network Services ou chacun de ses upstreams ont ensuite implémentés. La réponse correcte est de définir des preuves qui montreraient que la voie de panne est désormais maîtrisée.

1. Geler les exportations attendues

Pour chaque session eBGP, conserver un ensemble attendu d’exportation versionné. Cet ensemble doit inclure préfixe, spécificité maximale, origine, contraintes de chemin, relation et exceptions approuvées. Il doit être généré à partir des registres autoritaires et de l’intention opérationnelle explicite.

Preuve: dépôt du repository, enregistrement d’approbation, horodatages des sources de données, propriétaire de l’exception et expiration.

2. Tester les transformations de protocole

Là où des routes passent entre BGP, un IGP, un système de routes statiques ou une autre représentation, tester si la longueur de préfixe, l’origine, le chemin et les attributs de politique sont conservés comme prévu. Rejeter les transformations avec perte d’information, sauf si l’ensemble de routes résultant est explicitement borné.

Preuve: routes d’entrée représentatives, routes de sortie générées, résultats d’invariants et tests négatifs.

3. Comparer annonces attendues et générées

Avant déploiement, calculer le delta de routes. Arrêter si l’ensemble généré introduit des préfixes non autorisés, des plus spécifiques inattendus, des changements d’origine ou une hausse du nombre de routes au-delà de la frontière approuvée.

Preuve: diff pré-déploiement et résultat de condition d’arrêt.

4. Appliquer des filtres client directs

Les upstreams devraient filtrer les routes client selon un ensemble attendu, appliquer des limites de préfixes spécifiques à la relation et journaliser chaque exception. Les données de registre et RPKI peuvent orienter l’ensemble, mais les conflits non résolus devraient provoquer un arrêt sûr ou une revue explicite.

Preuve: attachement de la politique active, tests d’annonces acceptées et rejetées, historique de rafraîchissement et liste d’exceptions.

5. Déployer une politique de relation explicite

Chaque session eBGP devrait avoir une politique d’import et d’export explicite. Lorsque supporté, BGP Roles et contrôles sensibles aux relations doivent aligner la relation opérationnelle. La configuration doit rejeter l’absence ou l’incohérence de rôle plutôt que d’accepter silencieusement un défaut large.

Preuve: inventaire de sessions, cartographie des rôles, attachement de politique et test de conformité.

6. Surveiller depuis l’extérieur du réseau

Surveiller l’origine, la spécificité, le chemin, le volume de route et la joignabilité depuis des points de vue indépendants. Les alertes doivent relier les anomalies de routes aux tests de transit pour permettre aux équipes de distinguer une mise à jour visible d’un incident impactant l’utilisateur.

Preuve: requêtes collecteurs, chronologie d’alerte, résultats de sondes et rattachement à l’incident.

7. Mettre en place des arrêts automatiques de déploiement

Un déploiement doit s’arrêter quand le nombre de routes, l’origine inattendue, le volume de plus spécifiques, la visibilité pair ou l’impairment de transit dépasse un seuil défini. L’arrêt ne doit pas dépendre uniquement de la détection humaine de plaintes publiques.

Preuve: politique canari, seuil, déclencheur et arrêt exécuté.

8. Exercer retrait et nettoyage

Exécuter des tests sûrs en labo ou en zone isolée montrant qu’une route défaillante est retirée, que les sessions convergent, que les états obsolètes sont détectés et que les sondes indépendantes reviennent au comportement normal. L’exercice doit inclure la communication avec les pairs et un accès hors bande.

Preuve: horodatages de retrait d’origine, réception pair, normalisation des tables et récupération de forwarding.

9. Préserver les preuves d’incident

Conserver les mises à jour de route, différences de configuration, entrées de génération de politique, enregistrements d’approbation, alertes, commandes, messages pairs et contrôles de reprise. La synchronisation temporelle doit rendre la séquence auditable.

Preuve: lot d’incident immuable avec hachages et contrôles d’accès.

10. Vérifier la remédiation contre la classe d’échec initiale

Ne pas clore une remédiation par une déclaration générique d’amélioration de surveillance. Reproduire une représentation sécurisée de la transformation classless-to-classful ou d’une déagrégation non autorisée équivalente et démontrer où la chaîne de contrôle actuelle l’arrête désormais.

Preuve: conception du test, point de défaillance attendu, résultat observé et revue indépendante.

Ce programme reste neutre au produit. Il ne requiert ni fournisseur unique, ni registre unique, ni service de sécurité unique. Il exige qu’un opérateur montre que la politique attendue est exacte, que la politique en production l’applique, que les anomalies stoppent le déploiement et que la reprise est visible de façon indépendante.

Les questions de gouvernance doivent suivre la route

Les conseils, régulateurs, acheteurs de services et auditeurs n’ont pas besoin d’opérer le BGP pour poser des questions utiles. Ils doivent suivre la route au travers de la chaîne de contrôle.

Les conseils d’administration devraient demander quelles modifications peuvent changer les annonces publiques, comment les exports générés sont testés, qui peut approuver des exceptions et la vitesse d’exécution d’un rollback. Ils devraient recevoir des résultats d’exercices, et non seulement des documents de politique.

Les fournisseurs de transit devraient demander si les filtres clients sont dérivés de preuves actuelles, combien de sessions ont des limites de préfixes, quelles sessions acceptent des exceptions larges et si ces exceptions expirent. Un contrôle appliqué à la plupart des clients peut encore laisser la session à plus haut risque exposée.

Les acheteurs d’entreprise devraient demander si les clients ont des fournisseurs doublement indépendants, si la surveillance route externe couvre les préfixes critiques et si la communication d’incident distingue panne de routage et panne applicative. La diversité contractuelle n’est pas la même que la diversité de chemins.

Les auditeurs devraient échantillonner une session de politique réelle, les ensembles de routes générées et les observations de route. Ils devraient tracer un enregistrement de registre ou RPKI vers une décision de routeur et tester ce qui se produit quand les données sont manquantes ou contradictoires.

Les régulateurs devraient éviter de définir la responsabilité de routage comme la seule implémentation d’une technologie. Exiger la création de ROA peut améliorer l’exactitude d’origine, mais ne prouve ni filtrage sensible aux relations, ni validation de changement, ni reprise. Les obligations fondées sur la preuve peuvent demander aux opérateurs de documenter les contrôles adaptés à leur rôle et de les tester.

Les réviseurs d’incident devraient distinguer cause racine, conditions contributives, déclencheur, détection, réponse et reprise. "Erreur humaine" n’est pas une cause racine suffisante. Elle n’explique pas pourquoi le système a généré des milliers de routes inattendues, pourquoi les upstreams les ont acceptées, pourquoi la surveillance n’a pas stoppé la propagation ou pourquoi le nettoyage est resté difficile.

L’objectif de gouvernance n’est pas de rendre chaque changement de route sans risque. Il est de s’assurer que les organisations avec un contrôle pratique puissent montrer comment elles réduisent, contiennent et réparent le risque créé par leur position réseau.

Le test de responsabilité est une exécution observable

L’incident AS7007 de 1997 reste important car il concentre plusieurs obligations d’infrastructure réseau dans un seul événement. Une frontière interne de protocole a transformé l’information de route. La sortie transformée a franchi une frontière de politique externe. Les routes plus spécifiques ont changé la réalité de commutation. Plusieurs réseaux ont accepté et propagé les affirmations. La reprise a exigé un retrait distribué et une coordination.

Le dossier public ne justifie pas une hypothèse d’intention malveillante ni une séquence unique de commande non documentée. Il justifie une conclusion opérationnelle forte: la propriété attendue des ressources et l’intention de routage écrite n’ont pas contraint l’état de route en exécution.

La responsabilité était en couches. L’AS7007 contrôlait la transformation et l’export. Les upstreams directs contrôlaient l’acceptation client et la contention. Les autres réseaux contrôlaient la politique d’import. Les opérateurs de service contrôlaient la surveillance externe et la résilience. Les utilisateurs finaux subissaient les conséquences sans contrôle réseau significatif.

Les mécanismes modernes améliorent l’environnement de contrôle, mais seulement quand leurs limites sont explicites. La RPKI peut aider à rejeter des origines non autorisées. La RFC 8212 peut éliminer une posture eBGP implicite d’acceptation globale. Les BGP Roles et OTC peuvent aider à contenir les fuites relationnelles. Les limites de préfixes peuvent détecter un volume anormal. Les filtres clients peuvent contraindre les routes attendues. La modélisation peut comparer exports générés et intention. La surveillance et le rollback peuvent contenir et réparer des pannes.

La doctrine de Heng.lu donne une norme finale concise. Les registres et politiques de routage conservent les preuves comptables de responsabilité, mais ne gouvernent pas le plan de transit. Le code en exécution, la politique configurée et les routes acceptées déterminent ce que fait réellement l’internet. La continuité opérationnelle exige que l’état erroné puisse être détecté, supprimé et vérifié de manière indépendante.

Une preuve de remédiation crédible montrerait donc l’ensemble attendu d’exportation, les tests de politique générée, les filtres client directs, les limites de préfixes, la détection d’anomalie en direct, la chronologie de retrait, la confirmation par pairs et la reprise de commutation. Elle reproduirait la classe d’échec initiale en sécurité et indiquerait quel contrôle l’arrête désormais.

La question durable du 25 avril 1997 n’est pas de savoir si les opérateurs d’aujourd’hui savent que les fuites de route sont dangereuses. Elle est de savoir s’ils peuvent prouver qu’un ensemble transformé, non autorisé et très spécifique ne peut plus traverser leurs frontières sans être détecté, et s’ils peuvent prouver la reprise quand cela se produit. C’est le test de responsabilité Internet rendu visible par AS7007.

La fuite AS7007 de 1997 a fait du filtrage de routes un test de responsabilité d’Internet

Pourquoi c'est important