Le dépeering Cogent-Level 3 de 2005, test de responsabilité

Synthèse

Level 3 a cessé d’échanger directement du trafic avec Cogent le 5 octobre 2005. Les archives publiques montrent que certains clients ont perdu l’accessibilité vers des destinations situées de part et d’autre de la coupure, tandis que l’impact complet sur les clients et les préfixes reste inconnu. [1][21][22]
Cogent a demandé publiquement à Level 3 de rétablir la connexion avant toute négociation ultérieure. La position publique préservée de Level 3 indiquait que l’accord d’essai ne satisfaisait plus à ses conditions. Il s’agit de positions commerciales attribuées, et non de conclusions selon lesquelles un opérateur aurait violé un contrat ou agi illégalement. [1][22]
Un préfixe enregistré et un contrat client ne créaient pas de chemin fonctionnel. L’accessibilité dépendait des routes échangées, acceptées et sélectionnées par AS174 et AS3356, ainsi que des éventuels transits alternatifs ou du multihoming réellement disponibles pour les clients.
Merit a utilisé des observations RouteViews sélectionnées pour étudier l’accessibilité vers le 38.0.0.0/8 de Cogent. RouteViews et RIPE RIS peuvent préserver les annonces et retraits des collecteurs entités, mais ils ne peuvent pas révéler chaque politique privée, préférence locale, chemin client ou condition commerciale. [8]-[10]
Le multihoming ne réduisait le risque que lorsque les fournisseurs alternatifs, les annonces acceptées, la capacité et les dépendances applicatives étaient véritablement indépendants. Un second contrat sans route alternative effective n’était pas une continuité.
Le 28 octobre, les opérateurs ont annoncé un accord de peering sans règlement modifié, assorti d’obligations de trafic, de paiements conditionnels et d’un processus visant à protéger les clients si la relation expirait plus tard ou si des violations n’étaient pas corrigées. Le communiqué public décrit une conception de contrôle, et non la preuve que tout risque futur d’interconnexion avait disparu. [2]
Les orientations ultérieures de BGP, de MANRS et du NIST aident à définir des contrôles mesurables tels que la politique explicite, la surveillance des routes, les limites de préfixes maximaux, la coordination et les preuves d’incident. Il s’agit d’un matériel de comparaison, et non d’une loi rétroactive pour l’événement de 2005. [13]-[20]
La norme de responsabilité est opérationnelle: cartographier les clients dépendants, prouver l’accessibilité alternative avant la terminaison, observer l’impact sur les routes et les transactions pendant le changement, préserver un processus de correction borné et vérifier la restauration depuis l’extérieur des deux réseaux d’opérateurs.

L’accessibilité à Internet est souvent vendue comme une propriété stable. Un client reçoit une adresse, se connecte à un opérateur amont et voit des routes vers des destinations du monde entier. De ce point de vue, « Internet » semble être un service continu. Dans le plan de contrôle, en revanche, l’accessibilité n’est pas une promesse institutionnelle. Elle est le résultat actuel de réseaux indépendants qui annoncent des préfixes, acceptent ou rejettent ces annonces, sélectionnent des chemins et acheminent le trafic selon leurs propres politiques.

Le différend d’octobre 2005 entre Cogent Communications, exploitant AS174, et Level 3 Communications, exploitant AS3356, a mis en évidence cette différence. Le 5 octobre, Level 3 a cessé d’échanger du trafic directement avec Cogent. Les déclarations et les reportages contemporains décrivaient des clients des deux réseaux perdant l’accès à certaines destinations de part et d’autre de la coupure. Les entreprises restaient connectées à d’autres parties d’Internet, et l’événement n’a pas divisé l’ensemble du réseau mondial.

Mais là où aucune route alternative acceptable ne reliait une destination accessible via Cogent à une source accessible via Level 3, les enregistrements d’adressage et les attentes des clients ne pouvaient pas faire traverser l’interconnexion manquante aux paquets.

Il s’agissait d’un dépeering délibéré, et non d’une fuite de route, d’un détournement de route ou d’une annonce BGP accidentelle. La défaillance opérationnelle provenait de la suppression d’un chemin qui avait précédemment transporté du trafic entre deux grands réseaux. Cette distinction détermine les éléments probants pertinents. Les enquêteurs doivent examiner la décision d’interconnexion, les changements de routes BGP, les chemins alternatifs, la dépendance des clients, le multihoming, la communication et la restauration. Un récit générique d’un désaccord commercial passe à côté du mécanisme qui a rendu le désaccord lourd de conséquences.

L’épisode met également à l’épreuve un type particulier de responsabilité. Le peering et le transit sont des arrangements commerciaux différents, et les archives publiques décrivent la relation restaurée comme du peering sans règlement plutôt que du transit payant. Pourtant, les deux entreprises vendaient de la connectivité au sein d’un écosystème dont la valeur dépendait de l’accessibilité interdomaine. La question de la responsabilité n’est donc pas de savoir si deux réseaux autonomes doivent faire du peering gratuitement.

Elle est de savoir si des opérateurs qui contrôlent une interconnexion lourde de conséquences peuvent identifier la dépendance des clients, gérer la terminaison sans masquer les conséquences opérationnelles, préserver les preuves et prouver la restauration.

L’accessibilité existe dans le chemin en service

Une allocation d’adresses IP peut identifier le détenteur d’un bloc. Un numéro de système autonome peut identifier un domaine de routage. Un contrat peut indiquer ce qu’un client a acheté, et un accord d’interconnexion peut décrire ce que deux opérateurs attendent l’un de l’autre. Aucun de ces enregistrements, à lui seul, n’installe une route dans la table de transfert d’un routeur.

Pour qu’un paquet circule d’un client derrière AS174 vers une destination derrière AS3356, les réseaux concernés avaient besoin d’une séquence de routes acceptées dans les deux sens. Cette séquence pouvait utiliser l’interconnexion directe Cogent-Level 3. Elle pouvait aussi passer par un autre opérateur si les politiques d’export, les relations commerciales, la capacité et la sélection des routes le permettaient. Si aucun réseau n’annonçait une alternative acceptable, la destination pouvait rester valablement enregistrée et correctement originaire tout en étant inaccessible depuis l’autre côté.

Cela fait de l’« accessibilité totale à Internet » un raccourci opérationnel plutôt qu’une garantie absolue que chaque hôte répondra toujours. Les pare-feu, les pannes applicatives et les politiques locales peuvent rendre un service particulier indisponible même lorsqu’une route réseau existe. La question pertinente dans le différend de 2005 est plus étroite: le routage interdomaine ordinaire fournissait-il des chemins utilisables entre des préfixes dont la connexion pratique dépendait de la relation AS174-AS3356?

L’étiquette commerciale d’un opérateur ne peut pas répondre à cette question. Décrire un réseau comme un backbone majeur ou un opérateur de niveau 1 peut indiquer une échelle ou une position commerciale, mais cela ne crée pas d’obligation de routage imposée mondialement. Chaque système autonome conserve le contrôle des routes qu’il exporte, des routes qu’il accepte et des chemins qu’il préfère. Internet n’a pas de routeur central capable d’ordonner à deux réseaux d’échanger du trafic après la fin d’une relation bilatérale.

Cette indépendance est l’une des forces d’Internet. Elle permet aux réseaux de prendre des décisions distinctes de sécurité, d’ingénierie et commerciales sans demander la permission à une autorité centrale. La même indépendance crée un problème de continuité: une décision bilatérale peut avoir des effets au-delà des deux parties lorsque les clients n’ont aucun chemin utilisable pour la contourner. La responsabilité doit donc suivre le contrôle pratique plutôt que les étiquettes.

L’opérateur qui contrôle une session contrôle sa disponibilité; un opérateur qui vend de la connectivité contrôle la résilience qu’il fournit ou recommande; un client ne contrôle sa propre redondance que dans des limites techniques et financières.

L’événement de 2005 a réuni ces couches. Les entreprises avaient un différend commercial, mais son effet sur les clients s’est exprimé par BGP. Les faits décisifs n’étaient pas simplement ce que les parties estimaient que l’accord exigeait. C’étaient les routes qui avaient cessé d’être échangées, les routes alternatives restées acceptables, les clients qui dépendaient du chemin supprimé et la manière dont la relation directe avait été restaurée.

Une chronologie bornée du différend d’octobre

La chronologie défendable commence le 5 octobre 2005, lorsque Level 3 a cessé l’échange direct de trafic avec Cogent. Les documents publics décrivent l’action comme la fin de la relation de peering direct entre les entreprises. Les preuves disponibles n’établissent pas la configuration physique complète de cette interconnexion, le nombre de sessions ou de ports concernés, ni la capacité à chaque emplacement. « La connexion » ne doit donc pas être lue comme la preuve qu’un seul câble ou un seul routeur représentait toute la relation.

Les reportages contemporains ont rapidement présenté la conséquence comme un problème d’accessibilité. Certains utilisateurs et entreprises connectés par un réseau ne pouvaient, selon les témoignages, pas atteindre des destinations dépendantes de l’autre. Ces récits soutiennent la conclusion que le dépeering a eu des effets réels sur les clients. Ils n’établissent pas une liste complète des préfixes touchés, une panne universelle chez l’un ou l’autre opérateur, un impact égal des deux côtés ni un pourcentage précis de l’Internet devenu inaccessible.

Le 7 octobre, Cogent a publiquement demandé à Level 3 de rétablir l’interconnexion avant la poursuite des négociations. Cette déclaration prouve la position de Cogent et la séquence proposée: rétablir d’abord la connectivité client, puis traiter le différend. Elle n’établit pas de manière indépendante les obligations confidentielles de l’une ou l’autre partie, ni ne détermine si l’accord antérieur satisfaisait à ses conditions.

Level 3 a fourni une explication publique différente. Sa déclaration, conservée dans la couverture contemporaine, décrivait la relation interrompue comme un arrangement de peering d’essai qui ne satisfaisait plus aux conditions applicables. C’est une preuve de la raison invoquée par Level 3. Les archives publiques ne fournissent pas l’accord complet, les mesures utilisées pour l’évaluer, les caractéristiques précises du trafic en cause, ni les délibérations internes ayant conduit à la terminaison. Elles ne permettent pas de conclure que Cogent a violé une condition non publiée particulière ni que l’évaluation de Level 3 était incorrecte.

Les discussions d’opérateurs archivées par NANOG documentent les questions contemporaines sur les chemins et l’accessibilité. Ces messages sont précieux car ils montrent ce que les ingénieurs réseau observaient et testaient pendant l’événement. Ils ne constituent pas un recensement contrôlé d’Internet. Les entités avaient des points de vue, des relations commerciales et des accès aux informations de routage différents. Un rapport d’un réseau pouvait décrire avec exactitude le chemin de ce réseau sans établir ce que tous les autres réseaux voyaient.

Le 28 octobre, Cogent et Level 3 ont annoncé conjointement avoir conclu un accord de peering sans règlement modifié. Leur communiqué décrivait des obligations concernant les caractéristiques et le volume du trafic, des paiements si ces obligations n’étaient pas satisfaites, et un processus visant à réduire le préjudice pour les clients si la relation expirait plus tard ou si une violation restait non corrigée. L’annonce est la preuve publique partagée la plus solide de la structure de la remédiation, car les deux entreprises l’ont publiée ensemble.

Le communiqué n’était toujours pas le contrat complet. Il ne divulguait pas publiquement tous les seuils, méthodes de mesure, délais de correction, procédures opérationnelles ni droits de décision. Son existence ne prouve pas non plus que chaque chemin client a été rétabli au même moment ni que tous les risques ultérieurs d’interconnexion ont disparu. Elle montre que les entreprises ont restauré leur relation selon des conditions révisées et ont publiquement identifié des procédures de protection des clients comme partie de la solution.

Des documents ultérieurs de la FCC ont discuté l’événement dans des analyses plus larges de l’interconnexion Internet, de la concurrence des réseaux fédérateurs et de l’accessibilité des clients. Ces documents aident à expliquer pourquoi un différend entre grands réseaux pouvait affecter des parties qui n’étaient pas signataires de l’accord de peering. Ils ne doivent pas être convertis en jugement juridique sur la conduite de 2005. Les documents cités n’établissent pas que l’un ou l’autre opérateur a violé une loi, une réglementation ou un contrat.

Ce qui a changé dans BGP

BGP permet aux systèmes autonomes d’échanger des informations d’accessibilité. Une annonce de route identifie un préfixe accessible et porte des attributs qui aident les réseaux récepteurs à appliquer des politiques et à sélectionner des chemins. Le chemin AS enregistre les systèmes autonomes par lesquels l’annonce s’est propagée, tandis que d’autres attributs et préférences configurées localement influencent la route qu’un réseau installe.

Le processus de décision est décentralisé. Cogent pouvait annoncer des préfixes clients et internes à Level 3 selon sa politique d’export. Level 3 pouvait accepter, filtrer ou préférer ces annonces selon sa politique d’import, puis exposer les routes sélectionnées aux clients ou pairs appropriés. Le processus inverse s’appliquait aux routes de Level 3 atteignant Cogent. Aucune des deux entreprises ne contrôlait tous les réseaux intermédiaires, et aucune ne pouvait contraindre un tiers à exporter un chemin alternatif.

Lorsqu’une relation BGP externe directe est terminée, les routes apprises exclusivement par cette relation cessent d’être utilisables après les retraits, la perte de session ou la suppression de politique. Les routeurs reconsidèrent alors les autres chemins disponibles. Si un autre opérateur annonce une route acceptable, le trafic peut basculer vers cette route. Si les alternatives sont absentes, filtrées ou commercialement indisponibles, le routeur affecté n’a aucun chemin utilisable vers la destination.

C’est pourquoi le même dépeering peut produire des résultats différents pour différents clients. Un réseau peut avoir un autre amont portant un chemin entre les deux côtés. Un autre peut n’apprendre que les routes disparues avec la session directe. Un troisième peut voir un chemin alternatif mais le rejeter en raison de politiques, de règles de longueur de préfixe ou de contraintes relationnelles. Un quatrième peut sélectionner une route alternative dont la capacité ou le chemin de retour ne supporte pas un trafic applicatif fiable.

La perte du chemin direct ne produit pas nécessairement des symptômes symétriques. Les décisions BGP sont prises séparément par chaque réseau, et le trafic de données exige des chemins aller et retour fonctionnels. Un paquet peut atteindre une destination tandis que sa réponse ne suit aucune route utilisable en retour. Des préférences locales différentes peuvent envoyer les deux directions par des systèmes autonomes différents. Par conséquent, une observation de route réussie dans un sens ne prouve pas un service bidirectionnel complet.

Les archives publiques n’exposent pas les configurations complètes de préférence locale de Cogent et de Level 3. Elles ne révèlent pas chaque filtre de route, traitement de communauté, pair privé ou arrangement de transit tiers. Les chemins AS publics peuvent suggérer comment le trafic aurait pu circuler, mais ils ne peuvent pas divulguer toutes les politiques internes qui ont déterminé la sélection des routes.

Les communautés BGP ajoutent une autre couche potentielle de preuve. La RFC 1997, antérieure à l’événement, définit une manière d’attacher des étiquettes pertinentes en matière de politique aux routes. Les réseaux peuvent utiliser les communautés pour demander ou signaler un comportement de propagation. La signification et la mise en œuvre de nombreuses communautés sont toutefois propres à chaque réseau. Même lorsqu’une communauté apparaît dans une mise à jour publique, elle ne divulgue pas automatiquement l’accord privé régissant la route ni ne prouve que chaque routeur a appliqué la politique prévue.

L’événement ne peut donc pas être réduit à « les routes ont disparu partout ». AS174 et AS3356 ont continué à fonctionner, et les préfixes qui leur sont associés pouvaient rester visibles depuis de nombreux emplacements. La question plus étroite était de savoir si les chemins traversant l’ancienne relation restaient disponibles par d’autres réseaux. Un préfixe visible à un collecteur pouvait être inaccessible depuis un client particulier. Inversement, une route absente d’un collecteur pouvait rester accessible ailleurs par un chemin privé ou sélectionné différemment.

La validité d’une route ne garantit pas non plus la connectivité. Un préfixe correctement originaire peut être inaccessible parce qu’aucune route acceptable n’atteint un réseau donné. Les mécanismes modernes de validation d’origine peuvent aider à déterminer si une origine est autorisée, mais ils ne peuvent pas forcer deux systèmes autonomes à maintenir une session de peering ni exiger d’un troisième réseau qu’il transporte le trafic entre eux. La défaillance de 2005 concernait la disponibilité des chemins et les politiques, pas simplement la propriété des adresses ou l’authenticité de l’origine.

Pourquoi certains réseaux pouvaient contourner la coupure

Le multihoming est le mécanisme de résilience le plus évident lors d’un dépeering. Un client connecté à plus d’un amont peut annoncer son préfixe par plusieurs réseaux et apprendre des destinations par plus d’un chemin. Si un amont perd l’accessibilité à une partie d’Internet, l’autre peut préserver une route utilisable.

Cette description est techniquement correcte mais incomplète comme réponse de responsabilité. Le multihoming exige plus que la signature d’un second contrat d’accès. Le client peut avoir besoin d’un espace d’adressage accepté par les deux amonts, d’un numéro de système autonome, d’équipements de routage compatibles, de personnel capable d’exploiter BGP, de filtres de routes, de surveillance, de contrôles de sécurité et d’une capacité suffisante sur la connexion alternative. Le chemin de retour doit aussi converger vers une route fonctionnelle.

Les applications avec pare-feu à état, dépendances d’adresses ou sensibilité aux changements de chemin peuvent exiger une ingénierie supplémentaire.

La politique commerciale compte également. Un opérateur alternatif doit être disposé et capable d’exporter les routes pertinentes. Un client ne peut pas supposer que deux connexions quelconques créent un chemin à travers chaque différend entre réseaux amonts. Les filtres de longueur de préfixe peuvent empêcher la propagation d’annonces plus spécifiques. Un circuit alternatif dimensionné pour le trafic de gestion d’urgence peut ne pas supporter la charge de production ordinaire. Une connexion nominalement diverse peut partager des installations physiques ou une dépendance amont commune.

Pour ces raisons, l’existence du multihoming ne prouve pas que chaque client multi-hébergé a conservé le service. Elle établit un contrôle possible dont l’efficacité doit être testée. De même, l’absence de multihoming n’établit pas à elle seule une imprudence. Les petits clients peuvent manquer de budget, d’expertise, de ressources d’adressage ou de pouvoir de négociation pour exploiter des connexions routées indépendantes. Un service vendu comme un accès Internet ordinaire peut raisonnablement être consommé sans que le client construise un mini-backbone.

Les clients à hébergement unique faisaient face à une dépendance plus aiguë. Si leur seul amont manquait d’une route acceptable vers des destinations de l’autre côté, ils ne pouvaient pas recréer une interconnexion de backbone après le dépeering. Ils pouvaient chercher un service d’urgence auprès d’un autre opérateur, mais le provisionnement, l’acceptation du routage, les équipements et les contrats prennent du temps. La partie contrôlant l’interconnexion supprimée pouvait modifier la disponibilité des routes bien plus vite que de nombreux clients dépendants ne pouvaient la remplacer.

Les opérateurs tiers constituaient une autre partie du chemin. Un réseau alternatif pouvait avoir des relations avec Cogent et Level 3, mais sa politique d’export pouvait ne pas lui permettre d’agir comme intermédiaire entre eux. Le routage interdomaine reflète couramment des rôles commerciaux: un opérateur peut annoncer largement les routes de ses clients tout en refusant de fournir un transit gratuit entre pairs. Les chemins BGP publics peuvent soutenir des inférences sur ces relations, mais la documentation de CAIDA souligne que les arrangements commerciaux sous-jacents sont généralement confidentiels et doivent souvent être inférés.

Cela importe car un dessin topologique peut surestimer la résilience. Deux réseaux peuvent tous deux se connecter à un troisième système autonome sans obtenir un chemin utilisable à travers lui. La question pertinente n’est pas de savoir si une ligne existe sur une carte. Elle est de savoir si les routes sont exportées, acceptées et sélectionnées selon une politique réelle, avec une capacité de transfert suffisante pour transporter le trafic résultant.

Une évaluation de continuité défendable classerait donc les clients par dépendance observée plutôt que par une simple étiquette multi-hébergé ou à hébergement unique. Elle demanderait quels préfixes avaient des chemins alternatifs vérifiés, quels services avaient une accessibilité bidirectionnelle, si la capacité restait adéquate, et combien de temps chaque cohorte de clients a subi une dégradation. Les preuves publiques figées ne fournissent pas cette matrice complète pour octobre 2005, de sorte que les affirmations sur la distribution de l’impact doivent rester limitées.

Reconstituer l’événement à partir des preuves de routes publiques

Les collecteurs de routes publics offrent une fenêtre importante mais partielle sur l’incident. RouteViews a archivé les mises à jour BGP d’octobre 2005, permettant aux enquêteurs d’inspecter les annonces et retraits reçus des pairs entités. RIPE RIS explique le rôle comparable des collecteurs distribués: ils enregistrent les informations de routage visibles depuis les réseaux qui choisissent de faire du peering avec eux.

L’étude de cas d’inspection BGP de Merit traite l’événement Cogent-Level 3 comme un exercice d’analyse de routes et examine l’accessibilité impliquant le 38.0.0.0/8 de Cogent depuis des pairs RouteViews sélectionnés. C’est une enquête bornée utile. Elle ne transforme pas un agrégat et un ensemble de points de vue sélectionnés en un inventaire complet des clients de Cogent, des clients de Level 3 ou des routes affectées mondialement.

Une reconstitution rigoureuse commence par séparer les ancres d’événement des observations de routes. Les déclarations des entreprises établissent que la relation directe a été délibérément terminée puis restaurée. Les données des collecteurs peuvent ensuite montrer comment des routes particulières sont apparues aux pairs entités avant, pendant et après ces changements. Les messages d’opérateurs contemporains, les traceroutes et les signalements de clients peuvent tester si les changements observés dans le plan de contrôle correspondaient à des défaillances de transfert ou d’application.

L’alignement des horodatages importe. Les flux de mises à jour BGP contiennent un bruit de routage ordinaire ainsi que des changements liés à l’incident. Les sessions se réinitialisent pour de nombreuses raisons; des préfixes peuvent être retirés et réannoncés indépendamment d’un différend de peering. Un enquêteur ne doit pas étiqueter chaque mise à jour proche du 5 octobre comme causée par le dépeering. L’inférence la plus solide provient de changements répétés impliquant des chemins pertinents, d’une synchronisation cohérente entre points de vue indépendants et de corroborations issues d’observations opérationnelles.

La diversité des collecteurs compte tout autant. Un pair RouteViews fournit les routes qu’il a sélectionnées et choisi d’exporter au collecteur. Il n’expose pas chaque route considérée, chaque route rejetée par politique ni chaque entrée de table de transfert à l’intérieur du réseau. Un collecteur RIS a la même contrainte de base. Ajouter des collecteurs augmente la visibilité, mais aucun ensemble fini ne produit une vue omnisciente de chaque interconnexion privée et de chaque routeur.

Les preuves de chemin AS exigent aussi de la retenue. Le chemin visible identifie les systèmes autonomes listés dans l’annonce sélectionnée. Il ne révèle pas les sauts internes des routeurs, l’utilisation des ports, les prix contractuels ni tout le trafic effectivement transmis par ce chemin. La préférence locale ne se propage généralement pas entre systèmes autonomes, de sorte qu’un observateur externe peut ne pas savoir pourquoi un chemin a gagné. Le peering privé peut rester absent des données publiques des collecteurs.

Un retrait est également ambigu sans contexte. Il peut signifier qu’une route n’est plus disponible pour le pair annonceur, que la politique d’export a changé, ou qu’une session a échoué. Il n’identifie pas à lui seul la décision commerciale derrière le changement. Dans ce cas, les déclarations des entreprises fournissent l’intention que les mises à jour brutes ne peuvent pas: l’interconnexion a pris fin délibérément.

Les traceroutes ajoutent des indices de transfert mais pas l’omniscience. Les routeurs peuvent supprimer des réponses, utiliser des adresses sans rapport avec le chemin apparent ou transmettre le trafic de manière asymétrique. Un traceroute qui s’arrête n’identifie pas toujours le point exact de défaillance. Un traceroute réussi depuis un emplacement n’établit pas l’accessibilité depuis tous les emplacements. Néanmoins, des traces répétées depuis des réseaux indépendants peuvent aider à distinguer un problème applicatif local d’une absence plus large de chemins interdomaines.

Les signalements de clients constituent une autre couche. Une entreprise incapable d’atteindre un site de l’autre côté de la coupure fournit une preuve de préjudice pratique. Mais le signalement seul peut ne pas identifier quel amont, quelle politique de route ou quel chemin de retour a causé la défaillance. Le récit le plus défendable aligne la plainte avec les préfixes source et destination, les horodatages, les observations BGP et, lorsqu’ils sont disponibles, les tests de chemins aller et retour.

Les preuves résultantes doivent être exprimées en niveaux de confiance. Une annonce directe d’entreprise peut établir que la relation a été terminée ou restaurée. Un collecteur peut établir qu’un pair entité a annoncé un chemin particulier à un moment particulier. Plusieurs observations indépendantes de routes et de transfert peuvent soutenir une inférence plus large. Aucune de ces éléments ne fournit à elle seule la liste complète des clients, le contrat privé ou l’impact mondial précis.

Les documents de la FCC ajoutent un contexte de marché plutôt qu’une preuve au niveau des paquets. Leur discussion de l’interconnexion des backbones et des effets de réseau aide à expliquer pourquoi les clients valorisent l’accès à des destinations hors de leur propre opérateur. Les références réglementaires ultérieures au différend Cogent-Level 3 montrent sa pertinence pour la politique d’interconnexion. Elles ne remplacent pas les preuves de routes et ne décident pas de la responsabilité juridique pour les pertes individuelles des clients.

Pourquoi ce n’était pas une fuite de route ni un détournement

Une fuite de route implique généralement la propagation d’informations de routage au-delà de la portée prévue par les relations pertinentes. Le problème résultant est souvent la présence ou la sélection d’un chemin non intentionnel. Un détournement implique généralement une origine non autorisée ou une autre fausse revendication de routage qui détourne ou intercepte le trafic. Les deux peuvent créer des défaillances d’accessibilité et de sécurité, mais leurs mécanismes diffèrent du dépeering délibéré.

L’événement Cogent-Level 3 concernait la suppression de l’échange direct de routes. Les déclarations publiques décrivent une décision d’interconnexion intentionnelle. La défaillance centrale était que certains chemins n’étaient plus disponibles, et non qu’un opérateur avait faussement originaire les préfixes de l’autre ou s’était accidentellement annoncé comme transit pour des routes qu’il n’aurait pas dû propager.

Cette différence change les contrôles appropriés. Le filtrage de préfixes et la validation d’origine peuvent réduire l’acceptation d’annonces non autorisées. Une politique d’export sensible aux relations peut réduire les fuites de routes. Ces mécanismes ne contraignent pas un opérateur à poursuivre une relation de peering valide. Un routeur parfaitement filtré peut encore n’avoir aucune route vers une destination après une terminaison de session délibérée.

Les données BGP brutes ne peuvent pas toujours révéler la distinction à elles seules. Un collecteur peut voir des retraits, des chemins de remplacement ou une perte de visibilité. L’intention ne devient claire que lorsque ces observations sont combinées aux explications publiques des entreprises. Qualifier l’épisode de fuite ou de détournement déformerait à la fois les preuves et la surface de contrôle.

La distinction protège aussi la comparaison historique du recul. Les taxonomies ultérieures des fuites de routes et les mécanismes de rôles relationnels aident les opérateurs d’aujourd’hui à exprimer et vérifier l’intention de routage. Ils ne prouvent pas que la terminaison de 2005 était une échappatoire accidentelle de politique, et ils ne créent pas d’obligations rétroactives régissant la décision commerciale des entreprises.

Positions commerciales et responsabilité opérationnelle

Les conditions confidentielles de peering importent pour tout différend contractuel, mais elles ne sont pas nécessaires pour identifier le problème de continuité client. Les deux entreprises ont publiquement divergé sur la question de savoir si la relation d’essai continuait de satisfaire à ses conditions. Sans l’accord complet et les mesures sous-jacentes, un récit extérieur ne peut déterminer quelle interprétation commerciale était correcte.

La responsabilité opérationnelle commence à un autre point. Une fois qu’un opérateur sait que terminer une interconnexion peut supprimer le seul chemin fonctionnel pour certains clients, la décision a des conséquences mesurables de continuité. Ces conséquences peuvent être examinées sans déclarer que l’opérateur n’avait pas de droit contractuel de terminer.

Cette séparation évite deux erreurs opposées. La première est de supposer que tout impact client prouve une faute. Les réseaux doivent conserver la capacité d’appliquer les accords, de protéger l’infrastructure et de mettre fin aux relations. Une norme de continuité qui imposerait en pratique un peering sans règlement perpétuel effacerait une autonomie opérationnelle et commerciale légitime.

La seconde erreur est de traiter un différend contractuel bilatéral comme n’ayant que des effets bilatéraux. Les clients n’étaient pas parties à la relation de peering, mais certains dépendaient des routes échangées par celle-ci. Si aucun des deux opérateurs n’avait cartographié cette dépendance, testé des alternatives ou établi une procédure de terminaison bornée, l’absence de ces contrôles resterait importante même si la terminaison était contractuellement permise.

La responsabilité n’est donc pas synonyme de blâme. C’est une discipline de preuve qui demande qui contrôlait chaque décision, ce que chaque partie pouvait raisonnablement observer, quelles protections existaient et si le résultat a été vérifié. La responsabilité juridique exige des faits supplémentaires et le droit applicable. Les archives publiques n’établissent pas ici de violation, de négligence, de mauvaise foi, de conduite monopolistique ni de violation réglementaire.

Les allégations de déséquilibre de trafic illustrent pourquoi l’attribution est essentielle. L’explication publique de Level 3 évoquait les conditions de l’arrangement d’essai, tandis que le communiqué conjoint ultérieur décrivait des caractéristiques de trafic, des obligations de volume et des paiements conditionnels. Ces déclarations montrent que des critères commerciaux liés au trafic faisaient partie du différend public et de la remédiation. Elles ne divulguent pas les ratios exacts, les seuils, les intervalles de mesure ni les prix.

Un collecteur de routes ne peut combler cette lacune. Les chemins AS montrent l’accessibilité annoncée, pas le volume de trafic. Même les compteurs d’interface nécessiteraient un contexte sur l’emplacement, la direction, l’agrégation et la mesure contractuelle. Inférer des seuils de peering confidentiels à partir de données BGP publiques confondrait le plan de contrôle du routage avec la comptabilité commerciale.

La conclusion appropriée est bornée: un différend commercial a conduit à la suppression délibérée de l’échange direct de routes; certains clients ont signalé une perte d’accessibilité; les parties ont publiquement avancé des explications différentes; elles ont ensuite restauré l’interconnexion selon des conditions révisées incluant des procédures de protection des clients. Les preuves ne tranchent pas les mérites contractuels non publiés.

Une carte de contrôle pour la défaillance

Level 3 contrôlait sa décision de mettre fin à la relation de peering directe et son côté des sessions BGP pertinentes. Il contrôlait aussi les routes qu’il acceptait et exportait, son escalade interne, sa communication avec les clients, et toute procédure de terminaison échelonnée ou immédiate qu’il utilisait. Ces domaines définissent sa responsabilité opérationnelle sans résoudre la question de savoir si la terminaison était commercialement justifiée.

Cogent contrôlait ses propres sessions, annonces de routes, politiques d’import et d’export, communications clients et offres de résilience. Sa déclaration du 7 octobre proposait une restauration immédiate avant toute négociation ultérieure, mais le plaidoyer public n’élimine pas ses propres responsabilités. Cogent était en position de comprendre quels clients dépendaient de ses relations amont et de peering, quelles alternatives il pouvait fournir, et quelles limites accompagnaient la connectivité qu’il vendait.

Les deux opérateurs partageaient le contrôle de la restauration bilatérale. Une partie pouvait proposer de rétablir une session, mais une interconnexion fonctionnelle exigeait une action compatible des deux côtés: sessions actives, routes acceptées, politique fonctionnelle et transfert opérationnel. L’annonce conjointe indique que la relation a été restaurée par accord plutôt que par une action de routage unilatérale.

D’autres opérateurs contrôlaient les chemins alternatifs potentiels. Leurs politiques déterminaient s’ils transporteraient des routes entre les deux côtés et sous quelle relation commerciale. Ils contrôlaient aussi la capacité, le filtrage et la communication d’incident dans leurs propres réseaux. Leur présence dans la topologie ne garantissait pas qu’ils fourniraient un chemin acceptable.

Les clients contrôlaient certains choix de résilience, notamment l’achat de connexions diverses, l’exploitation de BGP, la distribution des services entre réseaux ou la surveillance de l’accessibilité externe. Ce contrôle était contraint par le coût, la capacité technique, les ressources d’adressage, la disponibilité des contrats et le temps de provisionnement. Il serait inexact de traiter chaque client affecté comme capable d’un multihoming instantané.

Les registres contrôlaient les enregistrements concernant les numéros de systèmes autonomes et les ressources d’adressage. Ces enregistrements soutenaient l’identité et l’administration du routage, mais ils n’imposaient pas un chemin fonctionnel entre AS174 et AS3356. Une entrée de registre correcte pouvait aider un opérateur à savoir qui originait un préfixe ou qui contacter. Elle ne pouvait pas restaurer une relation BGP terminée.

Les opérateurs de collecteurs de routes contrôlaient l’infrastructure de mesure, pas les chemins de production. Leurs archives rendent l’analyse ultérieure possible, mais un collecteur ne peut pas amener un opérateur à accepter une route. La mesure est un registre de responsabilité: elle enregistre une partie de ce que les réseaux entités exposaient. Elle ne remplace pas la continuité opérationnelle.

Les régulateurs pouvaient examiner la structure du marché et exercer des pouvoirs conférés par la loi, mais ils n’exploitaient pas les routeurs. Les documents de la FCC fournissent un contexte sur les incitations à l’interconnexion et les effets de réseau. Ils n’établissent pas que l’agence a ordonné la restauration de 2005 ni qu’elle a jugé l’une ou l’autre entreprise juridiquement fautive.

Cette carte empêche la responsabilité de s’effondrer sur un acteur commode. La décision de terminaison, le différend commercial, l’inventaire des chemins alternatifs, la résilience des clients et la restauration étaient contrôlés par différentes parties. Une responsabilité efficace enregistre ces divisions au lieu de supposer que le rôle d’un acteur annule tous les autres.

L’accord du 28 octobre comme conception de remédiation

L’annonce conjointe du 28 octobre importe parce qu’elle allait au-delà des déclarations publiques concurrentes. Cogent et Level 3 ont déclaré avoir conclu un arrangement de peering sans règlement modifié. Le communiqué décrivait des obligations liées aux caractéristiques et au volume du trafic, des paiements lorsque les obligations n’étaient pas satisfaites, et un processus visant à protéger la connectivité des clients si la relation expirait ou si des violations restaient non résolues.

Ces éléments répondent à plusieurs pressions de défaillance distinctes. Des obligations de trafic mesurables peuvent rendre les critères commerciaux moins ambigus entre les parties. Des paiements conditionnels peuvent fournir une alternative à la terminaison immédiate lorsque le service opérationnel continue malgré un déséquilibre commercial. Une procédure définie d’expiration ou de violation non corrigée peut créer du temps pour notifier les clients et organiser des chemins alternatifs.

La description publique ne montre pas exactement comment ces mécanismes fonctionnaient. Elle ne révèle pas les seuils, formules, délais, responsables d’escalade ni les preuves requises pour établir la conformité. Elle ne prouve pas non plus que le paiement conditionnel était disponible en toutes circonstances. Toute description plus forte reconstruirait des conditions privées jamais publiées.

La disposition de protection des clients est néanmoins significative. Son inclusion indique que les parties traitaient l’impact sur la connectivité comme quelque chose qu’un accord d’interconnexion pouvait traiter procéduralement. Cela diffère d’une garantie de continuité mondiale ininterrompue. Une procédure peut réduire le risque tout en échouant face à des conditions imprévues, une capacité inadéquate ou une mise en œuvre incomplète.

La restauration exige aussi plus que la signature de conditions ou le retour d’une session BGP à un état établi. Les routes doivent être échangées, acceptées et sélectionnées. Le transfert doit fonctionner dans les deux sens. Les chemins alternatifs devenus actifs pendant l’interruption peuvent devoir reconverger sans causer de nouvelle instabilité. Les points d’extrémité clients doivent devenir accessibles depuis les réseaux pertinents.

L’annonce publique établit l’arrangement restauré, mais elle ne fournit pas un enregistrement complet de restauration par client. Un récit borné doit donc dire que les entreprises ont restauré l’interconnexion directe selon des conditions révisées, et non que chaque application affectée s’est rétablie simultanément ni que toutes les conséquences ont pris fin à un moment universel.

Les orientations ultérieures comme comparaison, pas comme loi rétroactive

La RFC 4271 formalise le cadre d’échange de routes et de décision BGP-4. Elle a été publiée après le différend d’octobre 2005, bien qu’elle documente la famille de protocoles déjà en exploitation sur Internet. Elle aide à expliquer comment les routes sont annoncées, retirées et sélectionnées. Elle n’impose pas d’obligation commerciale à deux systèmes autonomes de maintenir un peering sans règlement.

La RFC 7454, publiée bien plus tard, rassemble des pratiques de sécurité opérationnelle pour les sessions BGP. Elle traite du filtrage, de la protection des sessions, des limites de préfixes et des contrôles de politique. Ces pratiques sont utiles pour évaluer comment un opérateur peut rendre le comportement d’interconnexion plus prévisible et observable. Elles ne décident pas si l’une ou l’autre entreprise a satisfait aux normes raisonnablement applicables en 2005, et elles ne garantissent pas la continuité après un arrêt intentionnel de session.

La RFC 8212 établit une politique d’import et d’export explicite comme valeur par défaut plus sûre pour BGP externe. Cette approche réduit la propagation accidentelle causée par une politique manquante. L’événement Cogent-Level 3 n’était pas un exemple de routes exportées accidentellement parce qu’une configuration vide avait par défaut un comportement permissif. Une politique explicite pourrait documenter l’intention, mais elle permettrait toujours une décision délibérée de n’échanger aucune route.

La RFC 7908 classe les fuites de routes. Sa taxonomie aide à distinguer la propagation non intentionnelle des relations légitimes client-pair-transit. L’événement de 2005 se situe hors du mode de défaillance central de cette taxonomie parce que les preuves concernent un dépeering délibéré. Appliquer soigneusement la terminologie évite qu’un chemin manquant soit étiqueté à tort comme un chemin excessif ou non autorisé.

La RFC 9234 a introduit plus tard les rôles BGP et des mécanismes d’expression de l’intention relationnelle entre systèmes autonomes voisins. Une meilleure expression des rôles peut aider à identifier des configurations incompatibles et à contraindre la propagation des routes. Elle ne peut pas encoder chaque condition commerciale privée et n’oblige pas deux réseaux à rester interconnectés après la fin d’une relation.

La RFC 1997 est historiquement différente parce que les communautés BGP étaient déjà standardisées avant le différend. Les communautés pouvaient aider les réseaux à signaler des préférences de traitement des routes. Leur disponibilité ne prouve pas comment AS174 ou AS3356 les utilisaient en octobre 2005. Elle ne transforme pas non plus une valeur de communauté observée à un collecteur en un énoncé complet d’intention contractuelle.

Les orientations MANRS ont articulé plus tard des actions d’opérateurs concernant le filtrage, la coordination, la validation globale et l’anti-usurpation. Les orientations ultérieures du NIST sur le routage interdomaine soulignent de même une configuration résiliente, une surveillance et une réponse aux incidents. Ces documents fournissent des points de comparaison contemporains utiles: les opérateurs peuvent maintenir des coordonnées, observer les changements de routes, valider les politiques et préparer des procédures de réponse.

Aucun n’est une loi rétroactive. Aucun ne fournit le contrat manquant de 2005, les mesures de trafic ou les enregistrements d’escalade internes. Aucun ne prouve une négligence simplement parce que la conduite historique d’un opérateur diffère d’une recommandation ultérieure. Leur usage approprié est prospectif: ils aident à traduire l’épisode en contrôles que les réseaux actuels peuvent mesurer.

La validation d’origine moderne basée sur RPKI mérite la même prudence. Elle peut aider un réseau à rejeter une annonce d’origine invalide. Elle n’établit pas si un pair devrait transporter une route valide, si la capacité existe ou si une relation commerciale doit se poursuivre. Une route peut être cryptographiquement cohérente avec une origine autorisée et rester inaccessible parce qu’aucun chemin acceptable ne franchit la frontière du réseau concerné.

La leçon ultérieure la plus transférable n’est donc pas qu’un mécanisme de sécurité aurait résolu le différend. C’est que l’intention relationnelle, la politique de route, la surveillance, la coordination et la planification de continuité doivent être connectées. Un réseau doit savoir ce qu’il entend échanger, ce qu’il échange réellement, quels clients dépendent de cet état et comment il vérifiera une sortie contrôlée.

Une norme mesurable de terminaison et de restauration

Une norme de responsabilité utile doit rester neutre quant au résultat commercial. Elle ne doit pas exiger un peering indéfini, dicter des conditions de règlement ni présumer qu’un entité a droit à un transit gratuit. Elle doit exiger des opérateurs qu’ils rendent observables et bornées les conséquences de continuité d’une terminaison planifiée.

La première mesure est la couverture de dépendance. Avant de mettre fin à une interconnexion lourde de conséquences, chaque opérateur devrait identifier les préfixes clients, groupes de destinations ou classes de service pour lesquels la relation directe est le seul chemin vérifié. Le résultat mesurable n’est pas une prétention à connaître tout Internet. C’est la proportion de l’inventaire client pertinent de l’opérateur pour laquelle la dépendance a été évaluée et horodatée.

Un enregistrement de dépendance doit distinguer l’observation directe de l’inférence. Une route vue par l’interconnexion n’en dépend pas nécessairement si un autre chemin acceptable existe. Un chemin alternatif montré dans une topologie n’est pas vérifié si l’opérateur n’a jamais testé s’il est exporté, accepté et utilisable. L’enregistrement doit donc indiquer les points de vue, politiques de route et tests de transfert soutenant chaque classification.

La deuxième mesure est la vérification des chemins alternatifs. Pour chaque groupe de dépendance, l’opérateur devrait enregistrer si au moins une route alternative testée existe, si les chemins aller et retour fonctionnent, et si le chemin a une capacité opérationnelle suffisante pour le service prévu. La métrique pertinente est la couverture vérifiée: les unités accessibles testées divisées par toutes les unités censées avoir besoin d’une alternative.

Ce ratio doit porter une information de portée. Un résultat élevé mesuré uniquement depuis les routeurs de l’opérateur n’établit pas l’accessibilité externe. Les tests devraient inclure des réseaux indépendants représentant des chemins matériellement différents. La norme n’a pas à prescrire un nombre universel de points de vue; elle devrait exiger de l’opérateur qu’il déclare pourquoi son ensemble choisi représente les clients et régions à risque.

La troisième mesure est la préparation des politiques. L’opérateur devrait préserver la politique d’import et d’export prévue avant, pendant et après la terminaison, avec le propriétaire responsable et l’heure d’activation. Cette preuve permet de distinguer un retrait planifié d’une fuite accidentelle, d’une erreur de configuration ou d’une défaillance de session sans rapport.

La préparation des politiques inclut aussi une simulation ou un test contrôlé lorsque cela est faisable. Un opérateur peut réduire la préférence pour la route directe ou tester des préfixes clients sélectionnés par des alternatives avant de mettre fin à la relation. Un tel test peut ne pas être possible dans toutes les architectures et peut lui-même créer un risque. L’exigence responsable est de documenter s’il a été effectué, ce qu’il couvrait et pourquoi toute dépendance non testée a été acceptée.

La quatrième mesure est la préparation de capacité. Un chemin BGP alternatif n’est pas un contrôle de continuité s’il s’effondre sous un trafic redirigé ordinaire. Les opérateurs devraient enregistrer la capacité testée des alternatives pertinentes, les classes de trafic incluses et l’heure du test. Cela n’exige pas de publier des volumes confidentiels. Cela exige des preuves internes suffisantes pour établir que le contournement de l’interconnexion était plus qu’une possibilité théorique.

La cinquième mesure est la notification et l’escalade. Un plan de terminaison devrait identifier le propriétaire de la décision, le propriétaire des opérations réseau, le propriétaire de la communication client et le contact de la contrepartie. Il devrait enregistrer quand chacun a été notifié et quand les clients des groupes de dépendance identifiés ont reçu une information actionnable.

Une notification actionnable doit expliquer le risque opérationnel plutôt que simplement décrire un différend commercial. Un client doit savoir quels services peuvent perdre l’accessibilité, quelle connectivité alternative est disponible, quels tests effectuer et où signaler une défaillance. La métrique est la couverture et le temps écoulé: combien de clients dépendants identifiés ont reçu une notification, et combien de temps avant ou après le changement de routage cette notification a eu lieu.

La norme devrait permettre une exception d’urgence. Des incidents de sécurité, des défaillances non contrôlées ou des risques contractuels immédiats peuvent rendre une notification préalable impossible. Une exception ne devrait pas effacer les preuves. Elle devrait enregistrer la raison de l’action immédiate, la personne l’autorisant, les protections envisagées et le moment le plus précoce auquel les clients et la contrepartie ont été informés.

La sixième mesure est l’observabilité des événements. À la terminaison, les deux opérateurs devraient préserver l’état des sessions, le nombre de routes, les annonces et retraits pertinents, les changements de chemins acceptés et les résultats des tests de transfert. Une seule entrée « session hors service » est insuffisante parce que l’effet client dépend des routes et chemins qui disparaissent avec elle.

L’observabilité devrait produire une matrice d’accessibilité plutôt qu’un pourcentage mondial unique. Les lignes peuvent représenter les réseaux sources testés ou les cohortes de clients; les colonnes peuvent représenter les préfixes ou services de destination pertinents. Chaque cellule peut enregistrer accessible, inaccessible, dégradé ou non vérifié, avec un horodatage et un point de vue. Cela expose l’incertitude au lieu de convertir l’espace non mesuré en succès présumé.

La septième mesure est la performance de détection. Un opérateur devrait savoir combien de temps la surveillance a mis pour identifier la perte d’accessibilité après le changement de routage. L’horloge ne devrait pas s’arrêter lorsque la session BGP change d’état. Elle devrait s’arrêter lorsque le système identifie la conséquence côté client avec une spécificité suffisante pour agir.

La détection devrait séparer les signaux du plan de contrôle et du plan de données. Un retrait de route peut prédire un préjudice, tandis que des sondes actives établissent si les paquets transitent encore par un chemin alternatif. Les vérifications applicatives peuvent montrer si un service fonctionne après la convergence du routage. Garder ces mesures séparées empêche qu’une entrée de table de route soit confondue avec un service client terminé.

La huitième mesure est la communication d’incident. Pendant l’interruption, les déclarations de statut devraient distinguer les faits vérifiés des hypothèses et des positions commerciales attribuées. Un opérateur devrait rapporter ce qui a changé, quelle portée il a mesurée, ce qui reste inconnu et quand il fournira une autre mise à jour. Des déclarations telles que « Internet reste disponible » sont inadéquates si elles masquent des partitions connues entre groupes de clients.

La neuvième mesure est la restauration bornée. La restauration commence lorsque les parties prennent une action corrective, mais elle n’est pas complète simplement parce qu’une session revient à un état établi. Un opérateur devrait vérifier que les préfixes attendus sont échangés, que les politiques les acceptent, que les chemins sélectionnés sont stables et que le transfert réussit depuis des réseaux externes représentatifs.

Un enregistrement de restauration devrait préserver des horodatages séparés pour l’établissement de session, l’acceptation des routes, les premiers tests réussis du plan de données, la récupération de chaque cohorte de clients et la clôture des plaintes en suspens. Ces horodatages empêchent qu’un événement techniquement commode — comme le premier keepalive BGP — soit présenté comme la fin universelle du préjudice client.

La dixième mesure est la réconciliation de l’état des routes. Les chemins utilisés pendant l’interruption peuvent rester préférés après le retour du peering direct, ou le trafic peut osciller pendant que les politiques reconvergent. Les opérateurs devraient comparer l’état post-restauration prévu avec les routes observées et enquêter sur les différences matérielles. L’objectif n’est pas de forcer chaque route à revenir à son chemin antérieur; c’est de s’assurer que l’état résultant est compris et utilisable.

La onzième mesure est l’exposition non vérifiée. Chaque enregistrement de terminaison devrait indiquer combien de préfixes, groupes de clients ou régions externes dans le périmètre n’ont pas été testés. La couverture inconnue est un fait de responsabilité, pas un champ vide. La rapporter empêche qu’un échantillon de succès limité devienne une affirmation non étayée de récupération universelle.

La douzième mesure est la conservation des preuves. Les observations de routes, changements de configuration, notifications, messages d’incident et tests de restauration devraient être conservés selon une chronologie cohérente. Les collecteurs publics restent des références indépendantes précieuses, mais les preuves propres des opérateurs devraient être plus complètes parce qu’ils peuvent voir la préférence locale, les routes rejetées, la topologie interne et l’association des clients.

Ces mesures peuvent être résumées en une chaîne de continuité:

Identifier qui dépend de l’interconnexion.
Vérifier quels chemins alternatifs fonctionnent réellement.
Enregistrer la politique, la capacité et la propriété de décision.
Notifier la contrepartie et les clients affectés selon une procédure déclarée.
Observer à la fois l’état des routes et la livraison des paquets pendant le changement.
Mesurer le préjudice par cohortes bornées et points de vue indépendants.
Restaurer les sessions, les routes acceptées et le transfert.
Réconcilier l’état résultant et préserver l’incertitude non résolue.

Aucune preuve publique ne montre que cette chaîne complète existait pour l’un ou l’autre opérateur en 2005. La norme ne doit pas être présentée comme une obligation historique que les entreprises auraient nécessairement violée. C’est une manière de convertir les pressions de défaillance démontrées de l’événement en pratique actuelle mesurable.

Elle évite aussi d’imposer une garantie impossible. Aucun opérateur ne peut prouver l’accessibilité depuis chaque réseau vers chaque point d’extrémité à chaque instant. Ce qu’un opérateur peut prouver, c’est la portée qu’il a évaluée, les alternatives qu’il a testées, les observations qu’il a conservées, les clients qu’il a avertis et les conditions dans lesquelles il a déclaré la restauration.

Ce que les archives publiques ne peuvent toujours pas établir

Le contrat de peering complet reste indisponible. Les déclarations publiques ne révèlent pas tous les ratios de trafic, fenêtres de mesure, capacités de port, prix, délais de correction ni droits de terminaison. Sans ces faits, un récit extérieur ne peut déterminer si l’une ou l’autre entreprise a satisfait ou violé ses obligations privées.

L’état de routage complet est également inconnu. RouteViews, RIPE RIS et Merit fournissent des observations précieuses, mais ils n’exposent pas chaque pair privé, préférence locale, route rejetée ou décision de transfert. Les données publiques survivantes ne peuvent pas identifier chaque préfixe ou client affecté.

Le préjudice client ne peut pas être quantifié précisément à partir de l’enregistrement figé. Les reportages contemporains soutiennent la conclusion que certaines entreprises et certains utilisateurs ont connu des pannes d’accessibilité. Ils n’établissent pas le revenu total perdu, la durée pour chaque client, les conséquences au niveau applicatif sur tous les services ni des effets égaux sur les deux réseaux.

La propriété de décision interne n’est pas publique. Level 3 contrôlait son action de terminaison, mais les documents disponibles n’identifient pas chaque approbateur exécutif ou opérationnel, la séquence d’escalade ni les tests internes effectués avant le changement. Le processus de réponse interne de Cogent et son évaluation de résilience sont également incomplets.

L’accord révisé est une preuve de conception de remédiation, pas une preuve complète de mise en œuvre. Sa description publique indique des obligations de trafic, des paiements conditionnels et un processus de protection des clients. Elle ne montre pas comment chaque contrôle a été testé par la suite ni s’il aurait traité chaque scénario de défaillance futur.

L’attribution juridique n’est pas résolue ici. Les discussions ultérieures de la FCC fournissent un contexte réglementaire, mais les documents cités n’établissent pas de constat d’illégalité, de violation contractuelle, de négligence ou de mauvaise foi dans cet événement. Le contrôle opérationnel et la responsabilité mesurable peuvent être analysés sans les convertir en conclusions juridiques.

La continuité se prouve par des routes qui fonctionnent

Le dépeering Cogent-Level 3 de 2005 reste instructif car il a écarté l’hypothèse selon laquelle le statut de grand réseau garantit une accessibilité universelle. AS174 et AS3356 sont chacun restés des réseaux identifiables avec des ressources enregistrées, des clients et des connexions ailleurs. Pourtant, certains chemins traversant leur ancienne relation ont cessé de fonctionner, et certains clients n’ont, selon les témoignages, pas pu contourner la coupure.

Le fait central de l’événement n’était pas simplement que deux entreprises étaient en désaccord. C’était qu’une décision commerciale bilatérale a modifié la disponibilité des routes interdomaines. Les retraits BGP, la propagation alternative, les politiques d’import et d’export, le multihoming et la restauration ont déterminé le résultat pratique.

Les preuves publiques soutiennent une conclusion prudente. Level 3 a délibérément mis fin au peering direct le 5 octobre. Cogent a publiquement cherché une restauration avant toute négociation ultérieure. Level 3 a déclaré que l’arrangement d’essai ne satisfaisait plus à ses conditions. Une partie de l’accessibilité client a été perturbée, bien que la portée complète soit inconnue. Le 28 octobre, les entreprises ont annoncé un peering sans règlement restauré selon des conditions révisées incluant un processus visant à protéger les clients lors d’une expiration future ou d’une violation non résolue.

Rien dans cette conclusion n’exige de trancher les mérites contractuels privés. Elle n’exige pas non plus le peering obligatoire. Elle exige de reconnaître que le contrôle autonome porte un devoir probatoire lorsque son exercice peut isoler des clients dépendants.

Un registre peut enregistrer qui détient un bloc d’adresses. Un contrat peut enregistrer des obligations commerciales. Une déclaration de statut peut enregistrer la position d’une partie. L’accessibilité totale à Internet se prouve ailleurs: dans des routes réellement annoncées, acceptées, sélectionnées et transmises, avec des alternatives observables lorsqu’une relation directe prend fin.

C’est le test de responsabilité durable. Avant de terminer une interconnexion lourde de conséquences, sachez quels clients en dépendent. Pendant le changement, mesurez ce qui disparaît au lieu de supposer que le reste d’Internet contournera la coupure. Après la restauration, vérifiez les chemins clients au lieu de s’arrêter à la signature du contrat ou à l’état de la session BGP. L’enregistrement n’est utile que s’il correspond à un chemin en service.

Le dépeering Cogent-Level 3 de 2005 a fait de l’accessibilité totale à Internet un test de responsabilité de transit