Résumé

  • Le 17 juin 2016 à 08 h 32 UTC, Cloudflare a détecté d’importantes pertes de paquets sur Telia Carrier AS1299. Le 20 juin à 12 h 10 UTC, l’entreprise a de nouveau observé des pertes massives. À 12 h 30, elle a désactivé ses ports Telia afin de transférer son trafic vers d’autres fournisseurs. [1]

  • Un avis de Telia conservé par Catchpoint décrit une phase distincte du 20 juin, commencée à 16 h 00 UTC lors d’une mise à jour courante de la politique appliquée aux préfixes agrégés du cœur IP. Selon cet avis, le changement a placé dans un trou noir le trafic destiné à des préfixes compris dans ces agrégats. L’ancienne politique fonctionnelle a été rétablie à 17 h 05, puis les services ont récupéré progressivement. [2]

  • Les sources publiques ne démontrent pas que les pertes détectées par Cloudflare à 12 h 10 et le changement de politique signalé à 16 h 00 appartenaient à un mécanisme unique et continu. Elles décrivent des faits survenus le même jour, chez le même fournisseur, mais avec des horaires et des niveaux de précision différents.

  • Catchpoint a rapproché l’avis de l’opérateur d’une forte augmentation des annonces et retraits BGP vus par deux pairs d’AS1299 depuis le collecteur RIPE RIS rrc01. Ces observations indiquent une perturbation importante du plan de contrôle depuis des points d’observation précis. Elles ne représentent ni un recensement des utilisateurs touchés, ni un décompte des paquets perdus, ni une mesure financière. [2]

  • Telia contrôlait la source de la politique de routage, son déploiement, les mécanismes internes de surveillance, le retour arrière et la communication destinée à ses clients. Cloudflare contrôlait pour sa part la diversité de ses fournisseurs, la décision de retirer le transit Telia, la capacité des chemins alternatifs, ses mesures applicatives et ses propres communications. [1]

  • Une session BGP établie et une route acceptée ne prouvent pas que les paquets atteignent leur destination. Le plan de contrôle peut sembler cohérent alors que le plan de transfert abandonne le trafic. La surveillance doit donc associer état BGP, tests de livraison, télémétrie indépendante et transactions applicatives.

  • Rien dans le dossier public ne permet d’identifier la commande fautive, l’auteur ou l’approbateur du changement, tous les équipements concernés, le nombre complet de clients affectés ou les mesures correctives durables. Aucune source n’établit un détournement malveillant, une interception ou un sabotage.

  • Les RFC 7908, 7454, 8212, 9234 et 6811, ainsi que les recommandations du NIST et de MANRS, fournissent un cadre utile pour évaluer les politiques interdomaines, le filtrage et l’autorisation d’origine. Elles ne prouvent ni leur déploiement chez Telia en 2016, ni la capacité d’un contrôle particulier à empêcher ce trou noir interne. [7][8][9][10][11][12][13]

  • La responsabilité doit suivre la maîtrise réelle des opérations. Pour l’opérateur de transit, cela signifie limiter les changements, vérifier les invariants des agrégats, surveiller la livraison, préparer le retour arrière et publier des preuves de récupération. Pour le client, cela signifie disposer de chemins véritablement indépendants, de capacité de réserve et d’un pouvoir de retrait testé.

Deux dates proches, mais pas une panne unique démontrée

La première discipline consiste à ne pas transformer plusieurs observations en une histoire plus simple que les preuves. Le 17 juin, Cloudflare a rapporté que ses systèmes avaient détecté des pertes importantes entre plusieurs destinations à 08 h 32 UTC sur Telia Carrier AS1299. Les pertes sont ensuite devenues intermittentes avant de disparaître pendant l’analyse. Ce constat prouve un problème de livraison mesuré par un client majeur. Il ne révèle ni la cause interne, ni l’étendue exacte, ni un incident continu jusqu’au 20 juin. [1]

Le lundi 20 juin, Cloudflare a identifié à 12 h 10 UTC ce qu’elle a qualifié de pertes massives de paquets chez le même fournisseur. L’entreprise a relié cette dégradation à une hausse de ses erreurs HTTP 522, qui correspondent à l’incapacité de joindre à temps certains serveurs d’origine. Elle a également indiqué que d’autres clients de Telia semblaient perdre du trafic. À 12 h 30, Cloudflare a mis ses ports Telia hors service et a réorienté le trafic vers ses autres fournisseurs et interconnexions. [1]

Cette décision est une preuve opérationnelle importante. Elle indique que le problème n’était pas seulement une variation abstraite dans une table de routage : un client observait des paquets abandonnés et des transactions applicatives en échec. Elle montre aussi que Cloudflare disposait d’un levier direct. L’entreprise ne pouvait pas réparer la politique interne de Telia, mais elle pouvait cesser de lui confier le trafic.

Un autre segment de la chronologie apparaît dans l’avis client de Telia reproduit par Catchpoint. Cet avis situe à 16 h 00 UTC une mise à jour courante de politique concernant des préfixes agrégés dans le cœur IP de Telia Carrier. Le changement aurait placé dans un trou noir le trafic destiné aux préfixes contenus dans les agrégats. Telia aurait rétabli à 17 h 05 la politique antérieure, connue pour fonctionner, avant d’observer une récupération progressive. [2]

La différence entre 12 h 10 et 16 h 00 interdit de présenter automatiquement les deux phases comme l’effet ininterrompu d’une seule configuration. Une perte de paquets peut provenir d’une congestion, d’une défaillance de transfert, d’un équipement, d’un lien optique, d’une politique de routage ou de plusieurs phénomènes combinés. Le trou noir des préfixes agrégés constitue un mécanisme plus précis, mais les documents publics ne le relient pas explicitement à chaque paquet perdu plus tôt dans la journée.

Les articles contemporains ont largement décrit les répercussions de l’incident et les difficultés rencontrées par Cloudflare et d’autres services. Ils aident à comprendre la visibilité publique de la panne, mais ne remplacent pas les mesures du client ni l’avis technique de l’opérateur. [5][6] Les événements ultérieurs associés à AS1299, Twelve99 ou Arelion ne doivent pas être introduits dans cette analyse. Le nom historique Telia Carrier désigne ici l’opérateur concerné en 2016 ; il ne permet aucune conclusion sur les performances actuelles de son successeur.

La chronologie défend ainsi une conclusion limitée : des pertes ont été observées le 17 juin ; de nouvelles pertes ont été observées le 20 juin ; Cloudflare a retiré son transit Telia ; puis un avis de Telia a décrit une mise à jour de politique d’agrégation, un trou noir et un retour à une version antérieure. Tout lien causal plus détaillé resterait une hypothèse.

Ce qu’un fournisseur de transit promet réellement

Le transit Internet n’est pas seulement l’achat d’un lien ou la présence d’une session BGP. Le fournisseur accepte le trafic de son client, échange des informations de joignabilité et transporte les paquets vers des destinations que le client ne peut pas atteindre directement. La valeur du service réside donc dans l’union de deux réalités : une route exploitable et une livraison effective.

Une dorsale mondiale peut continuer à annoncer une destination tout en étant incapable de lui transmettre certains paquets. Inversement, une modification de route peut être visible dans plusieurs collecteurs sans provoquer une panne pour tous les utilisateurs. Il faut distinguer la promesse du plan de contrôle — quelles routes sont annoncées et sélectionnées — de celle du plan de transfert — où les paquets vont réellement.

Dans l’incident étudié, Telia Carrier contrôlait plusieurs couches essentielles : la génération de ses politiques, leur validation, leur déploiement sur les équipements concernés, l’installation des routes, la résolution des prochains sauts, la surveillance interne et le retour arrière. L’avis conservé par Catchpoint rattache directement le trou noir à un changement effectué dans ce périmètre. [2]

Le client de transit possède d’autres commandes. Il choisit le nombre et la diversité de ses fournisseurs, les lieux d’interconnexion, la capacité réservée sur les chemins secondaires, les préférences locales et les conditions dans lesquelles un chemin doit être retiré. Il décide également si la bascule est automatique, assistée ou entièrement manuelle.

Cloudflare a expliqué qu’elle entretenait des relations avec plusieurs fournisseurs Tier 1 et de nombreux pairs. Cette architecture lui a permis de désactiver les ports Telia et de déplacer le trafic. [1] Une entreprise reliée à un seul fournisseur, ou dont les chemins alternatifs convergent vers la même dépendance physique, n’aurait pas nécessairement disposé du même recours.

Cette séparation ne dilue pas la responsabilité de Telia. Un client ne peut pas corriger une politique interne à AS1299. Elle évite cependant de traiter la résilience du client comme une simple conséquence du contrat. Lorsqu’un service promet une haute disponibilité, il doit démontrer que sa diversité est utilisable en situation de panne.

Tous les clients ne disposent pas des mêmes moyens. Un grand réseau de diffusion peut modifier ses annonces et absorber une bascule mondiale. Une entreprise achetant une connexion administrée peut ne contrôler ni BGP ni les capacités en amont. La responsabilité doit être proportionnée au pouvoir réel : exiger une réparation interne de la part du fournisseur, mais une préparation au basculement seulement de la part des clients capables de l’organiser.

Comment un agrégat peut attirer des paquets vers un trou noir

Un préfixe IP désigne un bloc d’adresses. Un réseau peut annoncer plusieurs préfixes détaillés ou les regrouper sous un préfixe plus large, appelé agrégat. Cette agrégation limite la taille des tables de routage et simplifie certaines politiques, mais elle crée une obligation : tout trafic attiré par l’agrégat doit pouvoir atteindre les destinations que celui-ci est censé couvrir.

Les routeurs utilisent généralement la correspondance de préfixe la plus longue. Lorsqu’une route plus spécifique existe, elle peut orienter le trafic vers le chemin adapté. Si cette route disparaît tandis que l’agrégat reste annoncé, les paquets peuvent suivre l’agrégat. Celui-ci devient dangereux si le réseau qui l’annonce ne possède plus de chemin valable vers certains de ses composants.

L’avis de Telia décrit précisément cette catégorie de défaillance. Une mise à jour de politique appliquée aux préfixes agrégés aurait fait disparaître le traitement correct du trafic destiné à des préfixes inclus. Les annonces visibles pouvaient donc continuer à attirer les paquets, alors que le réseau ne les livrait plus. [2]

Un tel trou noir diffère d’un retrait propre. Lorsqu’une annonce disparaît, les autres réseaux peuvent sélectionner une route alternative, si elle existe. Lorsqu’une route reste visible et préférée, le trafic continue d’entrer dans le fournisseur défaillant. La session eBGP peut rester établie, les messages KEEPALIVE peuvent circuler et une table peut contenir un chemin apparemment valide, sans qu’un paquet utile atteigne sa destination.

La configuration exacte n’est pas publique. Il serait imprudent d’affirmer qu’un filtre précis, une redistribution, un prochain saut invalide ou un générateur d’agrégats particulier était en cause. Chacun de ces éléments peut produire une défaillance similaire dans d’autres circonstances, mais aucun n’est établi ici. La preuve disponible s’arrête au niveau décrit par l’opérateur : changement de politique sur des agrégats, trafic des préfixes contenus placé dans un trou noir, puis restauration de la politique précédente.

Même sans la ligne de configuration, le contrôle attendu peut être défini. Une politique d’agrégation doit être accompagnée d’une liste des préfixes contenus dont la joignabilité dépend de l’agrégat. Le système doit vérifier la présence des routes attendues, la résolution de leurs prochains sauts, leur installation dans le plan de transfert et leur accessibilité depuis des points représentatifs.

La validation syntaxique ne suffit pas. Un fichier peut être bien formé, toutes ses références peuvent exister et son déploiement peut réussir techniquement, alors que son comportement est incorrect. La vérification doit porter sur le résultat : quelles annonces apparaissent, quels chemins sont installés, quels paquets arrivent, quels services répondent.

Une mise en production progressive réduit l’exposition. Un petit ensemble de sessions ou d’équipements peut recevoir le changement, tandis que des mesures comparent l’état avant et après. Si des préfixes contenus deviennent injoignables, si le volume de retraits dépasse une limite ou si les transactions applicatives échouent, le déploiement doit s’arrêter avant de toucher le reste de la dorsale.

Le contrôle le plus utile est un invariant négatif : un agrégat ne doit jamais être déclaré sain uniquement parce qu’il est présent dans la table. Sa santé dépend aussi de la livraison vers un échantillon représentatif de ses composants. Cette règle relie l’intention de routage à la réalité du transfert.

Ce que les collecteurs BGP montrent — et ce qu’ils ne montrent pas

Catchpoint a examiné les données du collecteur RIPE RIS rrc01, notamment les observations provenant de deux pairs d’AS1299. L’analyse décrit une forte augmentation des annonces et retraits autour de la période indiquée par l’avis de Telia. Elle évoque environ 500 000 réseaux IPv4 et 32 000 réseaux IPv6 dans les événements observés, soit une part importante des routes partagées par ces pairs. [2]

Ces chiffres caractérisent l’activité de routage depuis des points d’observation déterminés. Ils ne signifient pas que 500 000 réseaux ont tous été indisponibles, encore moins qu’un nombre équivalent d’organisations ou d’utilisateurs a subi la même panne. Un préfixe peut produire plusieurs mises à jour. Une modification peut ne pas affecter la livraison. À l’inverse, un client peut perdre des paquets sans que le collecteur sélectionné voie l’état interne responsable.

RIPE RIS et RouteViews collectent des annonces auprès de participants distribués. Leurs archives permettent de comparer des chemins, d’identifier l’apparition d’un retrait et de rapprocher une perturbation d’une chronologie d’opérateur. [15][16] Elles ne voient pas toutes les sessions privées, les préférences locales, les routes internes, les décisions de transfert ni les paquets abandonnés après leur entrée dans un réseau.

RIPEstat fournit des informations utiles sur AS1299 et les ressources associées. [14] Un registre ou une fiche d’ASN aide à attribuer une observation à un opérateur ; il ne commande pas les routeurs et ne garantit pas le service. De même, une route visible depuis un collecteur est une preuve de ce que ce point a reçu, non un certificat universel de joignabilité.

Cloudflare apporte un autre niveau de preuve : pertes mesurées, hausse des erreurs HTTP 522 et amélioration recherchée par le retrait du transit Telia. [1] Ces données relient le plan de contrôle aux conséquences de transfert et d’application. Elles restent toutefois celles d’un client doté d’une architecture et de points de présence particuliers.

Une analyse solide assemble quatre couches. La première est l’intention : la politique que l’opérateur voulait appliquer. La deuxième est l’état BGP effectivement observé : sessions, annonces, retraits et chemins. La troisième est le transfert : les paquets atteignent-ils des destinations représentatives ? La quatrième est l’application : une transaction utile aboutit-elle dans les délais requis ?

Chaque couche peut être correcte alors qu’une autre échoue. La politique approuvée peut différer de celle déployée. Une route peut être présente alors que le prochain saut est inutilisable. Des paquets peuvent atteindre un serveur dont une dépendance ne répond plus. Une preuve de récupération doit donc montrer que les différentes couches convergent vers un état cohérent.

Pourquoi l’étiquette de « fuite de route » doit rester prudente

La RFC 7908 définit une fuite de route comme la propagation d’annonces au-delà de la portée prévue. Cette portée dépend souvent des relations entre clients, fournisseurs et pairs, ainsi que des politiques d’importation et d’exportation des systèmes autonomes. [7]

Cette définition évite de qualifier toute anomalie de détournement. Une fuite peut être accidentelle et provenir d’un opérateur autorisé à annoncer un préfixe, mais dont la route a été propagée à un ensemble de voisins incompatible avec la politique attendue. Un détournement, en revanche, peut suggérer une origine non autorisée ou une intention que les preuves doivent établir.

Dans le cas de Telia, l’avis conservé décrit un problème de politique d’agrégation et un trou noir. Catchpoint a observé un volume considérable de mises à jour et de retraits. [2] Ces faits démontrent une perturbation du routage et de la livraison. Ils ne donnent pas la totalité des relations entre systèmes autonomes, de la portée d’exportation voulue ou de l’état des origines nécessaire pour classer chaque événement selon un type précis de la RFC 7908.

Aucune source ne désigne un attaquant, un identifiant compromis, une fausse origine, une interception recherchée ou un acte de sabotage. L’explication attribuée à Telia est celle d’une mise à jour courante suivie d’un retour arrière. Qualifier l’ensemble d’attaque ou de détournement malveillant dépasserait donc nettement le dossier.

Cette prudence ne réduit pas l’importance du cas pour la sécurité du routage. Elle déplace la question vers les contrôles pertinents. L’autorisation d’origine peut empêcher certaines annonces non autorisées. Elle ne vérifie pas qu’une politique interne d’agrégation conserve un chemin de transfert vers tous les préfixes inclus.

Une origine RPKI valide ne garantit pas la livraison

La RFC 6811 définit la validation de l’origine d’un préfixe à partir des données RPKI. Un réseau peut comparer l’AS d’origine d’une annonce aux autorisations publiées dans les ROA et classer l’annonce en conséquence. [11]

Ce mécanisme répond à une question essentielle : l’AS qui se présente comme origine est-il autorisé par les données disponibles ? Il ne répond pas à toutes les autres. Il ne vérifie ni le prochain saut interne, ni l’existence d’une route vers un préfixe plus spécifique, ni la capacité disponible, ni la livraison d’un paquet après son entrée dans l’AS autorisé.

Un agrégat peut donc être annoncé par une origine parfaitement autorisée et rester inutilisable pour certains de ses composants. La signature ou la validité de l’information d’origine n’atteste pas que le plan de transfert correspond à l’intention. Dans l’incident de 2016, aucune preuve ne permet d’affirmer que la validation d’origine aurait empêché le mécanisme décrit.

La RFC 8212 exige des politiques explicites d’importation et d’exportation pour eBGP au lieu de s’appuyer sur des comportements permissifs par défaut. [9] Cette approche réduit les échanges accidentels liés à l’absence de politique. Elle ne garantit pas qu’une politique explicitement écrite soit correcte.

La RFC 9234 introduit les rôles BGP et l’attribut Only-to-Customer pour rendre certaines relations plus explicites et limiter des propagations contraires à ces rôles. [10] Ces outils visent des erreurs de diffusion entre systèmes autonomes. Ils ne constituent pas une preuve rétrospective qu’ils auraient détecté un trou noir créé dans le traitement d’un agrégat.

Les recherches ultérieures sur Peerlock étudient d’autres moyens de limiter certaines fuites entre grands réseaux. [17] Elles apportent un contexte précieux pour la défense interdomaines, mais ne décrivent pas la configuration de Telia en 2016 et ne fondent aucun scénario certain de prévention.

La leçon n’est pas que ces contrôles seraient inutiles. Elle est qu’ils répondent à des classes de risque différentes. Une politique responsable combine autorisation d’origine, cohérence des relations, filtrage, validation du chemin, contrôle du transfert et mesure réelle des paquets.

Les contrôles qui relevaient de Telia Carrier

La première responsabilité de l’opérateur était de comprendre la portée de son changement. Une politique employée sur une dorsale ne doit pas être évaluée comme une modification locale isolée. Avant le déploiement, il faut identifier les routeurs, familles d’adresses, sessions, agrégats, préfixes plus spécifiques, groupes de clients et régions susceptibles d’être touchés.

La deuxième responsabilité concernait les invariants. Pour chaque agrégat modifié, Telia devait pouvoir répondre à des questions concrètes : quels préfixes doivent rester accessibles ? Quels prochains sauts doivent être résolus ? Quels voisins doivent recevoir l’annonce ? Quel comportement est attendu si un composant disparaît ? À quel moment l’agrégat doit-il lui-même être retiré ?

La troisième était la validation sémantique. Une comparaison de texte ou un contrôle de syntaxe ne suffit pas à prévoir l’état produit par des milliers de routes et plusieurs politiques combinées. Le candidat au déploiement doit être testé avec des données proches de l’état courant, notamment les exceptions et routes récemment apprises.

La quatrième était le déploiement borné. Une politique touchant un nombre élevé de préfixes ne devrait pas être appliquée partout au même instant sans mécanisme de coupure. Un canari sur un ensemble limité d’équipements ou de sessions permet de comparer les annonces, les retraits, la résolution des prochains sauts, les pertes et les transactions.

La cinquième était l’indépendance de la surveillance. Si la seule sonde utile emprunte le chemin que le changement vient de casser, l’opérateur peut obtenir un tableau de bord trompeur. Des points externes et plusieurs chemins doivent vérifier les préfixes contenus. Le plan de contrôle, le plan de transfert et les applications doivent être observés séparément.

La sixième était la préparation du retour arrière. L’avis attribué à Telia indique que la politique antérieure a été restaurée à 17 h 05. [2] Un retour arrière responsable exige que l’ancienne version soit identifiée, immédiatement disponible et compatible avec l’état courant. Son exécution doit être horodatée et son périmètre connu.

Enfin, Telia devait démontrer la récupération. Dire qu’une version précédente a été réinstallée décrit une action administrative. Cela ne prouve pas que les routes ont convergé, que les prochains sauts fonctionnent, que les paquets arrivent ou que les applications ont retrouvé leur niveau de service. La déclaration de rétablissement doit reposer sur ces résultats.

La RFC 7454 décrit notamment des politiques cohérentes aux frontières, le filtrage des préfixes et chemins, les limites de préfixes et la gestion prudente des sessions. [8] Le NIST et MANRS proposent des cadres plus larges de résilience, de coordination et d’hygiène du routage. [12][13] Ces références permettent d’évaluer les objectifs de contrôle ; elles ne révèlent pas les dispositifs que Telia possédait effectivement lors de l’incident.

Le basculement du client doit fonctionner sous charge

Cloudflare a pu désactiver les ports Telia et déplacer son trafic. [1] Cette opération illustre la différence entre une redondance dessinée et une continuité prouvée. Deux contrats ne forment pas nécessairement deux chemins utilisables.

Le second fournisseur peut manquer de capacité lorsque le premier disparaît. Les deux liens peuvent partager une fibre, un centre de données ou un autre réseau en amont. Les mêmes préfixes peuvent ne pas être annoncés sur chaque chemin. Une préférence locale peut continuer à sélectionner la route défaillante. Le déplacement du trafic peut aussi surcharger un point d’interconnexion qui semblait suffisant en période normale.

Un client responsable mesure donc la capacité de ses alternatives pendant des exercices réalistes. Il vérifie combien de temps prend le retrait, comment les autres réseaux convergent, si les annonces restent acceptées et si la latence ou les pertes demeurent compatibles avec le service annoncé.

Cloudflare a indiqué qu’un mécanisme de détection des pertes et de déplacement proactif du trafic était alors utilisé dans certains sites distants de plus petite taille, mais pas sur toute l’empreinte concernée. L’entreprise a présenté son extension comme l’un des enseignements de l’incident. [1] Cette admission montre que la multi-connectivité ne rend pas le basculement automatique par elle-même.

La décision de retrait doit reposer sur plusieurs signaux. Une seule sonde peut produire un faux positif. Une session BGP stable peut produire un faux sentiment de sécurité. Une politique utile combine pertes de paquets, latence, établissement de connexions, transactions applicatives, évolution des routes et disponibilité des chemins secondaires.

Les seuils doivent être explicites. Combien de destinations et de régions doivent échouer ? Pendant combien de temps ? Quelle capacité minimale doit rester disponible ? Comment éviter les oscillations entre deux fournisseurs ? Qui peut suspendre l’automatisme ? Quelles conditions autorisent le retour sur le chemin initial ?

Le basculement est également une question de réversibilité. Le client doit pouvoir quitter une dépendance défaillante sans demander à cette même dépendance l’autorisation d’agir. Lorsque l’architecture promet cette faculté, les clés de configuration, les annonces, les accès aux équipements et la capacité doivent rester sous un contrôle utilisable pendant l’incident.

Ce niveau d’exigence doit rester proportionné. Une petite organisation ne peut pas être jugée comme un opérateur mondial. Elle peut toutefois documenter sa concentration, ses délais d’escalade, ses objectifs de reprise et les engagements qu’elle a réellement achetés. Le fournisseur reste responsable de sa politique ; le client reste responsable des promesses de continuité qu’il fait à ses propres utilisateurs.

Pourquoi une session BGP verte ne suffit pas

BGP échange des informations de joignabilité. Il ne réalise pas en permanence un test de bout en bout de chaque destination annoncée. Deux routeurs peuvent maintenir leur session, envoyer leurs messages de contrôle et conserver des routes pendant que le trafic est abandonné plus loin.

Une route présente dans la RIB indique qu’un chemin a été appris ou sélectionné. Elle ne garantit pas que ce chemin est correctement programmé dans la FIB, que son prochain saut est joignable, que tous les liens intermédiaires disposent de capacité ou que le préfixe contenu sous un agrégat possède encore une sortie valide.

Cette distinction explique pourquoi l’incident est un test de responsabilité plutôt qu’une simple anomalie BGP. Un opérateur peut montrer qu’une annonce existait et néanmoins ne pas avoir livré le service représenté par cette annonce. Pour les clients, la preuve décisive reste la réussite du transfert.

Une surveillance complète doit donc associer des signaux hétérogènes. Les mises à jour BGP montrent la dynamique du plan de contrôle. Les sondes actives mesurent la livraison, les pertes et la latence. Les données de flux indiquent où le trafic change ou disparaît. Les transactions applicatives vérifient si le résultat attendu est obtenu.

Les horloges de ces systèmes doivent être synchronisées. Sans une chronologie commune, il devient difficile d’établir si une annonce a précédé la perte, si le retrait du client a réduit les erreurs ou si le retour arrière a réellement déclenché la récupération.

La meilleure règle de clôture est donc fondée sur la convergence des preuves. La session BGP est stable ; les routes attendues sont présentes ; les prochains sauts sont valides ; les paquets atteignent plusieurs destinations ; les applications récupèrent ; les clients ne signalent plus la même dégradation. Aucun voyant isolé ne doit déclarer la fin de l’incident.

La communication fait partie de la continuité réseau

L’avis de Telia reproduit par Catchpoint indiquait que le volume de plaintes avait retardé les communications par courrier électronique et téléphone. [2] Cloudflare a reconnu séparément que sa communication initiale n’avait pas correctement présenté la dépendance amont et qu’elle devait améliorer son dispositif. [1]

Ces constats ne relèvent pas seulement des relations publiques. Lorsqu’un fournisseur de transit tarde à préciser la nature d’un incident, ses clients doivent décider s’ils retirent des routes, déplacent du trafic, ajoutent de la capacité ou attendent. Une information tardive ou ambiguë peut prolonger l’utilisation d’un chemin nuisible.

Un avis utile doit séparer les faits connus des hypothèses. Il doit préciser la fenêtre temporelle, les services ou régions concernés, la mesure de mitigation en cours et les incertitudes restantes. Si le retour arrière est terminé mais que la convergence continue, cette différence doit être visible.

La capacité de communication doit elle-même résister à l’incident. Un centre d’assistance saturé par les appels ne peut pas être l’unique canal. Les grands fournisseurs ont besoin de messages de diffusion, de formats structurés, d’escalades techniques et d’un moyen de transmettre des mises à jour sans ouvrir un ticket individuel pour chaque client.

Les clients doivent, eux aussi, expliquer ce qu’ils observent directement. Cloudflare a décrit ses pertes, la hausse des erreurs, le retrait de Telia et les limites de son automatisation. [1] Cette séparation entre mesure client et explication fournisseur permet à chacun d’évaluer la réparation sans confondre deux niveaux de preuve.

Une chronologie de communication devrait enregistrer la première détection interne, le premier signalement client, la première notification, l’identification du mécanisme, le début de la mitigation, la fin du retour arrière, la récupération mesurée et la publication de l’analyse finale. Chaque heure doit être attribuée à une source précise.

Les normes définissent des objectifs, pas un verdict automatique

Les normes et guides de bonnes pratiques offrent un vocabulaire commun. Ils ne prouvent ni le déploiement d’un contrôle ni son efficacité lors d’un événement donné.

La RFC 7454 rassemble des pratiques opérationnelles pour la sécurité et la robustesse de BGP : filtrage des préfixes et des chemins AS, limites de préfixes, traitement des communautés et cohérence des politiques selon la relation avec le voisin. [8] Ces mesures réduisent plusieurs catégories d’erreur aux frontières, mais leur présence chez Telia en 2016 n’est pas documentée ici.

La RFC 8212 impose le principe de politiques explicites avant l’importation ou l’exportation de routes eBGP. [9] Elle réduit les risques associés aux comportements permissifs. Elle ne peut cependant pas juger la logique d’une politique correctement déclarée mais sémantiquement erronée.

La RFC 9234 fournit les rôles BGP et l’attribut Only-to-Customer afin de rendre certaines relations et contraintes de propagation plus vérifiables. [10] Elle vise notamment des fuites entre clients, fournisseurs et pairs. Un trou noir interne lié à un agrégat peut se produire sans que l’origine ou le rôle inter-AS soit incorrect.

La RFC 6811 décrit la validation d’origine RPKI. [11] Elle peut établir qu’une origine est valide selon les ROA disponibles. Elle ne confirme pas la livraison par l’opérateur autorisé.

Le document NIST SP 800-189 aborde la résilience du routage interdomaines et l’usage de mécanismes d’autorisation et de filtrage. [12] MANRS formule des actions destinées aux opérateurs, notamment la prévention des annonces incorrectes, la coordination et la validation des informations de routage. [13] Ces cadres aident à formuler les contrôles attendus aujourd’hui, sans constituer une preuve historique sur AS1299.

Les collecteurs RIPE RIS et RouteViews fournissent pour leur part des observations, non une autorité d’exécution. [15][16] Ils préservent des états visibles depuis leurs pairs. Ils n’imposent aucune politique à Telia et ne certifient pas la livraison.

L’emploi correct des normes est diagnostique. Pour chaque mécanisme, il faut demander : quel risque traite-t-il ? Quelle preuve montrerait qu’il fonctionnait ? Quelle partie de l’incident reste hors de sa portée ? Cette méthode évite de transformer le nom d’un contrôle moderne en solution certaine à un événement historique.

Registre opérationnel des responsabilités

Acteur Capacité contrôlée Preuve attendue Question laissée ouverte
Telia Carrier / AS1299 Source de politique, agrégats, déploiement, état interne, transfert, surveillance, retour arrière Diff de politique, périmètre, tests, canari, alertes, chronologie du retour arrière, mesures de récupération Quelle configuration exacte a produit le trou noir et quelle mesure durable a suivi ?
Cloudflare Choix des fournisseurs, préférences, mesures, capacité alternative, retrait du transit et communication applicative Seuils de perte, heure de retrait, capacité après bascule, couverture de l’automatisation et résultats applicatifs Quels sites ou chemins ne disposaient pas encore d’un basculement automatisé ?
Autres clients Transit acheté, diversité, escalade, éventuelle autorité BGP et continuité applicative Contrats, dépendances communes, tests de bascule et chronologie d’impact Quels clients pouvaient retirer Telia et lesquels dépendaient entièrement de l’opérateur ?
Pairs et réseaux adjacents Politiques d’importation et d’exportation propres Routes reçues, acceptées et propagées, relations et filtres pertinents Ont-ils amplifié une perturbation ? Le dossier public ne l’établit pas.
RIPE RIS et RouteViews Observation et conservation partielle du plan de contrôle Archives horodatées, liste des pairs et limites des points de vue Que s’est-il passé sur les sessions privées ou dans le plan de transfert ?
Opérateurs applicatifs Détection utilisateur, continuité du service et information publique Erreurs, transactions, régions touchées, activation du plan de continuité Quelle part de l’impact provenait directement du transit et quelle part d’autres dépendances ?

Ce registre évite deux raccourcis. Le premier consisterait à reprocher au client de ne pas avoir réparé une politique interne qu’il ne contrôlait pas. Le second consisterait à conclure que la faute du fournisseur dispense le client de préparer la continuité qu’il promet à ses utilisateurs.

Les responsabilités peuvent être simultanées sans être équivalentes. Telia possédait le pouvoir exclusif de prévenir et corriger son changement interne. Cloudflare possédait un pouvoir de réduction d’impact grâce au retrait du transit. Les collecteurs pouvaient préserver des indices, mais non modifier le réseau. Les autres clients disposaient de leviers variables.

L’analyse reste opérationnelle. Le dossier ne permet pas d’affirmer une violation juridique, un dommage financier déterminé ou une responsabilité contractuelle précise. Ces questions exigeraient des contrats, des données d’impact et des règles applicables qui ne figurent pas dans les sources.

Sources

  1. https://blog.cloudflare.com/a-post-mortem-on-this-mornings-incident/
  2. https://www.catchpoint.com/blog/incident-review-an-account-of-the-telia-outage-and-its-ripple-effect
  3. https://www.thousandeyes.com/blog/analyzing-internet-issues-traffic-outage-detection
  4. https://servebolt.com/articles/telia-went-down-and-so-did-we/
  5. https://www.theregister.com/2016/06/20/telia_engineer_blamed_massive_net_outage/
  6. https://www.theregister.com/2016/06/21/cloudflare_apologizes_for_telia_screwing_you_over/
  7. https://datatracker.ietf.org/doc/html/rfc7908
  8. https://datatracker.ietf.org/doc/html/rfc7454
  9. https://datatracker.ietf.org/doc/html/rfc8212
  10. https://datatracker.ietf.org/doc/html/rfc9234
  11. https://datatracker.ietf.org/doc/html/rfc6811
  12. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
  13. https://www.manrs.org/wp-content/uploads/2021/02/MANRS-Network-Operators-Actions-v2.4.4.pdf
  14. https://stat.ripe.net/AS1299
  15. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
  16. https://archive.routeviews.org/bgpdata/2016.06/UPDATES/
  17. https://arxiv.org/abs/2006.06576