Résumé

  • Le 8 avril 2010, BGPMon a observé AS23724, un réseau de centre de données associé à China Telecom dans les enregistrements de routage publics, annoncer environ 37 000 préfixes uniques pendant environ quinze minutes, alors que ce réseau n’en annonçait normalement qu’environ quarante; le chemin fréquemment observé incluait AS4134 puis AS23724, ce qui place la frontière d’importation, de sélection et de propagation d’AS4134 au centre de l’analyse.
  • BGPMon a également estimé qu’environ dix pour cent seulement des préfixes annoncés avaient été propagés hors des réseaux chinois, et que 28 pour cent des collecteurs RIPE RIS utilisés dans son analyse avaient vu une partie de l’événement; cette part de préfixes n’est pas une part de trafic, ne prouve pas l’inspection de paquets, ne prouve pas une intention malveillante et ne remplace pas une preuve de retrait vérifiée depuis des points d’observation indépendants.

Ce que l’événement établit

La séquence à analyser est étroite: l’événement de routage AS23724-AS4134 observé le 8 avril 2010. Elle ne doit pas être fusionnée avec des incidents ultérieurs impliquant China Telecom, ni avec d’autres fuites de routes passant par AS4134 dans les années suivantes. Dans ce dossier, la question n’est pas de reconstruire une histoire générale des incidents BGP associés à un opérateur national.

La question est plus précise: lorsqu’un système autonome exporte soudainement un très grand ensemble de préfixes qui ne lui sont pas assignés, et que son voisin direct accepte puis propage une partie de ces routes, où se situent les responsabilités de contrôle?

BGPMon a donné les bornes observées de son compte rendu initial: première annonce anormale à 17:54:31 UTC, dernière annonce anormale à 18:10:14 UTC. Ces horodatages sont des observations de collecteurs. Ils ne constituent pas une horloge universelle applicable à chaque routeur, chaque session BGP ou chaque chemin de paquets. Ils fixent cependant une fenêtre de preuve utile. Dans cette fenêtre, AS23724 a été vu comme origine d’un ensemble anormalement grand de préfixes. Le chemin commun observé contenait AS4134 suivi d’AS23724. Des pairs d’AS4134 ont ensuite propagé au moins une partie de cet ensemble anormal.

Cette distinction entre l’origine et la propagation est essentielle. AS23724 contrôlait les annonces d’origine et sa politique d’exportation. AS4134 contrôlait la première frontière visible d’importation, la sélection de routes reçues de ce voisin, puis la possibilité de les annoncer vers d’autres relations commerciales. Les réseaux en aval ou adjacents contrôlaient à leur tour leur propre acceptation, préférence locale, filtrage et propagation. Les collecteurs de routes, eux, n’ont pas contrôlé l’acheminement: ils ont conservé des observations.

Les détenteurs légitimes de préfixes contrôlaient leurs enregistrements d’autorisation, leurs ROA lorsque disponibles, leur surveillance externe et leurs circuits d’escalade, mais ils ne contrôlaient pas les filtres d’un autre système autonome. Les utilisateurs finaux, enfin, n’avaient aucun levier direct sur l’état BGP.

Le chiffre d’environ 37 000 préfixes est donc un signal de plan de contrôle, pas une mesure de trafic. BGPMon l’a présenté comme un changement extrême par rapport au comportement ordinaire d’AS23724, qui annonçait normalement environ quarante préfixes. Dans une table globale de routage, une telle apparition massive d’origines inattendues est une alarme opérationnelle. Elle ne démontre pas, par elle-même, qu’un volume donné de paquets a traversé AS23724 ou AS4134. Elle ne démontre pas non plus que des paquets aient été inspectés, stockés, modifiés ou exploités.

Une route BGP peut être visible dans un collecteur sans être préférée partout; elle peut être préférée dans certains réseaux et ignorée dans d’autres; elle peut être propagée comme information de plan de contrôle sans devenir le chemin de données effectivement emprunté par un utilisateur donné.

BGPMon a renforcé cette limite dans sa revue ultérieure. L’ordre de grandeur des 37 000 préfixes représentait environ onze pour cent de la table de routage de l’époque, mais BGPMon a explicitement séparé part de préfixes et part de trafic. Le paquet factuel impose cette séparation: une part de préfixes n’est pas une part de trafic.

Un préfixe peut couvrir un réseau très actif ou presque inactif; deux préfixes de taille différente ne portent pas le même nombre d’adresses; la préférence de route dépend de politiques locales; et le trafic applicatif dépend de la localisation des utilisateurs, des caches, des CDN, des chemins de retour et d’un ensemble de décisions qui ne sont pas contenues dans une annonce BGP. Dire qu’un certain pourcentage de la table de routage est apparu dans une fuite n’autorise donc pas à dire que le même pourcentage d’Internet, ou du trafic mondial, a été détourné.

BGPMon a aussi estimé qu’environ dix pour cent des préfixes annoncés avaient été propagés hors des réseaux chinois, et que 28 pour cent des collecteurs RIPE RIS inclus dans son analyse avaient détecté une partie de l’événement. Ces deux chiffres sont des mesures de visibilité et de propagation dans un ensemble d’observation donné. Ils ne disent pas que tous les réseaux externes ont accepté les routes; ils ne disent pas que tous les préfixes annoncés ont eu le même niveau de diffusion; ils ne disent pas qu’un chemin de données mondial unique s’est imposé.

Ils montrent en revanche que le problème n’est pas resté strictement local au lien qui a produit l’annonce initiale: la frontière AS4134, puis les politiques de ses voisins, ont permis à une partie de l’anomalie d’être visible hors du périmètre chinois.

Les chiffres différents apparus dans des analyses ultérieures ne doivent pas être traités comme une contradiction simple. Les observateurs peuvent compter des routes ou des préfixes, utiliser des collecteurs différents, appliquer des fenêtres temporelles différentes, séparer ou regrouper des préfixes plus spécifiques, et choisir des définitions différentes de ce qui constitue l’événement. Un compteur orienté annonces BGP, un compteur orienté préfixes uniques, une reconstruction à partir de collecteurs RIPE RIS et une visualisation historique à plus longue distance ne produiront pas nécessairement le même total.

La responsabilité éditoriale est alors de lier chaque nombre à sa méthode et à son auteur, au lieu d’additionner des chiffres hétérogènes dans une narration unique.

Chronologie opérationnelle

La chronologie sûre commence donc par les observations de BGPMon. Avant la fenêtre, AS23724 n’était pas connu, dans ce compte rendu, comme une origine massive de la table globale. Pendant la fenêtre, il a annoncé environ 37 000 préfixes uniques selon BGPMon. Le chemin fréquemment observé a placé AS4134 devant AS23724, ce qui signifie que la route reçue ou visible passait par AS4134 avant d’atteindre le réseau qui prétendait l’origine. Des pairs d’AS4134 ont propagé une partie de l’ensemble. Après la fenêtre, les annonces anormales ont cessé d’apparaître dans cette observation.

La première borne, 17:54:31 UTC, doit être lue comme “première observation dans ce compte rendu”. Elle ne prouve pas que le changement de configuration s’est produit exactement à cette seconde sur le routeur fautif. Une session BGP peut annoncer, retirer et réannoncer des routes; les collecteurs ne couvrent pas tous les liens; les délais de propagation et de sélection varient. La dernière borne, 18:10:14 UTC, a la même nature: elle indique la dernière observation anormale dans le compte rendu initial, pas nécessairement la fin simultanée de toute préférence de route dans chaque réseau du monde.

Pour juger l’incident, cette nuance est importante parce qu’une métrique de retrait défendable doit être mesurée depuis plusieurs points d’observation indépendants, et non déduite d’un seul flux.

La mention d’une configuration erronée doit rester attribuée et conditionnelle. L’auteur de BGPMon a considéré une erreur de configuration comme plus probable qu’une intention, mais a explicitement signalé que cette appréciation était spéculative puisqu’il n’avait pas parlé aux ingénieurs du réseau concerné. La revue ultérieure a également conservé l’intention et le devenir d’éventuelles données réacheminées parmi les inconnues. Dans une analyse de responsabilité, cette prudence n’affaiblit pas le dossier; elle le rend exploitable.

Il n’est pas nécessaire de prouver une intention malveillante pour constater qu’une frontière de routage n’a pas suffisamment contenu des annonces non autorisées. À l’inverse, il serait irresponsable d’utiliser un volume de préfixes pour affirmer une interception, une inspection de contenu ou une action délibérée que les sources ne démontrent pas.

L’événement est donc mieux décrit comme une fuite de routes ou un détournement BGP au sens opérationnel attribué par les sources: un système autonome apparaît comme origine de routes qu’il ne devrait pas originer, et une partie de ces routes est acceptée ou propagée par d’autres réseaux. Le mot “détournement” peut évoquer une intention; le mot “fuite” peut évoquer une erreur. Les deux termes doivent donc être définis par le mécanisme observé, non par une conclusion psychologique. Le mécanisme observable est l’annonce d’origines anormales, le passage visible par AS4134, puis la propagation partielle vers l’extérieur.

Propagation et preuve de mesure

Un collecteur BGP voit des mises à jour de plan de contrôle. Il peut montrer qu’une route a été annoncée, retirée, remplacée ou préférée dans la vue d’un pair collecteur. Il peut conserver une preuve datée d’un AS_PATH, d’un préfixe, d’une origine et d’une variation. Il peut permettre une reconstruction partielle de la propagation. Il ne voit pas directement les paquets utilisateurs. Il ne mesure pas automatiquement le débit, le taux de réussite des connexions, la latence effective, la perte de paquets ou le contenu applicatif.

Pour passer du plan de contrôle au plan de données, il faudrait des mesures actives ou des traces de trafic contemporaines, avec leurs propres limites.

La donnée “environ dix pour cent des préfixes propagés hors des réseaux chinois” attribuée à BGPMon est ainsi une donnée de propagation de préfixes dans une vue d’observation. Elle renseigne le périmètre extérieur atteint par l’anomalie. Elle ne permet pas d’attribuer un pourcentage de trafic mondial. Même si un préfixe devient visible à l’extérieur, il peut ne pas être choisi par la plupart des réseaux; il peut être moins spécifique qu’une route concurrente; il peut être filtré par certains opérateurs; il peut être préféré localement mais ne porter que peu de flux au moment de l’incident.

L’unité “préfixe” ne porte pas la même signification que l’unité “paquet”, “octet” ou “session utilisateur”.

La donnée “28 pour cent des collecteurs RIPE RIS” attribuée à BGPMon doit aussi être lue avec précision. Elle indique que, dans l’ensemble de collecteurs utilisé, une fraction a vu une partie de l’événement. Cela établit une visibilité distribuée, mais pas une couverture complète. Un collecteur qui ne voit rien ne prouve pas que le réseau voisin n’a rien reçu; il peut simplement ne pas être placé au bon endroit topologique. Un collecteur qui voit une route ne prouve pas que tous les clients du réseau collecteur ont utilisé cette route pour leurs flux.

Les collecteurs sont indispensables pour l’alerte et l’audit, mais ils ne remplacent pas les journaux de routeurs, les configurations effectives, les politiques générées, les seuils maximum-prefix et les mesures actives de retour à l’état attendu.

La propagation partielle est pourtant suffisante pour poser une question de contrôle. Si AS23724 a exporté une route non autorisée mais qu’AS4134 l’avait rejetée sur une politique d’importation explicite, l’incident aurait eu un périmètre plus petit. Si AS4134 l’a acceptée mais avait empêché son annonce vers des voisins pour lesquels la relation ne justifiait pas cette propagation, le périmètre extérieur aurait aussi été plus petit. Si des pairs en aval avaient filtré selon des listes de préfixes autorisés, des ROA valides, des politiques relationnelles ou des seuils de volume, la propagation aurait été plus limitée.

Le fait que la propagation extérieure ait été partielle n’efface pas l’échec; il aide à identifier où certains contrôles ont fonctionné et où d’autres ont manqué.

Pourquoi AS23724 et AS4134 ne portent pas la même frontière

Une fuite de routes met en jeu plusieurs frontières, et les confondre produit de mauvaises conclusions. La première frontière est l’export de l’origine anormale. AS23724, dans les observations publiques citées par le paquet factuel, a été vu comme origine d’un très grand nombre de préfixes non assignés à lui. Le contrôle attendu à cette frontière est simple à formuler: un réseau doit maintenir un ensemble borné de préfixes qu’il est autorisé à annoncer, empêcher l’export accidentel de routes apprises ou d’une table trop large, et vérifier que les exceptions temporaires expirent.

Ce contrôle peut être construit à partir de données de registre, d’IRR, de ROA et d’inventaires internes, mais il n’existe réellement que s’il est traduit en configuration active sur les routeurs.

La deuxième frontière est l’import par le voisin direct. AS4134 ne contrôle pas ce qu’un voisin tente d’annoncer, mais il contrôle ce qu’il accepte, ce qu’il préfère et ce qu’il rend éligible à une annonce ultérieure. Une politique d’importation défendable ne devrait pas traiter un voisin comme une source illimitée de préfixes globalement valides. Elle devrait appliquer une posture de rejet par défaut, des listes de préfixes attendus lorsque la relation le permet, des seuils d’alerte et d’arrêt, une validation d’origine lorsque les ROA existent, et une séparation claire entre routes de client, de pair et de transit.

Dans une fuite de volume, le point critique n’est pas seulement “l’origine a-t-elle menti?”; c’est “pourquoi le voisin a-t-il accepté assez de routes pour qu’une partie quitte le périmètre initial?”

La troisième frontière est la propagation vers l’aval ou vers les pairs. Un opérateur peut accepter une route pour une raison locale sans être obligé de l’exporter partout. La politique de propagation doit être consciente de la relation. Les routes apprises d’un pair ne devraient pas être annoncées à un autre pair comme si elles provenaient d’un client autorisé; les routes apprises d’un fournisseur ne devraient pas être redistribuées de manière à transformer un réseau en transit involontaire; les routes d’un client doivent être limitées au périmètre que ce client est autorisé à annoncer.

Les “BGP Roles” et les protections contre les fuites de routes abordent précisément cette couche relationnelle: ils ne vérifient pas seulement l’origine d’un préfixe, ils cherchent à empêcher une route de franchir une relation où elle ne devrait pas franchir.

La quatrième frontière appartient aux réseaux qui reçoivent les annonces plus loin dans la chaîne. Chaque système autonome décide de ses filtres, de sa validation, de ses préférences et de ses exceptions. Quand une fuite se propage, la responsabilité n’est pas uniforme: le point d’origine a produit l’annonce anormale; le voisin direct a offert la première zone de confinement; les réseaux ultérieurs ont chacun appliqué ou omis leurs propres contrôles. Une analyse sérieuse ne transforme pas cette chaîne en accusation globale.

Elle demande à chaque frontière ce qui était vérifiable, ce qui était automatisé, ce qui dépendait d’une confiance implicite, et combien de temps il a fallu pour retirer l’état anormal.

Autorisation de préfixes et limites de RPKI

Les enregistrements de registre, l’IRR, RPKI et les ROA sont des instruments de responsabilité. Ils aident à relier des ressources numériques à des titulaires, à exprimer des autorisations d’origine et à générer des filtres. Ils ne font pas tourner les routeurs à la place des opérateurs. Une base de données exacte peut être ignorée par une politique BGP permissive. Un ROA peut autoriser une origine correcte sans décrire toute la légitimité du chemin AS. Une absence de ROA peut laisser un opérateur choisir une politique moins stricte. Une exception manuelle peut contourner une génération de filtres.

Le routage réellement accepté dépend de la configuration active, de la politique locale et des décisions de propagation.

La validation d’origine RPKI est utile dans un incident comme celui-ci si des ROA valides permettent d’identifier une origine non autorisée. Dans ce cas, un réseau qui rejette les routes “invalides” peut empêcher une partie de l’anomalie. Mais RPKI origin validation ne prouve pas qu’un AS_PATH entier est légitime. Elle ne règle pas toutes les fuites où l’origine reste valide mais où la route franchit une relation commerciale inattendue. Elle ne garantit pas non plus qu’un opérateur a correctement configuré ses seuils de volume ou ses exports. Elle traite une dimension du problème: l’autorisation de l’origine pour un préfixe donné.

Les fuites de routes ont aussi une dimension relationnelle et opérationnelle.

Les filtres de préfixes répondent à un autre besoin. Ils limitent ce qu’un voisin précis peut annoncer. Pour un client avec un portefeuille de ressources connu, une liste générée depuis des sources autorisées peut empêcher l’annonce d’un ensemble massif de préfixes sans relation avec ce client. Les filtres doivent cependant être maintenus, renouvelés et liés à des processus d’exception. Un filtre obsolète peut bloquer une annonce légitime; un filtre trop large peut laisser passer l’anomalie; une exception sans expiration peut devenir une faille permanente.

La responsabilité ne consiste donc pas à dire “il fallait un filtre” en général, mais à montrer comment la source de données, la génération, l’installation, la vérification et l’expiration du filtre sont reliées.

Les seuils maximum-prefix forment une troisième couche. Quand un voisin qui annonce normalement un nombre faible de préfixes en annonce soudainement des dizaines de milliers, le volume lui-même est un signal. Un seuil d’avertissement peut alerter l’équipe avant de couper; un seuil dur peut fermer une session ou rejeter l’excès. Ces seuils ne savent pas si chaque préfixe individuel est autorisé, mais ils limitent le rayon d’une erreur grossière.

Dans l’événement du 8 avril 2010, le contraste attribué à BGPMon entre environ quarante préfixes ordinaires et environ 37 000 préfixes annoncés illustre le type de changement que ces seuils visent à contenir. Une telle limite aurait dû être discutée non comme une option esthétique, mais comme une barrière de confinement.

Les politiques relationnelles et les BGP Roles complètent l’ensemble. Ils abordent la question de savoir si une route apprise dans une relation peut être propagée dans une autre. Un incident de fuite n’est pas toujours un problème d’origine fausse; il peut être un problème d’export contraire à la relation. Une architecture de contrôle défendable combine donc validation d’origine, listes de préfixes autorisés, seuils de volume, rejet par défaut, rôles relationnels et surveillance indépendante. Aucun élément isolé n’est une cure complète.

Le test de responsabilité consiste à demander quelles couches étaient actives, quelle couche aurait dû arrêter l’événement, et quelle preuve indépendante montre que la même classe d’erreur ne franchirait plus la frontière AS23724-AS4134.

Mesurer le retrait au lieu de raconter la correction

Un incident BGP n’est pas clos parce qu’un communiqué ou une hypothèse de cause existe. Il est clos lorsque les routes anormales sont retirées, lorsque les voisins cessent de les propager, lorsque les collecteurs indépendants ne voient plus l’état fautif, et lorsque les contrôles qui auraient dû empêcher l’export ou l’import ont été vérifiés. Dans ce dossier, les observations de BGPMon fournissent une fenêtre d’apparition et de disparition dans un flux donné.

Une preuve de retrait plus complète identifierait aussi le moment où AS23724 a cessé l’export, le moment où AS4134 a retiré ou cessé de propager les routes, et le moment où les réseaux extérieurs ont convergé vers l’état attendu.

Cette preuve devrait être falsifiable. Elle devrait inclure les données sources de politique utilisées pour décider quels préfixes AS23724 pouvait annoncer, la configuration générée à partir de ces données, l’état effectivement chargé sur les routeurs, les exceptions en vigueur, les seuils maximum-prefix, les alertes déclenchées, les journaux de session et les retraits envoyés. Elle devrait préserver les flux de collecteurs avant, pendant et après la correction. Elle devrait comporter une mesure depuis des points d’observation indépendants, pas seulement depuis le réseau qui corrige.

Et elle devrait inclure un test de récurrence: rejouer en environnement contrôlé la classe d’erreur, vérifier que l’export non autorisé est bloqué, que l’import direct rejette l’ensemble inattendu, et que les politiques d’export relationnel empêchent la propagation.

Le retrait vérifié est important parce que la simple disparition dans une vue ne suffit pas toujours. Une route peut disparaître d’un collecteur mais persister dans un autre segment. Une session peut se réinitialiser et masquer la cause. Une préférence locale peut changer sans que le filtre racine soit réparé. Un opérateur peut retirer manuellement une anomalie sans empêcher sa répétition. Dans une analyse de responsabilité, l’objet n’est pas seulement le retour au calme. L’objet est la preuve que le mécanisme de défaillance a été compris, borné et rendu testable.

Limites de preuve et conclusion provisoire

La preuve publique disponible établit des annonces anormales de plan de contrôle et une propagation internationale partielle. Elle n’établit pas le volume de paquets transmis par AS23724 ou AS4134. Elle n’établit pas le contenu des paquets. Elle n’établit pas une inspection, un stockage, une modification ou une intention malveillante. Elle ne donne pas la commande exacte, le changement de configuration exact, l’escalade interne, les décisions de retour arrière ni les politiques actives sur chaque session externe. Ces inconnues ne doivent pas être remplies par des formulations plus fortes que les sources.

La conclusion opérationnelle reste néanmoins nette. Un réseau qui annonce normalement environ quarante préfixes et qui en annonce environ 37 000 selon BGPMon produit un signal que sa propre frontière d’exportation aurait dû borner. Un voisin direct dont le chemin apparaît comme AS4134 puis AS23724 possède une frontière visible d’importation et de propagation qui aurait dû appliquer des contrôles relationnels, des filtres de préfixes, des limites de volume et une validation d’autorisation lorsque les données le permettaient.

Les réseaux plus loin dans la chaîne ne sont pas de simples spectateurs: chacun possède une politique d’acceptation et d’export. Les collecteurs, enfin, doivent être utilisés pour alerter et vérifier, mais pas pour transformer une part de préfixes en part de trafic.

La norme de responsabilité qui ressort de cet événement est donc une norme de confinement prouvable. Avant l’incident, l’opérateur doit pouvoir dire quels préfixes un voisin est autorisé à annoncer et comment cette autorisation devient configuration. Pendant l’incident, il doit pouvoir détecter un saut de volume, nommer un propriétaire d’escalade et limiter la propagation. Après l’incident, il doit pouvoir démontrer le retrait depuis plusieurs vues et rejouer la classe d’erreur. Sans ces preuves, le récit reste dépendant d’un chiffre spectaculaire.

Avec ces preuves, l’événement devient un cas d’audit: non pas “combien d’Internet a été détourné”, question que les préfixes seuls ne peuvent pas trancher, mais “quelle frontière aurait dû empêcher cette annonce, quelle frontière l’a propagée, et quelle mesure indépendante prouve que cela ne franchit plus le même chemin?”