Panne FlowSpec CenturyLink et responsabilité backbone

Résumé

Le rapport de cause de panne diffusé par CenturyLink indique que l'opérateur a identifié un incident multimarché à 10 h 04 UTC le 30 août 2020. Il a attribué la perturbation à une annonce FlowSpec problématique qui empêchait l'établissement correct de BGP sur plusieurs éléments du réseau. Un changement de configuration global vers 14 h 14 a bloqué l'annonce, et l'opérateur a signalé un service stable et des alarmes effacées à 15 h 10. [1][3][6][8]
Le compte rendu détaillé de l'opérateur indique que l'opération initiale visait à bloquer une adresse IP pour un client. Un défaut entre l'interface utilisateur et l'équipement réseau a provoqué la réception de caractères génériques au lieu de l'adresse spécifique prévue, et un filtre secondaire n'a pas rejeté la règle étendue résultante. Ces détails proviennent d'une reproduction hébergée par un client des notes de panne de CenturyLink et doivent rester attribués plutôt que présentés comme un enregistrement de configuration inspecté indépendamment. [1][3]
Cloudflare a observé des erreurs de joignabilité de l'origine à partir de 10 h 03 UTC, a désactivé CenturyLink dans 48 villes connectées et a transféré le trafic vers d'autres fournisseurs. Il a également mesuré une forte augmentation du volume de mises à jour BGP et proposé une boucle plausible dans laquelle les routeurs établissaient à plusieurs reprises des sessions, recevaient la règle problématique et perdaient à nouveau BGP. Les mesures sont directes; la boucle est une hypothèse technique car les journaux privés du routeur de l'opérateur ne sont pas publics. [2][11]
ThousandEyes a observé une perte de paquets étendue et un comportement de routage cohérent avec un plan de contrôle paralysé. Ses exemples ont montré que la connectivité de secours ne suffisait pas à elle seule: les annonces obsolètes, la préférence de chemin, la densité de peering et la capacité alternative affectaient la capacité du trafic à échapper au transit défaillant. [3][4][5]
FlowSpec n'est pas simplement une interface de pare-feu. Il distribue des règles et actions de correspondance de trafic via BGP. Cela rend la validation, l'autorisation, la portée de distribution, le canari, le rollback, la protection du plan de contrôle et la récupération hors bande proportionnelles à la portée du réseau qui accepte la politique. [13][14][15][16][17]
La responsabilité est distribuée mais pas vague. CenturyLink contrôlait la plateforme politique, l'interface, la validation secondaire, la distribution réseau, les protections de contrôle de routage, le rollback et les preuves d'incident. Les clients et les pairs contrôlaient certaines parties de leur propre multihoming, politique de chemin, retrait et capacité alternative, mais ils ne pouvaient pas réparer la défaillance interne de l'opérateur.
Le test de réparation durable est basé sur les preuves. La désactivation de la plateforme et la modification d'un filtre ont été annoncées comme des actions correctives. Une assurance solide montrerait en outre la reproduction exacte de la défaillance en laboratoire, les contrôles indépendants la rejetant, le déploiement limité, l'accès de gestion protégé, la récupération sous un plan de contrôle dégradé et des tests ultérieurs contre la même classe de défaillance. [1][13][17][20]

Un blocage client est devenu un problème de contrôle à l'échelle du backbone

La façon la plus utile de comprendre l'incident est de commencer par la différence entre la portée prévue et l'autorité effective.

Selon le rapport de cause de panne diffusé par CenturyLink, une équipe d'exploitation utilisait FlowSpec dans le cadre d'un service normal pour bloquer le trafic d'une adresse IP pour le compte d'un client. Il s'agit d'une tâche familière d'atténuation DDoS. L'objet prévu était étroit: une source, un besoin client et une action de trafic limitée. L'objet effectif était beaucoup plus large. L'annonce résultante s'est propagée sur de nombreux dispositifs périphériques et a interféré avec les sessions BGP dont le réseau dépendait. [1]

Ce décalage est le cœur de la responsabilité. Une interface utilisateur peut afficher une seule adresse tandis que le compilateur de politiques aval ou le routeur reçoit un caractère générique. Un filtre secondaire peut sembler indépendant tout en interprétant l'objet malformé selon la même hypothèse erronée. Un système de distribution peut traiter la règle résultante comme ordinaire parce que chaque composant voit une syntaxe valide, même si le sens combiné est catastrophique. La question publique n'est donc pas simplement de savoir qui a tapé quoi.

Elle est de savoir comment un système à portée mondiale a représenté, validé et contraint l'autorité derrière une demande apparemment locale.

FlowSpec soulève cette question avec acuité car il associe la politique de trafic au plan de contrôle de routage. Une liste d'accès traditionnelle est souvent associée à un dispositif ou à une interface. FlowSpec peut transporter des composants de correspondance et des actions via BGP pour qu'un réseau puisse appliquer une atténuation rapidement sur de nombreux routeurs. Cette rapidité est utile lors d'une attaque volumétrique. Elle fait également de l'erreur sémantique un problème de distribution.

Le même mécanisme qui réduit le temps de réponse peut réduire le temps disponible pour détecter une règle dangereuse avant qu'elle n'atteigne une grande partie du réseau. [13][14][15]

Le protocole ne doit pas être traité comme le coupable. La RFC 5575 a défini le mécanisme de l'époque de l'incident, et la RFC 8955 l'a remplacée pour IPv4 tandis que la RFC 8956 couvre IPv6. Ces documents décrivent l'encodage, l'ordre, la validation et les actions de trafic. Ils ne révèlent pas le chemin logiciel privé de CenturyLink ni ne prouvent que chaque implémentation se comporte de la même manière. Un article solide doit distinguer la capacité du protocole de la gouvernance de l'opérateur.

L'incident concernait la manière dont un opérateur a mis en œuvre et utilisé un chemin politique à haute autorité, pas une conclusion que chaque déploiement de FlowSpec est dangereux. [13][14][15]

La même distinction empêche un titre facile mais faible: « une faute de frappe a mis Internet hors service ». Le dossier public ne divulgue pas les octets exacts de la commande, et le compte rendu détaillé de l'opérateur décrit un défaut entre une interface et un équipement réseau plutôt qu'un simple caractère générique visible tapé par une personne nommée. L'incident n'a pas rendu tous les réseaux injoignables. Différents observateurs ont mesuré des effets différents, et certains réseaux ont contourné le problème.

La conclusion défendable est plus étroite et plus importante: une demande d'atténuation à portée client a acquis suffisamment d'autorité pour altérer l'établissement de BGP sur un backbone mondial fortement connecté.

Il s'agit d'un échec de gouvernance exprimé par l'infrastructure réseau. Les contrôles pertinents incluent la validation de schéma, l'autorisation, l'affichage de la portée, la compilation de politiques, les vérifications secondaires, les limites de distribution, la protection du réflecteur de route, les exemptions du plan de contrôle, les canaris, le rollback et l'accès hors bande. Aucun ne peut être évalué uniquement en comptant les routeurs ou en affirmant que la redondance existait.

La chronologie sépare la détection, le diagnostic et la restauration

La chronologie de l'opérateur place l'identification de l'incident à 10 h 04 UTC. La surveillance de Cloudflare a commencé à enregistrer des erreurs de joignabilité de l'origine à 10 h 03. La différence d'une minute n'est pas un conflit; un horodatage est un déclencheur de mesure externe et l'autre est l'enregistrement d'incident de l'opérateur. Les deux placent le début dans la même fenêtre étroite. [1][2]

Cloudflare a vu le trafic via CenturyLink chuter fortement. Ses systèmes automatisés ont commencé à déplacer le trafic vers d'autres fournisseurs, notamment Cogent, NTT, GTT, Telia et Tata. Entre 10 h 03 et 10 h 11 UTC, il a désactivé CenturyLink dans 48 villes où les réseaux étaient connectés. Le déplacement n'a pas été instantané partout car la capacité alternative devait être prise en compte. Déplacer trop de trafic trop rapidement peut surcharger un fournisseur de secours et transformer la défaillance d'un opérateur en un problème en cascade. [2]

Le RFO diffusé indique que le centre d'opérations réseau IP de CenturyLink a mobilisé des ressources techniques et d'assurance de service supplémentaires tandis que les alarmes s'accumulaient. Les premières actions n'ont pas isolé la cause. Vers 14 h 00 UTC, l'ingénierie des opérations a identifié une annonce FlowSpec devenue problématique qui empêchait l'établissement correct de BGP. À 14 h 14, le NOC a déployé un changement de configuration global pour bloquer l'annonce. Au fur et à mesure que ce changement se propageait, les sessions BGP se sont rétablies et les alarmes se sont effacées. L'opérateur a signalé la stabilité à 15 h 10. [1]

Le SANS Internet Storm Center a capturé le langage contemporain de CenturyLink indiquant qu'un problème de routage empêchait l'établissement des sessions BGP et qu'un ajustement de configuration de haut niveau permettait aux sessions de se rétablir. Il a également averti que certains clients pourraient avoir besoin de réinitialiser l'équipement local ou les sessions BGP après la réparation côté opérateur. Les archives de la liste de diffusion Outages préservent les rapports d'opérateurs qui pouvaient voir l'adjacence BGP ou les annonces de route tandis que le trafic utilisable restait altéré.

Ces observations sont importantes car un statut de plan de contrôle peut sembler partiellement actif alors que la joignabilité de bout en bout ne l'est pas. [6][8]

ThousandEyes a généralement décrit l'incident comme ayant duré près de cinq heures. Des recherches ultérieures utilisant l'analyse de la topologie et des services placent l'événement entre 10 h 04 et 15 h 30 UTC, selon la mesure et le seuil de rétablissement. La bonne approche n'est pas de forcer chaque source dans une durée exacte. Les utilisateurs externes, les pairs, les collecteurs du plan de contrôle et les propres alarmes de l'opérateur ont mesuré différentes couches.

Un réseau peut être stable en interne avant que chaque chemin client ne reconverge, et certains points d'extrémité peuvent se rétablir avant que l'opérateur ne déclare l'incident clos. [3][9][10]

Cette chronologie expose trois lacunes d'assurance.

La première est le temps entre la détection et le diagnostic. Le réseau a généré suffisamment d'alarmes pour exiger des ressources supplémentaires, mais la cause n'a été identifiée qu'environ quatre heures après les premières erreurs externes. La question pertinente est de savoir si les opérateurs disposaient d'une représentation sûre et consultable de toutes les règles FlowSpec actives, de leur origine, de leur correspondance effective, de leur portée de distribution et du trafic de contrôle dépendant.

La deuxième est le diagnostic sous un plan de contrôle altéré. Si la règle a perturbé les sessions BGP ou la joignabilité de la gestion, les outils normaux ont pu devenir peu fiables précisément au moment où les intervenants en avaient besoin. Une architecture capable de distribuer une politique globalement a besoin d'un chemin de suppression qui ne dépend pas du chemin altéré.

La troisième est la preuve de restauration. Le blocage de l'annonce problématique a permis à BGP de s'établir, mais le rétablissement du service dépendait également de la reconvergence des routes, du comportement des pairs et de l'équipement client. Un opérateur devrait distinguer « la mauvaise règle est bloquée », « les sessions BGP sont stables », « les routes ont convergé », « le trafic circule » et « les services clients sont normaux ». Chaque état nécessite une mesure différente.

Ce que FlowSpec a changé dans le rayon d'impact

BGP est le protocole utilisé par les systèmes autonomes pour échanger des informations de joignabilité. Un locuteur BGP apprend des routes, applique des politiques et annonce des chemins sélectionnés à ses pairs. FlowSpec étend ce modèle de distribution aux filtres de trafic. Une route FlowSpec peut décrire le trafic à l'aide de champs tels que le préfixe source ou destination, le protocole, les ports, la longueur de paquet ou les drapeaux TCP, et peut associer des actions telles que le rejet ou la limitation du débit des paquets correspondants. [13][14][15][16]

L'avantage opérationnel est évident. Lors d'un événement DDoS, un fournisseur peut distribuer rapidement une atténuation sans modifier un filtre conventionnel sur chaque routeur périphérique. Le risque opérationnel est tout aussi structurel. Une règle trop large peut être appliquée par de nombreux dispositifs avant qu'une personne ne puisse se connecter à chacun d'eux. Si elle correspond au trafic nécessaire à BGP ou à la gestion du réseau, la politique peut endommager les moyens par lesquels elle a été distribuée ou supprimée.

L'analyse publique de Cloudflare a proposé une explication plausible du volume soutenu de mises à jour BGP. Un routeur pouvait établir BGP, recevoir une liste de politiques, atteindre la règle FlowSpec problématique, puis perdre la connectivité BGP. Une fois la session disparue, la règle dynamique pouvait ne plus persister; le routeur pouvait se reconnecter et répéter le cycle. Chaque cycle pouvait générer plus d'annonces et augmenter la charge. Cloudflare a explicitement présenté cela comme un scénario possible en attendant des preuves plus complètes de CenturyLink.

Il doit rester une hypothèse, pas une trace de paquets confirmée par l'opérateur. [2]

ThousandEyes a décrit une condition de boucle similaire dans son analyse après avoir reçu des informations élargies de l'opérateur. Il a rapporté une perte totale de paquets sur l'infrastructure CenturyLink géographiquement distribuée et une augmentation des annonces cohérente avec une perturbation BGP répétée. Parce que ThousandEyes a combiné des mesures directes, des documents d'opérateur et une interprétation, l'article devrait garder les couches de preuve visibles: la perte de paquets et le comportement des routes ont été observés; la séquence interne exacte dépend d'enregistrements que CenturyLink n'a pas publiés intégralement. [3]

La RFC 4271 explique pourquoi la stabilité des sessions est importante. BGP repose sur des relations de pairs persistantes et le traitement UPDATE pour maintenir l'état de routage. La RFC 7606 a ensuite amélioré le traitement des erreurs pour les messages UPDATE malformés, et la RFC 4724 définit des mécanismes de redémarrage progressif destinés à préserver le transfert pendant certains redémarrages du plan de contrôle. Ces documents fournissent un contexte utile, mais aucun n'est un bouclier générique contre une politique de trafic qui bloque la session elle-même.

Un réseau doit décider quel trafic est exempté, quelles politiques peuvent atteindre l'infrastructure de contrôle et comment une règle défaillante est supprimée. [16][18][19]

L'incident transforme donc le « rayon d'impact » d'une métaphore en une propriété d'ingénierie. Le rayon d'impact d'une politique est l'ensemble des dispositifs, classes de trafic, pairs et chemins de gestion qu'elle peut affecter avant détection et rollback. Les opérateurs peuvent réduire ce rayon grâce à des groupes de dispositifs, une autorisation de préfixe, des exclusions de protocole, des limites spécifiques aux clients, un déploiement progressif, des limites de temps et des contrôles de débit. Ils peuvent également préserver un plan de gestion indépendant qui ne peut pas être filtré par la même politique client.

Un backbone mondial devrait rendre cette propriété explicite. Une demande de changement devrait montrer non seulement l'adresse prévue, mais la correspondance normalisée après compilation, le nombre et la classe des dispositifs qui l'accepteront, les protocoles qu'elle pourrait toucher, les clients et pairs dans le champ d'application, l'expiration automatique et la voie de rollback. Plus la portée effective est grande, plus l'approbation et les preuves de test requises sont fortes.

Deux vérifications échouées peuvent toujours reposer sur une seule hypothèse erronée

Le RFO diffusé indique que l'interface utilisateur était conçue pour rejeter les entrées de caractères génériques, les entrées vides et les entrées non-adresse. Il indique également qu'un filtre secondaire était destiné à empêcher le blocage de plusieurs adresses de cette manière. Pourtant, la commande avec caractère générique a passé les deux. Le filtre secondaire recherchait des préfixes de destination, et la représentation avec caractère générique a fait qu'il interprétait la commande comme une seule adresse plutôt que plusieurs. [1]

Il s'agit d'un exemple d'indépendance nominale sans indépendance sémantique. Deux contrôles peuvent être implémentés dans des composants différents et reposer néanmoins sur la même hypothèse sur la manière dont un objet est représenté. Le premier contrôle peut valider l'entrée utilisateur avant traduction. Le second peut valider la forme traduite mais utiliser un analyseur qui partage le même angle mort. Si les deux traitent un caractère générique comme un objet valide unique, compter deux contrôles surestime la protection.

Une conception plus solide comparerait des représentations indépendantes.

Un contrôle pourrait valider l'adresse brute demandée par rapport aux préfixes autorisés du client. Un autre pourrait compiler la règle et calculer l'ensemble de paquets qu'elle correspond. Un troisième pourrait rejeter tout résultat qui inclut le port TCP BGP 179, les adresses de réflecteur de route, les préfixes de gestion ou l'infrastructure en dehors de l'allocation du client. Un quatrième pourrait comparer la correspondance effective à la demande lisible originale et exiger une approbation si la portée s'étend.

Un cinquième pourrait installer la règle sur un dispositif canari et observer la santé du plan de contrôle avant une distribution plus large.

Le terme « filtre secondaire » devrait donc inviter à une question: secondaire dans l'emplacement, ou indépendant dans la logique? Une défense efficace n'est pas simplement une autre instruction conditionnelle. Elle devrait échouer différemment, utiliser une source de vérité différente ou valider une propriété différente. L'autorisation de préfixe, la cardinalité de l'ensemble, l'exclusion de protocole et la portée effective simulée sont des propriétés distinctes. Les combiner rend moins probable qu'une erreur d'analyse partagée ne contourne toutes les sauvegardes.

Le comportement de fermeture par défaut est également important. Si une règle ne peut pas être normalisée sans ambiguïté, la réponse sûre est le rejet, pas une interprétation large. Si la portée prévue et la portée effective diffèrent, la distribution devrait s'arrêter. Si la politique touche le trafic du plan de contrôle, un processus d'exception à haute autorité devrait être requis. Si le service de validation est indisponible, le système ne devrait pas supposer que l'urgence autorise un contournement.

L'urgence est une condition prévisible dans l'atténuation DDoS. Cela en fait une partie de la conception, pas une raison de suspendre la conception. Les opérateurs ont besoin d'un chemin rapide parce qu'il est pré-validé et limité, pas rapide parce qu'il saute l'examen indépendant. Les demandes des clients peuvent être mappées à des préfixes pré-autorisés et à des modèles d'action. Les règles peuvent expirer automatiquement. Les dérogations d'urgence peuvent être enregistrées et limitées à un petit ensemble canari avant une publication plus large.

Le dossier public indique que CenturyLink a désactivé entièrement la plateforme FlowSpec en attendant des tests et a modifié le filtre pour interdire les caractères génériques. Ces actions traitent du déclencheur rapporté. Elles ne montrent pas en elles-mêmes si les deux contrôles sont devenus sémantiquement indépendants, si la portée est calculée après compilation, ou si le trafic du plan de contrôle est protégé. Ce sont les questions de preuve qui distinguent une action corrective d'une non-récurrence démontrée. [1][20]

Un opérateur fortement connecté crée une dépendance systémique

CenturyLink avait acquis Level 3, et AS3356 restait l'un des réseaux de transit les plus connectés du système de routage Internet. Les relations commerciales et techniques exactes variaient, mais le résultat pratique était que de nombreux réseaux atteignaient des destinations via des chemins contenant AS3356, même si aucun point d'extrémité ne se considérait comme un client de détail de CenturyLink. RIPEstat et les archives de routage publiques fournissent un contexte pour ce rôle réseau. [11][12]

Ceci est important car la responsabilité d'un backbone n'est pas limitée par les factures directes. Un client d'un autre fournisseur peut toujours dépendre d'une relation de transit à plusieurs sauts. Un service cloud peut déplacer son propre chemin sortant mais rester incapable d'atteindre une origine qui est mono-hébergée derrière l'opérateur défaillant. Un pair peut dé-préférer CenturyLink tandis que des réseaux distants continuent de sélectionner des chemins obsolètes ou plus attractifs via celui-ci.

Le devoir effectif de l'opérateur suit les dépendances que son réseau crée, pas seulement l'ensemble des utilisateurs qui peuvent ouvrir un ticket de support.

L'atténuation de Cloudflare illustre à la fois la puissance et les limites de la diversité. Il avait des connexions à plusieurs grands réseaux et a pu désactiver CenturyLink rapidement dans 48 villes. Cette action a considérablement réduit le pic d'erreurs. Pourtant, certains clients de Cloudflare restaient injoignables parce que leurs serveurs d'origine n'avaient pas de chemin utilisable évitant CenturyLink ou parce que l'opérateur continuait d'annoncer des routes qui attiraient le trafic dans un chemin cassé. [2]

ThousandEyes a comparé des clients dont les résultats différaient. OpenTable a subi une perte de paquets élevée pendant une grande partie de l'incident. GoToMeeting a activé GTT comme fournisseur de secours et a amélioré la joignabilité, même si Level 3 continuait d'annoncer ses préfixes. Les routes n'étaient pas nécessairement plus spécifiques; la préférence dépendait de la vue des réseaux distants et de la densité du peering alternatif. L'exemple n'est pas une règle universelle selon laquelle deux fournisseurs garantissent la continuité.

Il montre que les liens physiques, la politique BGP, l'état d'annonce et la capacité doivent tous s'aligner. [3]

L'expression « multihébergé » peut donc cacher plusieurs modes courants.

Deux circuits peuvent entrer dans le même bâtiment par le même conduit. Deux fournisseurs peuvent acheter du transit amont auprès du même backbone. Deux chemins annoncés peuvent être visibles tandis qu'un chemin obsolète reste préféré. Un fournisseur de secours peut manquer de capacité pour un déplacement mondial soudain. Les deux liens peuvent dépendre du même DNS, serveur de routes, portail de gestion ou routeur client. L'organisation peut également manquer d'une personne autorisée capable de modifier la politique pendant un incident.

La bonne preuve d'assurance est de bout en bout. Un client devrait connaître le chemin du système autonome dans des conditions normales et défaillantes, la route physique le cas échéant, le comportement de préférence locale et MED, les préfixes que chaque fournisseur annonce, les contrôles de retrait ou de communauté disponibles, la capacité testée et le déclencheur de basculement. La surveillance devrait venir de l'extérieur des deux fournisseurs afin de pouvoir détecter une route visible mais qui ne transporte pas de paquets.

Les clients et les pairs ont la responsabilité de ces contrôles, mais leur responsabilité n'efface pas celle de l'opérateur. Un client peut concevoir une meilleure diversité; il ne peut pas empêcher la plateforme FlowSpec interne de CenturyLink d'altérer BGP sur de nombreux éléments. La dépendance partagée crée une responsabilité en couches, pas une responsabilité égale.

La protection du plan de contrôle doit survivre à la politique qu'elle distribue

Tout système d'automatisation à l'échelle du réseau a besoin d'un chemin protégé pour l'observation et l'inversion. Dans cet incident, le mécanisme de distribution des politiques et le comportement des sessions BGP sont devenus entrelacés. Cela devrait amener les opérateurs à se demander si le réseau peut rester gouvernable lorsqu'une politique est erronée.

La première protection est le champ d'application. Les règles FlowSpec déclenchées par un client ne devraient être autorisées que pour les préfixes du client, les classes de trafic attendues et les actions approuvées. Elles ne devraient pas correspondre aux adresses d'infrastructure ou aux protocoles de contrôle à moins qu'un flux de travail séparé et explicite ne le permette. La validation devrait utiliser la règle compilée, pas seulement l'entrée demandée.

La deuxième protection est le déploiement progressif. Une règle peut être envoyée d'abord à une représentation en laboratoire, puis à un canari périphérique, puis à une région limitée, puis à un groupe de dispositifs plus large. Le système devrait surveiller le nombre de sessions BGP, la charge du réflecteur de route, la joignabilité de la gestion, la perte de paquets et les résultats des clients à chaque étape. Une atténuation conçue pour des secondes ne peut pas attendre des heures à chaque étape, mais elle peut utiliser des seuils automatisés et un rollback immédiat.

La troisième protection est un chemin de contrôle hors bande. Les opérateurs ont besoin d'un accès de gestion qui ne repose pas sur le même transit, les mêmes sessions de routage ou le même domaine de filtrage que le trafic client ordinaire. Les archives de configuration et les outils de rollback doivent rester joignables. Un blocage d'urgence global devrait être possible via un canal dont les propres paquets ne peuvent pas être capturés par la règle dangereuse.

La quatrième protection est une durée de vie limitée. Une atténuation peut expirer sauf si elle est renouvelée après un examen des preuves. L'expiration automatique limite la persistance des règles abandonnées ou mal comprises. Elle ne remplace pas le rollback, car une règle catastrophique de cinq minutes est toujours inacceptable, mais elle réduit l'exposition à long terme et oblige la propriété à rester explicite.

La cinquième protection est la visibilité de l'état. Les intervenants devraient pouvoir lister chaque règle FlowSpec active, son origine, demandeur, autorisation, correspondance normalisée, action, ensemble de distribution, état d'installation, âge et statut de rollback. Ils devraient également voir quels dispositifs l'ont rejetée et pourquoi. Sans cet inventaire, le diagnostic devient une recherche sur un réseau qui produit déjà un nombre extraordinaire d'alarmes et de mises à jour.

La sixième protection est une politique d'infrastructure protégée. Les réflecteurs de route, les locuteurs BGP, le DNS, la synchronisation temporelle, l'authentification, la journalisation et les systèmes de gestion ne sont pas des destinations client ordinaires. Le réseau devrait définir si une règle client peut jamais les affecter et, le cas échéant, par quels contrôles exceptionnels. La protection doit couvrir à la fois le transfert de paquets et les systèmes utilisés pour calculer et distribuer la politique.

La RFC 7454 fournit des directives de sécurité opérationnelle pour BGP, tandis que les RFC 7606 et 4724 traitent des aspects de la gestion des erreurs et du redémarrage. La présentation NANOG dans l'ensemble de sources discute des modes de défaillance de FlowSpec et des leçons de mise en œuvre. Ces sources aident à définir les questions et les contrôles. Elles ne peuvent pas certifier l'architecture actuelle de CenturyLink. La certification nécessiterait des preuves actuelles et spécifiques à l'opérateur. [17][18][19][20]

Le contrôle des changements devrait mesurer l'autorité réseau effective

Les formulaires de changement traditionnels classent souvent le travail par nombre de dispositifs, fenêtre de maintenance ou propriétaire de service. FlowSpec suggère une autre dimension: l'autorité effective. Une demande qui peut correspondre à n'importe quel paquet sur des centaines de routeurs périphériques a plus d'autorité qu'un changement textuel plus large confiné à un système de test.

Un enregistrement de changement basé sur l'autorité contiendrait au moins cinq vues.

Lavue d'intentionénonce la demande du client et l'objectif commercial en langage ordinaire. Dans ce cas, l'intention déclarée était de bloquer le trafic d'une adresse pour un client. [1]

Lavue compiléemontre les composants et actions FlowSpec exacts normalisés que les dispositifs recevront. C'est là que l'expansion des caractères génériques, les champs manquants et les différences d'analyse deviennent visibles.

Lavue de portéeidentifie les dispositifs, régions, pairs, préfixes et classes de trafic qui peuvent être affectés. Elle devrait calculer la portée la plus défavorable plutôt que de supposer que la règle fonctionne comme prévu.

Lavue de sécuritéliste le trafic de contrôle protégé, les limites d'autorisation, les étapes canari, les conditions de rollback, l'expiration et les validateurs indépendants.

Lavue de preuveenregistre qui a approuvé la portée effective, quels tests ont été exécutés, quel dispositif a accepté la politique en premier, quelles télémesures ont changé et quand la règle a été supprimée.

Cette approche fait passer la revue de « La syntaxe est-elle valide? » à « Quelle autorité le réseau exercera-t-il si chaque composant se comporte exactement comme encodé? » Elle rend également l'automatisation vérifiable. Une machine peut approuver une règle de routine si la portée effective reste dans une enveloppe pré-autorisée. Un humain peut être requis lorsque la portée compilée la dépasse. Aucun des deux chemins ne devrait accepter l'ambiguïté.

La revue par les pairs devrait se concentrer sur la différence. Un relecteur doit voir en quoi la règle effective proposée diffère d'un modèle connu sûr, pas analyser une configuration entière sous pression temporelle. Le système peut mettre en évidence des ensembles de préfixes étendus, des protocoles ajoutés, des groupes de distribution plus larges et l'absence d'expiration. Le relecteur devrait avoir un pouvoir d'arrêt qui n'est pas affaibli par l'urgence d'un incident ou l'importance d'un client.

Le rollback doit être testé contre la perte du plan de contrôle ordinaire. Il ne suffit pas de stocker la règle précédente si le réseau ne peut pas recevoir la commande de suppression. Une conception sûre peut pré-positionner un coupe-circut, maintenir un canal de gestion séparé ou limiter la règle initiale à un domaine que les intervenants peuvent isoler physiquement ou logiquement.

L'incident montre également pourquoi les fenêtres de maintenance sont une protection incomplète. La panne a commencé un dimanche matin en Amérique du Nord, une période qui pourrait sembler à moindre risque. Un backbone de niveau 1 a des clients dans tous les fuseaux horaires et transporte des services qui n'ont pas d'heure creuse. Plus important encore, une défaillance du plan de contrôle peut altérer les équipes et les portails nécessaires à la réponse. Le rayon d'impact et la réversibilité comptent plus que l'horloge.

L'observabilité doit lier l'état BGP à la joignabilité de service

Lors d'un incident de routage, les opérateurs peuvent se noyer dans des signaux techniquement précis mais opérationnellement incomplets. Une session BGP peut être établie tandis que des paquets sont rejetés. Un préfixe peut rester annoncé tandis que le chemin est inutilisable. Un routeur peut être joignable via la gestion tandis que le trafic client échoue. Un collecteur de routes global peut montrer des mises à jour sans révéler chaque résultat de transfert.

Cloudflare a combiné les erreurs d'origine, le trafic par fournisseur et les données de mise à jour BGP. ThousandEyes a combiné la visualisation de chemin, la perte de paquets et le comportement des annonces. NetForecast a utilisé un réseau de référence pour mesurer l'expérience utilisateur. La liste Outages a ajouté des rapports d'opérateurs voyant des symptômes à leurs propres extrémités. Chaque source a observé un plan différent. Ensemble, elles produisent une image d'incident plus solide qu'un seul tableau de bord. [2][3][7][8][11]

Un opérateur backbone devrait intégrer au moins quatre couches de preuve.

Lacouche de configurationenregistre la politique prévue et effective, l'état de distribution et l'acceptation par les dispositifs.

Lacouche du plan de contrôleenregistre les sessions BGP, la santé du réflecteur de route, le volume UPDATE, le churn des routes et la convergence.

Lacouche de transfertenregistre la perte de paquets, la latence, les prochains sauts et si le trafic atteint le client pair ou le périmètre prévu.

Lacouche de serviceenregistre si les clients peuvent effectuer des transactions réelles, joindre le support et utiliser des applications critiques.

La corrélation des alarmes devrait relier ces couches par le temps et la dépendance. Si une nouvelle politique FlowSpec est suivie d'une perte de session BGP et de pics de perte de paquets sur le même ensemble de dispositifs, le système devrait présenter ce candidat causal immédiatement. Si le portail client devient injoignable via le même backbone, le commandement de l'incident devrait passer à un canal de support indépendant plutôt que d'attendre les outils ordinaires.

La mesure externe est particulièrement importante pour un réseau qui peut continuer à annoncer des chemins obsolètes ou inutilisables. La télémétrie interne peut dire qu'un circuit est actif ou qu'une route est présente. Les sondes externes révèlent si les réseaux distants sélectionnent le chemin et si les paquets reviennent. Un opérateur peut exploiter ses propres points de vue externes et également préserver des preuves tierces.

L'objectif n'est pas de collecter toutes les métriques possibles. Il est de répondre rapidement à des questions limitées: Qu'est-ce qui a changé? Quels dispositifs l'ont reçu? Quelles sessions ont échoué? Quels préfixes sont restés annoncés? Où les paquets sont-ils rejetés? Quels chemins alternatifs ont de la capacité? Les intervenants peuvent-ils encore atteindre la surface de contrôle? Quelles preuves montrent que le correctif a atteint chaque domaine affecté?

Le support et la communication font partie de la capacité de récupération

Le RFO diffusé indique que de nombreux clients affectés n'ont pas pu ouvrir de tickets de support parce que le volume d'appels était extrême et que le portail client CenturyLink était également affecté. Ce détail est opérationnellement significatif. Un fournisseur peut avoir des ingénieurs qui réparent le noyau tandis que les clients manquent d'un chemin utilisable pour signaler les symptômes, recevoir des instructions ou distinguer une défaillance du fournisseur de leur propre défaut local. [1]

La capacité de support est donc un contrôle de résilience réseau. Le portail ne devrait pas partager toutes les mêmes dépendances de routage que le service qu'il supporte. Les pages de statut et les canaux de notification devraient être joignables via une infrastructure indépendante. Les grands clients et les pairs ont besoin de contacts préétablis et de mises à jour lisibles par machine qui ne dépendent pas d'une file d'attente générale surchargée.

La communication façonne également la récupération technique. Un client peut avoir besoin de réinitialiser une session BGP, de retirer une route, de modifier la préférence locale ou d'activer une capacité alternative. Ces actions comportent des risques. Les conseils devraient identifier qui doit agir, quelles preuves devraient déclencher l'action, quels effets secondaires sont attendus et comment l'inverser. Des instructions larges telles que « redémarrer l'équipement » peuvent détruire un état utile ou créer plus de churn si elles sont émises sans champ d'application.

Les déclarations publiques de CenturyLink pendant l'événement ont identifié une panne IP puis un problème de routage. Les analystes externes ont fourni plus de détails à mesure que les mesures s'accumulaient. Le dossier post-incident a fourni une cause plus profonde et des actions correctives. Cette progression est normale, mais chaque mise à jour devrait étiqueter la confiance et la source. La communication d'incident peut dire qu'une annonce FlowSpec est la cause principale sans prétendre que la chaîne de défaillance complète est connue.

Les clients ont également besoin d'une déclaration de clôture qui sépare la stabilité de l'opérateur de la normalisation complète du chemin. L'opérateur peut signaler quand la mauvaise règle est bloquée et les sessions sont stables. Il devrait également signaler si la convergence des routes se poursuit, si certains pairs ont besoin d'une action locale, si le portail est rétabli et quand l'analyse formelle des causes de panne sera disponible.

La réclamation de réparation nécessite un test reproductible

Le RFO diffusé indique que CenturyLink a désactivé entièrement la plateforme FlowSpec en attendant des tests approfondis et utiliserait d'autres outils d'atténuation entre-temps. Il indique que le filtre secondaire était modifié pour interdire les entrées de caractères génériques et que la plateforme modifiée reviendrait lors d'une maintenance planifiée non affectant le service après test. [1]

Ces étapes sont rationnelles. Désactiver le chemin élimine l'exposition immédiate. Reproduire le problème en laboratoire établit que l'équipe peut déclencher et observer la défaillance. Modifier le filtre traite du contournement rapporté. La question de responsabilité restante est de savoir si le système réparé a été testé comme un contrôle intégré, pas seulement si un analyseur a rejeté un caractère générique.

Un scénario de vérification solide commencerait par une demande à portée client et exercerait délibérément plusieurs représentations mal formées: caractères génériques explicites, champs vides, préfixes larges, encodages alternatifs, valeurs limites de l'analyseur et règles qui correspondent au trafic de contrôle. L'interface devrait rejeter les entrées dangereuses. Le validateur de politique compilée devrait calculer indépendamment la portée effective. L'autorisation de préfixe devrait rejeter les ressources en dehors de l'allocation du client. Les vérifications de protocole protégé devraient bloquer les correspondances BGP et de gestion.

Un canari ne devrait recevoir qu'une règle ayant passé toutes les barrières.

Le test devrait ensuite introduire une défaillance. Un validateur devrait devenir indisponible. Un canari devrait perdre une session BGP. Un réflecteur de route devrait montrer un churn inhabituel. Le chemin de gestion utilisé pour le rollback devrait rester joignable. L'automatisation devrait arrêter la propagation et supprimer la règle sans recourir au plan client altéré. Les opérateurs devraient pouvoir identifier la demande, l'objet compilé, les dispositifs installés et l'état de rollback à partir d'un seul enregistrement de preuve.

La dernière étape devrait tester l'échelle. Une règle devrait être distribuée à un ensemble contrôlé mais représentatif de dispositifs tandis que des sondes indépendantes surveillent les résultats du plan de contrôle et du transfert. L'équipe devrait prouver que le rollback atteint tous les dispositifs et qu'aucune politique obsolète ne peut rester cachée. Le test devrait enregistrer le timing, les seuils, les échecs et les résultats de re-test.

La vérification indépendante n'exige pas de publier une configuration exploitable. Un évaluateur peut confirmer que le test a couvert le chemin de caractère générique rapporté, le calcul de portée indépendant, le trafic protégé, le canari, le rollback sous BGP altéré et l'accès hors bande. La déclaration publique peut divulguer les scénarios, les critères de réussite, la date et le risque résiduel tout en gardant les adresses et la topologie confidentielles.

La distinction entre achèvement et efficacité est essentielle. « Filtre modifié » est une déclaration d'achèvement. « Les contrôles modifiés ont rejeté chaque représentation de la défaillance et limité le rayon d'impact lors de tests supervisés » est une affirmation d'efficacité. La responsabilité exige cette dernière avant qu'une plateforme à haute autorité ne revienne à un usage de routine.

Matrice de responsabilité

Étape	Propriétaire du contrôle principal	Contrôle requis	Preuve qui devrait exister	Limite publique
Demande client	Opérations produits CenturyLink	Lier l'atténuation aux ressources client autorisées et au trafic prévu	Enregistrement de la demande, autorisation de préfixe, intention normalisée	Le client spécifique et l'adresse demandée ne sont pas publics
Saisie	Propriétaires des outils CenturyLink	Rejeter les valeurs génériques, vides, ambiguës et hors champ	Tests de schéma, cas négatifs, enregistrement de version de l'analyseur	L'interface exacte et l'analyseur ne sont pas publics
Compilation	Plateforme politique CenturyLink	Calculer la correspondance de paquets effective et la comparer à l'intention	Règle compilée, diff sémantique, vérifications de cardinalité et de protocole	La commande malformée exacte n'est pas publique
Validation indépendante	Architecture/sécurité CenturyLink	Détecter une portée large via un chemin logique indépendant	Conception du validateur séparé, résultats d'injection de défaillance	Les preuves publiques ne prouvent pas l'indépendance sémantique
Autorisation	Propriétaire du changement CenturyLink	Escalader les règles à haute autorité ou affectant le plan de contrôle	Enregistrement d'approbation, affichage de la portée, pouvoir d'arrêt	La propriété individuelle des décisions n'est pas publique
Déploiement progressif	Opérations réseau CenturyLink	Canari et distribution limitée avant déploiement global	Plan de groupe de dispositifs, seuils de santé, arrêt automatique	La topologie de distribution de 2020 n'est pas publique
Protection du plan de contrôle	Architecture de routage CenturyLink	Exempter ou gérer séparément BGP, réflecteurs de route et gestion	Politique de préfixe/protocole protégé, test d'isolement	L'adressage privé et la topologie doivent rester confidentiels
Détection	NOC CenturyLink	Corréler le déploiement de politique, le churn BGP, la perte de paquets et l'impact sur le service	Chronologie, inventaire des règles actives, corrélation des alarmes	Le flux d'alarmes complet n'est pas public
Rollback	NOC et ingénierie CenturyLink	Supprimer la politique dangereuse via un chemin indépendant	Coupe-circut, test d'accès hors bande, confirmation des dispositifs	L'accès de récupération détaillé est sensible à la sécurité
Peering	CenturyLink et les pairs	Coordonner la déconnexion, les retraits et les preuves de convergence	Chronologie des pairs, état des routes, restauration du trafic	Les enregistrements bilatéraux complets sont privés
Continuité client	Clients et fournisseurs gérés	Maintenir des chemins alternatifs indépendants de la politique et de la capacité	Tests de chemin AS, diversité physique, exercices de basculement	Les conceptions et pertes des clients varient
Communication	Assurance de service CenturyLink	Garder le statut, la ticketing et les contacts critiques joignables	Chemin de statut indépendant, journal des mises à jour, tests de contact	Le paquet public n'a que des preuves de support partielles
Vérification	CenturyLink et évaluateur indépendant	Reproduire la défaillance et prouver une non-récurrence limitée	Plan de test, résultat supervisé, déclaration de risque résiduel	Les preuves de test indépendant à long terme ne sont pas publiques ici

La matrice empêche la responsabilité de se réduire à l'expression « panne Internet ». CenturyLink contrôlait le système de politique et le backbone interne. Les pairs contrôlaient leurs interconnexions. Les clients contrôlaient leur propre politique de bordure et leur diversité. Les organisations de mesure contrôlaient la collecte de preuves. Ces responsabilités ont interagi, mais seul l'opérateur pouvait reconcevoir le chemin interne qui a transformé une demande étroite en une défaillance généralisée.

Elle empêche également une erreur différente: supposer qu'un grand fournisseur est responsable de chaque conséquence client. Un client mono-hébergé accepte une posture de continuité différente d'un client avec un multihébergement testé. Un pair qui maintient une préférence obsolète peut prolonger un chemin. Un service cloud qui manque de connectivité d'origine alternative peut rester injoignable après le rétablissement d'autres chemins. La responsabilité devrait suivre le contrôle pratique sur chaque couche, sans s'étendre sans limite.

Ce que le dossier public ne peut pas prouver

L'ensemble de sources est suffisamment solide pour établir l'incident, son mécanique réseau à un niveau élevé, l'impact large et les principales questions de contrôle. Il ne s'agit pas d'un enregistrement médico-légal complet.

Le RFO original de CenturyLink est présent ici comme une reproduction hébergée par un client des notes du fournisseur plutôt qu'une publication stable de l'opérateur. De multiples sources contemporaines et ultérieures répètent ses principales conclusions, ce qui augmente la confiance, mais l'attribution reste nécessaire. Un futur enregistrement hébergé par l'opérateur ou déposé auprès du régulateur pourrait remplacer le libellé de ce paquet.

L'explication de la boucle BGP par Cloudflare est techniquement plausible et cohérente avec les mises à jour observées, mais il ne s'agit pas d'une capture de paquets divulguée par CenturyLink. L'article ne doit pas dire que chaque routeur a répété exactement cette boucle. ThousandEyes fournit des observations et une interprétation supplémentaires, mais il lui manque également la télémétrie privée complète de l'opérateur.

RouteViews enregistre les mises à jour visibles par les collecteurs, pas chaque état de réflecteur de route interne ou décision de transfert. RIPEstat fournit un contexte AS et de routage, pas un verdict de cause racine. APNIC et la recherche CNSM appliquent des méthodes de mesure après l'incident; ils n'assignent pas la propriété de décision privée. Les RFC définissent le comportement du protocole et les bonnes pratiques; elles ne certifient pas la conformité d'un opérateur nommé.

Aucune source de ce paquet ne prouve la négligence, l'intention ou le résultat disciplinaire d'un individu. Aucune source ne prouve la perte financière précise pour chaque client. Aucune source n'établit qu'un acteur hostile a compromis CenturyLink. Aucune source ne vérifie indépendamment chaque remédiation au fil des années.

Ces lacunes doivent rester visibles car elles identifient qui détient les preuves manquantes. CenturyLink peut fournir la lignée de configuration, la conception de validation, la reproduction en laboratoire, la politique de déploiement et les résultats de test. Les pairs peuvent fournir des enregistrements de routes et de déconnexion bilatéraux. Les clients peuvent fournir des preuves de panne et de basculement. Des évaluateurs indépendants peuvent vérifier la remédiation sans divulguer la topologie sensible.

Un test réutilisable de responsabilité des politiques du backbone

L'incident CenturyLink fournit un test pratique pour tout opérateur qui peut distribuer des politiques de trafic à grande échelle.

Intention:La demande humaine est-elle limitée à une ressource autorisée et exprimée sans ambiguïté?

Compilation:Le système peut-il montrer la correspondance effective exacte après chaque analyseur, caractère générique et valeur par défaut?

Autorité:L'approbation augmente-t-elle avec le nombre de dispositifs, les classes de trafic et les systèmes de contrôle que la règle peut affecter?

Indépendance:Les contrôles secondaires valident-ils une propriété différente ou utilisent-ils une source de vérité différente?

Chemins protégés:Une politique client peut-elle toucher BGP, les réflecteurs de route, la gestion, l'authentification, le DNS, la journalisation ou les systèmes temporels?

Déploiement progressif:La règle peut-elle être canariée et arrêtée automatiquement lorsque la santé du plan de contrôle ou du service change?

Rollback:Les intervenants peuvent-ils la supprimer sans dépendre du plan altéré?

Visibilité:Le commandement de l'incident peut-il voir chaque règle installée, l'état du dispositif, l'effet de session et le résultat client?

Dépendance:Les pairs et les clients ont-ils testé si les chemins alternatifs sont indépendants de la politique et correctement dimensionnés?

Preuve:La défaillance réelle rapportée a-t-elle été reproduite et les contrôles réparés supervisés dans des conditions réalistes?

Un opérateur qui ne peut pas répondre à ces questions ne devrait pas traiter une capacité de distribution de politique globale comme une automatisation de routine. L'absence d'incident récent n'est pas une preuve que la frontière sémantique est sûre.

Conclusion

La panne de CenturyLink en 2020 n'était pas importante parce que FlowSpec est exotique. Elle était importante parce qu'une intention opérationnelle étroite a acquis une autorité à l'échelle du backbone.

Les preuves publiques montrent une annonce FlowSpec problématique, des échecs d'établissement BGP, une perte de joignabilité généralisée et une action de configuration globale qui a restauré la stabilité. Elles montrent également que les réseaux externes ont vécu la défaillance différemment selon le peering, la préférence de chemin, les annonces obsolètes et la capacité alternative. Ce que les preuves ne montrent pas est tout aussi important: la commande exacte, la topologie interne complète, la chaîne de décision individuelle et la preuve indépendante à long terme de la réparation.

La responsabilité suit ces frontières. CenturyLink contrôlait la plateforme qui traduisait, validait et distribuait la politique. Il contrôlait si le plan de contrôle de routage et le chemin de récupération étaient protégés de cette politique. Les clients et les pairs contrôlaient certaines parties de leur propre continuité, mais ils ne pouvaient pas réparer le mécanisme interne d'AS3356. Les organisations de normalisation et de mesure ont fourni le protocole et l'observation, pas l'autorité opérationnelle.

Le standard de réparation est donc concret. Un système de politique à fort rayon d'impact doit prouver que la portée effective correspond à l'intention, que des contrôles indépendants rejettent l'expansion sémantique, que le trafic de contrôle reste protégé, que le déploiement est limité, que le rollback survit à l'altération du plan de contrôle et que la joignabilité externe confirme le rétablissement. Sans cette preuve, « backbone redondant » décrit la topologie tout en laissant l'autorité concentrée sur un chemin fragile.

La leçon durable n'est pas de ralentir chaque atténuation. Elle est de rendre la vitesse sûre en contraignant l'autorité avant que l'urgence n'arrive. Un blocage client doit rester un blocage client. Lorsqu'il peut devenir un événement de routage mondial, le réseau n'a pas simplement subi une erreur de configuration. Il a exposé une conception de responsabilité qui doit être reconstruite et prouvée.

La panne FlowSpec de CenturyLink en 2020 a fait du contrôle des changements du backbone un test de responsabilité Internet