Expérience BGP RIPE-Duke 2010: conformité et responsabilité

Résumé

Un attribut BGP transitif optionnel valide a été corrompu lorsque des systèmes IOS XR affectés l’ont propagé, provoquant des réinitialisations de session en aval et une instabilité de routage plus large.
La responsabilité se répartit entre plusieurs points de contrôle: périmètre et surveillance de l’expérience, comportement et correction du produit, contrôles de continuité des opérateurs et gestion des erreurs du protocole.

Le 27 août 2010, le personnel du RIPE NCC chargé du Routing Information Service (RIS) a collaboré avec un groupe de recherche de l’université Duke sur une expérience BGP en direct. Les chercheurs étudiaient une conception de routage sécurisé transportant des informations de certification dans un attribut de chemin transitif optionnel. À 08 h 41 UTC, RIPE NCC a annoncé 93.175.144.0/24 depuis RIS AS12654 via ses connexions à AMS-IX et GN-IX. La route a été retirée comme prévu à 09 h 08 UTC.[1]

L’annonce était inhabituelle parce que l’attribut était nouveau sur l’Internet public. Inhabituel ne signifiait toutefois pas malformé. RIPE NCC et Cisco ont décrit l’attribut initial comme valide ou conforme aux normes.[1][2] Cette distinction détermine l’analyse de l’événement. L’expérience n’a pas simplement montré que les routeurs rejettent les entrées invalides. Elle a montré qu’une entrée conforme aux normes pouvait passer les contrôles formels, rencontrer un défaut dans un logiciel déployé, être corrompue pendant la propagation, puis déclencher un traitement d’erreur sévère ailleurs.

Cisco a signalé que les systèmes IOS XR affectés traitaient mal l’attribut transitif valide mais non reconnu lors de sa transmission. Un routeur voisin pouvait recevoir l’UPDATE corrompu qui en résultait et réinitialiser la session d’appairage BGP. Comme une session BGP transporte de nombreuses routes, la réponse à un UPDATE défectueux pouvait temporairement supprimer des informations de joignabilité valides sans rapport. Si le routeur responsable de la corruption sortante ne détectait pas sa propre erreur, il pouvait réannoncer l’information problématique après le retour de la session, renouvelant ainsi l’instabilité.[2][3]

Les mesures de RIPE NCC étayent une conclusion d’impact limité mais matériel. L’événement a produit des taux de mise à jour jusqu’à vingt fois supérieurs au niveau de référence environnant. RIPE a estimé que 0,5 % de préfixes supplémentaires sont devenus totalement inaccessibles plus longtemps que la normale. La proportion de préfixes instables a culminé à 1,4 %, représentant près de 4 500 préfixes et environ neuf fois le niveau habituel observé autour de l’événement. Les résultats variaient selon le collecteur et l’emplacement, avec une activité de mise à jour particulièrement intense au collecteur de Vienne.[1]

Ces chiffres sont significatifs, mais ils n’autorisent pas à affirmer qu’un pourcentage connu d’utilisateurs, de routeurs, de réseaux ou de trafic a disparu. Les observations du plan de contrôle mesurent le comportement de routage, pas les personnes. L’analyse DNSMON de RIPE n’a constaté aucune défaillance des serveurs racine.

Elle a relevé une perte de requêtes limitée pour certains domaines surveillés et des problèmes plus visibles sur des portions des infrastructures faisant autorité.si et.fr, tandis que des serveurs redondants continuaient de répondre.[1] Les commentaires d’opérateurs de l’époque mentionnaient des problèmes d’accès et des changements de trafic d’échange, mais ces signalements ne constituent pas un bilan quantitatif complet.[4][6]

La leçon de responsabilité est donc plus étroite et plus utile qu’un récit où un acteur « casse l’Internet ». RIPE NCC contrôlait l’origine d’une route expérimentale visible sur Internet par son infrastructure de mesure, ainsi que le calendrier, la notification, la surveillance et le retrait. Les chercheurs de Duke contrôlaient la conception de la recherche et l’implémentation côté recherche. Cisco contrôlait la gestion par IOS XR d’un attribut valide non reconnu, ses tests produits, la divulgation et les correctifs de maintenance.

Les opérateurs réseau contrôlaient leurs logiciels installés, leurs politiques de routage, leurs protections d’appairage, leur surveillance et leur restauration au sein de leurs propres réseaux. Les règles protocolaires de l’époque fournissaient un mécanisme d’amplification en permettant à un UPDATE malformé de provoquer une défaillance au niveau de la session.

Les réparations relevaient également de couches distinctes.

Cisco a publié un avis le jour même et préparé des mises à niveau de maintenance.[2] RIPE NCC a préservé les preuves, fourni des informations au fournisseur, publié une analyse et s’est engagé à des contrôles plus stricts pour les futures expériences coopératives.[1] Son conseil d’administration a ensuite soutenu la poursuite de la recherche tout en insistant sur une communication appropriée.[5] La correction du produit a réduit le risque d’implémentation; une gouvernance d’expérience plus solide a réduit le risque de découvrir une interaction inconnue dans un domaine de défaillance public inutilement large.

Les normes ultérieures aident à expliquer comment le secteur a tiré les leçons de cette catégorie de défaillance, mais elles ne peuvent pas servir de preuve de ce qui était déployé ou requis en août 2010.

La RFC 7606 a ensuite préconisé un traitement plus restreint des UPDATE BGP malformés, car la réinitialisation d’une session entière peut écarter de nombreuses routes valides.[13] Les recommandations opérationnelles concernant une politique externe explicite, la prévention des fuites de routes, la validation d’origine, RPKI et BGPsec éclairent des contrôles adjacents, mais aucune n’établit rétroactivement une négligence et aucune ne corrige à elle seule le défaut précis de corruption sortante exposé par cet événement.[14][15][16][17][18][19][20]

La conclusion centrale est mesurée: une annonce expérimentale valide a déclenché une chaîne dans laquelle un défaut d’implémentation a corrompu l’information, le traitement d’erreur au niveau de la session a amplifié cette corruption, et des contrôles d’expérience en direct insuffisamment bornés ont exposé l’interaction sur l’Internet public. La responsabilité suit l’attribution du contrôle, pas la simplicité du premier déclencheur visible.

1. Pourquoi cet événement exige une analyse étroite

Les incidents BGP sont souvent réduits à des étiquettes comme fuite, détournement, panne ou mauvaise configuration. Ces étiquettes peuvent être utiles lorsque les preuves correspondent, mais elles peuvent aussi effacer le mécanisme qui compte vraiment. Cet événement exige une frontière plus précise.

Le sujet se limite à l’expérience RIPE NCC–Duke University du 27 août 2010. Il ne s’agit pas d’un récit des fuites de routes ultérieures, des détournements ultérieurs ni de toutes les défaillances BGP suivantes. La taxonomie ultérieure des fuites de routes de la RFC 7908 est utile pour distinguer les catégories, mais elle ne justifie pas de requalifier cette expérience en fuite de route classique sans preuve que les conditions de fuite spécifiées se sont produites.[16]

L’expérience a annoncé une route délibérément construite portant un nouvel attribut transitif optionnel. Sa visibilité publique était intentionnelle. L’instabilité qui en a résulté ne l’était pas. Cette combinaison soulève trois questions qu’il ne faut pas réduire à une seule:

L’UPDATE BGP initial était-il valide?
Quel composant a transformé une information valide en information corrompue?
Quels contrôles ont permis à la défaillance résultante de se propager au-delà d’un test étroitement borné?

Les archives disponibles répondent aux deux premières questions avec une confiance relativement élevée. RIPE NCC et Cisco ont tous deux qualifié l’attribut initial de valide ou conforme aux normes, tandis que Cisco a identifié une vulnérabilité IOS XR impliquant une corruption pendant la propagation.[1][2] NVD enregistre le problème produit sous CVE-2010-3035.[3]

La troisième question est répartie. Les chercheurs ne contrôlaient pas chaque routeur déployé. Cisco n’a pas décidé que RIS annoncerait la route expérimentale. Les opérateurs individuels n’ont pas conçu l’expérience ni l’implémentation affectée. Les connexions des points d’échange Internet ne prouvaient pas, par leur seule présence, l’approbation de chaque attribut transporté. L’attribution doit donc suivre les points de contrôle réels.

Cet événement compte parce qu’il brise une hypothèse facile mais dangereuse: la conformité aux normes à l’origine suffit à établir la sécurité opérationnelle dans un système de routage hétérogène. La conformité est nécessaire, mais le comportement déployé décide si un paquet ou un UPDATE survit au contact du code en cours d’exécution. L’expérience a franchi un type de frontière de validité et échoué à une autre.

RIS existe précisément pour collecter et exposer l’information de routage depuis plusieurs points d’observation.[7][8] RIPEstat et les enregistrements de la base RIPE fournissent un contexte d’identification pour AS12654, mais un enregistrement de système autonome ne peut pas révéler tous les comportements logiciels rencontrés le long d’un chemin propagé.[9][10] Les systèmes de collecteurs de routes comme RIS et Route Views sont précieux parce qu’aucun enregistrement de registre, déclaration d’appairage ou journal local ne peut décrire l’ensemble du système de routage interdomaine.[11]

La leçon n’est pas que les normes sont inutiles. C’est qu’une norme décrit le comportement requis, tandis que la responsabilité exige la preuve que les implémentations, les déploiements et les contrôles opérationnels produisent ce comportement dans des conditions réelles.

2. Chronologie: d’une annonce planifiée à une perturbation non intentionnelle

Avant 08 h 41 UTC: conception et vérifications préalables

Le groupe de recherche de Duke étudiait une conception de routage sécurisé dans laquelle des informations de certification circuleraient dans un attribut de chemin BGP transitif optionnel. Duke a fourni une implémentation Quagga modifiée dans le cadre de l’effort de recherche. Les vérifications préalables ont établi que l’attribut avait une forme protocolaire acceptable et qu’une seconde instance Quagga ne reproduisait pas le comportement observé plus tard sur des équipements déployés affectés.[1]

Ce résultat était informatif mais incomplet. Il montrait que l’implémentation initiale et un environnement de réception similaire pouvaient traiter l’attribut. Il ne montrait pas que chaque famille de routeurs, version logicielle ou chemin de transfert sur l’Internet public préserverait correctement l’attribut.

C’était la lacune de détection critique. Le chemin de test évaluait la structure formelle et un comportement d’implémentation limité. Il ne reproduisait pas le parc installé hétérogène que pouvait traverser un attribut transitif. Surtout, il n’exposait pas un défaut par lequel un routeur acceptait un attribut inconnu valide mais le corrompait en le transmettant.

Les archives publiques n’établissent pas le dossier complet d’approbation, tous les risques envisagés ni tous les contrôles discutés avant l’événement. Il serait donc inapproprié d’inventer un processus décisionnel non documenté. On peut affirmer que les contrôles utilisés avant l’annonce n’ont pas détecté l’interaction qui a produit la perturbation publique.

08 h 41 UTC: la route devient visible

À 08 h 41 UTC le 27 août 2010, RIS AS12654 a commencé à annoncer 93.175.144.0/24 avec l’attribut transitif optionnel expérimental. L’annonce a transité par les connexions de RIPE NCC à AMS-IX et GN-IX.[1]

Ce moment a été l’événement déclencheur. « Déclencheur » n’est toutefois pas synonyme de « cause racine ». Un déclencheur est l’événement qui active une condition latente. Si une entrée valide rencontre une implémentation défectueuse, l’entrée valide déclenche la séquence observée, mais le défaut explique pourquoi la séquence s’écarte du comportement spécifié.

La visibilité publique de la route a également créé l’exposition liée à la gouvernance de l’expérience. Un test sur un système fermé ou étroitement borné peut révéler un défaut sans lui permettre de traverser un large ensemble de réseaux autonomes. Dès que la route est entrée dans la propagation interdomaine ordinaire, le résultat a dépendu de logiciels et de politiques hors du contrôle direct des parties initiatrices.

Pendant la propagation: une information valide est corrompue

Les systèmes IOS XR affectés ont reçu un attribut qu’ils ne reconnaissaient pas. Selon la conception transitive optionnelle de BGP, l’absence de reconnaissance ne justifiait pas en soi le rejet de l’attribut. Le comportement pertinent était de le préserver et de le propager.

Le compte rendu de Cisco a identifié une défaillance dans ce chemin de propagation: les systèmes affectés corrompaient l’attribut par ailleurs valide lors de son envoi à un voisin.[2] Les preuves disponibles ne justifient pas d’inventer la mutation précise au niveau des octets pour chaque chemin affecté. La conclusion fiable est fonctionnelle: une information valide non familière est entrée dans une implémentation affectée, et une information corrompue en est ressortie lors de la propagation.

Cette distinction situe le défaut produit plus précisément que de dire que le routeur « ne prenait simplement pas en charge » la fonctionnalité expérimentale. La transitivité optionnelle existe pour qu’un routeur puisse transporter un attribut sans en comprendre la sémantique complète. Une implémentation conforme n’a pas besoin d’agir sur l’information de certification. Elle doit en revanche préserver correctement l’attribut si elle le propage.

La corruption a ensuite franchi une frontière d’implémentation. Un voisin en aval a reçu un UPDATE qui n’était plus équivalent à l’UPDATE valide émis par l’expérience.

Réception en aval: un UPDATE menace toute une session

Selon les règles de gestion d’erreur associées au référentiel normatif de l’époque, un attribut de chemin malformé pouvait produire une erreur de message UPDATE et la fermeture de la session BGP.[12] Cette réponse était sévère par conception: un routeur incapable d’interpréter en toute sécurité l’information de routage se protégeait en mettant fin à la session.

L’effet secondaire opérationnel était large. Une session BGP transporte ordinairement de nombreuses routes, pas seulement le préfixe expérimental. Fermer la session pouvait donc retirer des routes valides sans rapport apprises de cet homologue. Les réseaux cherchaient alors des alternatives, échangeaient de nouveaux UPDATE et reconvergeaient.

Un mécanisme de répétition supplémentaire était possible. Le routeur qui corrompait l’attribut sortant ne s’identifiait pas nécessairement comme la source de la corruption. Après le rétablissement d’une session voisine, la même route pouvait être réannoncée. La même corruption pouvait se reproduire, le système en aval pouvait réinitialiser à nouveau et l’instabilité de routage pouvait reprendre.[2]

La chaîne de défaillance était par conséquent plus large que le préfixe expérimental:

Un attribut valide mais non familier entrait dans un routeur affecté.
Le routeur le corrompait pendant la propagation.
Un voisin recevait un UPDATE malformé.
Le voisin pouvait mettre fin à la session BGP.
Des routes sans rapport avec l’expérience pouvaient disparaître de cette adjacence.
La reconvergence produisait un volume de mises à jour plus élevé.
La réannonce pouvait répéter la séquence.

C’est pourquoi l’événement est devenu un test de responsabilité plutôt qu’une simple curiosité d’interopérabilité. Chaque étape était contrôlée par un composant ou une organisation différente.

09 h 08 UTC: retrait planifié

RIPE NCC a retiré l’annonce expérimentale à 09 h 08 UTC, comme prévu.[1] La route avait donc été annoncée pendant environ vingt-sept minutes.

Le retrait était nécessaire, mais un retrait n’est pas une gomme instantanée. BGP est distribué. Les mises à jour déjà acceptées ou propagées doivent circuler par d’autres sessions, tandis que les routeurs recalculent les chemins et rétablissent les adjacences. Un retrait planifié peut arrêter l’émission continue au point d’origine sans annuler immédiatement chaque copie, mise à jour en file d’attente, réinitialisation ou processus de reconvergence déjà en cours.

RIPE a décrit l’impact opérationnel non intentionnel comme durant environ trente minutes. La plupart de l’instabilité est revenue à la normale environ vingt minutes après l’expérience, plutôt que de se terminer à la seconde exacte du retrait.[1] Ces descriptions doivent être traitées comme des intervalles opérationnels mesurés, et non comme l’affirmation que tous les chemins affectés se sont rétablis simultanément.

Après le retrait: réponse des opérateurs et collecte de preuves

Les opérateurs ont observé et réagi depuis leurs propres réseaux. Les discussions contemporaines sur liste de diffusion comprenaient des signalements de problèmes d’accès, de changements de routage et d’effets sur le trafic des points d’échange.[4][6] Ces commentaires sont des preuves utiles que la perturbation était visible opérationnellement, mais ils ont des limites strictes. Ils n’énumèrent pas tous les systèmes autonomes affectés, ne normalisent pas les observations entre emplacements et ne fournissent pas un décompte complet du trafic perdu.

RIPE NCC a conservé les données de l’expérience et fourni les preuves collectées à Cisco. Cette préservation comptait parce que l’événement traversait des frontières organisationnelles. Un journal côté origine pouvait montrer ce que RIS avait envoyé, mais pas nécessairement ce qu’une implémentation intermédiaire avait émis. Un rapport de fournisseur pouvait expliquer un défaut, mais pas quantifier les observations à l’échelle de l’Internet. Une reconstruction crédible exigeait des preuves issues de plus d’un domaine de contrôle.

22 h 00 UTC: l’avis de Cisco

Cisco a publié son avis IOS XR à 22 h 00 UTC le 27 août 2010.[2] Le problème a été enregistré sous CVE-2010-3035, et Cisco a préparé des mises à niveau de maintenance logicielle.[3]

L’avis publié le jour même a établi une réponse publique au niveau du produit. Il ne prouvait pas, à lui seul, quelle version était installée chez chaque opérateur affecté, combien d’appareils avaient rencontré la route, ni si chaque opérateur disposait d’une atténuation immédiatement utilisable. Ces éléments restent inconnus dans les archives limitées.

31 août et ensuite: analyse publique et réponse de gouvernance

RIPE NCC a publié son analyse d’incident et de mesure le 31 août 2010.[1] Le compte rendu décrivait l’expérience, l’interaction d’implémentation, les effets de routage observés, les conclusions DNSMON et les changements envisagés pour les futures expériences coopératives.

RIPE NCC a indiqué que les futures expériences feraient l’objet d’un traitement plus strict, comprenant une évaluation d’impact complète, un préavis suffisant aux opérateurs et une gestion responsable des vulnérabilités.[1] Son conseil d’administration a ensuite soutenu la poursuite de l’expérimentation tout en insistant sur une communication appropriée.[5]

Cette réponse ne niait pas la valeur de la recherche. Elle reconnaissait qu’un objectif de recherche utile n’élimine pas la nécessité de limiter l’exposition opérationnelle. La réparation de gouvernance n’était donc pas « arrêter d’expérimenter ». Elle consistait à conditionner l’autorité de lancer une expérience publique à des contrôles plus clairs de risque, de notification, de confinement et de réponse.

3. Qu’est-ce qu’un attribut transitif optionnel — et pourquoi « inconnu » ne signifiait pas « invalide »

Les attributs de chemin BGP transportent des informations associées à une route. Certains sont bien connus et censés être compris par les implémentations BGP. D’autres sont optionnels. Une distinction distincte concerne la transitivité: un attribut doit-il continuer à travers les locuteurs BGP même lorsqu’une implémentation intermédiaire n’en reconnaît pas le sens?

La RFC 4271 définit le comportement pertinent. Un attribut optionnel non transitif non reconnu n’a pas besoin d’être transmis. Un attribut optionnel transitif non reconnu est différent: il est accepté et transmis aux autres homologues BGP, avec le bit Partial utilisé pour indiquer qu’un système intermédiaire n’a pas pleinement reconnu l’attribut.[12]

Ce mécanisme soutient l’extensibilité. Sans lui, chaque système autonome le long d’un chemin devrait disposer du support logiciel simultané avant qu’une nouvelle fonctionnalité transitive puisse traverser l’Internet. La transitivité optionnelle permet un déploiement progressif: un routeur peut transporter une information sans l’interpréter.

La conception crée une responsabilité d’implémentation stricte. Un routeur qui ne comprend pas un attribut transitif optionnel doit néanmoins manipuler sa représentation en toute sécurité. Concrètement, il ne doit pas transformer une information opaque valide en information malformée.

Quatre concepts doivent rester distincts:

Reconnaissance.Le routeur comprend-il la sémantique de l’attribut?

Acceptation.L’attribut a-t-il une forme que le routeur peut recevoir en toute sécurité selon les règles du protocole?

Propagation.Le routeur doit-il ou peut-il transmettre l’attribut?

Mutation.Le routeur modifie-t-il l’attribut, et si oui, cette modification est-elle permise et correctement encodée?

L’événement de 2010 n’exigeait pas des systèmes IOS XR affectés qu’ils comprennent le schéma de certification de la recherche. Le défaut concernait la propagation. Le compte rendu de Cisco était que les systèmes affectés corrompaient l’attribut transitif valide non reconnu lors de son envoi.[2]

Cela explique pourquoi une seconde instance Quagga ne suffisait pas à prédire l’incident. Deux implémentations peuvent s’accorder sur la forme d’un attribut tandis qu’une troisième contient un défaut dans un chemin de code différent. Recevoir, stocker et sérialiser un attribut inconnu peut impliquer des opérations distinctes. Réussir un contrôle de conformité à l’entrée ne prouve pas un comportement correct à la sortie.

L’événement démontre aussi la différence entre validité syntaxique et sécurité opérationnelle de bout en bout. L’UPDATE initial pouvait être valide à l’origine. Un système intermédiaire pouvait ensuite produire une représentation invalide. Un système en aval pouvait répondre correctement selon les règles à sa disposition et créer néanmoins une conséquence opérationnelle dommageable en fermant une session entière.

Aucune couche ne suffit à expliquer l’impact:

L’expérience a fourni l’entrée non familière.
Le produit affecté a fourni la corruption.
La réponse d’erreur en aval a fourni la perte de session.
La reconvergence BGP a fourni l’amplification des mises à jour.
La propagation publique a fourni le domaine de défaillance.

Qualifier l’attribut initial de malformé effacerait le défaut produit, à moins que des preuves de paquets ne prouvent le contraire. Qualifier tout l’événement de simple bogue produit effacerait la décision d’exposer une interaction incertaine sur l’Internet en direct. Le qualifier uniquement de réponse protocolaire sévère effacerait l’implémentation qui a généré l’UPDATE malformé en aval.

La description exacte est une défaillance en chaîne avec des propriétaires de contrôle distincts.

4. D’un UPDATE corrompu à une instabilité de routage plus large

BGP distribue la joignabilité entre systèmes autonomes. Lorsqu’une session d’appairage se ferme, les routes apprises exclusivement ou préférentiellement par cette session peuvent être retirées de la table de routage locale. Le routeur peut sélectionner des alternatives et annoncer ces changements à d’autres homologues. Ces homologues répètent alors leurs propres processus de sélection.

Cela signifie qu’une erreur attachée à une route peut créer des changements impliquant de nombreuses routes si la réponse supprime une adjacence entière. Le préfixe expérimental n’avait pas besoin d’être la destination recherchée par les utilisateurs affectés. Une réinitialisation pouvait perturber d’autres joignabilités apprises sur la même session.

Le volume de mises à jour de l’événement correspond à ce mécanisme d’amplification. RIPE a observé des taux de mise à jour jusqu’à vingt fois supérieurs au niveau de référence environnant.[1] C’est une mesure du plan de contrôle: les routeurs échangeaient beaucoup plus de changements de routage. Elle n’indique pas directement la quantité de trafic applicatif perdu, mais elle montre que la perturbation allait au-delà du rejet silencieux d’un préfixe.

La restauration de session pouvait également créer une récurrence. Si le routeur affecté en amont conservait la route et répétait sa propagation défectueuse au retour de la session, le voisin pouvait rencontrer à nouveau l’UPDATE malformé. Le cycle résultant combinerait:

établissement de session;
annonce de route;
corruption pendant la propagation;
réception d’un UPDATE malformé;
fermeture de session;
retrait de route et reconvergence; et
rétablissement renouvelé.

Tous les homologues ou chemins n’ont pas nécessairement connu chaque étape. Les preuves soutiennent un mécanisme quipouvaitse répéter et des observations d’instabilité élevée; elles ne fournissent pas un enregistrement complet paquet par paquet pour chaque système autonome.

Cette distinction importe pour l’attribution de l’impact. Un collecteur de routes voit des annonces et des retraits à son point d’observation. Il ne voit pas chaque décision de transfert, chaque session utilisateur ni chaque paquet perdu. Différents collecteurs voient différentes tranches du système de routage. L’activité particulièrement intense au collecteur de Vienne illustre que l’effet était inégal.[1]

L’inégalité n’est pas un défaut de la mesure. C’est une propriété de la topologie et des politiques de l’Internet. Les systèmes autonomes choisissent leurs routes localement. Ils ont des homologues, des logiciels, des filtres et des alternatives différents. Une annonce défectueuse peut passer par un chemin, être bloquée sur un autre et n’être jamais sélectionnée sur un troisième.

La bonne démarche analytique n’est donc pas d’extrapoler le pic d’un collecteur à tout l’Internet. Elle consiste à combiner les collecteurs, décrire la distribution et préserver les limites d’inférence.

5. Impact borné: ce que les preuves soutiennent

Les mesures de RIPE fournissent trois indicateurs principaux.

Premièrement, les taux de mise à jour de routage ont atteint jusqu’à vingt fois le niveau de référence environnant.[1] Cela démontre une activité exceptionnelle du plan de contrôle pendant la fenêtre de l’événement. L’expression « jusqu’à » importe: elle décrit un pic, pas un taux uniforme à chaque collecteur ni sur toute la période.

Deuxièmement, RIPE a estimé que 0,5 % de préfixes supplémentaires sont devenus totalement inaccessibles plus longtemps que la normale.[1] C’est une mesure de visibilité au niveau des préfixes. Il ne faut pas la traduire en 0,5 % d’utilisateurs, de trafic, de routeurs ou d’activité économique. Les préfixes varient fortement en taille, usage et trafic, et les collecteurs de routes n’observent pas tous les chemins de transfert.

Troisièmement, la part de préfixes instables a culminé à 1,4 %. RIPE a associé ce pic à près de 4 500 préfixes, environ neuf fois le niveau habituel.[1] « Instable » n’est pas identique à « universellement injoignable ». Un préfixe peut connaître des changements de chemin répétés tout en restant joignable depuis certains endroits.

Ces résultats soutiennent la conclusion que l’événement a causé une instabilité de routage matérielle, mesurable et distribuée. Ils ne soutiennent pas l’affirmation selon laquelle 1,4 % de l’Internet serait totalement hors ligne.

Un raccourci contemporain selon lequel l’événement a affecté environ un pour cent de l’Internet peut saisir l’ordre de grandeur de certaines mesures, mais il est moins précis que les indicateurs séparés de RIPE. Il ne doit pas les remplacer. Les preuves distinguent l’inaccessibilité complète supplémentaire, l’instabilité observée et le volume de mises à jour.

Variation géographique et selon les collecteurs

Les effets variaient selon l’emplacement et le collecteur. Le collecteur de Vienne montrait une activité de mise à jour particulièrement élevée.[1] La variation peut refléter la topologie, la sélection des homologues, l’exposition aux implémentations affectées et la disponibilité de chemins alternatifs.

L’emplacement d’un collecteur n’est pas une carte directe de l’impact utilisateur dans cette ville ou ce pays. Les points d’observation BGP reçoivent des routes d’homologues entités. Leur vue peut inclure des chemins desservant des réseaux distants, et les utilisateurs locaux peuvent suivre des chemins non visibles par le collecteur. La preuve des collecteurs est solide pour le comportement de routage et plus faible pour attribuer un décompte géographique de personnes affectées.

Observations DNS

RIPE a utilisé DNSMON pour examiner si la perturbation de routage produisait des effets DNS visibles. Il n’a pas constaté de défaillance du système des serveurs racine.[1] Cette conclusion négative est importante, car une instabilité de routage large n’implique pas automatiquement la défaillance de tous les services critiques.

L’analyse a observé une perte de requêtes limitée pour certains domaines surveillés et des difficultés plus notables sur des portions des infrastructures faisant autorité.si et.fr. Des serveurs redondants continuaient de répondre.[1] Les preuves soutiennent donc des effets DNS partiels et inégaux, et non une défaillance DNS universelle.

La disponibilité continue des serveurs redondants rappelle aussi que la responsabilité de routage inclut l’architecture de service. Une perturbation de routage peut atteindre un chemin de serveur faisant autorité tandis qu’un autre reste joignable. La redondance n’élimine pas le défaut de routage, mais elle peut empêcher qu’une défaillance de composant devienne une défaillance complète de service.

Signalements d’opérateurs

Les forums opérationnels contemporains ont enregistré des signalements de perturbation d’accès, de réactions de routage et de changements de trafic.[4][6] Ces signalements aident à établir que l’incident était visible hors des institutions initiatrices. Ils peuvent aussi identifier des questions pour une enquête plus approfondie.

Ils ne remplacent pas une mesure normalisée. Une baisse de trafic à un point d’échange ou chez un opérateur peut refléter un reroutage, une perte, des changements de politique prudents ou une autre réponse locale. Sans bases de référence appariées, topologie et enregistrements de trafic, elle ne peut pas être convertie en un chiffre d’impact total sur l’Internet.

Affirmations que les preuves ne soutiennent pas

Les archives limitées n’établissent pas:

une liste complète des versions IOS XR affectées telles que déployées à l’époque;
un nombre exact de routeurs ou d’appareils affectés;
chaque système autonome ayant réinitialisé une session;
un nombre exact d’utilisateurs affectés;
le trafic applicatif total perdu;
la défaillance universelle du préfixe expérimental;
la défaillance de la racine DNS;
une intention malveillante de RIPE NCC, Duke, Cisco ou des opérateurs;
un compte rendu complet de chaque approbation préalable;
que chaque opérateur disposait d’une atténuation disponible avant l’événement; ni
une responsabilité juridique.

Ces réserves ne sont pas des clauses de non-responsabilité mineures. Elles définissent la différence entre un reportage d’infrastructure fondé sur des preuves et un récit de panne construit sur des multiplications non étayées.

6. Responsabilité par attribution du contrôle

La responsabilité est la plus forte lorsqu’elle demande qui contrôlait chaque décision, implémentation et action de restauration. Elle s’affaiblit lorsqu’elle traite la proximité du premier événement visible comme preuve de responsabilité unique.

Domaine de contrôle	Ce que le entité contrôlait	Ce que le entité ne contrôlait pas	Preuves nécessaires pour une évaluation plus solide
RIPE NCC	Utilisation de l’infrastructure RIS, origination visible sur Internet, calendrier, communication, surveillance, retrait, conservation des preuves et politique future d’expérimentation	Comportement logiciel de chaque routeur externe et restauration de chaque opérateur	Dossier d’approbation, évaluation des risques, plan de notification, seuils de surveillance, critères de retrait et observations conservées
Chercheurs de Duke	Conception de la recherche, construction de l’attribut expérimental, modifications Quagga côté recherche et tests côté recherche	Code IOS XR déployé, politiques de session en aval et déploiement logiciel des opérateurs	Vecteurs de test, octets d’UPDATE générés, enregistrements de l’implémentation de recherche et étendue des tests d’interopérabilité
Cisco	Analyse, stockage et propagation IOS XR; couverture de test produit; divulgation; correctifs de maintenance	La décision d’annoncer l’expérience et les calendriers d’installation des opérateurs	Analyse du défaut, matrice des versions affectées, résultats de régression, preuves du code corrigé et consignes de déploiement
Opérateurs réseau	Logiciels installés, maintenance, politiques d’importation et d’exportation, contrôles d’homologues, filtrage, surveillance et restauration dans leurs réseaux	Conception expérimentale, code du fournisseur en amont et chemin de propagation mondial complet	Journaux d’appareils, captures de paquets, configurations, versions logicielles, historique de sessions et enregistrements de restauration
Implémentations BGP en aval	Traitement local de l’UPDATE malformé selon les règles qu’elles implémentaient	La création de l’attribut valide initial ou la corruption en amont	Journaux d’erreurs UPDATE, notifications de session et preuve d’un traitement plus étroit lorsque pris en charge
Points d’échange Internet	Connectivité par laquelle les réseaux entités échangeaient des routes	Par défaut, le contenu et la justesse de chaque annonce BGP des entités	Preuve d’un rôle spécifique de serveur de routes, de filtrage ou opérationnel avant d’attribuer davantage de contrôle

Contrôle de RIPE NCC

RIPE NCC contrôlait l’acte qui a introduit la route expérimentale dans la propagation publique. RIS AS12654 était l’origine utilisée pour le test, et l’annonce a traversé les connexions de RIPE NCC à AMS-IX et GN-IX.[1] RIPE NCC contrôlait aussi le retrait planifié, sa collecte de preuves et ses futures règles pour des recherches coopératives similaires.

Ce contrôle établit la responsabilité de gouvernance de l’expérience. Il n’établit pas que RIPE NCC a créé le défaut produit. L’attribut initial a été décrit comme valide. La question pertinente pour RIPE NCC n’est pas de savoir s’il aurait dû prédire avec certitude la défaillance non documentée exacte. C’est de savoir si l’incertitude de l’expérience a été évaluée, communiquée, surveillée et contenue proportionnellement à sa portée publique possible.

L’engagement ultérieur en faveur d’une évaluation d’impact plus complète, d’un préavis aux opérateurs et d’une gestion responsable des vulnérabilités indique que RIPE NCC a lui-même identifié des améliorations de gouvernance.[1] Le soutien du conseil d’administration à la poursuite de l’expérimentation avec une communication appropriée renforce la distinction entre la légitimité de la recherche et l’adéquation de ses contrôles opérationnels.[5]

Contrôle de Duke

Les chercheurs de Duke contrôlaient la conception de la recherche sur le routage sécurisé et fournissaient la modification Quagga utilisée dans leur périmètre. Leur travail a contribué à créer l’entrée expérimentale valide. Les archives disponibles ne montrent pas qu’ils contrôlaient le traitement interne d’IOS XR ni la réponse d’erreur des routeurs en aval.

La responsabilité côté recherche concerne les hypothèses de conception et l’étendue des tests d’interopérabilité. Une seconde instance Quagga pouvait démontrer un comportement dans un environnement logiciel similaire. Elle ne pouvait pas établir la sécurité dans toutes les implémentations déployées pertinentes.

Les preuves publiques ne révèlent pas la répartition complète des décisions préalables entre Duke et RIPE NCC. Il serait impropre d’en inventer une. Toute attribution plus granulaire exigerait des plans d’expérience, des enregistrements de tests et des communications identifiant qui a approuvé les conditions de propagation publique.

Contrôle de Cisco

Cisco contrôlait l’implémentation IOS XR affectée. Son avis identifiait la corruption d’un attribut transitif valide non reconnu pendant la propagation.[2] Ce comportement relève du domaine de contrôle produit: analyse, rétention, sérialisation, traitement des drapeaux d’attribut et tests de régression.

Cisco contrôlait aussi sa divulgation et sa réponse de maintenance. L’avis est paru le jour de l’incident et des mises à niveau de maintenance logicielle ont été préparées.[2] CVE-2010-3035 fournit l’identifiant public de vulnérabilité.[3]

La responsabilité produit doit rester fondée sur des preuves. Les archives n’établissent pas chaque version déployée, le nombre d’appareils affectés ni si le défaut avait été découvert plus tôt. Une évaluation plus solide exigerait des tests par version, l’historique du défaut et des preuves d’installation.

Contrôle des opérateurs

Chaque opérateur réseau contrôlait une portion locale du système: sélection et installation des logiciels, calendrier de maintenance, politique d’appairage, filtres, surveillance, protection des sessions et restauration. Ces contrôles pouvaient affecter l’exposition et la récupération.

Cela ne rend pas les opérateurs responsables de prédire un défaut de corruption inconnu du fournisseur. Cela ne montre pas non plus que chaque opérateur disposait d’un correctif ou d’une atténuation de configuration disponible avant l’expérience. La responsabilité des opérateurs est conditionnée à ce qui était connaissable et contrôlable au moment pertinent.

Après la divulgation, les preuves requises pour une assurance continue changent. On peut demander aux opérateurs d’identifier les versions affectées, d’appliquer les correctifs, de tester le comportement et de conserver des preuves. Avant la divulgation, les allégations d’inaction déraisonnable exigeraient la preuve qu’un risque et une atténuation réalisable étaient déjà connus.

Pourquoi il ne faut pas attribuer un rôle inventé aux points d’échange

L’expérience a utilisé des connexions à AMS-IX et GN-IX.[1] Ce fait établit un chemin de propagation. Il n’établit pas, sans preuves supplémentaires, que l’un ou l’autre point d’échange a conçu l’expérience, approuvé l’attribut, exploité un routeur affecté ou contrôlé les politiques d’exportation des entités.

Le reportage d’infrastructure confond souvent le transit physique ou logique avec l’autorité décisionnelle. Un point d’échange nommé peut faire partie du chemin de la route sans être l’acteur qui a émis, corrompu ou accepté l’UPDATE. La responsabilité ne doit pas être déduite de la seule topologie.

7. La réparation produit et la réparation de gouvernance d’expérience sont différentes

Une réponse complète exigeait deux pistes de réparation.

Réparation produit

Le défaut produit était la corruption d’un attribut transitif valide non reconnu pendant la propagation par les systèmes IOS XR affectés. La réparation directe relevait du logiciel et de ses tests.

Une réparation produit crédible démontrerait que:

un attribut transitif optionnel inconnu valide peut être reçu;
il est stocké sans mutation destructrice;
il est propagé sous la forme requise par le protocole;
les drapeaux d’attribut et champs de longueur pertinents restent cohérents;
l’établissement répété de session ne recrée pas la corruption;
les variantes malformées sont contenues selon le comportement de gestion d’erreur pris en charge;
les tests de régression couvrent à la fois les chemins de reconnaissance et de propagation opaque; et
la version corrigée est identifiable par les opérateurs.

L’avis et les mises à niveau de maintenance de Cisco ont été les actions publiques immédiates traitant cette couche.[2] Un avis communique le défaut; une mise à niveau modifie l’implémentation. Les deux sont liés mais non interchangeables.

La vérification exige aussi des preuves de déploiement. Un fournisseur peut prouver qu’une version corrigée passe les tests de régression, tandis qu’un opérateur peut prouver quelle version s’exécute sur un routeur donné. Aucun enregistrement seul n’établit à la fois la correction produit et l’adoption sur le terrain.

Réparation de gouvernance d’expérience

Le défaut de gouvernance n’était pas que la recherche ait eu lieu. C’était qu’une interaction incertaine ait été testée via l’infrastructure de routage publique sans contrôles suffisants pour prévenir ou limiter rapidement le rayon d’impact observé.

La réponse de RIPE NCC a identifié des exigences futures plus strictes: évaluation d’impact complète, préavis suffisant aux opérateurs et traitement responsable des vulnérabilités.[1] Celles-ci concernent les décisions prises avant et pendant une expérience.

Une réparation de gouvernance crédible inclurait:

un objectif technique clairement borné;
l’identification de chaque attribut et route à annoncer;
une frontière de propagation documentée ou une explication de la nécessité d’une propagation plus large;
des tests d’implémentations hétérogènes proportionnés au risque;
une communication préalable aux opérateurs concernés lorsque possible;
une fenêtre de test définie;
une observation en temps réel par collecteurs de routes;
des sondes de plan de données ou de service lorsque pertinent;
des critères quantitatifs d’arrêt;
une personne autorisée capable de retirer immédiatement;
une procédure de retrait répétée;
des critères pour contacter les fournisseurs;
des données pré-événement et post-événement préservées; et
un compte rendu public d’incident lorsqu’un impact externe non intentionnel se produit.

Les contrôles de gouvernance ne peuvent pas garantir qu’un défaut inconnu n’apparaîtra jamais. Leur but est de réduire la probabilité que la découverte produise des conséquences externes non maîtrisées et de raccourcir le délai entre détection et confinement.

Pourquoi une réparation ne peut pas remplacer l’autre

Si Cisco corrigeait IOS XR mais que les contrôles d’expérience restaient inchangés, une expérience ultérieure pourrait exposer un autre défaut inconnu dans une autre implémentation. Le risque produit spécifique diminuerait, tandis que le risque de découverte subsisterait.

Si RIPE NCC renforçait les contrôles d’expérience mais que le logiciel affecté restait non corrigé, le trafic Internet ordinaire transportant un autre attribut transitif non familier valide pourrait encore rencontrer le défaut latent. Le risque de test public diminuerait, tandis que le risque produit subsisterait.

L’événement exige donc deux questions de clôture indépendantes:

Le défaut d’implémentation est-il corrigé et déployé là où pertinent?
Les futures expériences en direct sont-elles bornées, observables et gouvernées d’une manière adaptée à leur incertitude?

Un rapport qui ne répond qu’à une seule n’a pas démontré une réparation complète.

8. Les normes ultérieures comme contexte analytique — pas comme jugement rétroactif

Les normes publiées après août 2010 aident à décrire de meilleures pratiques de confinement et de politique. Elles ne prouvent pas que ces pratiques étaient déployées pendant l’événement, et elles ne peuvent pas transformer rétroactivement des recommandations ultérieures en conclusion de négligence.

RFC 4271: la base historique

La RFC 4271 décrit BGP-4, y compris les attributs transitifs optionnels et la gestion d’erreur.[12] Ses règles de propagation expliquent pourquoi un attribut transitif non reconnu doit être transporté. Sa gestion d’erreur UPDATE aide aussi à expliquer pourquoi un attribut malformé pouvait conduire à la terminaison de session.

Cette combinaison produisait une interaction dangereuse. L’extensibilité dépendait d’une propagation opaque sûre, tandis qu’une entrée malformée pouvait activer une réponse large. Lorsqu’une implémentation intermédiaire corrompait l’information opaque, le système en aval faisait face à une condition d’erreur aux conséquences plus grandes que la route unique.

RFC 7606: réduire le domaine de défaillance

La RFC 7606 a ensuite révisé la gestion d’erreur des UPDATE BGP, car la réinitialisation de session peut écarter de nombreuses routes valides et provoquer une perturbation de routage substantielle.[13] Elle promeut généralement des réponses plus étroites, y compris le traitement des routes affectées comme retirées dans des cas définis, plutôt que la destruction automatique de la session entière.

Appliquée comme contexte analytique, elle montre comment le domaine de défaillance peut être réduit. Si une annonce malformée peut être confinée à la route affectée pendant que la session et les routes sans rapport restent, un attribut corrompu a moins de pouvoir de déstabiliser une adjacence.

Il serait inexact de dire que la RFC 7606 était la règle régissant l’événement de 2010. Elle a été publiée plus tard. Il serait aussi inexact de supposer que chaque implémentation actuelle applique chaque recommandation uniformément. La RFC explique une direction de réparation architecturale; les preuves de déploiement restent requises.

RFC 7454 et RFC 8212: politique externe explicite

La RFC 7454 rassemble des recommandations de sécurité opérationnelle pour BGP, tandis que la RFC 8212 établit une attente de politique explicite pour les annonces et l’acceptation BGP externes.[14][15] Ensemble, elles renforcent un principe de contrôle fondamental: les routes externes ne devraient pas être échangées simplement parce qu’une session existe.

Des politiques d’importation et d’exportation explicites peuvent réduire la propagation accidentelle et rendre les relations prévues auditables. Dans une expérience bornée, une politique soigneusement définie pourrait aider à limiter les homologues recevant une route de test.

Ces mesures ne corrigent pas directement un routeur qui corrompt un attribut qu’il est tenu de propager. Elles opèrent à la frontière politique, pas dans le chemin de sérialisation défectueux. Elles peuvent réduire l’exposition, mais seulement si la route ou la session peut être distinguée et contrainte sans compromettre l’objectif légitime de l’expérience.

RFC 7908: taxonomie des fuites de routes

La RFC 7908 décrit des types de fuites de routes.[16] Elle est utile ici principalement comme frontière contre une terminologie lâche. L’événement de 2010 impliquait une route expérimentale intentionnellement annoncée et un défaut d’implémentation affectant un attribut transitif optionnel. Les preuves disponibles ne doivent pas être étirées pour le placer dans une catégorie de fuite ultérieure sans correspondre aux conditions de la catégorie.

La taxonomie soutient la responsabilité lorsqu’elle empêche la fusion de mécanismes sans rapport. Elle la sape lorsqu’une étiquette familière remplace l’analyse causale.

Validation d’origine RPKI

La RFC 6480 décrit l’architecture de l’infrastructure de clés publiques de ressource, et la RFC 6811 définit la validation d’origine de préfixe BGP.[17][18] La validation d’origine demande si un système autonome d’origine est autorisé par une autorisation d’origine de route pertinente pour un préfixe.

Ce contrôle répond à une question différente de celle exposée ici. Une route peut avoir une relation d’origine acceptable tout en portant un attribut qu’un produit intermédiaire corrompt ensuite. La validation d’origine ne prouve pas que chaque attribut de chemin est correctement encodé ou préservé.

Aucune conclusion sur l’état RPKI réel de l’expérience n’est nécessaire. Le point analytique est limité: la validation d’origine, à elle seule, ne testerait pas le chemin de traitement sortant affecté.

BGPsec

La RFC 8205 spécifie la validation de chemin BGPsec.[19] BGPsec traite la protection cryptographique des informations de chemin dans une architecture définie. Elle est liée à l’objectif plus large de routage sécurisé étudié par le groupe de Duke, mais elle ne constitue pas une preuve de ce qui était déployé pendant cette expérience de 2010.

Elle ne doit pas non plus être présentée comme une correction automatique de tout défaut d’implémentation. Les mécanismes de sécurité sont eux-mêmes implémentés en logiciel. L’analyse sûre, la sérialisation, le confinement des défaillances et les tests d’interopérabilité restent nécessaires.

Guide de sécurité du routage du NIST

La publication NIST SP 800-189 fournit des recommandations ultérieures pour sécuriser l’échange de trafic interdomaine, notamment les protections de routage et les pratiques opérationnelles.[20] Elle est utile pour structurer les attentes actuelles en matière de filtrage, surveillance, validation et réponse.

Elle n’établit pas une obligation légale en 2010 ni ne prouve ce qu’un entité savait à l’époque. Son usage approprié est prospectif: demander quelles preuves un réseau devrait désormais conserver et quels contrôles peuvent réduire des chaînes de défaillance similaires.

9. Contrefactuels: quel fait modifié aurait réduit l’impact?

L’analyse contrefactuelle n’est utile que si chaque scénario modifie une condition définie et préserve le reste des preuves. Elle ne peut pas prouver ce qui se serait certainement produit, mais elle peut identifier des contrôles à forte valeur.

Contrefactuel 1: IOS XR préserve correctement l’attribut

Modifions un fait: les systèmes IOS XR affectés reçoivent l’attribut transitif valide non reconnu et le propagent sans corruption.

L’UPDATE malformé en aval ne provient pas de ce chemin produit. Le mécanisme de réinitialisation de session attribué à l’UPDATE corrompu n’est donc pas activé par ce défaut. L’annonce reste inhabituelle et expérimentale, mais la chaîne de défaillance documentée est interrompue à son principal point d’implémentation.

C’est le contrefactuel produit le plus fort, car il supprime le mécanisme de corruption identifié. Il ne prouve pas qu’aucune autre implémentation n’aurait mal réagi.

Contrefactuel 2: des tests hétérogènes reproduisent le comportement déployé

Modifions un fait: les tests préalables à la publication incluent une implémentation affectée suffisamment représentative et déclenchent la corruption sortante.

Le défaut peut être examiné avant que la route n’entre dans une large propagation publique. Cisco peut recevoir le cas de test, tandis que RIPE NCC et Duke peuvent décider de reporter, contraindre ou reconcevoir l’expérience.

La limite est la représentativité. Aucun laboratoire ne peut reproduire tous les chemins de l’Internet. La valeur réside dans l’élargissement au-delà de deux extrémités Quagga similaires et dans le test spécifique du comportement de réception et de propagation opaque entre implémentations distinctes.

Contrefactuel 3: l’expérience est menée dans un environnement de routage borné

Modifions un fait: le même attribut et le logiciel affecté interagissent dans un environnement fermé ou étroitement contrôlé plutôt qu’à travers la propagation publique ordinaire.

Le défaut peut encore réinitialiser une session, mais le nombre de routes sans rapport et de réseaux externes exposés peut être limité. Les preuves peuvent être capturées à chaque saut.

La limite est le réalisme. Un environnement borné peut ne pas reproduire les combinaisons de topologie, de politique ou de logiciels présentes sur l’Internet public. C’est pourquoi une montée en puissance par étapes est préférable: commencer par une diversité bornée, puis élargir seulement lorsque le risque et les preuves le justifient.

Contrefactuel 4: les routeurs en aval utilisent une gestion d’erreur UPDATE plus étroite

Modifions un fait: un routeur en aval confine l’annonce malformée sans fermer toute la session BGP, là où une réponse étroite de type ultérieur est applicable.

La route expérimentale peut être écartée, mais les routes valides sans rapport apprises sur la session restent disponibles. L’amplification des mises à jour et la pression de reconvergence devraient être matériellement plus faibles.

Ce contrefactuel reflète la direction formalisée plus tard dans la RFC 7606.[13] Il doit rester analytique, car cette RFC est postérieure à l’événement et le traitement exact dépend de la classe d’erreur et de l’implémentation.

Contrefactuel 5: un préavis atteint les opérateurs affectés

Modifions un fait: les opérateurs reçoivent un préavis technique suffisant du préfixe, de l’attribut, de la fenêtre, du comportement attendu et des conditions d’arrêt.

Certains opérateurs peuvent surveiller plus étroitement les sessions concernées, préparer le personnel, limiter l’exposition ou se coordonner rapidement après l’apparition d’anomalies. Le diagnostic peut s’accélérer parce que la route est reconnue comme une expérience plutôt que comme un événement inexpliqué.

Le préavis ne répare pas IOS XR. Il peut aussi exiger une gestion prudente des vulnérabilités si un test est censé exposer un comportement dangereux. La communication est donc une atténuation et un contrôle de coordination, pas un mécanisme de confinement complet.

Contrefactuel 6: des critères quantitatifs d’arrêt déclenchent un retrait plus précoce

Modifions un fait: la surveillance identifie des taux de mise à jour anormaux ou des réinitialisations de session suffisamment tôt pour franchir un seuil d’arrêt prédéfini avant 09 h 08 UTC.

RIPE NCC retire plus tôt. L’émission continue se termine plus tôt, réduisant potentiellement les répétitions et la durée d’exposition.

La limite est l’état distribué de BGP. Les mises à jour déjà propagées exigeraient encore retrait et reconvergence. Une action plus précoce pourrait réduire la durée mais ne rétablirait pas instantanément tous les chemins affectés.

Contrefactuel 7: la politique limite la propagation à des homologues sélectionnés

Modifions un fait: des politiques d’importation et d’exportation contraignent la route expérimentale à des réseaux explicitement entités.

Le domaine de défaillance devient plus petit et les opérateurs entités peuvent capturer des preuves. Cela correspond à l’accent ultérieur sur une politique externe explicite.[14][15]

La limite est la question de recherche. Si l’objectif exige d’observer diverses implémentations publiques, un confinement strict change ce qui peut être appris. Ce compromis doit être fait explicitement plutôt que supposé.

Contrefactuel 8: collecteurs de routes et sondes de service fournissent des alarmes corrélées immédiates

Modifions un fait: les observations du plan de contrôle, la télémétrie de session et les sondes de service pertinentes sont corrélées en temps réel.

Les enquêteurs peuvent distinguer plus tôt une annonce nouvelle inoffensive d’une amplification de mises à jour, d’une invisibilité de préfixe et d’effets de service. La décision de retrait devient fondée sur des preuves.

Cela n’empêche pas la première corruption. Cela améliore la détection et raccourcit l’intervalle pendant lequel l’incertitude persiste.

Contrefactuel 9: l’expérience n’a jamais lieu

Modifions un fait: aucune annonce publique n’est faite.

Le déclencheur du 27 août disparaît, de sorte que cet événement n’expose pas le défaut. Le défaut produit peut néanmoins rester latent et être activé plus tard par un autre attribut non familier valide.

Ce contrefactuel clarifie pourquoi « ne pas expérimenter » n’est pas une stratégie de sécurité suffisante. Éviter le test évite cet incident, mais ne corrige pas le logiciel en cours d’exécution. Un meilleur objectif est la découverte sûre: des expériences bornées combinées à la réparation produit.

10. À quoi ressemblerait une réparation vérifiable

Une affirmation de réparation doit être liée à des artefacts et observations plutôt qu’à des réassurances.

Preuves produit

Pour l’implémentation affectée, des preuves crédibles incluraient:

les versions logicielles corrigées exactes;
une description du fournisseur du chemin de traitement défectueux à un niveau de détail approprié;
des tests de régression utilisant des attributs transitifs optionnels inconnus valides;
des tests montrant une propagation préservant les octets ou autrement conforme;
des tests utilisant des variantes malformées ou délibérément corrompues;
la preuve qu’une gestion d’erreur étroite prise en charge préserve les routes sans rapport lorsque applicable;
des tests répétés de cycle de session pour détecter la récurrence;
des enregistrements d’opérateurs identifiant les versions installées; et
des observations post-installation montrant que le défaut n’est plus reproduit.

Le CVE public et l’avis identifient le problème et la réponse.[2][3] Ils sont le début de la vérifiabilité, pas la preuve complète de la clôture sur le terrain.

Preuves d’expérience

Pour une future expérience de routage en direct, des preuves crédibles incluraient:

le préfixe de test et l’origine;
l’encodage d’attribut proposé;
les homologues entités et l’étendue de propagation prévue;
des résultats d’interopérabilité entre implémentations matériellement différentes;
une évaluation d’impact couvrant les conséquences sur le plan de contrôle et les services;
un enregistrement de préavis;
des seuils quantitatifs d’arrêt;
une autorité de retrait immédiat;
une répétition de retrait;
une surveillance en direct par collecteurs;
des contrôles pertinents de plan de données ou de service;
des horodatages pour les anomalies et décisions;
des données d’UPDATE préservées; et
un compte rendu post-événement comparant comportement attendu et observé.

RIS et Route Views illustrent la valeur de multiples points d’observation du routage.[7][11] Ils ne remplacent pas les journaux d’appareils ou les captures de paquets, mais ils peuvent montrer indépendamment si une annonce s’est propagée, si les retraits se sont multipliés et si les effets différaient selon le point de vue.

Preuves d’opérateur

Un opérateur affirmant que son réseau est protégé devrait pouvoir montrer:

si le logiciel IOS XR affecté est ou était présent;
quelle version corrective est installée;
comment la politique de route externe est définie;
comment les UPDATE malformés sont traités par le logiciel actuel;
comment les réinitialisations de session sont détectées;
comment la perte de routes sans rapport est mesurée;
quelles protections d’homologues sont activées;
comment les décisions de restauration sont enregistrées; et
si un test de régression contrôlé a été achevé.

C’est la continuité opérationnelle sous forme concrète. Une déclaration de configuration sans preuve de version en cours d’exécution est incomplète. Une version logicielle sans preuve de politique et d’observation est également incomplète.

Critères de clôture

L’événement peut être considéré comme techniquement compris lorsque les octets d’origine, la mutation intermédiaire et la réponse en aval sont reliés par des preuves. Le problème produit peut être considéré comme réparé lorsque le logiciel corrigé passe les tests de régression pertinents et que le déploiement est démontré là où requis. Le problème de gouvernance peut être considéré comme réparé lorsqu’une future expérience ne peut pas se dérouler sans périmètre, notification, surveillance, autorité d’arrêt et conservation documentés.

Ces critères de clôture sont intentionnellement séparés. Un rapport public d’incident devrait indiquer lesquels sont satisfaits et lesquels restent inconnus.

11. Preuves qui modifieraient la conclusion

La conclusion actuelle dépend des preuves. Plusieurs découvertes exigeraient une révision matérielle.

Captures de paquets montrant que l’attribut initial était malformé

Si des captures faisant autorité démontraient que RIS AS12654 a émis un attribut malformé avant qu’il n’atteigne un système IOS XR affecté, la conclusion selon laquelle une entrée valide a d’abord été corrompue pendant la propagation devrait changer.

La responsabilité se déplacerait vers la génération et la validation préalable à l’annonce, bien que toute mutation ou amplification supplémentaire exigerait encore une analyse distincte. L’exigence clé serait une comparaison d’octets de bout en bout: ce que l’origine a transmis, ce que chaque système intermédiaire a reçu et ce qu’il a émis.

Journaux d’appareils identifiant un autre point de corruption

Si des journaux ou captures montraient qu’une autre implémentation, un serveur de routes ou un intermédiaire a créé la corruption, l’attribution produit devrait être révisée. Un avis Cisco peut identifier un défaut réel sans prouver que le même défaut explique chaque chemin observé.

L’événement peut avoir contenu plus d’un mode de défaillance. Seules des preuves spécifiques au chemin peuvent établir si toutes les réinitialisations partageaient un point de corruption unique.

Données de collecteurs révisant matériellement les estimations d’impact

Si des données de collecteurs préservées montraient que la référence, le nombre de préfixes affectés ou la durée étaient matériellement différents, l’évaluation d’impact borné devrait être mise à jour. Les corrections pourraient augmenter ou réduire l’étendue mesurée.

Une révision ne changerait pas automatiquement le mécanisme d’implémentation. La cause et l’ampleur sont des questions probatoires liées mais indépendantes.

Dossiers d’approbation et de risque montrant des contrôles supplémentaires

Si des dossiers d’expérience complets montraient un confinement, une notification ou des contrôles d’arrêt substantiels non visibles dans le compte rendu public, l’évaluation de gouvernance devrait les reconnaître. Il faudrait alors expliquer pourquoi ces contrôles n’ont pas empêché ni raccourci la perturbation observée.

Inversement, des dossiers montrant que des risques à impact élevé identifiés ont été acceptés sans atténuation renforceraient la critique de gouvernance. Le compte rendu public seul n’établit aucun des deux scénarios.

Dossiers produit montrant une identification et un contrôle efficaces préalables

Si des dossiers de test produit démontraient que le défaut avait été identifié et contrôlé efficacement avant l’expérience, la chronologie et l’attribution des responsabilités changeraient. Les enquêteurs devraient demander si les systèmes déployés affectés manquaient d’une correction disponible, si les opérateurs avaient reçu un avis applicable et si le comportement observé provenait d’un autre mécanisme.

Les archives actuelles n’établissent pas une telle identification préalable.

Preuves d’un impact de service plus large ou plus étroit

Des mesures de trafic complètes, des journaux d’opérateurs ou de la télémétrie de service pourraient améliorer l’évaluation des conséquences visibles pour les utilisateurs. Elles pourraient montrer que l’instabilité du plan de contrôle a causé plus de perturbation applicative que documenté actuellement, ou que la redondance a maintenu la plupart des services disponibles malgré les changements de routage.

De telles preuves changeraient la section d’impact, mais ne justifieraient pas de réécrire la validité de l’UPDATE initial sans preuve au niveau des paquets.

12. Une conclusion mesurée

L’expérience RIPE-Duke de 2010 n’était pas un détournement de route malveillant classique, et les preuves disponibles ne soutiennent pas de la présenter comme tel. Elle n’était pas non plus un simple test de normes inoffensif ayant rencontré des routeurs irrationnels.

C’était une expérience de routage en direct dans laquelle un attribut transitif optionnel valide et non familier a rencontré une implémentation IOS XR affectée. Cette implémentation a corrompu l’attribut en le propageant. Un routeur en aval a alors pu répondre à l’UPDATE malformé en réinitialisant une session BGP, en retirant des routes valides sans rapport et en contribuant à des reconvergences répétées. Les mesures de RIPE ont capturé une perturbation bornée mais matérielle: taux de mise à jour exceptionnels, invisibilité supplémentaire de préfixes et un pic de près de 4 500 préfixes instables.[1][2]

L’événement a exposé deux défauts dans des domaines de contrôle différents. L’un était un défaut produit dans le traitement d’informations de routage opaques valides. L’autre était une faiblesse de gouvernance d’expérience: des tests préalables limités et une exposition publique insuffisamment bornée ont permis à une interaction inconnue de devenir un incident de routage Internet.

L’avis et les mises à niveau de maintenance de Cisco ont traité le défaut produit. L’enquête de RIPE NCC, la préservation des preuves et des engagements futurs plus stricts ont traité le défaut de gouvernance. Les normes ultérieures ont fourni un meilleur confinement des erreurs et des conseils de politique, mais elles sont un contexte, pas une preuve rétroactive.

La leçon la plus durable porte sur le contrôle. La conformité aux normes à l’origine ne garantit pas un comportement sûr de bout en bout. Un registre ou un collecteur de routes peut identifier qui a annoncé un préfixe et montrer comment la visibilité a changé, mais il ne peut pas forcer chaque implémentation intermédiaire à préserver correctement un attribut. Les fournisseurs doivent prouver un code en cours d’exécution sûr. Les initiateurs d’expérience doivent borner les tests publics incertains. Les opérateurs doivent connaître leurs logiciels, politiques et état de restauration.

Les systèmes d’observation doivent conserver suffisamment de preuves pour distinguer déclencheur, corruption, amplification et impact.

La responsabilité ne s’obtient pas en nommant la première organisation de la chronologie. Elle s’obtient en reliant chaque contrôle déterminant à un propriétaire et en exigeant la preuve que la réparation correspondante fonctionne.