La fuite BGP de Rostelecom en 2020 révèle les limites de la validation d'origine

Résumé

• Le suivi de Qrator place le début de l'incident vers 19h28 UTC le 1er avril 2020 et décrit une observation d'environ une heure. Il s'agit d'une fenêtre d'observation externe attribuée, pas d'une chronologie interne complète de Rostelecom ni d'une preuve d'un début et d'une fin exacts sur chaque réseau affecté.[1]

• Qrator a signalé 8 870 préfixes affectés appartenant à près de 200 systèmes autonomes. CERT-EU a ensuite résumé plus de 8 800 routes venant de plus de 200 réseaux. Ces chiffres décrivent l’ampleur observable selon des perspectives de reporting différentes; aucune source n’établit chaque chemin de données, chaque utilisateur affecté ou l’impact commercial total.[1][2]

• Qrator a observé des annonces AS12389 propagées via Rascom AS20764, Cogent AS174 et Level 3 AS3356. Cette chaîne montre que l’événement a traversé des domaines de routage contrôlés indépendamment, mais ne révèle ni les filtres d’import exacts, ni les contrats, ni l’état de validation, ni la configuration de routeurs de chaque réseau nommé.[1]

• La preuve de routage doit maintenir séparées plusieurs catégories: une route apprise exportée au-delà du périmètre de politique prévu; une annonce à origine non autorisée; une réémission de préfixe plus spécifique; et une route où l’origine autorisée reste intacte même si son chemin viole une relation commerciale attendue. Ces catégories interagissent différemment avec le filtrage, l’autorisation, et la validation RPKI.[4][17]

• Un incident RIPE NCC distinct est survenu dans le plan de contrôle de RPKI. Suite à une mise à jour du logiciel de registre, 2 669 Route Origin Authorisations ont été supprimées après qu’un certain nombre d’attributions provider-independent aient été classées comme non certifiables. RIPE NCC a restauré les ROA manquantes le 2 avril.[3][5]

• La contemporanéité n’établit pas la causalité. Une analyse rétrospective de RIPE NCC et un groupe de travail de routage indépendant n’ont trouvé aucun lien direct entre la suppression des ROA et l’incident de routage de Rostelecom.[4][5]

• L’intersection mesurée entre les incidents était étroite: trois titulaires de ressources provider-independent et 12 préfixes. Ce recoupement ne peut pas être extrapolé à tous les 8 870 préfixes, et le registre public ne permet pas de décrire toutes les routes affectées comme RPKI Invalid.[4][5]

• La validation de l’origine de route peut comparer un préfixe et son ASN d’origine aux données ROA validées et classer le résultat comme Valid, Invalid ou NotFound. Elle ne valide pas le chemin AS complet, ne détermine pas si chaque export respecte une relation commerciale, ne reconstruit pas un changement de configuration et n’établit pas l’intention.[13]-[15]

• Le contrôle pratique était distribué. Rostelecom contrôlait ses annonces et sa politique d’export. Les réseaux receveurs contrôlaient leurs décisions d’import, d’export et de validation propres; les titulaires de préfixes contrôlaient leurs enregistrements et ROA; RIPE NCC contrôlait son service de certification et de gestion de ROA; les relying parties contrôlaient la fraîcheur des caches et l’application; les fournisseurs de monitoring contrôlaient leurs systèmes d’observation et d’alerte.

• Des faits importants restent inconnus: la séquence déclenchante interne initiale, la répartition exacte entre fuites de routes apprises et réémissions plus spécifiques, l’état RPKI visible par chaque relying party, les filtres appliqués à chaque saut, la chronologie complète de la réponse et l’effet complet sur le plan de données, et si l’incident a commencé par erreur ou intentionnellement.

• La conclusion de responsabilité est donc opérationnelle plutôt qu’accusatoire. Les registres de RIPE NCC et les ROA ont fourni des éléments sur l’autorisation de ressources et d’origine, tandis que les configurations en cours, les caches actuels, les politiques de voisinage, la surveillance et la remédiation coordonnée ont déterminé si cette preuve modifiait le comportement de routage en direct.

La question de la responsabilité

L'incident du 1er avril 2020 est important car il a mis en évidence une division entre autorité enregistrée et contrôle en cours.

RIPE Database pouvait identifier l’objet administratif associé à AS12389, et RPKI pouvait exprimer les autorisations d’origine de certains titulaires de préfixes.[8][10] Aucun des deux systèmes n’imposait à lui seul ce qu’accepterait, privilégierait ou propagerait chaque routeur.[12] Des BGP speakers ont échangé des messages UPDATE, sélectionné des routes selon une politique locale puis annoncé des résultats autorisés à leurs voisins.[12] Une fois que des annonces inattendues franchissent une frontière de réseau, chaque opérateur recevant prend une nouvelle décision localement contrôlée.

Cette structure exclut une explication simpliste où un enregistrement de registre, un mécanisme de sécurité unique ou une seule organisation aurait gouverné l’issue entière. La propagation rapportée par Qrator via AS20764, AS174 et AS3356 a placé plusieurs plans de contrôle opérationnel dans la chaîne observée.[1] Le comportement de Rostelecom était central car AS12389 apparaissait dans les annonces examinées. Toutefois, la portée de ces annonces dépendait aussi des voisins qui les ont acceptées, des routes exportées par ces voisins et des réseaux aval qui ont sélectionné.

C’est pourquoi l’événement est devenu un test des limites de la validation d’origine. Si une annonce utilisait une origine non autorisée ou une longueur de préfixe interdite couverte par un ROA, un opérateur disposant de données validées récentes et d’une politique d’application aurait potentiellement pu la classer et la rejeter comme Invalid. Si une route gardait une origine autorisée mais passait par un AS path jugé inapproprié, le même contrôle d’origine pouvait rester Valid. S’il n’existait aucun ROA de couverture, le résultat serait normalement NotFound, pas Invalid.

Les contrôles techniques avaient donc une influence différente sur les différentes parties de l’événement observé.

La preuve publique soutient une analyse de responsabilité uniquement si ces distinctions sont conservées. Retirer les annonces BGP, la preuve AS12389, les observations de propagation, l’état des ROA, les décisions d’acceptation en amont, la surveillance et la coordination d’incident laisserait une discussion sécurité générique plutôt qu’une explication de cet incident. Inversement, traiter chaque route comme le même type d’incident attribuerait à RPKI des capacités qu’il n’a pas été conçu pour posséder.

La responsabilité, ici, signifie identifier qui détenait un contrôle pratique sur une décision mesurable et quelle preuve peut démontrer cette décision. Elle ne signifie pas inférer négligence, criminalité, faute individuelle, violation, responsabilité légale ou motif d’interception à partir d’observations externes de routage. CERT-EU a indiqué qu’il restait incertain si l’événement était accidentel.[2] Le registre public ne résout pas cette incertitude, l’analyse ne doit donc pas la trancher par assertion.

Chronologie forensique

Une reconstruction forensique doit distinguer les observations rapportées directement des inférences et des événements internes non résolus. Les collecteurs de routes publics et les plateformes de monitoring révèlent des vues de plan de contrôle sélectionnées plutôt qu’une transcription universelle. La documentation RIPEstat encadre aussi les données de routage comme une observation issue de sources disponibles, avec des limites dues aux points de vue et à la couverture des données.[9] La chronologie suivante identifie donc ce qui est rapporté, ce qui est séparé et ce qui reste inconnu.

Cette chronologie contient deux séquences de défaillance simultanées mais analytiquement séparées. L’une concernait les annonces BGP et leur acceptation à travers des frontières de réseau. L’autre concernait la production et la disponibilité d’enregistrements d’autorisation d’origine. La première dépendait de la politique de routage en direct; la seconde affectait les données de ROA validées disponibles pour les relying parties. Leur intersection limitée rend légitime la question de savoir si les enregistrements manquants ont changé le traitement de 12 préfixes.

Cela ne fait pas de la suppression des ROA la cause de l’événement des 8 870 préfixes.

La chronologie sépare aussi le temps de détection du temps de déclenchement. L’observation approximative à 19:28 signalée par Qrator est une preuve du moment où l’événement est devenu visible depuis ses points de vue. Elle n’identifie pas quand un changement interne a été saisi, validé ou distribué. De même, la durée d’environ une heure décrit l’observation externe. Elle ne permet pas d’établir la période exacte pendant laquelle chaque route individuelle était présente dans chaque base d’informations de routage.

L’absence d’une chronologie routeur par routeur est déterminante. Sans cela, aucune conclusion fiable ne peut être tirée sur le premier voisin acceptant, la séquence d’évaluations de politique, quelles routes ont été retirées ou corrigées en premier, ou si certains réseaux ont continué à relayer l’événement alors que d’autres l’avaient arrêté. Une reconstruction responsable préserve ces lacunes au lieu de transformer une trace de monitoring en journal interne imaginaire.

Ce que la propagation observée établit

Les observations du chemin AS établissent que l’information d’accessibilité inattendue n’est pas restée confinée à un seul réseau. BGP est un protocole distribué: une UPDATE acceptée par un système autonome peut devenir une entrée au processus de décision d’un autre système et, selon la politique, être annoncée à des voisins supplémentaires.[12] La propagation AS12389–AS20764–AS174–AS3356 signalée marque donc une suite de décisions opérationnelles à travers des domaines administratifs distincts.[1]

Cette suite ne prouve pas que tous les réseaux nommés ont accepté chacun des 8 870 préfixes ou qu’un chemin identique a atteint tout Internet. Elle ne révèle pas non plus pourquoi une politique d’import précis a accepté une route. Un opérateur a pu s’appuyer sur des filtres de préfixes clients, des données IRR, la validation RPKI, des exceptions manuellement maintenues, des limites larges, des hypothèses contractuelles ou une combinaison. La preuve figée ne révèle pas la configuration d’avril 2020 d’aucun upstream ou pair nommé.

La preuve de propagation reste cependant utile car elle identifie où des opportunités de confinement existaient. AS12389 contrôlait l’origine ou l’export des annonces. Chaque réseau directement connecté contrôlait son acceptance de celles-ci. Chaque annonceur ultérieur contrôlait une décision d’export différente. Les réseaux aval contrôlaient la sélection de route et toute politique de validation locale. C’est un contrôle partagé au sens technique précis: plusieurs opérateurs disposaient de mécanismes indépendants pouvant modifier au moins certains résultats de routage.

Un contrôle partagé ne se convertit pas automatiquement en responsabilité partagée par défaut. Un chemin AS visible ne révèle pas les termes d’une relation de routage, l’exactitude de l’inventaire des préfixes d’un opérateur, l’état de ses caches, ni si une route appartenait à la portion de fuites de routes apprises ou aux réémissions plus spécifiques. Il identifie un point de décision, pas la portée juridique ou morale de cette décision.

Quatre catégories de routage qui ne doivent pas être fusionnées

Le terme « leak » est souvent utilisé de manière souple, mais cet incident ne peut être interprété correctement sans séparer quatre conditions de routage. La RFC 7908 définit les route leaks autour de la propagation d’annonces de routage au-delà du périmètre prévu, notamment lorsque le chemin résultant viole l’ordre attendu entre relations client, fournisseur et peer.[17] Ce concept diffère de l’autorisation d’origine.

1. Fuite de politique de route apprise.Un réseau apprend une route légitime depuis un voisin et l’exporte vers un autre voisin en dehors du périmètre de politique prévu pour cette route. L’origine autorisée du titulaire du préfixe peut rester à la fin du chemin AS. L’erreur réside dans la portée d’exportation: le réseau intermédiaire agit en transit là où la politique n’y prévoyait pas cette action. Comme l’AS originel et la longueur de préfixe peuvent encore correspondre à un ROA, la validation de l’origine de route peut classer la route comme Valid même si le chemin est opérationnellement ou commercialement inapproprié.

2. Annonce à origine non autorisée.Un ASN annonce un préfixe que le titulaire pertinent de ressource n’a pas autorisé à annoncer. Si un ROA de couverture autorise un ASN différent, et qu’un relying party dispose de données validées actuelles, l’annonce peut être classée Invalid en raison d’une discordance d’origine.[13]-[15] Le terme technique « origin hijack » est parfois appliqué à cette condition, mais le libellé seul ne prouve ni intention malveillante, ni interception de trafic, ni comportement criminel, ni propriété légale.

3. Réémission plus spécifique.Un ASN annonce un préfixe plus long à l’intérieur de l’agrégat d’un autre réseau et se présente comme origine. Un ROA couvrant peut rendre la version plus spécifique Invalid si l’ASN d’origine diffère ou si la longueur annoncée dépasse lemaxLengthautorisé. Un sous-préfixe plus spécifique peut attirer la sélection de route parce que la correspondance du préfixe le plus long intervient avant la comparaison path classique BGP. Le registre public ne permet pas d’établir le but de chaque réémission ni l’effet sur le plan de données de chaque préfixe.

4. Fuite de politique à origine valide.Le préfixe, l’ASN d’origine et la longueur sont autorisés, mais le chemin AS ou la relation d’export viole la politique voulue. C’est la démonstration la plus claire de la frontière de ROV. La validation d’origine répond à la question de savoir si l’origine est autorisée au regard des ROA disponibles. Elle ne répond pas à savoir si un AS intermédiaire était habilité à fournir du transit, si le chemin suivait une relation admise, ou si la route devait être exportée vers ce voisin.

Les analyses publiques indiquent que les observations d’avril 2020 comprenaient un mélange de routes apprises et de réémissions plus spécifiques.[4] La répartition exacte est inconnue. Il serait donc inexact de décrire l’ensemble des 8 870 routes comme des origines non autorisées, comme des fuites de politique à origine autorisée, ou comme toutes en état RPKI Invalid. Chaque description remplacerait une distribution non résolue par une catégorie uniforme non appuyée par les preuves.

NotFound doit aussi rester distinct. Quand aucun ROA valide de couverture n’existe, la validation d’origine retourne habituellement NotFound.[14] Cet état est fréquent dans un système où les couvertures ROA ne sont pas complètes. Il n’est pas une preuve positive d’autorisation d’origine, mais il n’est pas non plus un résultat Invalid et n’identifie pas à lui seul un comportement répréhensible. Un réseau peut adopter une politique locale pour les routes NotFound, mais l’état signifie uniquement que l’ensemble ROA validé disponible n’offrait aucune autorisation couvrant l’annonce à tester.

Ces catégories définissent la portée des contrôles potentiels. Des filtres d’origine fondés sur un inventaire client convenu pouvaient contenir à la fois des origines non autorisées et des routes apprises exportées à tort sur une frontière client. La ROV pouvait identifier certaines annonces à origine non autorisée ou à longueur excessive quand des ROA adéquats existaient. Les contrôles de relation de chemin pouvaient traiter les fuites de politique à origine valide. Aucune catégorie unique ne couvre nécessairement l’ensemble du mélange.

Ce que pouvait établir la validation d’origine RPKI

La RPKI fournit une structure cryptographiquement appuyée par laquelle les titulaires de ressources d’adresse peuvent créer des Route Origin Authorisations. Un ROA exprime qu’un ASN donné est autorisé à annoncer un préfixe, sous réserve d’une longueur maximale de préfixe.[13] Un relying party récupère et valide le matériel RPKI, produit des paquets ROA validés et rend ces informations disponibles aux systèmes de routage ou moteurs de politique. RIPE NCC exploite les services de certification et de gestion de ROA pour les ressources de sa zone de service, mais ne programme pas centralement les routeurs de tous les réseaux entités.[10]

Par rapport à un jeu de données validé précis, la validation d’origine peut produire trois résultats pertinents. Une route estValidquand une autorisation couvrante permet l’ASN d’origine observé et la longueur de préfixe. Elle estInvalidquand des autorisations couvrantes existent mais qu’aucune ne permet la combinaison ASN d’origine/longueur. Elle estNotFoundquand aucune autorisation couvrante n’est disponible.[14] Il s’agit d’assertions relatives aux données détenues par un relying party à un moment donné, pas de propriétés intemporelles de la route.

Cette qualification compte lors d’un incident de gestion des enregistrements. Deux réseaux dépendants peuvent posséder temporairement des vues validées différentes parce que leurs temps de synchronisation, états de cache, comportement d’expiration ou réponses opérationnelles divergent. La RFC 7115 rappelle l’importance opérationnelle du traitement par les relying parties et des informations validées.[15] La preuve figée ne révèle pas le contenu exact des caches vus par chaque réseau au moment de l’observation d’une heure de Rostelecom.

L’affirmation selon laquelle un opérateur nommé a « vu un Invalid » requiert donc une preuve sur les données validées de cet opérateur et sa politique au moment pertinent.

La ROV fournit une preuve d’origine utile. Si une annonce AS12389 pour un préfixe couvert entrait en conflit avec l’ASN autorisé, ou si une version plus spécifique dépassait unmaxLengthapplicable, un opérateur qui applique la politique pouvait potentiellement la rejeter comme Invalid. Cette affirmation conditionnelle suppose l’existence du ROA pertinent, son expression correcte, sa livraison à un cache de relying party actuel, son intégration dans la politique de routage et son application sans exception dominante. Enlever l’un de ces éléments peut modifier le résultat en direct.

Un résultat Valid prouve bien moins qu’une « route sûre ». Il ne valide pas la séquence AS intermédiaire. Il ne certifie pas les relations client-fournisseur ou peer-to-peer. Il ne montre pas qu’un réseau intermédiaire était habilité à exporter une route apprise. Il ne démontre pas non plus que le chemin de données a atteint la destination voulue, qu’aucune diversion n’a eu lieu ou que les contacts opérationnels auraient répondu. Une origine autorisée peut apparaître derrière un chemin non voulu.

Un résultat Invalid a également une signification bornée. Il signale un conflit avec les autorisations validées couvrantes disponibles pour le relying party. Il peut provenir d’une origine non autorisée, d’une longueur excessive, d’un état opérationnel périmé, ou d’un ROA erroné. Il ne prouve pas, en soi, intention, interception ou comportement criminel. Les opérateurs doivent encore appliquer gestion des changements, gestion des exceptions et enquête pour distinguer attaque, erreur de configuration ou erreur d’enregistrement.

NotFound apporte la preuve d’origine la moins spécifique. Aucun ROA validé de couverture n’existe dans la vue du relying party, donc la ROV ne peut ni confirmer ni contredire l’origine via un ROA. Traiter toutes les routes NotFound comme hostiles relèverait d’un choix local de politique distinct, pas d’une implication de l’état de validation. Cela ferait aussi courir le risque de rejeter des routes ordinaires pour des espaces d’adressage sans couverture ROA.

La suppression des ROA par RIPE NCC illustre cette distinction. Supprimer 2 669 ROA peut faire passer certaines routes de Valid ou Invalid à NotFound dans les vues de relying parties après synchronisation, selon les enregistrements couvrants restants et le moment des caches.[3][5] Cela n’a pas créé les annonces BGP d’AS12389, ni provoqué l’exportation de celles-ci par des réseaux intermédiaires, ni modifié l’ensemble complet des AS paths. Pour l’événement Rostelecom, l’intersection documentée était seulement trois titulaires PI et 12 préfixes, et les analyses ultérieures n’ont trouvé aucun lien direct entre les incidents.[4][5]

Une ROV universelle ne peut donc pas être considérée comme ayant empêché cet incident dans son intégralité. Elle a pu contraindre la sous-partie impliquant les annonces Invalid sous des ROA valides et des politiques applicatives en vigueur. Elle n’aurait pas rejeté naturellement une fuite de route apprise dont l’origine autorisée restait inchangée. Elle ne valide pas non plus le chemin AS complet. Cette frontière n’est pas une faiblesse de la preuve; c’est la description correcte de ce pour quoi le mécanisme était conçu.

Cause racine

La séquence initiale interne chez Rostelecom est inconnue. Les sources publiques n’identifient pas un changement de configuration, une commande, un routeur, une décision de revue ou une défaillance d’automatisation précis. Elles montrent un comportement d’annonces AS12389 observé de manière externe et sa propagation ultérieure, pas le mécanisme interne qui l’a généré. L’analyse du facteur causal racine ne peut donc pas être réduite à une action ou un individu nommé à partir des éléments disponibles.

Au niveau observable, l’incident a commencé par un comportement d’origine ou d’export AS12389 qui a introduit des routes inattendues en BGP, y compris des éléments interprétés comme fuite de routes apprises et réémissions plus spécifiques.[1][4] L’acceptation et l’exportation ultérieurs d’autres réseaux ont élargi la portée visible. Il s’agit d’une séquence d’événement soutenue par des observations de routage; ce n’est pas une détermination complète de cause racine.

L’incident RIPE NCC avait une séquence technique différente. Une mise à jour logicielle du registre a classé certaines affectations provider-independent comme non certifiables et supprimé 2 669 ROA.[3][5] Cette défaillance de logiciel et de gestion des enregistrements a modifié les données RPKI, tandis que l’incident Rostelecom a modifié des annonces BGP en direct. Les analyses ultérieures n’ont trouvé aucun lien causal direct entre les deux.[4][5] Les regrouper en une seule cause racine contredirait le registre documenté.

Conditions contributives

La première condition contributive fut la dépendance de BGP aux politiques locales à chaque frontière de réseau. BGP distribue l’accessibilité, mais les opérateurs décident de ce qu’ils acceptent, privilégient et annoncent.[12] Une route qui devait rester dans une seule relation de politique peut se propager quand des configurations successives la permettent. Le passage observé par AS20764, AS174 et AS3356 démontre plusieurs points d’acceptation et d’export, bien que les politiques spécifiques de chacun ne soient pas révélées.[1]

La deuxième condition fut la pertinence inégale de l’autorisation d’origine. Les routes avec des ROA conflictuels et couverts pouvaient être candidates au rejet ROV. Les fuites de politique à origine autorisée ne le seraient pas. Les routes sans ROA de couverture seraient en NotFound. Le mélange inconnu de catégories signifie qu’aucune analyse défendable ne peut attribuer un remède de validation unique à l’ensemble.

La troisième condition fut la dépendance à des données opérationnelles courantes. Un ROA correctement créé n’a aucun effet de routage tant que les relying parties le récupèrent et le valident, que les caches restent à jour, que les routeurs reçoivent le résultat et que la politique locale en tient compte. La suppression RIPE NCC a temporairement affecté la couche d’enregistrement; la synchronisation des caches et l’application locale ont déterminé quand et si ce changement affectait les décisions d’un réseau.[3][10][15]

La quatrième condition fut la visibilité fragmentée. Les fournisseurs de monitoring peuvent observer des annonces anormales depuis des points de vue choisis et avertir les opérateurs, mais ils ne contrôlent pas chaque Adj-RIB-In de routeur, base de routage local, table de forwarding ou historique de configuration. L’alerte Qrator a fourni une preuve externe exploitable.[1] Elle ne pouvait pas reconstruire indépendamment la panne interne déclenchante ni garantir la convergence simultanée de tous les réseaux touchés.

La cinquième condition fut la dépendance mutuelle entre filtres. Les filtres préfixes clients, contrôles de préfixe maximum, registres d’Internet, validation RPKI et contrôles de politiques d’export peuvent se compléter.[11][16] Le registre public n’établit pas lesquels étaient présents, absents, contournés ou mal paramétrés chez Rostelecom et les réseaux de propagation en avril 2020.

Événement déclencheur

Le déclencheur immédiat interne chez Rostelecom reste non identifié. Il ne pouvait pas être attribué de façon responsable à une personne, une commande, un routeur, un contrat ou une intention sur la base des preuves publiques. Le premier évènement externe défendable est l’apparition des annonces AS12389 pertinentes aux points d’observation de Qrator vers 19:28 UTC.[1]

Le « déclencheur » ne doit pas être confondu avec la « condition ». Une politique de voisinage permissive, une couverture ROA incomplète, des données périmées ou une surveillance limitée peuvent permettre qu’un événement se propage ou retarde son confinement, mais aucune de ces conditions ne prouve ce qui a initié les annonces. De même, la suppression séparée des ROA fut contemporaine, pas le déclencheur documenté du comportement AS12389.[4][5]

Détection

Qrator a déclaré avoir détecté l’événement en temps réel et averti Rostelecom.[1] Ses mesures ont fourni le début approximatif, la durée, l’échelle et la chaîne de propagation visibles qui servent d’ancrage à la reconstruction publique. CERT-EU a ensuite résumé l’événement et noté à la fois l’incertitude sur le caractère accidentel et la coopération de Rostelecom avec la société rapporteuse.[2]

La détection externe est un contrôle de continuité important car la vue interne d’un opérateur peut ne pas montrer comment ses voisins ou des réseaux éloignés reçoivent ses routes. Sa limite est également essentielle: une alarme de monitoring prouve la visibilité depuis les points du système de surveillance. Elle ne révèle ni l’heure exacte du déclencheur interne, ni chaque décision de sélection aval, ni l’impact complet sur le plan de données. Une détection robuste combine donc télémétrie locale session/politique et observations de routes indépendantes.

Réponse

Qrator a indiqué que Rostelecom a travaillé avec lui pour dépanner et restaurer après la réception de l’alerte en temps réel.[1] Cela étaye un constat de coordination d’incident. Cela ne dévoile pas la chaîne d’escalade interne, l’identité des intervenants, la configuration inspectée, la mesure corrective retenue ni le moment exact de chaque étape.

La réponse des réseaux de propagation n’est pas documentée avec un niveau de détail comparable dans le registre figé. Leurs options opérationnelles ont pu inclure filtrage des annonces, modification de préférence de route, contact avec les réseaux adjacents ou attente d’annonces corrigées, mais il serait spéculatif d’affirmer qu’un opérateur nommé a utilisé une méthode précise. La responsabilité exige de séparer les contrôles disponibles des actions démontrées.

La réponse de RIPE NCC a suivi sa propre chronologie. Elle a enquêté sur les ROA manquants, les a restaurés le 2 avril et a ensuite décrit des améliorations de monitoring.[3][5] Cette réponse concernait l’intégrité et la disponibilité des enregistrements RPKI. Elle n’était pas le mécanisme de routage par lequel les annonces AS12389 ont été corrigées.

Récupération

L’observation d’environ une heure par Qrator et son récit de dépannage et de restauration soutiennent la conclusion selon laquelle l’événement de routage visible a été ramené sous contrôle dans cet intervalle large.[1] Ils ne permettent pas d’identifier si la récupération est venue de retraits, d’annonces corrigées, de changements de politique d’export ou d’une combinaison. Ils ne prouvent pas non plus une convergence simultanée sur chaque réseau.

La récupération opérationnelle a au moins trois couches. La couche d’annonce demande l’arrêt ou la correction des routes inattendues. La couche de propagation dépend des voisins et des réseaux aval pour traiter le changement. La couche de preuve exige une surveillance confirmant que les chemins anormaux ont disparu sur des points de vue utiles.[1] Une déclaration basée sur un seul routeur local peut manquer une propagation résiduelle; une déclaration basée uniquement sur des collecteurs externes peut manquer des états internes.

La récupération du service RPKI était distincte: RIPE NCC a restauré les ROA supprimés le 2 avril.[3][5] Les relying parties ont ensuite dépendu de leur propre synchronisation et validation pour recevoir l’état réparé. La restauration au niveau du dépôt et la convergence sur chaque relying party sont liées mais pas identiques.

Allocation du contrôle pratique

La responsabilité devient plus claire quand le contrôle est alloué par décision plutôt que par étiquette institutionnelle large.

Cette allocation évite deux erreurs opposées. La première consiste à concentrer toute la responsabilité dans le réseau d’origine et à ignorer les décisions d’acceptation indépendantes qui ont rendu la propagation possible. La seconde consiste à diluer le contrôle si largement qu’aucune décision n’a de propriétaire. Rostelecom a contrôlé ce qu’AS12389 annonçait ou exportait. Chaque voisin contrôlait sa propre acceptation. Chaque réseau ultérieur contrôlait une autre décision de propagation. Le titulaire de registre contrôlait la disponibilité des enregistrements d’origine.

Les relying parties contrôlaient si ces enregistrements influençaient le routage.

Le contrôle sur une couche ne signifie pas contrôle sur une autre. Un titulaire de préfixe peut publier un ROA correct mais ne peut pas contraindre chaque réseau à le récupérer ou à l’appliquer. RIPE NCC peut restaurer un enregistrement supprimé mais ne peut pas retirer directement une route BGP d’un opérateur non connecté. Un fournisseur de monitoring peut alerter Rostelecom mais ne peut pas exécuter un rollback. Un amont peut rejeter une route à sa frontière mais ne peut pas réparer la configuration d’origine. La continuité opérationnelle émane de la combinaison de ces contrôles.

Cette allocation fixe aussi une limite à l’inférence. La présence d’un AS dans un chemin rapporté est une preuve que son identifiant réseau apparaît dans l’observation. Elle n’est pas, en soi, preuve de l’état d’esprit d’un employé, d’une violation contractuelle ou d’une responsabilité légale. Ces conclusions nécessiteraient des enregistrements au-delà des preuves de routage considérées ici.

Preuve de cause racine versus preuve contributive

La preuve de cause racine doit identifier le mécanisme interne qui a produit pour la première fois le comportement AS12389 inattendu: par exemple, une différence de configuration, un log d’automatisation, un historique de commits, une trace de session avec horodatage correspondant. Aucun de ces éléments n’est présent dans le registre public. Les observations externes des routes établissent l’événement et son extension, mais ne remplissent pas cet écart de preuve interne.

La preuve contributive a une fonction différente. Une route acceptée et exportée par des réseaux successifs montre que les politiques actives le long du chemin observé ne la retenaient pas aux frontières précédentes. Une annonce Invalid visible au-delà d’un réseau validateur peut poser des questions sur la fraîcheur des données, l’application ou les exceptions, mais seulement si l’état RPKI réel de ce réseau est connu. Une fuite à origine valide qui passe ROV montrerait au contraire que l’autorisation d’origine n’était pas le contrôle approprié pour cette portion.

La preuve de déclenchement relierait une action interne au premier update inattendu. La preuve de détection indiquerait quand les systèmes de monitoring ont identifié l’anomalie. La preuve de réponse enregistrerait contacts, décisions et changements. La preuve de récupération montrerait un retrait ou une correction sur vues locales et externes. Garder ces classes de preuve séparées rend compte-rendu testable et évite qu’un horodatage de détection se fasse passer pour l’instant de déclenchement.

Remédiation mesurable

L’incident soutient une remédiation en couches, mais les mesures doivent être exprimées comme contrôles observables plutôt que comme affirmations de faute.

Premièrement, un réseau d’origine ou de transit peut maintenir un inventaire de préfixes par voisin et tester à la fois la politique d’import et d’export avant déploiement. Les mesures utiles incluent le nombre de préfixes autorisés par voisin, les changements par rapport à une base d’approvisionnement approuvée, les ASN d’origine inattendus, les annonces plus spécifiques et les routes dont la classification de relation change durant une mise à jour prévue. Un test doit distinguer les routes originées localement de celles apprises ailleurs.

Deuxièmement, les opérateurs peuvent mesurer la contention aux frontières externes. Les sessions client et peer peuvent être vérifiées pour des comportements de refus par défaut, des listes d’autorisation explicites, des seuils max-prefix et des règles d’export qui empêchent l’envoi de routes apprises client/peer vers une relation inappropriée. Les pratiques générales de filtrage et de validation décrites dans les guides opérationnels fournissent un modèle en couches plutôt qu’un contrôle universel unique.[11][16]

Troisièmement, les opérations RPKI peuvent être mesurées de bout en bout. Les indicateurs pertinents incluent l’âge de synchronisation du dépôt, la progression des séries temporelles de cache, la disponibilité des flux de validation, le nombre de routes Valid, Invalid et NotFound par session, les exceptions de politique, et les alertes sur changements brusques de couverture ROA. Un enregistrement existant au système émetteur est insuffisant si un cache périmé ou un moteur de politique déconnecté l’empêche d’influencer les décisions en direct.[10][15]

Quatrièmement, les titulaires de préfixes peuvent réviser si les ROA reflètent les origines actuelles et si lemaxLengthn’est pas plus large que nécessaire. Une autorisation plus étroite peut rendre certaines plus spécifiques non autorisées invalides, mais une valeur trop restrictive peut aussi invalider des annonces légitimes de traffic engineering. Le réglage correct dépend des plans de routage réels, et l’analyse ultérieure demaxLengthet de l’exposition aux sous-préfixes forgés confirme la nécessité de le traiter comme un choix opérationnel précis.[20]

Cinquièmement, la réponse d’incident peut être évaluée avec des mesures temporelles: temps entre la première mise à jour anormale et l’alerte interne; temps jusqu’à une observation externe corroborante; temps pour contacter le voisin concerné; temps pour identifier la politique affectée; temps pour arrêter la propagation; et temps pour confirmer la récupération sur plusieurs points de vue. Le récit Qrator montre la valeur d’un avertissement en temps réel et de la coordination sans révéler tous ces intervalles.[1]

Un enregistrement post-incident utile préserverait la première mise à jour observée, l’état de configuration, les résultats d’évaluation de politiques de route, l’état du cache RPKI, les contacts opérateurs, le changement correctif et la vérification externe finale. De telles preuves permettraient à une revue ultérieure de distinguer échec d’origine, échec d’export, échec d’acceptation, données RPKI obsolètes et coordination retardée. Sans elles, les enquêteurs sont contraints d’inférer des causes internes depuis des observations globales partielles.

Ces mesures restent neutres sur l’intention et la responsabilité. Elles interrogent l’existence d’un contrôle, son fonctionnement, la visibilité de sa sortie et la rapidité de la récupération du système. C’est une méthode de responsabilité plus solide qu’un postulat selon lequel une anomalie de route prouve nécessairement une malveillance ou qu’une technologie de sécurité devait empêcher chaque catégorie de route.

Preuve de registre et réalité opérationnelle

Les objets de registre et les ROA sont une preuve essentielle. Un enregistrement de base associe des informations administratives à une ressource réseau, tandis qu’un ROA exprime l’autorisation d’origine d’un titulaire de ressource.[8][13] Exactitude, unicité et métadonnées de sécurité courantes rendent ces enregistrements utiles aux opérateurs et enquêteurs. Ils aident à déterminer qui est enregistré pour une ressource et quel ASN est autorisé à annoncer un préfixe.

Les enregistrements n’opèrent pas Internet par décret. Un speaker BGP applique sa politique en cours aux mises à jour reçues. Un relying party doit obtenir des données RPKI actuelles. Un routeur doit recevoir les résultats de validation. Un opérateur doit décider quoi rejeter, préférer ou enquêter. Les filtres d’export doivent encoder les relations prévues, et la surveillance doit révéler quand la propagation effective diverge de ces intentions. La récupération coordonnée doit ensuite transformer la preuve en action corrective.

La suppression distincte des ROA RIPE NCC souligne les deux faces de cette structure. Le registre et le service RPKI étaient pertinents car la suppression d’autorisations pouvait modifier la preuve d’origine disponible pour les relying parties. Pourtant, cette suppression n’a pas réécrit centralement les AS paths ni obligé les réseaux à accepter les annonces AS12389. La continuité opérationnelle dépendait de la restauration des enregistrements, des caches actuels, de la politique de routage locale, des filtres actifs et de la coordination de la réponse.

Cette lecture basée sur la couche réelle évite de traiter le registre comme une autorité souveraine de contrôle de chemin. Elle évite aussi de rejeter les enregistrements comme non pertinents parce que l’application est locale. Les ROA peuvent fournir une preuve vérifiable par machine qui rend certaines incohérences d’origine actionnables. Leur valeur est maximale lorsque la précision des enregistrements, la distribution, l’état des caches et la politique opérateur sont tous mesurables.

Contexte de conception ultérieur, non exigences rétroactives

La RFC 8212 décrit une posture de rejet par défaut pour les sessions BGP externes lorsque la politique d’import ou d’export n’a pas été explicitement configurée.[18] En tant que contexte de conception, cette approche réduit le risque qu’une relation incomplètement spécifiée échange des routes par défaut. Elle est pertinente pour la discipline future des configurations, mais n’est pas une preuve que chaque opérateur nommé a déployé ce comportement en avril 2020 ni un standard de responsabilité rétroactif.

La RFC 9234 a ensuite précisé les RPKI Roles et le mécanisme Only-to-Customer, fournissant des signaux de protocole destinés à aider à identifier et prévenir certaines fuites de routes selon la structure de relation.[19] Cette initiative traite une information que la ROV ne porte pas: la conformité d’un chemin aux rôles déclarés. Elle ne doit pas être présentée comme une exigence d’avril 2020, une preuve de la cause de l’événement ni un mécanisme connu pour les sessions observées.

La RFC 9319 a ensuite analysé les considérations opérationnelles autour dumaxLengthRPKI et de l’exposition aux sous-préfixes à origine forgée.[20] Elle aide à expliquer comment une autorisation couvrante peut ou non contraindre une annonce plus spécifique. Elle n’établit pas la configuration ROA exacte de chaque préfixe affecté en 2020, ni ne transforme le nombre de 8 870 routes en compteur de routes Invalid.

Ensemble, ces documents ultérieurs montrent pourquoi une conception en couches est nécessaire. La politique par défaut de rejet peut traiter une configuration de relation manquante. Les rôles BGP et les signaux de chemin peuvent traiter certaines fuites de politique de portée. La RPKI peut traiter certains conflits d’origine et violations de longueur. La surveillance et la coordination restent nécessaires car aucun mécanisme ne valide chaque propriété d’une route.

Ce que cet article ne confond pas

L’événement de 2020 est distinct de l’anomalie financière de routage de Rostelecom en 2017. Ce dernier concernait une autre période, un autre ensemble de routes affectées, une autre durée et une autre question d’attribution. Il n’est pas repris ici, et les éléments de preuve de cet épisode ne peuvent pas être utilisés pour inférer intention, causalité récurrente ou responsabilité pour l’incident du 1er avril 2020. L’analyse est limitée à la chaîne de propagation AS12389 observée, sa période d’environ une heure et les contrôles pertinents pour cet évènement précis.

L’article est également distinct d’une analyse générique des erreurs de configuration ROA et des dépendances de mode commun. La suppression RIPE NCC n’a ici une importance que comme incident contemporain distinct, avec une intersection mesurée de trois titulaires PI et 12 préfixes.[4][5] Une théorie plus large d’erreurs de création de ROA masquerait la question concrète: quelles portions de cet événement de routage mixte la validation d’origine pouvait-elle identifier, et lesquelles nécessitaient un filtrage basé sur la politique de chemin et les frontières d’acceptation.

La distinction protège le noyau factuel de l’événement. Le test de responsabilité de 2020 dépend des annonces AS12389, de la propagation via AS20764, AS174 et AS3356, des catégories de routes différenciées, de la dépendance temporelle de l’état des ROA et de décisions de routage indépendamment contrôlées. Sans ces éléments, l’analyse devient soit un récit d’un autre incident Rostelecom, soit une dissertation abstraite sur la RPKI.

Incertitudes essentielles

La séquence de panne initiale interne reste inconnue. La répartition exacte entre fuites de routes apprises et réémissions plus spécifiques reste inconnue. L’ensemble des chemins de forwarding affectés et des symptômes utilisateur reste inconnu. L’état RPKI visible par chaque relying party à chaque moment reste inconnu. Les filtres d’import et d’export configurés par chaque réseau de propagation restent inconnus.

La chronologie complète de la réponse n’est pas non plus disponible. Qrator a documenté l’alerte en temps réel, la coopération, le dépannage et la restauration, mais pas chaque décision interne.[1] Les preuves ne permettent pas d’établir une personne responsable, une interception intentionnelle, un acte criminel, une négligence ou une responsabilité légale. Elles ne mesurent pas une panne de service pour chaque service dont les routes ont pu figurer dans l’ensemble affecté.

Il ne s’agit pas de simples réserves. Elles définissent la frontière entre comportement d’infrastructure observé et spéculation. Une analyse précise peut identifier des détenteurs de contrôle et les opportunités de confinement tout en laissant ouvertes les conclusions sur intention et les implications juridiques.

Conclusion

L’incident de routage de Rostelecom le 1er avril 2020 a montré que la preuve d’origine et la preuve de politique de route répondent à des questions différentes. Qrator a observé un important événement AS12389 commençant autour de 19:28 UTC, d’une durée d’environ une heure et se propageant via Rascom, Cogent et Level 3. Il a compté 8 870 préfixes associés à près de 200 systèmes autonomes et rapporté une coordination temps réel avec Rostelecom.[1] Ces observations établissent l’échelle, la propagation et la réponse, mais pas une cause interne complète.

La suppression simultanée de 2 669 ROA RIPE NCC était un incident opérationnel séparé. Les analyses ultérieures n’ont trouvé aucun lien direct avec la fuite Rostelecom et n’ont identifié que trois titulaires PI en intersection et 12 préfixes. Ces éléments empêchent à la fois la confusion causale et la revendication selon laquelle toutes les routes affectées étaient Invalid.[3]-[5]

La ROV aurait pu fournir une preuve actionnable pour certaines origines non autorisées ou certaines plus spécifiques à longueur excessive lorsque des ROA de couverture actuels et des politiques d’application étaient en place. Elle ne pouvait pas valider les AS paths complets ni rejeter chaque fuite de politique à origine valide. La responsabilité résiduelle se situait dans les politiques d’import/export en cours, les filtres sensibles à la relation, la fraîcheur des caches, la surveillance des routes et la récupération coordonnée.

La leçon de responsabilité est donc distribuée mais concrète. Rostelecom détenait ses décisions d’annonce et d’export. Les réseaux de propagation détenaient leurs décisions de frontière. Les titulaires de préfixes détenaient l’exactitude de leurs autorisations et de leurs contacts. RIPE NCC détenait la fiabilité de ses services de certification et de gestion de ROA. Les relying parties détenaient la fraîcheur des données et l’application. Les fournisseurs de monitoring détenaient la qualité et la rapidité de leurs observations et alertes.

Aucun ne contrôlait l’ensemble du système, mais chacun contrôlait une part identifiable de la continuité opérationnelle.