Fuite BGP TTNet 2004: test de responsabilité des préfixes

Résumé

Contexte de l’incident figé:Cet article couvre la fuite de la table de routage AS9121/TTNet observée le 24 décembre 2004. Il ne regroupe pas cet événement avec des incidents de connectivité turcs ultérieurs, des détournements de route non liés, ou d’autres fuites impliquant des systèmes autonomes différents.
L’ampleur doit être attribuée:La reconstruction NANOG et les recherches ultérieures décrivent une fuite touchant plus de 100 000 préfixes, représentant une large part de la table de routage visible mondiale de l’époque. Le nombre exact dépend des collecteurs, de l’intervalle, du traitement des doublons et de la définition de l’événement. Il s’agit d’un résultat de preuve, pas d’un journal d’opérateur universel.
La panne a franchi des limites de relation:Des routes apprises dans un contexte ont été annoncées là où elles n’étaient pas censées aller. D’autres réseaux les ont acceptées et propagées selon leur propre politique locale. Le résultat n’était pas simplement une panne de service TTNet; c’était un changement distribué de l’état de route mondial.
La responsabilité suit le contrôle:AS9121 contrôlait son import, son export, la génération des routes, le déploiement, la surveillance et le retrait. Les fournisseurs directs et pairs contrôlaient les filtres de préfixes client, les contraintes AS-path, les limites de préfixe maximum, les alertes et la redistribution ultérieure. Les importateurs ultérieurs contrôlaient leur propre acceptation et contention.
Un registre est une preuve, pas une application:Les enregistrements ASN, d’adresse, IRR et RPKI peuvent décrire les origines attendues et les détenteurs de ressources. Ils ne configurent pas par eux-mêmes la politique des routeurs. Les éléments de code et la politique chargée déterminent quelle route est acceptée et propagée.
Les contrôles modernes sont complémentaires:Politique eBGP explicite, filtres de préfixes autorisés, limites de préfixes maximum, validation d’origine de route, BGP Roles et OTC, validation de cone client, détection d’anomalies et rollback testé adressent des modes de panne différents. Aucun n’est une cure rétrospective complète.
La reprise exige une preuve externe:Une correction de routeur ou une réinitialisation de session ne suffit pas comme preuve. Une preuve de reprise imputable montre retraits, chemins de remplacement, routes obsolètes résiduelles, coordination de pairs, convergence et restauration de la joignabilité depuis des points de vue indépendants.

La frontière de l’événement est le 24 décembre 2004

La première discipline dans une revue d’incident d’infrastructure est de figer l’événement. Le 24 décembre 2004, les opérateurs ont observé un ensemble anormal de routes associées à TTNet, système autonome 9121. L’événement a été discuté sur NANOG à l’époque, puis reconstruit dans une présentation NANOG à partir des données BGP publiques de RouteViews et RIPE. [1][2] Des études académiques ultérieures ont utilisé l’incident comme exemple majeur ou cas étendu de détection de fuites de route et d’analyse d’anomalies de routage. [3][4][5]

Le dossier public soutient de manière constante la proposition centrale: AS9121 a propagé une très grande partie de la table de routage au-delà de son périmètre prévu, et d’autres réseaux ont accepté ou redistribué suffisamment de ces annonces pour créer des problèmes de joignabilité massifs. C’est ce modèle factuel que cet article analyse.

Il faut éviter d’exagérer cette proposition. Les sources publiques ne donnent pas une configuration TTNet complète, chaque route-map, chaque accord bilatéral, tous les messages opérateurs ni une chronologie universellement faisant autorité. Elles ne démontrent pas une intention malveillante. Elles ne montrent pas non plus que chaque réseau d’internet a accepté chaque chemin fuité ni que chaque utilisateur a vécu le même effet.

Les chiffres exigent une attention particulière. La reconstruction NANOG et la littérature ultérieure décrivent souvent plus de 100 000 préfixes touchés et caractérisent cet ensemble comme une majorité de la table globale visible à l’époque. [1][3][4] Ces affirmations sont utiles, mais il s’agit de déclarations de mesure. Un collecteur voit les routes exportées par les sessions qui l’alimentent. Des collecteurs différents peuvent recevoir différents chemins, enregistrer les mises à jour à des horaires différents, éliminer les doublons différemment et ne pas voir les routes filtrées avant leur arrivée.

La bonne pratique éditoriale est donc une attribution plutôt qu’une fausse précision. L’événement était énorme au vu des standards de la table de routage de 2004. Son nombre exact de préfixes et sa durée varient selon le point de vue et la méthode analytique. Cette variabilité n’est pas une excuse pour minimiser l’incident; c’est une raison de conserver les preuves BGP sous-jacentes et d’expliquer comment a été produit une estimation.

La date compte aussi. Les contrôles standardisés des années suivantes doivent être utilisés comme comparaisons, pas comme tests de conformité rétroactive. Le RFC 7908 sur la taxonomie des fuites de routes a été publié en 2016. [12] Le comportement par défaut explicite du RFC 8212 pour l’eBGP a été publié en 2017. [13] Le RFC 9234 sur BGP Roles et le mécanisme Only-to-Customer est apparu en 2022. [14] Ces documents aident à identifier le problème de contrôle, mais n’établissent pas ce qu’AS9121 ou ses voisins avaient déployé en 2004.

La question défendable n’est pas: "Pourquoi un réseau de 2004 n’a pas respecté une norme de 2022?" C’est: "Quels invariants opérationnels devaient contraindre ce qu’un client ou un peer pouvait annoncer, quelles organisations contrôlaient ces invariants, et quelles preuves montreraient que l’état du routage est revenu à la normale?"

Une fuite de route est un échec de politique relationnelle

Le BGP distribue l’information de joignabilité entre les systèmes autonomes. Chaque réseau sélectionne des routes selon sa politique locale et décide quelles routes sélectionnées annoncer à chaque voisin. Le RFC 4271 définit le protocole de base, les types de messages, les attributs de route, le processus de sélection et le comportement de retrait. [11] Il n’encode pas une relation commerciale ou opérationnelle universelle pour chaque session.

Cette information relationnelle compte parce qu’une route internet n’est pas automatiquement éligible pour chaque voisin. En général, un client annonce ses propres routes et les routes pour lesquelles il est autorisé à fournir du transit. Un fournisseur peut généralement envoyer une large joignabilité à un client car le client le paie pour du transit. Un peer settlement-free échange généralement ses propres routes et celles de ses clients, pas de transit gratuit entre fournisseurs non liés.

Les termes "client", "fournisseur", "peer" simplifient des arrangements réels, mais exposent la frontière de politique. Une route apprise d’un fournisseur ne devrait pas d’ordinaire être annoncée à un autre fournisseur comme si le réseau annonceur offrait du transit entre eux. Une route apprise d’un peer ne devrait pas être exportée vers un autre peer ou fournisseur. La table complète d’un client ne devrait pas être traitée comme l’ensemble d’origines autorisées du client.

Le RFC 7908 définit plus tard une fuite de route comme une propagation au-delà du périmètre prévu, généralement en violation des politiques associées aux relations pair-à-pair. [12] Cette définition est utile ici car elle se concentre sur la propagation observable plutôt que sur la motivation supposée. La mauvaise route a traversé la mauvaise frontière.

L’événement TTNet est souvent décrit comme une fuite de table de routage parce que les annonces anormales représentaient un vaste ensemble de routes qu’AS9121 ne devait pas exporter dans ce contexte. Les preuves disponibles ne nécessitent pas une topologie interne exacte pour rendre claire la question de responsabilité. Que l’erreur déclenchante concerne une route-map, une redistribution, la génération de politique, la classification de session, ou un autre mécanisme, la panne visible à l’extérieur était un ensemble d’exportation radicalement incohérent avec un rôle client ou pair limité.

Les destinataires ont ensuite pris des décisions locales. Un voisin direct a accepté les routes. Certains destinataires les ont peut-être préférées en raison d’attributs de chemin, de préférence commerciale ou de longueur de chemin. Certains les ont exportées davantage. D’autres peuvent les avoir filtrées, rejetées sous une limite maximum de préfixes, ou choisi des alternatives non affectées. La portée de l’événement était donc une propriété émergente de politiques multiples.

La causalité distribuée ne doit pas devenir causalité sans propriétaire. Le fuyard contrôlait ce qu’il annonçait. Ses voisins directs contrôlaient ce qu’ils acceptaient dans cette relation. Chaque relais en aval contrôlait ce qu’il relayait. Les responsabilités pertinentes diffèrent, mais chacune reste concrète.

Une preuve BGP n’est pas un journal universel de forwarding

Les collecteurs de routes publics rendent possible une responsabilité historique. RouteViews archive les mises à jour BGP et les bases d’informations de routage des pairs entités. Son archive décembre 2004 conserve des données que les chercheurs peuvent utiliser pour reconstruire les changements autour de l’événement TTNet. [9] La Routing Information Service de RIPE fournit une autre surface de mesure distribuée et une documentation sur ce que les collecteurs peuvent et ne peuvent pas observer. [10]

Un enregistrement de mise à jour indique qu’une annonce ou un retrait de route a atteint un collecteur via une session donnée. L’enregistrement peut conserver préfixe, chemin AS, origine, attributs et horaires. En comparant les observations, les chercheurs peuvent estimer quand un chemin anormal est apparu, comment il s’est propagé et quand les retraits ou remplacements ont suivi.

C’est une preuve puissante, mais elle a des limites.

Premièrement, la visibilité du collecteur est partielle. Une route peut atteindre des réseaux qui ne fournissent pas de collecteur. Une autre route peut être filtrée avant d’atteindre tout point de vue public. Un pair de collecteur peut n’exporter que son meilleur chemin au lieu de chaque chemin appris. La politique peut donc rendre le dossier public incomplet.

Deuxièmement, la visibilité de la couche de contrôle n’est pas identique à l’acheminement de données. Un routeur peut recevoir une mise à jour mais choisir de ne pas l’installer. Une route peut entrer dans une table de routage et ne pas entrer dans la table de forwarding. Le trafic peut suivre la route mais rencontrer ensuite congestion ou black hole. À l’inverse, des sessions en cache et la diversité de chemin peuvent laisser certains services accessibles alors que la couche de contrôle est instable.

Troisièmement, les horodatages reflètent l’observation. La première mise à jour dans une archive n’est pas nécessairement la première mauvaise annonce globale. Le dernier retrait dans un collecteur n’est pas nécessairement la fin d’un état obsolète partout. La convergence est distribuée.

Quatrièmement, un compte de préfixes dépend des définitions. Les analystes doivent décider s’ils comptent les préfixes uniques, les messages de mise à jour, les chemins, les origines ou les changements de route. Ils doivent définir l’intervalle d’incident et traiter les annonces dupliquées. Différentes méthodes valides peuvent produire des chiffres différents.

Un article imputable évite donc d’écrire par exemple: "tout internet était indisponible pendant exactement X minutes" sauf si une source établit réellement cette portée. La thèse plus solide est aussi la plus précise: AS9121 a généré une anomalie de routage extraordinaire; l’anomalie s’est propagée largement; les mesures publiques montrent le changement de la couche de contrôle globale; et la joignabilité a été matériellement perturbée.

La lacune de preuve identifie ce qu’un dossier d’incident complet devrait contenir. Les données BGP publiques devraient être associées au diff de configuration du réseau d’origine, aux journaux de génération de politique, aux enregistrements de déploiement, à la chronologie d’alertes, aux états de session, aux commandes de retrait, aux tickets NOC et aux communications avec les pairs. Les voisins directs doivent conserver les routes qu’ils ont acceptées, les filtres appliqués, tout événement de préfixe maximum et la raison pour laquelle la session est restée ouverte ou a été réinitialisée.

Sans ces enregistrements privés, les enquêteurs externes peuvent reconstruire les effets mais ne peuvent pas assigner chaque action interne. Cela doit être présenté comme une limite de preuve, pas comblé par une supposition.

La fuite est plus précise que le hijack

Les incidents de routage sont souvent appelés "hijacks" dans la discussion publique car le trafic suit un chemin associé au mauvais réseau. Le terme peut être utile pour des événements délibérés ou à fausse origine, mais peut aussi impliquer une intention non établie par la preuve.

Le dossier TTNet soutient "fuite de route" comme terme principal. Les routes ont dépassé leur périmètre relationnel prévu. L’événement semble cohérent avec un échec grave de politique ou de configuration. Il n’est pas nécessaire d’alléguer que TTNet avait l’intention d’usurper chaque origine touchée ou d’intercepter délibérément du trafic.

La distinction est techniquement importante. La détournement d’origine de route implique souvent qu’un système autonome annonce un préfixe qu’il n’est pas autorisé à annoncer. Une fuite de politique de chemin peut garder l’origine légitime mais exposer une route via une relation qui ne devrait pas la porter. Certains incidents combinent des éléments, et les sources publiques peuvent être ambiguës.

La validation de l’origine de route répond à la première question: l’ASN d’origine est-il autorisé pour ce préfixe selon un Route Origin Authorization? Le RFC 6811 définit comment un routeur peut classer les routes à l’aide des données RPKI. [15] Il n’encode pas chaque relation client-fournisseur ni ne détermine si une route à origine valide a traversé une vallée interdite.

Les mécanismes sensibles aux relations répondent à une autre question: vu où cette route a été apprise, doit-elle être exportée ou acceptée dans cette session? Le RFC 9234 formalise les BGP Roles et l’attribut Only-to-Customer pour une catégorie de prévention et détection de fuites de route. [14] Les approches par customer-cone ou de type ASPA abordent l’autorisation de chemin d’un autre angle.

Qualifier chaque événement de hijack peut donc conduire à une remédiation incomplète. Un opérateur peut créer des ROA, observer que les routes fuyantes restent d’origine valide, et conclure que le problème est résolu. Ce n’est pas le cas. L’autorisation d’origine, l’autorisation relationnelle, la contention de volume et la sécurité de changement sont des contrôles séparés.

L’intention reste importante pour les conclusions légales et disciplinaires, mais elle n’est pas requise pour le containment opérationnel. Les filtres devraient rejeter un ensemble de routes non autorisées qu’il soit produit par erreur, automation compromise, action malveillante ou contrat mal compris. La surveillance doit alerter sur un client exportant la majeure partie de la table globale sans d’abord se demander pourquoi.

Cette terminologie fondée sur la preuve fait partie de la couche réalité. Elle décrit ce que le réseau a affirmé, accepté et propagé. Elle ne transforme pas une inférence sur le motif en fait.

L’autorisation de préfixe client doit être exécutable

La leçon de contrôle la plus directe est que l’ensemble attendu d’annonces client devrait être représenté comme une politique exécutable.

Si un client est autorisé à annoncer un groupe défini de préfixes, le fournisseur peut créer un filtre d’import qui autorise ces préfixes et rejette le reste. La source de vérité peut inclure des enregistrements contractuels, un registre de routage, des autorisations d’origine RPKI, une attestation directe du client, un historique de routes observées et des exceptions manuelles. Chaque source a des limites, mais le résultat final doit être une décision explicite dans le routeur.

Une allowlist est plus forte qu’une denylist. Une denylist essaie d’énumérer les routes manifestement impossibles, comme le default ou les espaces réservés, en laissant un ensemble non listé énorme acceptable. Une allowlist part des routes que le client est censé annoncer ou transiter et traite l’augmentation comme un changement contrôlé.

Le filtre généré doit être testé. Un objet de registre apparemment correct peut encore produire une configuration incorrecte. Une chaîne d’automatisation peut fusionner le mauvais client, omettre un préfixe, accepter un agrégat trop large, ou échouer en mode fail-open quand les données sont indisponibles. Les tests doivent comparer ressources prévues, politique générée et un ensemble représentatif d’annonces acceptées et rejetées.

Les exceptions exigent propriété et expiration. Un client peut devoir annoncer un nouveau préfixe pendant une migration, fournir un transit à une affiliée, ou utiliser un agrégat pendant un incident. Une exception doit identifier le propriétaire approbateur, la preuve, la session concernée, le périmètre de préfixe et de chemin, l’heure de début, le temps de révision et la condition de rollback. Une exception temporaire permanente constitue un transfert caché de risque.

L’incident TTNet montre pourquoi l’échelle elle-même est un signal d’autorisation. Un réseau censé annoncer un ensemble borné ne devrait pas soudainement exporter la majorité de la table mondiale sans déclencher plusieurs contrôles. Même si la liste de préfixes est obsolète ou incomplète, la variation de volume de route doit être extraordinaire.

L’autorisation de préfixe client a aussi une dimension réciproque. Le client doit valider ce qu’il exporte. Il doit figer l’ensemble attendu de routes avant un changement, inspecter la sortie générée, et comparer les annonces sortantes réelles à cet ensemble. Le fournisseur doit valider indépendamment ce qu’il reçoit. Ces contrôles ne sont pas redondants; ils réduisent les défaillances en mode commun.

Les attentes écrites ne s’imposent pas seules. Les objets Internet Routing Registry, contrats, tableurs et tickets sont des registres de responsabilité. Le routeur implémente la frontière. Le test pratique est de savoir si une route non autorisée est rejetée dans un exercice de validation sûr et si le rejet est visible pour les deux opérateurs.

Les contrôles AS-path et la politique relationnelle couvrent des preuves différentes

L’autorisation de préfixe vérifie si une route couvre une destination attendue. Les contrôles AS-path vérifient si le chemin est plausible pour la relation.

Un client peut légitimement fournir du transit pour des réseaux descendants. Dans ce cas, un filtre uniquement lié à l’ASN d’origine du client pourrait rejeter un service valide. Le fournisseur a besoin d’un customer-cone autorisé ou d’une autre représentation des origines et des chemins que le client peut transporter.

La représentation du chemin est difficile. Les relations AS changent. Les fusions, revendeurs, accords régionaux, route servers, confédérations et sessions complexes résistent à une classification simple. L’inférence relationnelle publique est utile mais imparfaite. Les enregistrements business privés peuvent être précis mais ne peuvent pas toujours arriver à temps dans les opérations de routage.

Cette difficulté n’est pas une raison d’accepter tous les chemins. C’est une raison de classer la confiance, borner l’incertitude et surveiller les déviations. Un fournisseur peut combiner déclarations explicites du client, preuves de registre, chemins stables observés, données d’origine RPKI et revue manuelle. Il peut rejeter les chemins contenant son propre ASN à une position inattendue, des ASNs réservés, une longueur manifestement impossible ou des origines clairement non autorisées.

Le RFC 9234 rend explicites les rôles de session entre deux routeurs BGP et définit les règles de propagation pour les rôles fournisseur, client, peer, route server et client de route server. [14] L’attribut OTC peut marquer des routes qui devraient ensuite voyager seulement vers les clients. Le mécanisme aide à prévenir et détecter les fuites qui violent ces règles relationnelles.

Mais les BGP Roles ne sont pas un modèle complet de chaque arrangement commercial. Le RFC reconnaît les relations complexes et avertit qu’une configuration de rôle incorrecte peut aussi affecter la propagation. La leçon n’est pas de "activer une seule fonction". La leçon est de rendre la relation lisible par la machine, la confirmer avec le voisin quand c’est possible, tester le résultat et surveiller l’état de route en fonctionnement.

Pour un incident de 2004, ces mécanismes sont des comparatifs rétrospectifs. Le constat d’imputabilité est plus ancien et plus général: la politique relationnelle était déterminante, mais trop d’application de celle-ci dépendait d’une configuration qui n’a pas arrêté la chaîne d’exportation et d’acceptation anormale.

Les limites de préfixe maximum fournissent un disjoncteur de volume

Une limite maximum de préfixes fixe une borne supérieure au nombre de routes qu’une session BGP peut contribuer. Lorsque le total dépasse le seuil configuré, le routeur peut alerter, rejeter des routes supplémentaires, ou fermer la session selon l’implémentation et la politique.

Pour un événement impliquant plus de 100 000 préfixes inattendus, une limite bien choisie est une couche de contention évidente. Un client annonçant un ensemble beaucoup plus petit ne devrait pas pouvoir atteindre une échelle quasi-globale sans franchir le seuil.

Le contrôle est simple en principe et délicat en exploitation.

Définir un seuil trop bas et une croissance légitime ou un événement de déaggregation peut réinitialiser la session, entraînant une panne. Le définir trop haut le rend décoratif. Redémarrer automatiquement une session sans corriger la source de route peut provoquer des oscillations. Alerter sans chaîne de réponse propriétaire transforme l’alerte en bruit.

Le seuil doit être basé sur le volume attendu, la croissance, la variation opérationnelle et le coût d’un échec. Il devrait avoir des niveaux d’avertissement et d’action dure. Une exception doit être documentée et limitée dans le temps. La réponse doit déterminer s’il faut maintenir la session à l’arrêt, n’accepter que le sous-ensemble autorisé ou coordonner une correction avec le client.

Le maximum de préfixe ne prouve pas non plus l’autorisation. Un client peut fuir un petit ensemble mais dommageable en dessous du seuil. Il peut annoncer un préfixe plus spécifique critique, un seul default, ou un groupe plausible appartenant à une autre organisation. La limite est un disjoncteur, pas un substitut à la validation de préfixe et de chemin.

L’incident démontre la valeur des contrôles indépendants. Si l’allowlist de préfixe échoue, la limite de volume peut encore contenir une fuite massive. Si les deux échouent, la détection d’anomalies peut comparer les routes courantes avec le jeu client attendu. Si la surveillance échoue, des alertes de route externes et des rapports de pairs peuvent encore déclencher la réponse.

Un opérateur imputable doit être capable de rapporter combien de sessions externes ont des seuils d’avertissement et des seuils durs configurés, comment ces seuils sont revus, quelles sessions ont des exceptions, à quelle fréquence les seuils se déclenchent, et si les exercices prouvent que la réponse protège à la fois la sécurité de routage et la continuité.

La politique explicite d’import et d’export réduit les ambiguïtés par défaut

Le RFC 8212 a modifié le comportement attendu pour les routeurs eBGP: les routes ne devraient pas être importées ni exportées lorsqu’aucune politique explicite n’est configurée. [13] La norme visait une classe récurrente de pannes où une politique manquante permettait une propagation large.

Le principe s’étend au-delà d’un comportement de fournisseur. Chaque session externe devrait avoir un comportement d’import et d’export intentionnel. L’opérateur doit connaître le comportement si une route-map est absente, échoue à générer, référence un objet vide ou est détachée pendant la maintenance.

Le comportement fail-open est attrayant sous pression de disponibilité. Si un flux de registre est indisponible, accepter tout peut maintenir une session active. Si un générateur de politique échoue, conserver la dernière configuration valide peut sembler périmée. Rejeter toutes les routes peut aussi casser le service. Il n’existe pas de réponse universelle.

L’exigence d’imputabilité est de choisir délibérément et tester les modes de défaillance. Un opérateur peut conserver la dernière configuration connue bonne, bloquer seulement les expansions nouvelles, exiger une approbation manuelle ou basculer le trafic sur un autre chemin. Ce qu’il ne doit pas faire est de découvrir pendant un incident qu’un objet manquant a changé silencieusement de "autoriser ces routes" à "autoriser toutes".

La politique d’export mérite une attention équivalente. Un réseau peut valider ses imports clients mais annoncer par erreur des routes fournisseur ou peer dans une autre relation. Il peut attacher une communauté erronée, omettre un contrôle no-export, ou appliquer une route-map dans le mauvais sens. Les ensembles d’annonces sortantes générés doivent être comparés à l’intention relationnelle avant déploiement.

L’événement TTNet est un cas de test utile pour les systèmes de politique. Injectez un jeu de table complète représentatif ou un jeu client anormal dans une session laboratoire. Vérifiez que les contrôles propres au client rejettent ces routes, que les contrôles d’import du fournisseur les rejettent, que la limite de préfixes les contient et que la surveillance identifie toute route résiduelle.

Ce test se concentre sur le comportement. Un document de politique indiquant que "les routes client sont filtrées" n’est pas une preuve que la configuration générée actuelle rejette la classe d’incident.

Le RPKI améliore la preuve d’origine, mais n’encode pas toute fuite

Le RPKI permet aux détenteurs de ressources de créer des Route Origin Authorizations vérifiables cryptographiquement. Un routeur s’appuyant peut comparer le préfixe et l’ASN d’origine d’une route BGP aux données ROA validées et classer la route comme Valid, Invalid ou NotFound selon les sémantiques pertinentes. Le RFC 6811 définit la validation d’origine de préfixe. [15]

C’est une amélioration importante par rapport aux revendications d’origine non authentifiées. Si une annonce fuyante présente un ASN d’origine que le détenteur de la ressource n’a pas autorisé, la validation d’origine de route peut l’identifier et la rejeter selon la politique locale.

Mais une fuite de politique de chemin peut conserver une origine légitime. Un client apprend une route valide d’un fournisseur et la fuite vers un autre fournisseur tout en gardant l’ASN d’origine initial. La route peut être d’origine valide même si sa propagation viole la relation prévue. Le RPKI de validation d’origine ne code pas, à lui seul, cette vallée.

Cette distinction compte pour TTNet. Les résumés publics divergent dans la description de l’origine et de la structure de chemin de toutes les routes touchées. Un article ne doit pas prétendre que le RPKI aurait bloqué chaque annonce sans tester l’ensemble réel de routes contre les autorisations contemporaines, qui n’existaient pas non plus sous leur forme moderne.

Le NIST SP 800-189 recommande des protections interdomaines en couches, incluant la validation d’origine basée sur RPKI et le filtrage de préfixes. [18] Son cadre plus large est utile: un routage résilient exige plusieurs mécanismes car la sécurité d’origine, la politique de chemin, la falsification, la réponse aux attaques de déni-service et la surveillance opérationnelle sont des problèmes différents.

Le RPKI crée aussi des responsabilités opérationnelles. Les opérateurs ont besoin d’une diversité de caches validés, d’une surveillance de fraîcheur, d’un comportement sûr pendant une panne de dépôt, d’une politique pour Invalid et NotFound, d’une gouvernance des exceptions et de métriques montrant l’application réelle. Créer des ROA sans déployer la validation d’origine de route laisse la preuve hors décision de forwarding.

Le principe Heng.lu est visible ici. Les enregistrements de ressources sont des registres. Ils peuvent établir des preuves d’autorisation et soutenir l’imputabilité. Ils ne sont pas des ordres souverains pour les routeurs. C’est la politique exécutée qui détermine si la preuve affecte la joignabilité.

La surveillance doit comparer les routes en fonctionnement aux routes attendues

L’incident TTNet était visible car l’état de route avait changé de manière spectaculaire. Un système de surveillance mature doit détecter plusieurs dimensions de ce changement.

La surveillance de volume observe combien de préfixes une session annonce, retire et conserve. Un saut d’une base bornée vers une grande fraction de la table globale doit être traité comme un événement critique.

La surveillance d’origine observe si les préfixes attendus ont changé d’ASN d’origine ou si un client a commencé à annoncer de l’adressage hors de son autorité. Le RPKI et les données de registre peuvent soutenir cette comparaison.

La surveillance de chemin observe si les relations client, fournisseur et peer apparaissent dans des séquences inattendues. Elle peut identifier une propagation de type vallée, des boucles, un raccourcissement soudain du chemin ou l’ASN du réseau lui-même dans une position anormale.

La surveillance de spécificité observe si des routes plus spécifiques inattendues sont apparues. Un nombre réduit de préfixes plus précis peut attirer beaucoup de trafic même si le total de routes reste sous une limite.

La surveillance géographique et topologique compare des observations de plusieurs collecteurs. Une route visible dans une seule région peut être un problème de politique local; une route qui se diffuse à travers des upstream indépendants indique une propagation plus large.

La corrélation des changements connecte les anomalies de route aux déploiements, fenêtres de maintenance, commits de configuration et tâches d’automatisation. Un pic global de routes secondes après un push de politique doit immédiatement identifier le changement candidat sans obliger les opérateurs à chercher des systèmes non liés.

La surveillance doit produire une preuve exploitable. Une alerte doit avoir un propriétaire, une sévérité, une session concernée, le delta de route observé, la base attendue, la recommandation de contention et le parcours d’escalade. Elle doit préserver les échantillons de routes qui l’ont déclenchée.

L’alerte seule n’est pas la contention. Un réseau peut détecter la fuite et passer de précieuses minutes à décider qui peut réinitialiser une session, quel route-map restaurer, comment contacter les pairs, ou si le rollback aggraverait la panne. Les exercices doivent tester la chaîne opérationnelle.

La surveillance publique offre une couche indépendante. Les clients et opérateurs de services critiques peuvent surveiller leurs propres préfixes et origines depuis des points de vue externes. Les fournisseurs peuvent comparer leur vue avec RouteViews, RIPE RIS ou des flux commerciaux. Une preuve indépendante aide à détecter des défaillances de télémétrie interne et confirme si un retrait s’est propagé.

Responsabilité entre AS9121, fournisseurs, pairs et importateurs

L’imputabilité doit être assignée selon le contrôle, la preuve et le devoir.

AS9121 avait le contrôle principal sur l’ensemble de routes qu’il exportait. Sa revue opérationnelle devait identifier le déclencheur, la politique prévue, la configuration générée, l’approbation, le chemin de déploiement, l’heure de détection, l’action de contention, le processus de retrait et les tests de remédiation. Si un client ou une source de route aval a initié la table, la revue devait distinguer ce déclencheur de la responsabilité d’AS9121 dans l’acceptation et l’export.

Les fournisseurs en amont directs et peers ont contrôlé la première frontière externe de contention. Ils devaient montrer la relation attribuée à la session AS9121, l’ensemble de préfixes et de chemins attendu, la politique de préfixe maximum, les exceptions, les alertes et la politique d’exportation ultérieure. Si une quantité extraordinaire de routes a été acceptée, la revue doit expliquer quel contrôle a échoué, était absent ou a été outrepassé.

Les réseaux de transit et pairs suivants ont contrôlé les frontières ultérieures. Leur responsabilité dépend de ce qu’ils ont appris, de qui l’a appris et quelle politique était raisonnable pour cette relation. Un client aval recevant une table complète de son fournisseur est dans une position différente d’un fournisseur acceptant une table complète d’un petit client.

Les opérateurs de collecteurs de route contrôlent la mesure, pas la propagation des routes. Leur devoir est de documenter les points de vue, les horodatages, la rétention et les limites méthodologiques. Les chercheurs doivent rendre les transformations reproductibles lorsque licences et confidentialité le permettent.

Les opérateurs de service critiques contrôlaient la résilience autour de l’événement. Le multihoming, la diversité de fournisseurs, la surveillance externe des routes, les communications hors bande et les plans de secours peuvent réduire l’impact. Mais ces opérateurs ne contrôlaient pas la source de la route fuyante et ne doivent pas absorber la faute qui revient aux frontières de politique interdomaines.

Les utilisateurs finaux contrôlaient presque rien de pertinent au BGP. Ils ont connu lenteurs, black holes ou panne de service. Leurs rapports peuvent aider à détecter l’impact, mais ils ne peuvent valider les chemins AS ni émettre des retraits.

Ce modèle en couches évite deux erreurs. La première consiste à attribuer toute la responsabilité à l’opérateur source tout en traitant les fournisseurs comme de simples tuyaux. La seconde consiste à disperser la responsabilité si largement qu’il ne reste plus de propriétaire de contrôle. Chaque réseau doit répondre pour la frontière qu’il a opérée.

La reprise est une transition d’état de route, pas une déclaration

Arrêter le déclencheur est nécessaire mais insuffisant. Le BGP est distribué, et l’état de route converge dans le temps.

Le réseau source peut corriger une politique, retirer des routes, réinitialiser des sessions ou déconnecter une source. Les voisins directs doivent traiter le retrait ou la perte de session, choisir des alternatives et exporter des changements. Leurs voisins répètent le processus. Le dampening de flap, les mécanismes de routes obsolètes, l’état des sessions et la politique locale peuvent affecter la chronologie.

Une déclaration opérateur du type "la configuration a été corrigée" marque une action interne. Elle ne prouve pas que l’état de route global est propre.

Un registre de reprise imputable devrait répondre:

Quand AS9121 a-t-il cessé d’exporter l’ensemble de routes anormales?
Quelles sessions ont été réinitialisées, filtrées ou maintenues à l’arrêt?
Quand les pairs directs ont-ils observé des retraits ou des remplacements?
Combien de préfixes anormales restaient-ils à chaque collecteur indépendant, au fil du temps?
Les chemins légitimes sont-ils revenus, et étaient-ils utilisables dans le data plane?
Des chemins obsolètes ou des fuites secondaires restaient-ils visibles après la correction principale?
Quand les services critiques ont-ils récupéré depuis plusieurs régions et réseaux d’accès?
Quels pairs ont nécessité une coordination directe plutôt qu’une convergence automatique?

L’archive de routes peut aider à répondre à certaines de ces questions. Les journaux de session privés et les instantanés de routes peuvent répondre davantage. Les sondes de data plane peuvent distinguer la normalisation de la table de route de la joignabilité réelle.

La preuve de reprise doit aussi conserver l’incertitude. Si un collecteur normalise à 10:00 et un autre à 10:07, le rapport ne doit pas inventer une unique seconde de reprise globale. Il peut rapporter un intervalle de convergence et décrire les points de vue.

L’étape finale est un replay sûr. Les opérateurs devraient reproduire la classe d’échec dans un laboratoire ou un environnement de validation contrôlé. Un client représentatif devrait tenter d’annoncer un ensemble client surdimensionné et non autorisé. Le test doit montrer quelle couche le rejette, quelles alertes se déclenchent, qui répond et comment la preuve est conservée.

Sans ce test, un changement de politique reste une promesse.

Un contrôle moderne est en couches

Aucun contrôle unique ne résout toutes les fuites de route, et les couches doivent être conçues pour échouer indépendamment.

Politique de session explicite:Le comportement d’import et d’export doit être explicite, avec un traitement sûr des objets de politique manquants ou en échec. Le RFC 8212 fournit une direction utile par défaut. [13]

Filtres de préfixes autorisés:Les clients directs doivent être limités aux préfixes qu’ils sont autorisés à annoncer ou à transporter, sur la base de preuves maintenues et d’exceptions contrôlées.

Contrôles AS-path et customer-cone:Les fournisseurs doivent évaluer si le chemin est plausible pour la relation, pas uniquement si l’origine est valide.

Limites de préfixe maximum:Les seuils par session doivent avertir et contenir des volumes anormaux avant qu’une fuite à l’échelle de table ne se propage.

Validation d’origine RPKI:Les routeurs doivent utiliser des preuves d’origine validées selon une politique opérationnelle qui gère les routes Invalid, NotFound, l’échec de cache et les exceptions. [15]

BGP Roles et OTC:Là où c’est pris en charge et approprié, des rôles mutuellement confirmés et la gestion Only-to-Customer peuvent encoder et appliquer les attentes relationnelles. [14]

Tests de politique générée:L’automatisation doit comparer ressources prévues, configuration générée et annonces simulées avant déploiement.

Sûreté du changement:Les changements de routage à haut risque doivent utiliser déploiement progressif, revue, canaris quand possible, conditions d’arrêt automatiques et rollback testé.

Surveillance indépendante:Les vues internes et externes de route doivent détecter anomalies de volume, d’origine, de chemin et de spécificité et les relier aux changements récents.

Coordination d’incident:Les opérateurs doivent disposer de contacts à jour, de canaux hors bande, d’actions de contention préautorisé, et de modèles pour partager les préfixes affectés et la preuve de retrait.

Vérification de reprise:Plusieurs points de vue de couche de contrôle et de data plane doivent confirmer la normalisation.

Ces contrôles doivent être mesurés. Les métriques utiles incluent le pourcentage de sessions clients avec allowlists générées, limites de préfixe strictes, politique d’origine validée, surveillance externe, classification relationnelle actuelle et tests de replay récents de fuite. L’âge des exceptions et les preuves obsolètes sont également importants.

MANRS encadre le filtrage, la coordination, l’anti-spoofing et la validation globale comme actions d’opérateur. [17] Le NIST SP 800-189 traite aussi la sécurité du routage comme un ensemble de mesures complémentaires plutôt qu’un seul appareil. [18] La valeur de ces cadres réside dans l’adoption opérationnelle et la vérification.

La preuve des registres et la primauté du code en exécution

L’événement TTNet s’inscrit directement sur la surface de responsabilité Heng.lu: routage BGP, enregistrements ASN et IP, et relations de peering/transit.

Un enregistrement ASN peut identifier AS9121. Les registres d’adresses peuvent identifier les allocations et les détenteurs. Les registres de routage peuvent publier les objets route et la politique. Le RPKI peut fournir une autorisation d’origine signée. Ces enregistrements réduisent l’ambiguïté et créent une chaîne de preuve.

Ils ne font pas acheminer les paquets.

Les routeurs en service ont accepté et propagé un ensemble de routes selon la configuration chargée et l’état de session actif. Si la politique opérationnelle a ignoré, mal interprété ou échoué à récupérer la preuve du registre, l’enregistrement écrit n’a pas contraint le réseau.

C’est pourquoi un registre doit être compris comme un registre-comptable, pas un souverain. Sa légitimité vient d’enregistrements exacts, uniques, sécurisés, transférables et opérationnels. L’application reste la responsabilité de l’opérateur.

La primauté du code en exécution n’écarte pas la gouvernance. Elle la rend testable. Un conseil peut exiger des ressources autorisées, mais doit aussi exiger la preuve que ces ressources produisent des filtres et des décisions de validation de route. Un auditeur peut inspecter un objet IRR, mais il doit aussi tracer cet objet via le générateur de politique jusqu’au routeur et tester une annonce contradictoire.

La couche réalité rejette deux formes d’argumentaire. L’une dit que la décentralisation signifie que personne ne peut être imputable. L’autre dit qu’un registre central peut imposer la correction d’internet. Aucune ne décrit le système.

Internet est un réseau de systèmes opérés indépendamment reliés par des accords et des sessions de protocole. L’imputabilité vient de preuves exactes, de frontières explicites, de politiques exécutables, de contrôles indépendants et de reprises vérifiables.

Retirer BGP, AS9121, l’autorisation de préfixe, la politique relationnelle, les collecteurs et les retraits de cet article détruit la thèse. La surface de contrôle réseau n’est pas de la décoration. C’est le sujet.

Ce qu’un dossier de remédiation crédible devrait contenir

Un dossier crédible de classe TTNet serait suffisamment concret pour qu’un autre opérateur ou auditeur puisse reproduire l’affirmation de contrôle.

Il commencerait par une chronologie d’incident distinguant le premier déclencheur interne, la première mauvaise route externe, la première alerte, le diagnostic, la contention, le retrait, la convergence partielle et la reprise vérifiée. Chaque horodatage identifierait sa source et la référence temporelle.

Il inclurait la politique d’import et d’export prévue pour les sessions concernées, la configuration pré-incidente réelle, le changement ou l’échec ayant produit la fuite, et la configuration corrigée. Les valeurs sensibles pourraient être masquées tout en préservant la logique.

Il figerait le jeu de préfixes et de chemins client attendus, expliquerait les sources de référence, listerait les exceptions et afficherait le filtre généré. Il enregistrerait les seuils d’avertissement et d’action hard.

Il inclurait des mises à jour BGP représentatives des moniteurs internes, pairs directs, RouteViews et RIPE RIS. Il expliquerait les limites des collecteurs et la méthodologie de comptage.

Il montrerait pourquoi les contrôles initiaux ont échoué: absence de filtre, données obsolètes, mauvais rôle de session, génération défaillante, ordre de politique, exception trop large, comportement fail-open, alerte sans propriétaire ou une autre cause fondée sur les preuves.

Il documenterait les décisions de contention et la coordination avec les pairs. Si une session a été réinitialisée, le rapport indiquerait pourquoi. Si des routes ont été rejetées de manière sélective, il montrerait les critères.

Il fournirait un graphe de retrait et de convergence par point de vue, plus des vérifications data plane pour les destinations critiques.

Il rendrait compte de la propriété de la remédiation, des échéances, des preuves de fin des travaux et du risque résiduel. Une formule du type "les procédures ont été mises à jour" ne suffit pas.

Enfin, il inclurait une répétition contrôlée montrant qu’une exportation de table complète ou un export client anormal est rejeté sur plusieurs couches indépendantes et que l’événement atteint une alerte possédée sans s’échapper vers les pairs en production.

Ce dossier ne rend pas l’internet sans risque. Il rend la revendication de contrôle de l’opérateur testable.

Les questions de gouvernance doivent suivre la route

Dirigeants, régulateurs, auditeurs et acheteurs de services peuvent poser des questions efficaces sans prétendre configurer des routeurs.

Les conseils devraient demander quelles modifications peuvent changer les annonces BGP publiques, combien de sessions client n’ont pas d’allowlists actuelles ou de limites de préfixe strictes, comment les exceptions sont approuvées, et quand le dernier exercice de replay de fuite a eu lieu.

Les fournisseurs de transit devraient demander si les enregistrements de relation sont à jour, si la politique d’import et d’export est explicite, si les filtres générés échouent en sécurité, et si les routes anormales sont contenues avant redistribution.

Les acheteurs d’entreprise devraient demander si la diversité de transit est topologiquement indépendante, si leurs préfixes critiques sont surveillés de façon externe, et si les rapports de fournisseur incluent des preuves d’état de route.

Les auditeurs devraient échantillonner des configurations actives et des politiques générées. Ils devraient tracer les preuves de ressources jusqu’aux décisions de route et tester des cas négatifs. Une capture d’écran d’un portail de politique n’est pas une preuve d’application.

Les régulateurs devraient éviter des mandats à contrôle unique qui confondent déploiement et résultat. Exiger des ROA améliore la preuve d’origine, mais un programme d’imputabilité de fuite de route demande aussi une politique relationnelle, du filtrage, de la surveillance, de la coordination et des tests de reprise.

Les réviseurs d’incidents ne doivent pas s’arrêter à l’expression "erreur humaine". Cette expression n’explique pas pourquoi une erreur pouvait exporter un ensemble extraordinaire de routes, pourquoi des pairs directs l’ont acceptée, pourquoi les protections n’ont pas contenu, ou pourquoi la reprise a pris le temps observé.

Les métriques doivent montrer couverture et exceptions, pas du vanity. Un réseau peut annoncer 99 pour cent de couverture de filtres en laissant un client à fort volume non restreint. Le risque suit la frontière exposée, pas la moyenne.

La gouvernance doit aussi protéger l’incertitude vraie. Les opérateurs doivent devoir divulguer quelles parties de l’état de route n’ont pas pu être reconstruites, quelles données n’ont pas été conservées et quels contrôles contrefactuels n’ont pas été testés.

Le test d’imputabilité est la propagation bornée et le retrait vérifié

L’événement TTNet du 24 décembre 2004 reste pertinent car il a mis en évidence un problème de contrôle qui existe encore là où les relations BGP sont implicites, les filtres larges et les preuves de route déconnectées de la politique exécutée.

AS9121 a exporté un ensemble de routes extraordinaire. D’autres systèmes autonomes ont accepté et redistribué suffisamment pour transformer une panne locale de politique en un incident de joignabilité distribué. Les collecteurs de route publics ont conservé une partie du registre de contrôle. Des analyses ultérieures ont fait de l’événement un repère pour la détection de fuite.

Les preuves publiques ne justifient ni des allégations d’intention malveillante, ni un nombre universel unique de préfixes, ni une reconstruction complète de chaque décision opérateur. Ces limites doivent rester visibles.

La responsabilité était en couches. Le réseau exportateur contrôlait sa génération et ses annonces de routes. Les fournisseurs directs et pairs contrôlaient la première frontière externe d’acceptation. D’autres réseaux contrôlaient la propagation ultérieure. Les opérateurs de surveillance contrôlaient la qualité des preuves. Les opérateurs de service contrôlaient la résilience. Les utilisateurs finaux ont subi l’impact sans contrôler l’état de route.

La remédiation moderne est aussi en couches. Les filtres de préfixes autorisés, les contrôles de chemin AS, les limites de préfixes maximum, la politique explicite, la validation RPKI, les BGP Roles, le test de politique, la surveillance indépendante, la coordination d’incident et la vérification de reprise couvrent des parties différentes de la chaîne de panne.

La doctrine Heng.lu fournit la distinction finale. Les registres des ressources et de la politique de routage peuvent établir qui est censé annoncer quelles ressources et quelles relations sont prévues. Ils sont des registres d’imputabilité indispensables. Les routeurs en service déterminent toujours la joignabilité.

Un opérateur crédible devrait donc pouvoir prouver trois choses.

Premier: il sait ce qu’un client ou un peer est autorisé à annoncer.

Deuxième: ses systèmes de production rejettent ou contiennent les annonces dépassant ce périmètre, même quand une source de politique ou un composant d’automatisation échoue.

Troisième: quand un état erroné s’échappe, il peut le retirer rapidement et prouver à partir de points de vue indépendants que l’internet est revenu à un état de route autorisé.

C’est le test de responsabilité du filtrage de préfixes clients rendu visible par la fuite TTNet de 2004. Le standard n’est pas une prévention parfaite. C’est la propagation bornée, un contrôle assigné, des preuves conservées et une reprise vérifiée.

TTNet et la fuite de route de 2004 qui a fait du filtrage des préfixes clients un test de responsabilité

Pourquoi c'est important