Résumé

  • Une perturbation majeure du backbone CenturyLink/Level 3 a commencé autour de 10 h 00 UTC le 30 août 2020 et a rendu de nombreux réseaux injoignables pendant environ cinq heures. Quatre observateurs ont vu, chacun depuis ses propres instruments, des oscillations de routes, une hausse anormale des mises à jour BGP, du trafic qui s’arrêtait dans le réseau, des annonces périmées et une perte étendue de joignabilité.
  • CenturyLink a attribué l’incident à une demande FlowSpec destinée à bloquer une seule adresse IP mais reçue avec des jokers, admise par un filtre secondaire puis largement propagée. L’opérateur a déclaré que l’annonce problématique empêchait BGP de s’établir correctement sur des éléments du réseau ; les observations externes confirment les effets de routage, pas toute la chaîne causale privée.
  • La responsabilité se mesure donc dans le système en fonctionnement : calcul de la portée effective, limitation de la propagation, capacité de retrait, autorité d’arrêt et preuve de reprise de bout en bout. Le dossier public ne désigne ni individu ni fournisseur responsable, n’établit ni intention malveillante ni responsabilité juridique, et ne prouve pas l’efficacité actuelle de toutes les mesures préventives ultérieures.

Un incident mondial vu par quatre horloges différentes

Le dimanche 30 août 2020, la connectivité d’une partie importante de l’Internet s’est dégradée en quelques minutes. Les sources situent le début dans une fenêtre étroite autour de 10 h 00 UTC, sans prétendre observer le même instant technique. L’Information Sciences Institute de l’USC a placé la détérioration générale vers 09 h 55 à partir de sondes de joignabilité. Cloudflare a enregistré le début des erreurs à 10 h 03 sur sa propre infrastructure. Ces repères ne s’annulent pas : ils correspondent à des points d’observation, des seuils et des phénomènes distincts.

La perturbation a duré approximativement cinq heures. Parler d’une panne de CenturyLink ne signifie pas qu’elle se limitait aux sites hébergés ou aux clients directs de l’entreprise. Level 3 exploitait un backbone de premier plan, présent dans les chemins utilisés par de nombreux autres réseaux. Lorsqu’un tel intermédiaire continue à annoncer une route qui ne transporte plus correctement le trafic, un utilisateur peut perdre un service sans connaître CenturyLink et sans avoir choisi ce fournisseur.

Les symptômes étaient ceux d’une défaillance du plan de contrôle : routes qui apparaissaient puis disparaissaient, volumes inhabituels de messages BGP, trafic envoyé vers un chemin où il s’arrêtait, préfixes injoignables et annonces devenues obsolètes. Une application pouvait afficher un délai d’attente ; un opérateur de réseau voyait plutôt une route instable ou un chemin annoncé mais inutilisable. Relier ces niveaux est important, car l’expérience de l’utilisateur est la conséquence finale d’un état de routage diffusé entre systèmes autonomes.

Cloudflare a indiqué avoir retiré automatiquement CenturyLink/Level 3 de ses choix de routage dans 48 villes. Ce geste montre la valeur d’un chemin alternatif lorsqu’il existe et lorsque l’information de retrait permet de le sélectionner. Pourtant, des échecs ont continué là où des routes périmées retenaient le trafic ou là où un réseau ne disposait en pratique que d’un seul amont. La baisse de 3,5 % du trafic mondial mesurée par Cloudflare décrit ce que sa plateforme a vu ; elle ne constitue ni un nombre de personnes touchées, ni une estimation financière, ni une mesure universelle de l’Internet.

Catchpoint a étudié des données RouteViews et rattaché les annonces anormales à AS3356, le système autonome de Level 3. Son analyse a constaté une forte augmentation du trafic BGP sur un collecteur du London Internet Exchange. Elle a aussi distingué les réseaux capables de contourner l’événement de ceux dont les chemins continuaient à traverser CenturyLink. Cette distinction empêche de confondre deux contrats de transit inscrits dans un inventaire avec deux voies réellement indépendantes en situation d’incident.

Le système Trinocular de l’USC/ISI a observé la perte de joignabilité depuis des points de mesure nationaux et internationaux. Il a vu des milliers de réseaux devenir injoignables avant la reprise. L’unité est ici un réseau et un état de réponse depuis certains points, non une personne ou une entreprise unique. Plusieurs instruments peuvent compter le même phénomène, tandis qu’un réseau peut desservir une population très variable. Le constat solide est celui d’une atteinte étendue à la continuité, pas celui d’un total humain inventé.

ThousandEyes apporte une autre combinaison de preuves. Ses observations ont décrit du trafic qui se terminait dans le réseau Level 3, des oscillations de routes, des annonces périmées et des changements de comportement chez les pairs. La publication conserve aussi les explications préliminaires puis développées que CenturyLink avait transmises à ses clients. Il faut maintenir une séparation nette : les effets externes ont pu être observés indépendamment ; la séquence interne FlowSpec reste un récit attribué à l’opérateur.

La séquence FlowSpec décrite par CenturyLink

BGP permet aux réseaux autonomes d’échanger des informations de joignabilité et de choisir par quel voisin atteindre un préfixe. FlowSpec réutilise ce mécanisme de distribution pour transporter des règles qui reconnaissent certains flux et leur appliquent une action, par exemple les rejeter ou les rediriger. En cas d’attaque par déni de service, cette capacité permet d’étendre rapidement une mesure défensive à plusieurs équipements sans configurer chaque routeur séparément.

Cette efficacité donne à l’entrée une portée potentiellement considérable. Une demande humaine possède un but — ici, bloquer une adresse IP selon le récit de CenturyLink — tandis que l’objet encodé possède un ensemble de correspondances. Des masques, champs ou jokers déterminent le trafic réellement visé. Le réseau n’exécute pas l’intention telle qu’elle est formulée dans un ticket ; il exécute la règle normalisée qu’il a admise. Si les deux périmètres diffèrent, la distribution rapide amplifie immédiatement l’écart.

L’explication développée de CenturyLink, conservée par ThousandEyes, indique qu’une demande destinée à bloquer une seule adresse a été reçue avec des jokers. Elle aurait franchi un filtre secondaire avant de se propager largement. L’annonce FlowSpec problématique aurait alors empêché BGP de s’établir correctement sur des éléments du réseau. Chacun de ces détails internes doit rester explicitement attribué à CenturyLink. Les collecteurs et les sondes peuvent montrer l’instabilité et l’injoignabilité ; ils ne voient ni la demande originale, ni chaque comparaison du filtre, ni l’état exact de tous les routeurs.

La mention d’un « filtre secondaire » ne suffit pas à conclure que la validation était robuste ou à expliquer précisément son échec. Un contrôle peut vérifier la syntaxe sans comparer l’effet au but. Il peut accepter un joker valide mais trop large. Il peut lire une représentation antérieure à une transformation, ou partager avec le premier contrôle la même interprétation erronée. Le dossier ne précise ni le langage complet de la règle, ni l’implémentation, ni la hiérarchie des configurations. Ces possibilités servent donc à formuler des questions de contrôle, pas à reconstruire un défaut précis.

Il serait tout aussi injustifié de désigner un constructeur, un logiciel ou une plateforme. FlowSpec est une technique normalisée disponible dans plusieurs environnements, et les quatre sources ne documentent aucun défaut de produit. Elles ne permettent pas davantage d’identifier la personne qui aurait saisi, validé, transformé, approuvé ou propagé la demande. La formulation « une demande a été reçue » ne donne pas l’intention ni la répartition des responsabilités individuelles.

CenturyLink a déclaré avoir bloqué l’annonce fautive et restauré la stabilité de BGP. Voilà ce que le dossier permet d’affirmer sur l’atténuation immédiate. Le retour du réseau démontre une capacité à interrompre la condition active et à reconstruire le routage. Il ne prouve pas que toutes les améliorations envisagées ensuite ont été installées sur l’ensemble du parc, testées de manière indépendante et maintenues jusqu’à aujourd’hui.

Pourquoi l’accord des mesures ne reconstitue pas les journaux internes

Les quatre publications se renforcent parce qu’elles emploient des méthodes différentes. Un réseau de diffusion mondial observe les erreurs et les relations de transit. Un service de mesure analyse les chemins et les annonces. Un laboratoire universitaire teste activement la joignabilité depuis plusieurs endroits. Un observateur de performance décrit les trajets et conserve les communications de l’opérateur. Leur convergence réduit le risque qu’un tableau de bord isolé ait produit une fausse image de l’événement.

Mais leur accord porte sur l’extérieur. Un collecteur BGP ne reçoit qu’une partie des annonces visibles depuis ses sessions. Une sonde active indique qu’une destination répond ou ne répond pas depuis un point déterminé. Une trace peut montrer où le trafic cesse d’avancer. Aucun de ces instruments n’enregistre les évaluations d’un filtre privé, le texte de la commande, les droits d’approbation ou la réaction interne de chaque appareil.

Cloudflare avait discuté, pendant l’incident, de scénarios susceptibles d’expliquer les symptômes. Ces hypothèses contemporaines ont une valeur historique : elles montrent comment un opérateur voisin raisonnait avec des informations incomplètes. Elles ne doivent pas être fusionnées avec l’explication ultérieure de CenturyLink pour former une causalité prétendument indépendante. La chronologie probante distingue les conjectures du moment, le récit de l’opérateur et les effets vérifiables.

Les données d’impact doivent elles aussi conserver leurs dénominateurs. Trois virgule cinq pour cent du trafic vu par Cloudflare, des milliers de réseaux injoignables selon Trinocular, une hausse des mises à jour dans RouteViews et du trafic interrompu sur des chemins ThousandEyes ne sont pas des quantités additionnables. Elles mesurent des objets qui se recouvrent. Elles soutiennent l’existence d’une atteinte de grande ampleur, mais non un chiffre unique de victimes, de pertes, de transactions ou de dommages.

Valider l’effet, pas seulement la forme de la règle

Pour une entrée de contrôle aussi puissante, trois questions doivent être résolues avant une diffusion générale. La première concerne la structure : l’objet est-il valide pour le protocole et pour l’implémentation ? La deuxième concerne la politique : la combinaison de correspondances et d’actions appartient-elle à une classe autorisée ? La troisième concerne l’intention : la portée que les équipements vont réellement appliquer est-elle celle que le demandeur et l’approbateur ont comprise ?

Un contrôle qui répond « oui » à la syntaxe peut échouer sur l’intention. Un joker peut être licite dans la grammaire tout en étendant une règle de façon disproportionnée. Une valeur par défaut peut produire un ensemble de flux plus grand que celui affiché dans l’interface de demande. Le cas de 2020 invite donc à demander si le système calculait et présentait la correspondance effective avant de libérer la règle, sans prétendre savoir quel test exact manquait chez CenturyLink.

Une preuve utile rapprocherait dans un même affichage la cible autorisée et l’effet normalisé. Pour une demande portant sur une adresse, le système pourrait expliciter le nombre d’adresses, de préfixes, de protocoles et de ports concernés, ainsi que les régions et équipements destinataires. Une différence inattendue devrait créer une exception forte. Un clic d’approbation n’apporte aucune sécurité supplémentaire si le réviseur voit le même texte ambigu que le demandeur plutôt que l’objet que le réseau exécutera.

L’indépendance des vérifications compte davantage que leur nombre. Deux étapes qui utilisent le même analyseur, les mêmes valeurs par défaut et la même représentation peuvent reproduire la même erreur. Une seconde preuve peut venir d’un calcul séparé, d’une simulation sûre, d’une comparaison avec l’autorisation ou d’un essai borné dont les effets sont observés. Il n’est pas indispensable de changer de fournisseur ; il faut éviter qu’une seule hypothèse commune franchisse toutes les étapes.

Le déploiement progressif limite le coût d’une incertitude résiduelle. Une nouvelle règle peut d’abord être appliquée à un petit ensemble représentatif d’éléments, avec une ligne de base pour les sessions BGP, le volume de mises à jour, le trafic correspondant et la joignabilité de destinations non visées. La progression ne devrait pas dépendre seulement de l’absence d’alarme locale. Elle devrait exiger que le comportement externe reste dans l’enveloppe attendue.

Un essai limité n’est pourtant pas une protection magique. Il doit reproduire les transformations et le contexte qui seront utilisés à grande échelle. Il doit avoir une durée suffisante pour révéler l’instabilité et, surtout, un seuil d’arrêt explicite. Une augmentation corrélée des réinitialisations de session, des oscillations de routes, du trafic qui se termine ou des pertes de joignabilité doit geler l’expansion avant que toutes les régions ne partagent le même état.

L’autorité d’arrêt complète la validation. Certaines erreurs ne deviennent visibles qu’une fois la règle active. La personne ou l’automate qui détecte une divergence doit pouvoir interrompre la propagation et retirer la règle sans attendre une reconstruction causale complète. Cette décision peut s’appuyer sur des faits opérationnels limités : la portée excède l’autorisation, des sessions échouent après la diffusion, les annonces s’emballent ou des sondes externes perdent des destinations sans rapport avec le blocage demandé.

Enfin, l’échec du dispositif de validation doit lui-même avoir un état sûr. Si un service ne répond pas, si deux calculs sont en désaccord ou si la portée reste ambiguë, une règle de backbone ne devrait pas bénéficier par défaut du privilège de diffusion maximale. L’incertitude doit réduire le périmètre ou retarder l’expansion. Cette règle de décision transforme la validation d’une formalité documentaire en frontière opérationnelle.

Des routes de secours qui doivent pouvoir devenir actives

La gravité de l’incident tient aussi au fait que certains réseaux n’ont pas pu contourner le chemin défaillant. BGP repose sur un échange d’informations : lorsqu’une route disparaît ou perd sa préférence, une autre peut être choisie. Une annonce périmée rompt ce mécanisme. Elle continue d’attirer le trafic vers un réseau qui ne le transporte plus correctement, même si une voie alternative existe ailleurs.

L’expérience de Cloudflare fournit un contraste concret. Dans 48 villes, l’entreprise a pu retirer CenturyLink/Level 3 et déplacer le trafic. Ailleurs, des routes anciennes ou une dépendance à un seul amont ont laissé des destinations inaccessibles. Catchpoint a observé la même différence entre les réseaux qui pouvaient modifier leur chemin et ceux dont le trajet restait lié à AS3356. La diversité déclarée ne produit de continuité que si les chemins sont indépendants et sélectionnables au moment critique.

Le contrôle de l’annonce FlowSpec ne peut donc pas être isolé du mécanisme de retrait. Une règle défensive ne devrait pas compromettre la capacité du backbone à annoncer sa propre indisponibilité. Les sessions BGP, les retraits, les préférences locales, les réactions des pairs et la purge des états périmés deviennent des contrôles de récupération. Leur comportement doit être testé lorsque la source de l’incident se trouve précisément dans le plan de contrôle.

La reprise mérite plusieurs jalons plutôt qu’un seul mot « résolu ». Bloquer l’annonce problématique arrête le déclencheur. Rétablir les sessions permet au réseau d’échanger de nouveau. Laisser les routes converger élimine les états périmés. Vérifier la joignabilité confirme enfin que les utilisateurs disposent de chemins stables. Ces étapes peuvent apparaître à des heures différentes dans les sources sans qu’une mesure soit erronée.

Une validation externe est nécessaire parce qu’un backbone peut paraître sain depuis son centre tout en restant mal représenté chez ses voisins. Les collecteurs doivent montrer la diminution des oscillations et des annonces anormales. Les pairs doivent pouvoir retirer ou remplacer les chemins. Des sondes indépendantes doivent retrouver les préfixes depuis plusieurs régions. Le trafic ne doit plus se terminer dans le chemin endommagé. La preuve de reprise se situe à la frontière où l’Internet recommence à faire confiance aux annonces.

Ce que l’on sait, ce qui reste inconnu

Le dossier public ne fournit pas les journaux internes complets ni la séquence exacte de saisie, de transformation et d’évaluation. Il ne dit pas quel rôle possédait la décision de propagation, de révision ou d’arrêt. Il ne permet pas de savoir si la demande provenait directement d’une personne, d’un processus client, d’une automatisation ou d’une combinaison de ces éléments. Une histoire centrée sur un individu comblerait ces lacunes par de la spéculation.

Aucun équipementier, système d’exploitation ou contrôleur FlowSpec n’est identifié comme cause. Même si des produits ont nécessairement participé au fonctionnement du réseau, cette banalité ne démontre aucun défaut. L’analyse de responsabilité reste centrée sur la capacité de l’opérateur à borner et à surveiller l’entrée qu’il distribue, sans transférer arbitrairement la faute à un fournisseur non documenté.

Rien n’établit une intention malveillante. Une demande visant à bloquer une adresse correspond à un usage défensif courant. Le fait qu’elle ait pris, selon CenturyLink, une portée excessive ne transforme pas son auteur inconnu en attaquant. La question productive est de comprendre comment une intention légitime peut être convertie en un objet dangereux sans être arrêtée par le système.

Les sources ne permettent pas non plus d’évaluer l’état actuel des contrôles. Elles documentent la mitigation immédiate signalée par CenturyLink, mais pas un inventaire récent du parc, des exercices de propagation progressive, des tests d’autorité d’arrêt ou une évaluation indépendante des validations aujourd’hui en service. Affirmer que le problème est définitivement corrigé serait aussi infondé qu’affirmer que rien n’a changé.

Cette retenue n’empêche pas un opérateur de rendre des comptes. Sans publier de configurations sensibles, il peut expliquer la classe d’entrée en cause, la différence entre portée demandée et portée effective, la limite de diffusion, les critères d’arrêt et les jalons de reprise. Il peut indiquer ce qui a été observé directement, ce qui provient de son analyse privée et ce qui demeure non vérifié. Une frontière claire entre ces catégories augmente la crédibilité.

La continuité se prouve dans le plan de contrôle actif

FlowSpec reste un outil utile pour réagir rapidement à du trafic hostile. BGP reste le mécanisme qui permet à des réseaux indépendants d’échanger leurs chemins. L’incident ne démontre pas que l’un ou l’autre protocole serait par nature irresponsable. Il montre qu’un mécanisme puissant ne peut tirer sa légitimité de son nom, de sa normalisation ou de l’existence d’un filtre secondaire.

La chaîne essentielle commence par un objet admis dans le système. Selon CenturyLink, sa portée ne correspondait pas à la cible d’une adresse et son annonce empêchait BGP de s’établir correctement sur des éléments du réseau. Les mesures indépendantes ont ensuite enregistré les conséquences dans les routes, les chemins et la joignabilité. Sans ce lien avec le plan de contrôle en fonctionnement, l’analyse de responsabilité perd son objet.

Le standard de responsabilité qui en découle est exigeant mais concret : rendre visible la portée effective, séparer les vérifications, limiter l’exposition initiale, donner un droit d’arrêt utilisable et mesurer la reprise depuis l’extérieur. Il ne suppose ni de blâmer un individu, ni d’accuser un fournisseur, ni de condamner FlowSpec. Il exige que l’organisation possède la preuve de ce que son backbone a fait et des moyens par lesquels elle peut l’arrêter.

En 2020, une règle destinée, selon l’opérateur, à une adresse a été associée à une interruption de routage qui a dépassé les frontières de CenturyLink. La leçon durable n’est pas qu’une règle a franchi un filtre, mais qu’un filtre ne vaut que par l’effet qu’il empêche dans le réseau actif. L’entrée est maîtrisée lorsque l’intention et l’exécution restent alignées, la propagation demeure réversible et la continuité est de nouveau visible pour les réseaux dépendants.

Sources