BGP de Level 3 en 2017: responsabilité du backbone

Résumé

Frontière d'événement figée:Le 6 novembre 2017, la surveillance indépendante a lié une perturbation majeure de la connectivité de Comcast à des changements de routage associés à Level 3 et à AS3356. ThousandEyes a placé son impact principal sur Comcast approximativement entre 09 h 45 et 11 h 25 heure du Pacifique, avec des incohérences de routage visibles à partir d'environ 09 h 30. [2] Les reportages contemporains ont relayé la déclaration de Level 3 selon laquelle un problème de configuration avait causé la perturbation. [1][5][6] Cet article ne fusionne pas cet événement avec la panne distincte de Level 3 en 2016, la panne de CenturyLink/ Lumen de décembre 2018 touchant le service 911, ou l'incident FlowSpec d'AS3356 d'août 2020.
Mécanisme observé:ThousandEyes a signalé des annonces plus spécifiques pour plus d'un millier de préfixes de filiales et clients Comcast et a observé du trafic qui avait transité auparavant par le backbone AS7922 de Comcast et qui était dirigé via AS3356 de Level 3, avec une hausse de la perte de paquets et de la latence. [2] C'est une preuve forte d'une défaillance de politique de routage et de ses conséquences de forwarding. Elle ne révèle toutefois pas la commande interne exacte, l'objet de politique de route généré, le processus de déploiement ou l'ensemble exact des utilisateurs affectés.
Frontière de responsabilité:Level 3 contrôlait la génération de configuration, l'approbation, la portée de déploiement, la politique d'export BGP, la surveillance de route, l'autorité de rollback et la communication incident. Les pairs et les réseaux en aval contrôlaient la politique d'import, les attentes de cône client, les limites de préfixes, la détection d'anomalies et les choix de failover. Comcast contrôlait la communication abonnés et certains segments du parcours de reprise côté utilisateur final. Les clients et utilisateurs finaux pouvaient observer la panne mais ne pouvaient pas réparer l'état de routage interdomaines.
Leçon de contrôle:Une configuration peut être syntaxiquement valide et violer quand même un invariant opérationnel. Le contrôle de changement du backbone doit tester la joignabilité prévue, la portée d'export, les changements de path et le rayon d'impact avant le déploiement, puis comparer l'état de route en direct et la joignabilité utilisateur réelle aux attentes. Batfish a utilisé l'événement pour plaider en faveur d'une validation réseau basée sur modèles plutôt que la confiance dans la revue manuelle seule. [3]
Couche de réalité:Les registres et enregistrements ASN aident à identifier les ressources et les opérateurs responsables, mais ils ne font pas respecter la politique BGP. Les collecteurs de route montrent ce que les réseaux en fonctionnement ont annoncé et accepté; les sondes de forwarding montrent si le trafic est arrivé à la destination prévue. La responsabilisation dépend de la jonction entre politique prévue, annonces en fonctionnement, chemins de paquets, enregistrements de rollback et restauration visible pour l'utilisateur.

L'incident doit rester borné au 6 novembre 2017

La première exigence d'une reconstruction accountable consiste à définir quel événement est examiné. Level 3 et l'organisation CenturyLink ou Lumen apparaissent dans plusieurs rapports de panne majeurs. Les combiner produirait un récit plus long mais des conclusions plus faibles, car les mécanismes, détenteurs de contrôle et preuves diffèrent.

Cet article concerne l'événement BGP observé le lundi 6 novembre 2017. ThousandEyes a rapporté que ses employés utilisant des connexions Comcast ont rencontré des défaillances sur des services tels que Slack, Gmail et Webex. Ses mesures ont placé l'impact principal sur Comcast d'environ 09 h 45 à 11 h 25 heure du Pacifique. Elle a aussi identifié des incohérences BGP dès environ 09 h 30, avant l'intervalle complet visible pour les utilisateurs décrit. [2]

Wired a rapporté qu'une erreur de configuration de Level 3 affectait des portions de l'accès internet américain et que le fournisseur a indiqué que le service avait été restauré après correction du problème. [1] D'autres reportages contemporains décrivaient de nombreuses plaintes touchant plusieurs fournisseurs d'accès et reprenaient une explication Level 3 centrée sur un problème de configuration. [5][6] Ces rapports établissent un signal d'impact public large, mais les cartes de réclamations et rapports simultanés ne prouvent pas que tous les réseaux ont échoué pour la même raison technique.

ThousandEyes fournit le pont public le plus solide entre état de route et expérience utilisateur. Son analyse décrivait des pertes de paquets dans les chemins Comcast et Level 3, des changements de route pour des destinations liées à Comcast et un retour à la normale après retrait par Level 3 des routes fuitées. [2] La revue annuelle de sécurité de routage d'APNIC a aussi identifié l'incident comme l'un des événements de routage à grande échelle marquants de 2017. [4]

Trois exclusions sont essentielles.

Premièrement, l'incident n'est pas la panne 2016 de Level 3. Cet événement distinct a ensuite fait l'objet d'un contrôle réglementaire et sectoriel et impliquait un mécanisme différent. [8] Deuxièmement, il ne s'agit pas de la panne de décembre 2018 de CenturyLink qui a perturbé le transport et le service 911. Troisièmement, il ne s'agit pas de l'incident FlowSpec d'août 2020 d'AS3356, où une action de filtrage de trafic propagée via un backbone a produit un schéma de panne différent.

L'historique d'opérateur commun peut orienter des questions de gouvernance comparative. Il ne peut pas substituer la preuve d'un événement à celle d'un autre. La conclusion 2017 doit reposer sur les observations de route de 2017, la déclaration du fournisseur et les preuves publiques contemporaines de chemin utilisateur.

AS3356 a fait d'un changement de configuration un événement inter-réseaux

Un système autonome est un réseau ou un groupe de réseaux présentant une politique de routage commune à l'internet. BGP permet aux systèmes autonomes d'échanger des informations de joignabilité, y compris les préfixes atteignables et la séquence des systèmes autonomes représentés dans un chemin. RFC 4271 définit la mécanique du protocole et le cadre décisionnel dans lequel les opérateurs appliquent leurs politiques locales. [14]

Level 3 exploitait AS3356, un backbone de transit mondial majeur. Les enregistrements RIPEstat fournissent une ressource publique et une vue de routage pour cet ASN. [10] Un enregistrement ASN aide à identifier l'opérateur associé aux observations de route. Il ne montre pas chaque contrat de peering privé, relation client ou politique de routeur active pendant un incident.

Le changement d'échelle modifie la portée de responsabilité de la configuration. Une petite entreprise peut annoncer un ensemble limité de préfixes à un seul fournisseur. Un grand réseau de transit échange des routes avec des fournisseurs d'accès, des réseaux de contenu, des entreprises et d'autres transporteurs. Une erreur de politique à ce niveau peut influencer des chemins bien au-delà des seuls clients retail directs de l'opérateur.

L'internet n'a pas de contrôleur central qui approuve chaque route. Chaque réseau décide de ce qu'il annonce et de ce qu'il accepte. Cette architecture soutient l'exploitation indépendante, mais aussi le fait qu'une mauvaise annonce peut se propager quand plusieurs réseaux la considèrent acceptable selon leurs politiques locales. Les conséquences dépendent de la granularité du préfixe, des attributs de chemin, des relations commerciales, des filtres et du moment de la sélection de route.

ThousandEyes a décrit Level 3 annonçant des routes plus spécifiques associées à des réseaux de filiales et de clients Comcast. Un trafic qui avait transité par le backbone AS7922 de Comcast était observé via AS3356 à la place. [2] Les routes plus spécifiques comptent parce que le forwarding suit généralement la correspondance la plus longue. Une annonce couvrant un bloc d'adresses plus étroit peut attirer du trafic même quand une route plus large reste visible.

La preuve ne signifie pas qu'un seul routeur a dicté l'ensemble de l'internet. Cela signifie qu'un réseau à vaste interconnexion a produit ou propagé de l'information suffisante pour que suffisamment d'autres réseaux l'acceptent et créent des changements de forwarding substantiels. Chaque acceptation relevait d'une décision de politique locale, mais Level 3 contrôlait le changement ayant introduit l'état de route observé.

C'est pourquoi une configuration backbone ne peut pas être traitée comme un détail administratif interne. Son résultat opérationnel est un ensemble d'assertions consommées par d'autres systèmes autonomes. Plus grande est l'étendue d'interconnexion, plus forte est l'obligation de modéliser la portée d'export, d'établir un plan de déploiement par étapes et de vérifier l'effet externe.

Les preuves BGP et les preuves de forwarding répondent à des questions différentes

Les collecteurs de routes et les sondes de chemin utilisateur observent des parties liées mais différentes de l'incident.

Un collecteur de routes enregistre les mises à jour BGP des pairs entités. Les archives RouteViews fournissent les données historiques de mises à jour de novembre 2017. [11] Le Routing Information Service de RIPE NCC collecte également des informations de routage depuis des points de vue mondiaux. [12] CAIDA BGPStream propose des outils et interfaces de données pour analyser les événements BGP. [13]

Ces systèmes aident à reconstruire quand un préfixe a été annoncé ou retiré, quel préfixe d'origine et quel chemin sont apparus sur un collecteur, et comment la visibilité a évolué dans le temps. Ils ne peuvent pas voir chaque route dans chaque routeur. Une route non visible sur un collecteur peut avoir existé ailleurs. Une route visible n'a pas forcément porté beaucoup de trafic. Les préférences locales, l'ingénierie de trafic et le peering privé peuvent produire un comportement de forwarding non entièrement représenté dans les flux publics de collecteurs.

Les mesures de forwarding et d'application ajoutent une couche. ThousandEyes a rapporté des changements de chemin, de latence et de perte de paquets depuis des agents distribués. [2] Ces mesures indiquent ce que des paquets sélectionnés ont vécu depuis des lieux sélectionnés. Elles se rapprochent davantage de l'impact utilisateur qu'une mise à jour de plan de contrôle seule, mais ne représentent pas non plus tous les utilisateurs ni tous les chemins.

Une enquête accountable combine les couches:

la politique de route prévue avant le changement;
le diff de configuration exact ou la politique générée;
les annonces et retraits BGP observés en interne;
les annonces observées par des collecteurs indépendants;
les chemins de forwarding depuis des réseaux divers;
la perte de paquets, la latence et les transactions réussies;
les réclamations clients et les mises à jour de statut du fournisseur;
le rollback ou la correction;
la confirmation indépendante d'un routage et d'une connectivité restaurés.

Sans cette jonction, les équipes peuvent classer mal l'événement. Une mise à jour de route peut être visible sans causer de préjudice matériel. Une perte de paquets peut survenir sans cause BGP. Une application peut échouer parce que le DNS, l'identité ou une dépendance cloud a failli alors que la route est restée stable.

La preuve de 2017 est convaincante car les observations de route et de forwarding vont dans la même direction. ThousandEyes a vu des incohérences de route et un AS path modifié avec hausse de latence et de perte de paquets. [2] Le fournisseur a attribué la perturbation à une configuration. [1][5][6] Cette combinaison soutient une conclusion de mauvaise configuration BGP tout en conservant l'incertitude sur la mise en œuvre interne.

La même discipline s'applique à la restauration. Un retrait observé sur un collecteur ne suffit pas pour déclarer que chaque chemin utilisateur est rétabli. Les opérateurs devraient confirmer l'état stable de route, la sélection de chemin attendue, la baisse de la perte, une latence normalisée et la réussite des transactions applicatives sur les régions concernées.

La fuite de route est plus précise que le détournement, mais reste une question d'attribution

La discussion publique utilise souvent route leak et route hijack de manière interchangeable. La distinction est importante car elle oriente les affirmations sur l'intention, l'autorisation et la prévention.

RFC 7908 définit une route leak comme la propagation d'annonces de routage au-delà de leur portée prévue. [16] Le document décrit des catégories selon les relations entre réseaux et la direction dans laquelle les routes sont propagées. Une fuite peut survenir quand un client exporte des routes apprises auprès d'un fournisseur vers un autre fournisseur, quand des routes internes sortent de leur périmètre, ou quand un réseau annonce des informations contraires à une relation commerciale prévue.

Un hijack renvoie souvent à une origine ou à un chemin non autorisé qui attire du trafic, parfois de manière malveillante. Les preuves publiques du 6 novembre 2017 appuient un échec de configuration involontaire, non une assertion d'intention malveillante. Les reportages contemporains décrivaient un problème de configuration, et ThousandEyes utilisait la terminologie de route leak. [1][2][5][6]

Même l'étiquette de fuite doit être liée aux preuves. Les observateurs publics n'avaient pas accès à l'intention de politique complète de Level 3, à ses contrats et à ses configurations de routeurs. ThousandEyes a observé des annonces plus spécifiques et des changements de chemin incohérents avec le routage normal de Comcast. [2] Ce comportement est cohérent avec une fuite, et des analystes l'ont caractérisé ainsi. L'article doit conserver cette attribution sans revendiquer un accès à une intention privée.

La terminologie affecte aussi l'analyse de contrôle. Si le problème central est une origine non autorisée, la validation d'origine BGP peut couvrir une partie du risque. Si l'origine reste autorisée mais que la portée d'export viole une politique relationnelle, la validation d'origine peut encore considérer la route comme valide. Si une route plus spécifique est techniquement couverte par l'autorisation mais erronée opérationnellement, l'acceptation suppose d'autres contrôles de politique.

La conclusion la plus prudente est donc circonscrite: Level 3 a reconnu un problème de configuration; des mesures indépendantes ont observé des changements de route liés à AS3356 et une altération du forwarding; les analystes ont qualifié l'événement de route leak. Les sources n'établissent ni sabotage, ni compromission de credentials, ni intention d'interception, ni la commande interne exacte.

Cette limite n'est pas une échappatoire. Elle empêche l'incertitude technique de devenir une accusation. Elle maintient la remédiation focalisée sur les contrôles que les preuves soutiennent: validation de changement, politique d'export, filtrage pair, surveillance de route et rollback.

Une configuration syntaxiquement valide peut rester erronée opérationnellement

Les systèmes de changement réseau vérifient souvent si un texte de configuration se parse correctement et si un équipement l'accepte. Ces vérifications sont nécessaires, mais ne prouvent pas que le comportement réseau obtenu correspond à la politique.

Une configuration BGP peut être valide pour un routeur tout en violant un invariant opérationnel. Elle peut exporter une route vers le mauvais voisin, accepter une route client en dehors d'un ensemble attendu, créer un chemin plus spécifique avec une portée involontaire, modifier la préférence ou retirer un filtre. Le routeur exécute simplement la commande reçue. La défaillance se situe dans le fossé entre validité syntaxique et état réseau visé.

L'analyse de Batfish sur l'incident Level 3 plaidait pour tester la configuration réseau par rapport à des propriétés attendues avant déploiement. [3] La validation basée sur modèles peut vérifier si des destinations importantes restent joignables, si des chemins interdits apparaissent, si des routes sortent de leur portée prévue, si la redondance survit à une panne et si un changement affecte davantage de dispositifs ou de préfixes que prévu.

Cela ne signifie pas qu'un modèle puisse reproduire parfaitement l'internet public. Les pairs ont des politiques privées, l'état de route change en continu et certaines relations ne sont pas documentées. Un modèle utile est explicite sur ces limites.

La chaîne de contrôle des modifications doit donc contenir plusieurs vérifications:

Contrôle des sources:La configuration ou l'objet de politique proposé est stocké comme diff révisable avec un propriétaire identifié.
Validation de schéma et de syntaxe:Les outils confirment que la configuration est acceptée et référence des objets valides.
Invariants de politique:Des tests automatisés vérifient la portée d'export, les préfixes autorisés, les origines prévues, les contraintes de chemin et la connectivité.
Calcul du rayon d'impact:Le système estime les routeurs, sessions, préfixes et classes de clients touchés.
Pré-production représentative:Le changement est testé sur un état de topologie et de politique proche de la production pour révéler des conflits pertinents.
Déploiement canari:Un sous-ensemble observé reçoit le changement avant un déploiement plus large.
Télémétrie indépendante:Les collecteurs de routes, vues peer et sondes de forwarding comparent l'état prévu à l'état observé.
Conditions d'arrêt automatiques:Un nombre de routes inattendu, un changement de chemin, de perte ou de latence bloque le déploiement.
Autorité de rollback:Un opérateur désigné peut annuler le changement sans attendre une chaîne d'approbation longue.
Vérification post-changement:L'équipe démontre que les routes et services attendus restent stables.

Aucune vérification ne supprime le risque à elle seule. Ensemble, elles réduisent la chance qu'une erreur administrative devienne un incident à l'échelle d'un backbone.

L'accountability exige des preuves que ces contrôles existaient et ont été opérationnels. Un postmortem mentionnant qu'une erreur de configuration est intervenue ne répond pas à la question de savoir si le changement avait revue par les pairs, si les tests couvraient le comportement d'export, quels alertes ont été déclenchées ou à quelle rapidité le rollback était autorisé.

Le rayon d'impact doit être une propriété pré-déploiement

Les équipes opérationnelles décrivent souvent le rayon d'impact après un incident en comptant les services, les préfixes ou les utilisateurs affectés. Pour les changements réseau à fort impact, le rayon doit aussi être estimé avant déploiement.

La question n'est pas seulement combien d'équipements reçoivent une configuration. Un changement appliqué à un objet de politique de route peut affecter de nombreuses sessions BGP. Un changement sur un routeur de bordure peut modifier des annonces consommées par un grand pair. Un préfixe plus spécifique peut rediriger du trafic sans un grand nombre d'équipements modifiés. Des modèles partagés peuvent convertir une ligne en comportement à l'échelle de flotte.

L'évaluation pré-déploiement du rayon d'impact devrait vérifier:

quels routeurs et sessions référencent l'objet modifié;
quels préfixes peuvent correspondre à la politique;
quels voisins peuvent recevoir de nouvelles annonces ou des annonces modifiées;
si le changement affecte différemment clients, pairs et relations de transit;
quelles applications critiques dépendent des routes concernées;
si le rollback lui-même peut générer un gros pic de mises à jour;
si la surveillance couvre les chemins externes les plus probables;
si un canari fournit un échantillon pertinent du déploiement final.

L'évaluation doit intégrer l'incertitude. Si les politiques de pairs sont inconnues, cette incertitude justifie de réduire le déploiement initial et de renforcer la surveillance externe. Ce n'est pas une raison pour supposer que les pairs contiendront l'erreur.

ThousandEyes a signalé plus d'un millier de routes plus spécifiques lors de l'événement de 2017. [2] La revue annuelle d'APNIC a placé l'incident parmi les grands événements de sécurité de routage ayant touché des milliers de systèmes autonomes. [4] Ces chiffres sont des observations de analyses nommées, pas un comptage interne complet. Ils montrent néanmoins pourquoi le nombre de routes et la propagation externe auraient dû être des conditions d'arrêt.

L'objectif opérationnel n'est pas de garantir zéro mise à jour BGP. Les réseaux doivent changer. L'objectif est de rendre la portée prévue mesurable et de détecter quand l'état de fonctionnement s'en écarte.

Pour un backbone, la condition d'arrêt peut combiner nombre de routes, nouveaux modèles d'origine ou de chemin, modifications d'export par pair, visibilité collecteurs, perte de paquets et alertes clients. Un seuil devrait être rattaché à la demande de changement pour que les équipes sachent si une anomalie est attendue, tolérable ou justifie un rollback.

Quand un incident survient, le même modèle de rayon d'impact devient partie du dossier de preuve. Les enquêteurs peuvent comparer étendue prédite et portée réelle, identifier les dépendances manquantes et améliorer le test suivant.

Le rollback est une capacité de production, pas une ligne de plan

Un processus de contrôle de changement est incomplet si le rollback n'existe que comme instruction de restauration de la configuration précédente. Le rollback BGP peut lui-même produire convergence, retraits et changements de trafic. Il doit être conçu et testé comme action opérationnelle.

Le registre public indique que Level 3 a corrigé le problème de configuration et que ThousandEyes a observé le retrait des routes fuitées vers environ 11 h 25 heure du Pacifique. [1][2] Il ne précise pas qui a autorisé le rollback, si la configuration antérieure a été restaurée de façon atomique, comment les équipements ont convergé ni quels signaux externes ont été utilisés pour confirmer la reprise.

Ces inconnues définissent les preuves qu'un opérateur accountable devrait conserver:

l'identifiant du changement et le diff exact;
début de déploiement, portée et opérateur;
première anomalie et première alerte;
déclaration d'incident et propriétaire de la commande;
décision de stopper ou d'inverser le déploiement;
commande de rollback ou politique de remplacement;
achèvement par équipement et session;
retrait de route et annonce de retour attendue;
récupération de forwarding par région et par pair;
confirmation par clients et fournisseurs d'accès;
intervalle de stabilité post-rollback.

La vitesse de rollback n'est pas la seule métrique. Une inversion rapide qui laisse des états de routes obsolètes ou surcharge les sessions peut prolonger le préjudice. Un rollback plus progressif peut être justifié s'il évite une défaillance secondaire. Le dossier doit expliquer la décision et en montrer l'effet.

L'équipe a aussi besoin d'une voie hors bande pour contrôler le réseau si le routage de production est dégradé. La gestion reposant sur le même chemin en réparation peut transformer une erreur de routage en échec de récupération. Les preuves publiques de 2017 ne disent pas que Level 3 a perdu d'accès de gestion. Le point reste une exigence de contrôle dérivée de la classe de panne, non une assertion spécifique à l'incident.

Les clients ont besoin d'un plan de rollback parallèle. Une entreprise voyant une panne de route en amont peut dévier du trafic, changer ses annonces ou activer un autre fournisseur. Ces actions peuvent créer leurs propres risques de propagation. Le client doit définir qui peut agir, quels chemins sont indépendants et comment vérifier qu'une bascule ne détériore pas l'incident.

Le rollback devient crédible quand les opérateurs peuvent le démontrer en exercices et montrer que les preuves en direct correspondent aux étapes prévues. Une formule déclarative disant que la configuration a été corrigée est un fait de départ, pas la preuve complète d'une gouvernance de récupération.

Les pairs avaient aussi leurs propres contrôles de confinement

Le réseau qui introduit une mauvaise route est le détenteur de contrôle principal pour le changement, mais le routage interdomaines distribue la responsabilité. Chaque pair décide ce qu'il accepte, préfère et propage.

RFC 7454 décrit des pratiques opérationnelles de sécurité BGP, y compris filtrage de préfixes, filtrage AS-path, limites et politique tenant compte des relations. [15] MANRS fixe également des attentes communes de filtrage, coordination, validation globale et anti-spoofing entre opérateurs réseau. [18]

La responsabilité entre pairs n'est pas identique dans toutes les relations. Un fournisseur est en meilleure position pour connaître l'ensemble de préfixes et le rôle de routage d'un client que d'un pair settlement-free. Un client ne dispose pas forcément d'une liste complète des routes de chaque fournisseur. Les réseaux dynamiques de grande taille rendent les filtres statiques plus difficiles à maintenir. Des erreurs de politique peuvent survenir d'un côté comme de l'autre.

Pourtant, un réseau acceptant des routes devrait être capable d'expliquer son modèle de confiance:

quels préfixes et quelles origines sont attendus de chaque client;
si les annonces plus spécifiques sont autorisées;
si un AS path est cohérent avec la relation;
quels seuils de nombre de routes ou de max-prefix s'appliquent;
si des annonces inhabituelles déclenchent des alertes ou un rejet;
comment les exceptions sont approuvées et expirent;
quelles sources de données indépendantes valident les attentes;
comment la coordination d'urgence se fait avec le réseau qui annonce.

Les informations de registre public peuvent soutenir ces contrôles, mais elles peuvent être obsolètes ou incomplètes. Les objets de registries internet, les autorisations RPKI et les chemins observés répondent à des questions différentes. Les opérateurs ne doivent pas traiter une source unique comme oracle complet de politique.

L'événement de 2017 montre un problème collectif de confinement. Level 3 contrôlait la configuration qui a produit les annonces observées. D'autres réseaux ont accepté assez de ces annonces pour modifier les chemins de trafic. Certains avaient probablement des raisons opérationnelles valides selon l'information disponible. D'autres pouvaient manquer de filtres qui auraient limité la propagation.

Une revue accountable ne doit pas attribuer la faute à des pairs non nommés sans leurs configurations. Elle doit demander quels contrôles de confinement étaient techniquement disponibles, lesquels étaient actifs, quelles alertes se sont déclenchées et si les exercices ultérieurs démontrent une amélioration.

La même logique évite le transfert de coût. Un backbone peut externaliser l'effet d'une erreur de configuration vers des fournisseurs d'accès, réseaux de contenu et utilisateurs. Les pairs peuvent externaliser un filtrage insuffisant vers l'ensemble du système de routage. Des preuves partagées et une remédiation coordonnée sont nécessaires car aucun opérateur ne contrôle chaque décision d'acceptation.

RPKI aide à l'autorisation d'origine, pas à toutes les fuites de route

RPKI permet aux détenteurs d'adresses de créer des Route Origin Authorizations identifiant quels systèmes autonomes peuvent être l'origine de préfixes spécifiés. Le Route Origin Validation classe une route selon que son origine et sa longueur de préfixe sont cohérentes avec une autorisation valide. RFC 6811 définit cet état de validation et la manière dont il peut informer la politique locale. [17]

Il s'agit d'un contrôle important, mais sa portée doit être explicitée précisément.

Si un système autonome non autorisé émet une origine de préfixe, une ROA valide peut aider les réseaux à identifier et rejeter la route invalide. Si une fuite conserve une origine autorisée mais viole la portée d'export, la route peut rester valide côté origine. La validation RPKI n'encode pas la relation commerciale complète ni le chemin métier attendu.

Le registre public de Level 3 ne renseigne pas l'état ROA de tous les préfixes affectés en novembre 2017, la politique ROV de chaque pair ni un scénario contrefactuel où un tel contrôle aurait empêché l'incident. L'article n'affirme donc pas que RPKI aurait arrêté l'événement.

RPKI s'intègre au cadre de remédiation comme une couche:

les ROA rendent l'autorisation d'origine explicite;
la ROV peut rejeter certains origines non autorisées;
les filtres de préfixe limitent ce qu'un voisin peut annoncer;
la politique de chemin sensible aux relations limite la propagation des routes;
les contrôles de max-prefix limitent la quantité;
la détection d'anomalies identifie les changements inattendus;
la validation de changement basée sur modèles teste le comportement d'export prévu;
les collecteurs de routes et les sondes de forwarding vérifient les résultats en production.

Des mécanismes ultérieurs comme BGP Roles et la prévention des route leaks peuvent encoder directement une partie des frontières relationnelles. Ils doivent être évalués comme contrôles plus récents, pas comme des mécanismes rétrospectivement déployés en 2017.

Le point de gouvernance plus large est qu'un contrôle de sécurité doit correspondre au mode de panne. Classer tous les problèmes BGP comme un manque RPKI peut produire une assurance fausse. Un réseau peut avoir une autorisation d'origine complète et exporter pourtant des routes valides dans la mauvaise direction ou avec un préfixe plus spécifique non prévu.

Les opérateurs devraient déclarer le contrôle qu'ils estiment avoir interrompu la chaîne réelle. Si la panne vient d'une génération de politique, montrer un invariant de test nouveau. Si la panne vient d'un filtre pair manquant, montrer le filtre et l'exercice de rejet de route. Si l'origine invalide s'est propagée, montrer la couverture ROV. Chaque affirmation doit être liée à un comportement observé.

Les enregistrements de registre sont des preuves, pas une exécution de route

La doctrine Heng.lu propose une distinction utile entre un enregistrement et un système en fonctionnement.

Les enregistrements ASN et adresses conservent des identifiants, des détenteurs de ressources, des contacts et l'historique d'inscription. Les registres de routage peuvent consigner une politique prévue. RPKI peut consigner l'autorisation d'origine. Ces systèmes soutiennent l'unicité, la traçabilité, les transferts, les métadonnées de sécurité et la coordination.

Ils ne font pas transiter de paquets ni appliquer par déclaration chaque politique de pair.

RIPEstat peut aider un enquêteur à identifier AS3356 et à consulter des données de routage publiques. [10] RouteViews, RIPE RIS et BGPStream peuvent montrer les annonces observées par des collecteurs. [11][12][13] Ces enregistrements font partie du journal de responsabilisation. Le routeur actif accepté par chaque réseau et le chemin de forwarding réellement choisi pour les paquets restent la couche de réalité.

Cette distinction évite deux erreurs.

La première erreur consiste à traiter l'enregistrement comme preuve de fonctionnement sain. Un ASN correctement enregistré peut annoncer des routes sous une politique défaillante. Des données de ressources exactes ne prouvent pas qu'un changement de configuration est sûr.

La deuxième erreur consiste à traiter les administrateurs de registres comme des contrôleurs souverains du routage interdomaines. Les opérateurs choisissent la politique locale et font fonctionner les routeurs. Les teneurs de registre peuvent améliorer la preuve et les métadonnées de sécurité, mais ils ne remplacent pas la responsabilité opérationnelle.

Pour l'incident de 2017, la chaîne de preuve doit donc relier:

l'ASN et les ressources d'adresses enregistrées;
les politiques de relation prévues entre Level 3 et Comcast;
le diff de configuration ayant changé le comportement de route;
l'état de route interne;
les annonces observées par collecteur;
l'acceptation pair;
les chemins de forwarding réels;
les pertes et latences visibles pour les utilisateurs;
le retrait et la restauration.

Aucune couche ne suffit seule. Un diff de configuration privé sans preuve externe peut manquer la propagation. Une mise à jour de collecteur sans intention ne peut expliquer pourquoi la route est apparue. Une plainte client sans donnée de route ne peut identifier le contrôle en échec.

La doctrine est une règle pratique de gouvernance, pas un texte d'incitation. Elle dit que la responsabilité doit suivre les parties qui opèrent le système en fonctionnement, tandis que les registres exacts conservent qui contrôlait les ressources et quelle politique était revendiquée.

La communication d'incident doit nommer la couche en échec

Les utilisateurs touchés par la perturbation de 2017 ont vu des applications échouer ou ralentir. Ils n'ont généralement pas vu un objet de politique BGP, un AS path ou la route qui redirigeait le trafic.

Ce fossé rend la communication d'incident partie du système de contrôle technique. Une déclaration d'« interruption internet » est trop large pour guider un fournisseur d'accès, une entreprise ou un réseau de contenu. Une déclaration indiquant un problème de configuration affectant le routage réduit le périmètre du problème. Une mise à jour utile va plus loin sans exposer de détails sensibles.

Un avis accountable peut indiquer:

la couche réseau affectée;
le temps de début approximatif et la source de détection;
l'étendue large connue à ce moment;
si l'opérateur a arrêté d'autres changements;
si les routes sont retirées ou restaurées;
quelles classes de clients ou régions pairs restent affectées;
quels faits définiront la restauration;
quels faits restent non confirmés.

Les reportages publics ont relayé l'explication de configuration de Level 3. [1][5][6] C'était plus informatif qu'une alerte de dégradation de service non expliquée. Le registre public ne montre pas de compte rendu détaillé de post-incident avec toute la séquence interne et les changements de contrôle.

Les fournisseurs d'accès ont aussi un devoir de communication. Les utilisateurs Comcast ont vu des pannes de service, et l'analyse de ThousandEyes était centrée sur les chemins Comcast. [2] Comcast contrôlait la relation client et pouvait décrire l'impact abonné même s'il ne contrôlait pas la configuration de Level 3.

La communication doit préserver l'incertitude. Les rapports de problèmes simultanés chez AT&T, Verizon, Spectrum et d'autres réseaux ne prouvent pas une cause technique commune. [5][6] Un fournisseur doit séparer l'impact partagé confirmé des réclamations corrélées encore sous investigation.

Le message de restauration doit aussi reposer sur des preuves. « Résolu » devrait signifier plus qu'un rollback effectué. Il faut un soutien de routes stables, de chemins attendus, de perte de paquets normalisée et de transactions client réussies sur un intervalle défini.

Une communication précise réduit le coût opérationnel. Elle aide les clients à décider d'une bascule, de conserver des logs ou d'attendre la récupération amont. Elle crée aussi un enregistrement horodaté contre lequel les assertions ultérieures peuvent être testées.

L'impact utilisateur ne doit pas être gonflé au-delà des chemins mesurés

Les reportages contemporains décrivaient une perturbation nationale ou très large. ThousandEyes a observé des effets sur plusieurs régions américaines et signalé que des millions d'utilisateurs Comcast étaient potentiellement concernés. [1][2][5][6] Ces récits établissent un impact matériel. Ils ne justifient pas une assertion selon laquelle chaque client Comcast ou chaque fournisseur rapporté a subi la même panne.

L'évaluation d'impact doit distinguer:

la visibilité de route sur collecteurs;
les changements de forwarding d'emplacements précis;
perte de paquets et latence;
l'incapacité de rejoindre des destinations nommées;
les réclamations de service des fournisseurs d'accès;
les échecs de transactions applicatives;
la durée selon géographie et réseau;
les utilisateurs potentiels versus les sessions réellement en échec.

Une personne peut avoir une réponse DNS en cache et un chemin opérationnel, tandis qu'une autre ne peut pas atteindre le même service. Une entreprise peut utiliser un second fournisseur transit. Une application mobile peut reprendre via un autre point de terminaison après nouvelle tentative. Le même événement BGP produit des résultats hétérogènes.

La source de l'article ne contient pas de chiffre agrégé de perte financière défendable. Elle n'établit pas non plus la causalité juridique pour chaque interruption métier. Cet article n'invente pas cela en multipliant une estimation d'utilisateurs par une durée d'arrêt.

Un opérateur disposant de télémétrie interne peut faire mieux. Il peut rapporter déplacements de trafic, paquets perdus, sessions échouées, préfixes affectés, tickets clients et restauration par région. Les fournisseurs d'accès peuvent mesurer les effets sur les sessions abonnés et au niveau applicatif. Les grands clients peuvent mesurer les transactions échouées et des pertes dépendantes des services.

Ces mesures doivent être réconciliées plutôt que réunies dans un nombre unique. Le nombre de routes mesure l'état réseau. La perte de paquets mesure un symptôme de chemin. Le volume de plaintes mesure la frustration visible. L'échec transactionnel mesure l'effet métier. Chaque indicateur est utile quand son dénominateur et ses limites sont explicités.

La maîtrise est importante. Des affirmations gonflées peuvent rendre le rapport plus facile à contester. Des mesures bornées identifient précisément où les contrôles ont échoué et ce que la remédiation doit démontrer.

La reconstruction indépendante a des limites qu'il faut documenter

Les données de route publiques sont exceptionnellement utiles car elles permettent d'étudier un incident en dehors de l'opérateur. Cette indépendance crée de la responsabilisation, mais ne donne pas une omniscience.

RouteViews et RIPE RIS voient les routes envoyées à leurs collecteurs par les pairs entités. [11][12] BGPStream aide les chercheurs à traiter et comparer ces observations. [13] RIPEstat combine vues de ressources et de routage. [10] ThousandEyes ajoute des tests de forwarding et de service depuis des points de vue distribués. [2]

Ensemble, ces sources peuvent établir:

que des routes sélectionnées ont changé;
quels origines et chemins étaient visibles;
le timing approximatif des annonces et retraits;
si le trafic a suivi un chemin modifié depuis les emplacements mesurés;
si la perte ou la latence ont augmenté;
quand la connectivité mesurée s'est rétablie.

Elles ne permettent généralement pas d'établir:

la commande exacte saisie par un opérateur;
la chaîne de génération de politique interne;
chaque route dans chaque routeur;
le peering privé et les décisions de préférence locale;
l'ensemble complet des clients;
le propriétaire de la décision de déploiement ou rollback;
les alertes internes et communications d'incident;
l'efficacité actuelle des remédiations.

Un rapport indépendant doit déclarer la couverture des collecteurs, la précision des horodatages, les choix de normalisation et les données manquantes. Il doit conserver les références brutes de mises à jour quand c'est possible pour qu'un autre analyste puisse reproduire la constatation.

L'opérateur devrait conserver un jeu de preuves plus riche. Ce jeu peut inclure versions de configurations, journaux d'équipement, évaluations de politique de route, état des route-reflectors, notifications peers, télémétrie, tests de chemins de paquets, incidents tickets et approbations de changement. Les détails sensibles peuvent être partagés avec des auditeurs ou partenaires affectés sous contrôle.

Le postmortem le plus crédible connecte les vues privée et publique. Il explique pourquoi les annonces observées sont apparues, quel contrôle interne a échoué, comment la route a été contenue et quel test empêche la récurrence.

Quand l'opérateur ne publie pas ces preuves, les observations indépendantes soutiennent encore une conclusion bornée. Elles ne doivent pas être étirées pour combler les zones privées.

La remédiation doit être testable sur une panne de route reproductible

Le registre public examiné ici ne montre pas toutes les remédiations qu'a mises en place Level 3 ou ses pairs après novembre 2017. Une évaluation responsable définit donc quelles preuves démontreraient la réparation plutôt que d'affirmer succès ou échec actuel.

Un programme de remédiation testable devrait couvrir cinq groupes de contrôle.

Génération et revue de configuration

L'opérateur devrait montrer que la politique de routage est générée à partir de données contrôlées, revue sous forme de diff et vérifiée par rapport à des invariants. Les preuves devraient identifier quelles classes de routes et relations un changement peut affecter.

Déploiement en étages et conditions d'arrêt

L'opérateur devrait déployer par canari borné quand c'est possible, comparer les annonces live aux attentes et arrêter en cas de dépassement des limites prévues sur volume de routes, changements de chemin, perte ou latence.

Filtrage pair et client

L'opérateur et les pairs devraient maintenir des politiques de préfixe et de relation attendues, tester le traitement des exceptions et surveiller les annonces plus spécifiques inattendues. Les contrôles doivent utiliser plusieurs sources de preuve plutôt que de supposer qu'un registre est complet.

Récupération et rollback

Les équipes devraient exercer le rollback, le retrait de route, la convergence de session et la gestion hors bande. La récupération doit être confirmée par des observations indépendantes de routes et de forwarding.

Divulgation et vérification

Les communications post-incident devraient distinguer cause confirmée, contrôles contributifs, portée, inconnues et remédiation. Les exercices ultérieurs devraient montrer si le nouveau contrôle détecte ou contient une panne représentative.

Un exercice réaliste peut introduire une erreur de politique synthétique et sans risque dans un labo ou un domaine de routes isolé. L'erreur peut tenter d'exporter un préfixe plus spécifique au-delà d'une relation prévue. Le système doit la rejeter lors de la génération ou de la validation pré-déploiement. Si elle atteint un canari, la surveillance doit stopper le déploiement. Un test pair doit démontrer le filtrage d'import. Un test rollback doit retirer la route et confirmer le forwarding attendu.

L'exercice ne doit pas injecter de routes nuisibles dans l'internet public. Son objectif est de prouver la chaîne de contrôle dans un environnement représentatif et de conserver une preuve auditable.

La remédiation est la plus solide quand elle se rattache au chemin de panne d'origine. Un investissement générique en surveillance ne prouve pas la validation d'export. Un programme RPKI révisé ne prouve pas le confinement de fuites d'origine valide. Une procédure revue ne prouve pas que le rollback fonctionne sous bruit de route.

Ce que les conseils d'administration et les acheteurs de services devraient demander

Le risque de routage backbone peut paraître trop technique pour le pilotage d'un conseil. Les questions de gouvernance pertinentes sont concrètes.

Les conseils devraient demander combien de changements peuvent modifier des routes publiées externes, qui peut les approuver, quels invariants pré-déploiement sont obligatoires et quelles conditions d'arrêt automatiques existent. Ils devraient demander des preuves issues d'exercices, pas seulement une étiquette de maturité.

Les acheteurs de services devraient demander si leurs fournisseurs surveillent routes et forwarding depuis en dehors de leur propre réseau, comment ils notifient rapidement les clients d'incidents de routage et si des chemins alternatifs sont opérationnellement indépendants. Un contrat prévoyant deux opérateurs ne prouve pas la diversité de route si les deux dépendent d'un même backbone ou d'une même infrastructure partagée.

Les opérateurs réseaux devraient demander si les données de registre, RPKI et routes observées sont réconciliées, comment les attentes de cône client sont maintenues et comment les exceptions expirent. Ils devraient savoir quels pairs peuvent diffuser des ensembles de routes anormalement larges ou plus spécifiques.

Les responsables d'incident devraient demander qui peut figer le déploiement, qui peut autoriser le rollback et quel fait constitue la preuve de reprise. La chaîne de décision devrait rester exploitable quand le réseau affecté est instable.

Les auditeurs devraient échantillonner des configurations actuelles et des observations de route plutôt que d'examiner uniquement les documents de politique. Un contrôle existant dans une norme mais contourné par des gabarits ou des exceptions d'urgence n'est pas opérationnellement efficace.

Les régulateurs devraient éviter de réduire la sécurité de routage à une seule exigence technologique. L'autorisation d'origine, le filtrage, la vérification de changement, la surveillance, la coordination et la continuité couvrent des modes de panne différents. Les exigences de preuve peuvent être techniquement informées sans prétendre qu'un mécanisme résout toutes les fuites.

Ces questions ne supposent pas une faute. Elles suivent un contrôle concret. Un opérateur avec des preuves solides peut montrer qu'un écart inhabituel a passé un contrôle raisonnable et a été contenu rapidement. Un opérateur sans preuves ne peut pas substituer la complexité de BGP à une démonstration de diligence.

Les questions non résolues font partie du résultat

Les preuves publiques laissent des questions importantes sans réponse:

Quelle configuration exacte ou quelle politique générée a introduit les routes?
Quels contrôles de revue et de validation ont été exécutés avant déploiement?
Combien d'équipements et de sessions ont reçu le changement?
Quelles relations de pair étaient prévues pour accepter ou rejeter les annonces?
Quelle alarme interne a identifié en premier une propagation inattendue?
Qui a arrêté le déploiement et autorisé le rollback?
Comment les retraits de route et la restauration du forwarding ont-ils été vérifiés?
Quels pairs ont modifié leurs filtres après l'événement?
Quelle remédiation a été mise en place et exercée par la suite?

Ces inconnues n'annulent pas l'incident observé. Elles définissent la limite de la conclusion et la preuve nécessaire pour la renforcer.

Le dossier soutient une catégorie de cause racine: Level 3 a attribué la perturbation à une configuration, tandis que des analystes indépendants ont observé une fuite de route et une dégradation du forwarding impliquant AS3356. [1][2][3][4][5][6]

Il soutient des conditions contributives: l'ampleur du backbone, l'acceptation de route cross-network, la puissance des préfixes plus spécifiques et les limites de confinement externe.

Il soutient un évènement déclencheur de haut niveau: un changement ou une mauvaise configuration de politique de routage. La commande exacte et le chemin de déploiement complet demeurent non divulgués.

Il soutient une chronologie de détection et de reprise depuis mesures externes, mais pas la timeline interne complète de l'incident.

Cette distinction compte. Cause racine, conditions contributives, déclenchement, détection, réponse et restauration sont liés mais non interchangeables. Un rapport parlant d'« erreur humaine » comme cause racine s'arrêterait avant d'examiner pourquoi une modification a pu échapper à la revue, se propager et nécessiter des observateurs externes pour expliquer la panne.

Le standard d'accountability, c'est la politique prévue prouvée dans l'état exécuté

L'incident du 6 novembre 2017 n'était pas simplement une période où plusieurs sites semblaient lents. C'était un événement de routage interdomaines dans lequel des changements BGP observés publiquement ont redirigé du trafic et dégradé la joignabilité à travers les frontières organisationnelles.

La preuve publique la plus forte est bornée. ThousandEyes a rapporté des changements de routes et de forwarding, des annonces plus spécifiques associées aux réseaux Comcast, une hausse de perte et latence, et leur retrait vers environ 11 h 25 heure du Pacifique. [2] Level 3 a attribué la perturbation à un problème de configuration. [1][5][6] Batfish a utilisé l'événement pour montrer pourquoi la politique intentionnelle doit être modélisée avant déploiement. [3] APNIC l'a placé parmi les incidents de sécurité de routage de grande ampleur de 2017. [4]

Les sources n'exposent pas la commande interne exacte, tous les préfixes et utilisateurs affectés, l'ensemble des politiques par pair, le propriétaire des décisions de déploiement ou rollback ni l'efficacité de remédiation actuelle. Elles ne soutiennent pas des assertions d'intention malveillante.

La responsabilisation suit le contrôle opérationnel réel. Level 3 contrôlait le changement et sa politique d'export. Les pairs contrôlaient acceptation et confinement. Comcast contrôlait la communication aux abonnés et une partie de la restauration de service. Les clients pouvaient concevoir des chemins alternatifs et une surveillance externe. Les utilisateurs finaux pouvaient signaler l'impact mais ne pouvaient pas réparer BGP.

La doctrine Heng.lu fournit le test final. Les enregistrements ASN, de registre et de politique identifient les ressources et préservent l'intention. Ce sont des registres de responsabilité, pas l'exécution du routage. Les annonces BGP en production, les décisions de pair, les chemins de forwarding et la récupération observée déterminent si le réseau a réellement respecté cette intention.

Une réparation crédible n'est donc pas la déclaration que filtres, RPKI ou procédures de revue existent. C'est la preuve qu'une exportation fautive représentative est rejetée ou contenue, que des changements inattendus arrêtent le déploiement, que le rollback restaure les chemins attendus et que des sondes indépendantes confirment la joignabilité utilisateur.

Pour un backbone dont la configuration peut influencer des milliers de réseaux, une politique prévue doit être prouvée dans l'état opérationnel. C'est le standard d'accountability que l'incident Level 3 de 2017 rend incontournable.