La fuite de route financière de Rostelecom en 2017 a fait des preuves d'attribution un test de responsabilité

Résumé

• BGPMon a situé l'événement AS12389 entre 22:36 et environ 22:43 UTC le 26 avril 2017. Il a compté 50 préfixes affectés dans 37 systèmes autonomes. ThousandEyes a utilisé un cadre différent: il a observé 137 préfixes originaires d'AS12389 pendant la fenêtre, en a traité environ 100 comme ordinaires ou associés à des organisations russes, et a identifié 36 préfixes d'entreprises extérieures. Ces dénominateurs décrivent des sélections différentes et ne doivent pas être fusionnés. [1][2]
• Le mécanisme infrastructurel direct était la fausse origination et propagation de routes. Certaines annonces étaient des routes plus spécifiques. BGPMon a mis en évidence 203.112.90.0/24 par rapport à un /23 normalement annoncé, une distinction qui aide à expliquer pourquoi une sélection de route ordinaire pourrait préférer la fausse route sans aucune compromission du service affecté lui-même. [2]
• ThousandEyes a observé des pairs, dont Cogent, Hurricane Electric et Tata, acceptant et propageant les annonces d'AS12389. Ses mesures de chemins ont montré que le trafic pour au moins un service e-commerce affecté entrait dans Rostelecom avant d'atteindre la destination prévue. Cela soutient le détournement d'une partie du trafic de production, et non l'affirmation selon laquelle chaque route, utilisateur ou paquet a été détourné. [1]
• Les services financiers, de paiement, de commerce électronique, de sécurité web et liés aux certificats étaient représentés parmi les préfixes affectés. Les exemples nommés dans les rapports incluaient Mastercard, Visa, BNP Paribas, HSBC, Symantec et GeoTrust. Les preuves de routage ne montrent pas que les systèmes internes de ces organisations aient été compromis. [1][2]
• Les preuves confirmées consistent en des observations d'origine AS12389, la courte fenêtre d'événement, certaines annonces plus spécifiques, la propagation par plusieurs pairs et des changements de chemin mesurés. Une défaillance de routage ou de configuration est une explication plausible. Le ciblage délibéré et l'interception restent contestés. L'identité de l'acteur, le déclencheur interne, l'inspection des paquets, le contenu déchiffré, les effets sur les transactions, les pertes et la remédiation durable restent inconnus.
• La concentration de destinations financières et liées à la sécurité a rendu le motif suspect aux yeux de BGPMon et ThousandEyes. BGPMon a également observé des annonces impliquant d'autres systèmes autonomes liés à Rostelecom, ce qui soutient l'hypothèse concurrente d'une défaillance interne accidentelle. Aucune des organisations de surveillance ne disposait des enregistrements internes de modification, d'authentification ou de configuration de l'opérateur. [1][2]
• La responsabilité suit le contrôle pratique, non une conclusion non étayée sur le motif. Rostelecom contrôlait la création et l'exportation des routes au sein d'AS12389. Les pairs acceptants contrôlaient les filtres, la validation, l'acceptation et la propagation des routes. Les détenteurs de préfixes contrôlaient les données d'autorisation, la surveillance externe et l'escalade. Les moniteurs indépendants contrôlaient la qualité et la préservation des observations externes.
• RPKI peut aider un réseau à évaluer si une origine est autorisée par une autorisation d'origine de route correspondante, mais elle ne prouve pas l'intention ni le mécanisme interne. L'événement est également antérieur à l'application généralisée de la validation d'origine de route. L'état historique des ROA de chaque préfixe affecté et la politique de validation de chaque pair devraient être établis avant d'affirmer que RPKI aurait bloqué une route particulière. [11]-[14][18]
• Le préjudice étayé est une perte temporaire du contrôle de routage prévu et une exposition d'une partie du trafic à un chemin de transit non autorisé. Le dossier n'établit pas de fraude de transaction, de vol d'identifiants, de compromission TLS, de données modifiées, de panne complète, de population affectée quantifiée ou de dommages financiers. Le chiffrement peut réduire l'exposition du contenu, mais les preuves disponibles n'établissent pas quelles sessions utilisaient un chiffrement efficace.
• Un compte rendu décisif nécessiterait des enregistrements que les observations publiques de routage ne peuvent fournir: journaux de modification et d'authentification d'AS12389, rapport d'analyse des causes racines, journaux de filtres et de sélection de route des pairs, analyse d'archives reproductible, état historique des ROA, enregistrements de trafic et TLS côté service, captures de paquets, enregistrements d'incidents clients, et preuves sur le fait que les chemins mesurés transportaient du trafic de production.

Sept minutes ont créé un problème de preuve durable

L'événement a été court, mais sa structure probante reste importante. BGPMon a situé le début à 22:36 UTC et la fin à environ 22:43 UTC le 26 avril 2017. Pendant cet intervalle, les collecteurs de routes et les systèmes de surveillance ont vu AS12389 annoncer l'accessibilité pour des espaces d'adressage associés à d'autres systèmes autonomes. Plusieurs réseaux externes ont accepté au moins certaines de ces annonces et les ont propagées. ThousandEyes a également mesuré des chemins de bout en bout modifiés plutôt que de se fier uniquement aux mises à jour du plan de contrôle. [1][2]

Ces observations établissent plus qu'une vague anomalie de routage. Elles identifient un système autonome d'origine, une fenêtre temporelle, des préfixes annoncés, une propagation et une conséquence de chemin. Les données de routage distribuées peuvent donc soutenir une conclusion solide sur ce qui a été dit à l'Internet: AS12389 s'est présenté comme une origine pour des routes qui ne faisaient pas partie de son ensemble autorisé ordinaire, y compris des espaces d'adressage utilisés par des organisations extérieures à Rostelecom.

Les mêmes observations établissent moins que ce que de nombreuses descriptions impliquent. Une mise à jour BGP ne contient pas le motif d'un opérateur. Un chemin modifié ne révèle pas qui a saisi une commande, quel système l'a générée, si un compte a été mal utilisé, ou si une configuration planifiée a échappé à son périmètre prévu. Même un ensemble suspect de destinations ne divulgue pas la décision interne qui a produit l'ensemble.

La distinction est importante car les mots utilisés pour décrire un incident de routage peuvent silencieusement une conclusion. « Fuite » peut décrire la propagation de routes qui n'auraient pas dû être exportées. « Détournement » peut décrire une fausse origination ou une route qui détourne le trafic, mais il est souvent perçu comme une preuve d'intention hostile. Le dossier observable soutient les annonces de fausse origine et le détournement de trafic. Il n'établit pas en soi une saisie délibérée, de l'espionnage ou un plan pour cibler des institutions financières.

Des évaluations ultérieures de CERT-EU et ENISA ont placé l'événement dans des discussions plus larges sur le détournement BGP et le risque de sécurité de routage. Ces descriptions sont utiles en tant qu'évaluations institutionnelles attribuées. Elles ne remplacent pas les journaux d'AS12389 non divulgués, les enregistrements de politique des pairs ou les preuves de trafic côté service. [4]-[6]

Le test de responsabilité approprié commence par cette asymétrie. Les preuves publiques de routage peuvent être observées et reproduites indépendamment. La cause interne et le but dépendent largement des enregistrements contrôlés par l'opérateur d'origine et les autres réseaux entités. Plus les preuves externes d'un changement de routage sont fortes, plus les questions internes sans réponse deviennent spécifiques. Cependant, les preuves externes ne doivent pas être étirées en réponses qu'elles ne peuvent fournir.

C'est pourquoi un événement de sept minutes peut rester non résolu des années plus tard. Le retrait a mis fin à la condition de routage immédiate. Il n'a pas comblé le fossé des preuves. La récupération opérationnelle et l'explication publique sont des devoirs séparés: l'un restaure le routage, tandis que l'autre montre comment la défaillance s'est produite, quel trafic a été exposé, pourquoi les contrôles ne l'ont pas contenu, et ce qui a changé par la suite.

Les deux décomptes de préfixes répondent à des questions différentes

BGPMon a compté 50 préfixes affectés dans 37 systèmes autonomes. ThousandEyes a rapporté qu'AS12389 originait 137 préfixes pendant la fenêtre pertinente, puis a séparé environ 100 qui semblaient ordinaires ou associés à des organisations russes de 36 préfixes appartenant à des organisations extérieures. [1][2]

Les chiffres sont assez proches pour tenter un seul chiffre principal et assez différents pour rendre cette manœuvre peu fiable. Le décompte de 50 préfixes de BGPMon concerne son ensemble affecté dans 37 systèmes autonomes. ThousandEyes a commencé par tous les 137 préfixes observés originaires d'AS12389, puis les a classés pour isoler 36 préfixes d'entreprises extérieures. Chaque organisation a utilisé ses propres observations et méthode de sélection. Le dossier public fourni ici ne définit pas une conversion qui transforme un dénominateur en l'autre.

Ce n'est pas un détail statistique mineur. Les décomptes font partie de l'affirmation causale. Un chiffre pour toutes les annonces vues d'un système autonome n'est pas le même qu'un chiffre pour les fausses origines suspectées. Un chiffre pour les préfixes n'est pas un chiffre pour les organisations victimes, les services, les utilisateurs, les sessions ou les paquets. Un chiffre pour les systèmes autonomes n'est pas un chiffre pour les entités juridiques. Combiner ces unités peut transformer une anomalie de routage limitée en une estimation non étayée de la population.

La formulation responsable préserve les deux mesures et nomme ce qu'elles mesurent. BGPMon a observé 50 préfixes affectés dans 37 systèmes autonomes. ThousandEyes a observé 137 préfixes originaires d'AS12389, traité environ 100 comme probablement ordinaires ou associés à la Russie, et identifié 36 préfixes d'entreprises extérieures. La différence peut refléter les points de vue, le timing, les choix de classification et de comptage, mais ces explications restent des possibilités à moins qu'une comparaison reproductible ne les démontre.

La reconstruction historique peut améliorer cette position. Le travail examiné par les pairs de Moriano et ses co-auteurs a utilisé des données historiques de BGPStream, tandis que CAIDA décrit l'accès de BGPStream aux archives de Route Views et RIPE RIS. Ces sources rendent une réanalyse reproductible possible en principe. Elles n'effacent pas la nécessité de documenter la couverture des collecteurs, les limites temporelles, les filtres de préfixes et les règles de classification. [7][8]

La discipline de comptage est un contrôle de responsabilité car elle limite les exagérations. Une réponse d'opérateur, un moniteur externe et une évaluation institutionnelle devraient tous divulguer leur dénominateur. Si leurs chiffres diffèrent, la tâche est de réconcilier les méthodes ou de préserver la différence, non de choisir le nombre qui donne à l'événement l'air le plus grand ou le plus petit.

Des routes plus spécifiques expliquent pourquoi une sélection ordinaire pouvait détourner le trafic

BGP est le système inter-domaines par lequel les réseaux échangent des revendications sur l'accessibilité des blocs d'adresses IP. Le mécanisme crucial de l'événement n'était pas simplement qu'AS12389 apparaissait quelque part dans un chemin inattendu. Il a été observé comme l'origine de routes pour des espaces d'adressage associés à d'autres systèmes autonomes. Certaines de ces routes étaient plus spécifiques que les routes de couverture normalement utilisées pour le même espace d'adressage. [1][2]

BGPMon a mis en évidence 203.112.90.0/24, alors que l'annonce normale couvrait un /23. Un /24 décrit un bloc d'adresses plus petit qu'un /23. Les routeurs préfèrent généralement la route la plus spécifique pour le trafic dont la destination se trouve dans ce bloc plus petit. Cette préférence se produit avant de nombreuses autres comparaisons de meilleur chemin. Le faux /24 pouvait donc attirer le trafic même si le /23 légitime restait visible.

Ce mécanisme est important pour la discipline d'attribution. Un chemin détourné ne nécessite pas la preuve qu'une banque lointaine, un service de paiement ou un fournisseur lié aux certificats ait été compromis. Le système de sélection de route peut envoyer le trafic vers la fausse origine car le réseau a reçu et préféré une revendication d'accessibilité plus spécifique. L'organisation affectée peut continuer à faire fonctionner ses systèmes normalement pendant que certains utilisateurs atteignent ces systèmes par un chemin de transit non intentionnel.

L'observation plus spécifique distingue également l'événement d'une affirmation vague selon laquelle AS12389 aurait simplement redistribué une route avec un chemin plus long ou inhabituel. Le RFC 7908 fournit un cadre de classification des fuites de routes, et le RFC 7454 fournit des conseils opérationnels sur la sécurité et le filtrage. Ces normes aident les opérateurs à décrire les défaillances de politique de routage et les contrôles. Elles ne déterminent pas, à partir des seules preuves publiques, quelle action interne a généré les annonces d'avril 2017 ni si l'action était intentionnelle. [9][10]

Une analyse de responsabilité devrait séparer la création, l'exportation, l'acceptation et la sélection. Premièrement, une route a été créée ou introduite dans AS12389. Deuxièmement, AS12389 l'a exportée vers ses voisins. Troisièmement, certains voisins l'ont acceptée et propagée. Quatrièmement, les routeurs en aval l'ont sélectionnée selon leurs informations et politiques locales. Cinquièmement, au moins une partie du trafic mesuré a suivi le chemin résultant.

Chaque étape a un propriétaire de preuve différent. Les enregistrements de génération et d'authentification des routes seraient les plus proches de l'origine. Les journaux de politique d'exportation et de session montreraient ce qu'AS12389 a envoyé à quel voisin. Les enregistrements des pairs montreraient l'acceptation, le filtrage et la sélection locale. Les archives des collecteurs montreraient ce qui a atteint les points d'observation externes. Les mesures actives montreraient les effets de chemin de bout en bout. Les opérateurs de services détiendraient les preuves de trafic et d'application.

Cette chaîne empêche une attribution simpliste de toute la responsabilité à un seul endroit. AS12389 était la fausse origine observée et contrôlait la première exportation. Les pairs n'ont pas créé la route, mais l'acceptation et la propagation ont élargi sa portée. Les détenteurs de préfixes n'ont pas causé l'annonce, mais leur posture d'autorisation et de surveillance pourrait affecter la détection et le rejet. Aucun entité unique ne contrôlait l'ensemble de l'Internet, mais plusieurs contrôlaient des points spécifiques où l'événement aurait pu être empêché, limité ou expliqué.

Les mesures de chemin prouvent le détournement, pas l'intention d'interception

Les observations du plan de contrôle montrent quelles routes ont été annoncées. Les mesures de chemin ajoutent des preuves sur l'endroit où le trafic a voyagé. ThousandEyes a rapporté que certains pairs, dont Cogent, Hurricane Electric et Tata, ont accepté et propagé les annonces d'AS12389. Ses mesures pour au moins un service e-commerce affecté ont indiqué que le trafic entrait dans le réseau de Rostelecom puis continuait vers la destination prévue. [1]

Cette forme de chemin est importante. Elle soutient plus qu'un risque théorique qu'une fausse route puisse attirer du trafic. Elle indique que le trafic de production mesuré a suivi un chemin de transit non autorisé. Le chemin ne s'est pas simplement terminé à AS12389 dans l'exemple cité; le trafic a ensuite atteint la destination prévue. Cela est cohérent avec un détournement suivi d'une livraison ultérieure.

La mesure ne soutient pas une déclaration universelle. Tous les réseaux n'ont pas accepté ou préféré la route. ThousandEyes a noté que l'acceptation variait. Un chemin vu d'un ou plusieurs points de mesure ne peut être étendu à une affirmation concernant tous les utilisateurs, tous les réseaux sources ou tous les paquets. Les décisions de routage varient selon l'emplacement, le fournisseur, le timing et la politique.

La livraison ultérieure ne prouve pas non plus l'interception. Le trafic passant par un réseau non intentionnel crée une opportunité d'observation ou d'interférence, mais l'opportunité n'est pas une preuve que l'inspection a eu lieu. Les données de chemin disponibles ne montrent pas de capture de paquets, d'accès au contenu, de modification, de collecte d'identifiants ou de manipulation de transactions. Elles n'identifient pas un système d'interception ou un opérateur qui en aurait utilisé un.

Le chiffrement complique encore l'évaluation des préjudices. Un chiffrement efficace peut limiter ce qu'un réseau de transit non intentionnel peut lire ou modifier, mais le dossier public de routage n'établit pas l'état de sécurité de chaque session affectée. La présence de services financiers et liés aux certificats ne prouve pas que le chiffrement a échoué. Elle ne prouve pas non plus que chaque connexion était correctement protégée. Des enregistrements TLS côté service, une télémétrie de session et des preuves de paquets seraient nécessaires pour une conclusion plus spécifique.

Le préjudice le plus sûr étayé est donc une perte du contrôle de chemin prévu et une exposition temporaire d'une partie du trafic à un chemin de transit non autorisé. C'est une conséquence réelle de sécurité réseau même sans preuve de compromission du contenu. Les utilisateurs et les opérateurs de services se fient au routage inter-domaines pour acheminer le trafic via des relations d'accessibilité attendues. Une fausse origine peut briser cette frontière de contrôle tout en laissant les serveurs d'application et les sessions chiffrées intacts.

Cette distinction protège à la fois la responsabilité et la précision. Minimiser l'événement parce qu'aucun vol de données n'a été prouvé ignore le détournement de route démontré. Qualifier l'événement d'interception parce que le trafic a traversé Rostelecom traite une capacité possible comme un acte accompli. Les preuves soutiennent la position intermédiaire: le détournement a eu lieu pour le trafic mesuré; l'inspection, le déchiffrement, l'altération et l'exploitation restent inconnus.

Quatre classes de preuves maintiennent l'attribution honnête

L'événement est mieux compris à travers quatre classes de preuves: confirmées, probables, contestées et inconnues. Mélanger ces classes est la principale voie d'une observation technique à une accusation non étayée.

Les preuves confirmées incluent les observations d'origine AS12389, la fenêtre de 22:36 à environ 22:43 UTC, les fausses annonces, certaines plus spécifiques, la propagation par plusieurs pairs et les changements de chemin mesurés. Les catégories de services nommées et les exemples sont également étayés lorsqu'ils sont liés aux rapports de surveillance. Ces conclusions dépendent d'observations distribuées plutôt que d'un accès aux systèmes privés de Rostelecom. [1][2]

Les explications probables devraient rester conditionnelles. Une défaillance interne de routage ou de configuration est un candidat plausible pour la cause racine. BGPMon a observé des annonces simultanées impliquant d'autres systèmes autonomes liés à Rostelecom, un modèle qui peut soutenir l'hypothèse d'une erreur interne plus large plutôt que d'un ensemble de cibles externes soigneusement limité. Les preuves n'établissent pas la configuration exacte, la commande ou le système qui a échoué.

Les interprétations contestées concernent le ciblage délibéré et l'intention d'interception. La concentration de destinations financières, de paiement, de commerce électronique et liées à la sécurité, combinée à des routes plus spécifiques nouvellement introduites, a rendu le motif suspect aux yeux de BGPMon et ThousandEyes. La suspicion est pertinente car elle façonne la réponse aux incidents et la préservation des preuves. Ce n'est pas une conclusion de but.

Les inconnues incluent qui a initié le changement, si cette personne était autorisée, le mécanisme interne exact, la raison des préfixes sélectionnés, si les paquets ont été inspectés, si un contenu a été déchiffré, si les transactions ont été affectées, si les utilisateurs ont perdu des données ou de l'argent, la population affectée complète selon une méthode de mesure commune, et quelle remédiation durable a eu lieu.

CERT-EU et ENISA ont ensuite utilisé un cadrage plus fort axé sur la menace dans leurs discussions institutionnelles. Ces évaluations méritent une attribution précise car les organismes publics utilisent des incidents passés pour expliquer le risque de routage. Leur cadrage ne crée pas d'accès aux journaux de modification d'AS12389 ni aux enregistrements de paquets des services affectés. Une étiquette ultérieure et catégorique ne devrait pas être traitée comme une nouvelle preuve primaire sur l'intention d'un opérateur en 2017. [4]-[6]

La revue annuelle de la sécurité de routage de l'Internet Society place l'épisode dans un modèle beaucoup plus large d'incidents de routage et de préoccupations de prévention. Ce contexte aide à montrer pourquoi le cas compte au-delà d'un seul opérateur. Il ne devrait pas aplatir l'événement en une statistique générique ou répondre à ses questions d'attribution non résolues. [3]

Une échelle de preuves clarifie ce qui justifierait un langage plus fort. Les mises à jour de routes distribuées peuvent établir une fausse origination. Les données de propagation multi-points de vue peuvent établir la portée. Les mesures de chemin actif peuvent établir le détournement depuis des points de vue particuliers. Les journaux de service peuvent établir les connexions reçues, l'état TLS et les effets applicatifs. Les captures de paquets peuvent établir le contenu du trafic et les modifications dans leur périmètre. Les journaux de modification et d'authentification de l'opérateur peuvent identifier l'action interne.

Une enquête sur les causes racines peut relier ces enregistrements à la responsabilité et à l'intention.

Le dossier public d'avril 2017 atteint les trois premiers niveaux pour certaines parties de l'événement. Il n'atteint pas les niveaux ultérieurs. Cette frontière permet une responsabilité opérationnelle ferme sans attribuer un motif non étayé. Rostelecom peut être tenue responsable d'expliquer les routes originaires et exportées par AS12389 même lorsque le ciblage délibéré n'est pas prouvé. Les pairs peuvent être invités à expliquer l'acceptation et la propagation même s'ils n'ont pas créé les routes. Les détenteurs de préfixes peuvent être interrogés sur l'autorisation et la surveillance sans impliquer qu'ils ont causé l'incident.

Les preuves d'attribution devraient également être symétriques. Les preuves qui soutiennent une hypothèse hostile devraient être préservées, y compris la concentration de cibles et les annonces plus spécifiques. Les preuves qui soutiennent une hypothèse de défaillance accidentelle devraient également être préservées, y compris les annonces impliquant des systèmes autonomes apparentés. Un récit crédible explique pourquoi une hypothèse correspond finalement mieux ou indique que le dossier disponible ne peut pas trancher entre elles.

Cette discipline n'est pas de l'indécision. Elle attribue une responsabilité claire pour les actions observables tout en refusant d'inventer l'état mental derrière elles. Dans les incidents de routage, c'est souvent la différence entre une analyse responsable et une narration géopolitique.

AS12389 contrôlait les preuves internes les plus probantes

Rostelecom, en tant qu'opérateur d'AS12389, contrôlait le système que les observateurs publics ont vu originer et exporter les routes. Cela ne prouve pas que la haute direction a dirigé l'événement ni qu'un individu a agi intentionnellement. Cela identifie l'organisation la plus proche du processus de génération des routes et des preuves les plus capables de l'expliquer.

Les contrôles pertinents commencent avant l'exportation. Les permissions de génération de routes déterminent quels comptes, systèmes et workflows peuvent introduire un préfixe dans le processus de routage. La revue des modifications peut exiger une deuxième vérification sur les modifications sensibles ou inhabituellement larges. Les listes d'autorisation de préfixes peuvent contraindre les annonces des clients et de l'infrastructure à l'espace d'adressage attendu. La politique d'exportation peut arrêter une route qui ne devrait pas quitter le système autonome.

La surveillance peut détecter une origine inattendue ou un ensemble soudain d'annonces plus spécifiques. Les procédures de retrait peuvent raccourcir l'exposition après détection.

Ce sont des catégories de contrôle, pas des affirmations sur la configuration exacte d'AS12389 en avril 2017. Le dossier public ne divulgue pas quels contrôles existaient, lesquels ont échoué ou lesquels ont été contournés. Il ne divulgue pas non plus si l'ensemble de routes provenait d'une commande manuelle, d'une automatisation, d'une session client, d'une erreur de redistribution interne, d'identifiants compromis ou d'un autre mécanisme.

Les preuves de l'opérateur devraient relier les catégories. L'historique de configuration pourrait montrer ce qui a changé. Les enregistrements d'authentification pourraient montrer quel compte ou système a effectué le changement. Les enregistrements d'approbation pourraient montrer si le changement était autorisé. Les journaux de session BGP et d'exportation pourraient montrer quelles routes ont été envoyées à quels voisins. Les enregistrements d'alerte pourraient montrer quand le personnel a su pour la première fois. Les enregistrements d'incident pourraient montrer qui a ordonné le retrait et comment l'ensemble affecté a été déterminé.

La vitesse seule ne suffit pas. Les annonces ont été retirées après une courte fenêtre, mais une durée de sept minutes ne révèle pas si la surveillance a fonctionné, si un pair a donné l'alerte, si un opérateur a remarqué une erreur ou si la condition d'origine s'est terminée automatiquement. Une fin rapide réduit l'exposition; elle n'explique pas l'efficacité de la détection ou du contrôle.

La divulgation est le dernier point de contrôle de l'opérateur d'origine. Un récit d'incident public utile distinguerait les faits de route observés de la constatation de cause racine de l'opérateur. Il indiquerait le périmètre d'exportation affecté, expliquerait si les préfixes ont été introduits par configuration, automatisation, un client ou une autre source de route, identifierait le contrôle qui a échoué, décrirait le confinement et donnerait des preuves de remédiation limitées. Il n'a pas besoin d'exposer des identifiants, une topologie confidentielle client ou des détails exploitables.

Sans ce récit, les observateurs externes peuvent toujours attribuer la responsabilité opérationnelle de l'origine et de l'exportation. Ils ne peuvent pas attribuer de manière fiable la responsabilité personnelle, l'intention ou la répartition interne des fautes. L'asymétrie des preuves est elle-même un fait de responsabilité: l'organisation qui contrôlait le processus de route contrôlait également les enregistrements nécessaires pour résoudre l'incertitude la plus conséquente.

Un opérateur ne peut pas répondre à cette lacune en soulignant que BGP est distribué. La distribution signifie qu'AS12389 ne contrôlait pas quels réseaux distants acceptaient la route. Cela n'efface pas le contrôle sur ce qu'AS12389 a originait et exporté. Inversement, localiser la fausse origine chez AS12389 n'efface pas le rôle des voisins qui l'ont propagée. La responsabilité pratique suit chaque point de contrôle plutôt que d'effondrer toute la chaîne en un seul acteur.

Les pairs acceptants contrôlaient la frontière de propagation de l'événement

Une fausse origine devient largement conséquente seulement lorsque d'autres réseaux l'acceptent et la propagent. ThousandEyes a observé Cogent, Hurricane Electric et Tata parmi les pairs portant les annonces d'AS12389. Cette observation ne montre pas le processus politique ou décisionnel complet à l'intérieur de chaque réseau nommé. Elle montre que l'acceptation par les pairs faisait partie du chemin de l'origine au détournement mesuré. [1]

La question de responsabilité du pair diffère de celle de Rostelecom. Un réseau acceptant ne savait pas nécessairement qu'une route était fausse quand elle est arrivée, et il n'a pas créé la revendication originale. Il contrôlait néanmoins la politique d'importation locale, les filtres clients et pairs, l'utilisation d'informations d'autorisation de route, l'alerte d'anomalie, l'exportation ultérieure et la coordination d'urgence.

Les responsabilités de filtrage doivent être décrites avec des preuves plutôt que supposées à partir d'une étiquette commerciale. Un réseau peut traiter un voisin comme client, pair ou fournisseur de transit selon sa propre politique. Les observations publiques ne divulguent pas ces contrats ni les règles d'importation de chaque session. Elles ne montrent pas non plus si une route est passée parce qu'aucun filtre n'existait, qu'une liste d'autorisation était trop large, que les données de registre étaient incomplètes, qu'un signal de validation était indisponible, ou que la politique locale a accepté un avertissement.

Le RFC 7454, le NIST SP 800-189 et les documents opérateur de MANRS fournissent des références de contrôle pour le filtrage, la coordination et l'échange de routes résilient. Ils soutiennent l'attente que les réseaux devraient connaître quelles routes un voisin peut annoncer, rejeter les publicités invraisemblables lorsque des informations fiables le permettent, surveiller les anomalies et maintenir des voies de contact pour une correction rapide. Ils n'établissent pas qu'un pair particulier a violé un devoir spécifique en avril 2017.

Cette conclusion nécessiterait la politique historique du pair, les enregistrements de sélection de route et d'alerte. [10][15]-[17]

La propagation crée un devoir de preuve proportionnel. Un pair qui a porté une route plus spécifique inattendue devrait pouvoir montrer ce qu'il a reçu, quelles validations ou filtres ont été exécutés, quelle préférence locale l'a sélectionné, où il a exporté la route et quand il l'a retirée. Les preuves conservées permettent une distinction ultérieure entre une limitation inévitable des données d'autorisation disponibles et une défaillance de contrôle notable.

Les mêmes preuves peuvent empêcher un blâme injuste. Un pair peut montrer qu'aucune ROA applicable n'existait, que les données de registre ne définissaient pas un ensemble client suffisamment restreint, qu'il a accepté la route sous une politique documentée, ou qu'il a rapidement changé de cap après une alerte. Alternativement, les enregistrements peuvent montrer qu'une restriction connue était absente ou ignorée. Les observations publiques de routes identifient les réseaux à questionner; elles ne fournissent pas la réponse complète.

Le routage distribué produit donc une responsabilité distribuée. AS12389 porte la responsabilité de la fausse origine et de l'exportation. Les réseaux acceptants portent la responsabilité des contrôles à leur propre frontière. Ces responsabilités se chevauchent en effet sans devenir identiques en cause.

Les détenteurs de préfixes et les moniteurs indépendants contrôlaient différentes formes de préparation

Les organisations dont l'espace d'adressage est apparu dans l'ensemble affecté n'ont pas créé les annonces d'AS12389. Leur responsabilité concerne la préparation, la détection, l'escalade et les preuves côté service, non le blâme pour l'origine.

Les détenteurs de préfixes peuvent maintenir des enregistrements de routage et d'autorisation précis, organiser une surveillance externe de l'origine, définir des contacts d'escalade pour les fournisseurs et préserver les preuves de service lorsqu'une alerte se produit. Lorsque cela est approprié sur le plan opérationnel, ils peuvent envisager d'annoncer une route plus spécifique d'atténuation via des fournisseurs légitimes. Toute atténuation doit être évaluée avec soin car les modifications de route effectuées pendant un incident peuvent créer de nouveaux problèmes d'accessibilité.

Le contexte historique est essentiel. L'événement s'est produit avant l'application généralisée de la validation d'origine de route. Le dossier disponible n'établit pas quels préfixes affectés avaient des ROA valides en avril 2017, quelles longueurs maximales ces ROA autorisaient, ni quels réseaux récepteurs utilisaient la validation. Il serait donc erroné de traiter l'absence de rejet universel comme une preuve que chaque détenteur de préfixe a négligé RPKI ou que chaque pair a ignoré un signal invalide disponible.

Les organisations de surveillance contrôlaient un point de contrôle différent: la qualité des preuves externes. BGPMon a fourni une fenêtre d'événement délimitée, un décompte de préfixes affectés, un dénominateur de 37 systèmes autonomes, un exemple plus spécifique et des hypothèses concurrentes sur l'intention. ThousandEyes a fourni son cadre d'observation de 137 préfixes, la classification menant à 36 préfixes d'entreprises extérieures, des observations de propagation par les pairs, des exemples de services affectés et des chemins mesurés. [1][2]

Ces enregistrements sont les plus solides lorsque leurs points de vue, limites temporelles et méthodes de classification restent reproductibles. L'accès aux données BGPStream de CAIDA et la reconstruction historique par Moriano et ses co-auteurs illustrent comment les archives de Route Views et RIPE RIS peuvent soutenir une analyse ultérieure. Une reconstruction ultérieure doit encore indiquer quels collecteurs et intervalles de mise à jour ont été utilisés et comment les préfixes ont été regroupés. [7][8]

Les moniteurs indépendants ont également un devoir de langage. Ils peuvent décrire la sélection suspecte et expliquer pourquoi les routes plus spécifiques suscitent des inquiétudes. Ils devraient indiquer séparément s'ils possèdent des preuves de but, d'accès interne ou d'interception de contenu. Cette séparation permet à un moniteur d'avertir rapidement les opérateurs sans convertir un score d'anomalie en verdict d'attribution.

Les opérateurs de services affectés détiennent les preuves nécessaires pour évaluer les préjudices en aval. Les journaux de trafic peuvent montrer des changements de connexion. Les enregistrements TLS peuvent montrer si les sessions se sont terminées en toute sécurité. Les journaux d'application et de transaction peuvent montrer des erreurs, une fraude ou aucun effet matériel. Les rapports clients peuvent identifier la géographie et la durée. Aucun de ces enregistrements ne peut être reconstruit de manière fiable à partir des seules mises à jour de routes.

La division pratique est claire. Les détenteurs de préfixes contrôlent la préparation et l'escalade. Les moniteurs indépendants contrôlent l'observation et l'analyse externes. Les opérateurs de services contrôlent les preuves des effets applicatifs et clients. Chacun peut fermer une partie différente du dossier d'incident, et aucun ne devrait prétendre que les preuves d'une autre partie sont inutiles.

RPKI peut contraindre les fausses origines mais ne peut pas décider du motif

RPKI est centrale dans la discussion sur le contrôle car l'événement impliquait une fausse origine. Son rôle doit être énoncé de manière étroite. L'architecture RPKI soutient des déclarations cryptographiquement vérifiables sur les ressources numériques Internet. Une autorisation d'origine de route identifie un système autonome autorisé à originer des préfixes spécifiés dans le périmètre de l'objet. La validation d'origine de route permet à un réseau récepteur de comparer une annonce d'origine BGP avec les données d'autorisation disponibles. [11]-[14][18]

Ce mécanisme peut donner à un réseau une preuve utile qu'une origine observée ne correspond pas à une autorisation de couverture. Si un préfixe affecté avait une ROA appropriée en avril 2017 et qu'un réseau récepteur effectuait une validation, une origine AS12389 aurait pu produire un signal que la politique pourrait rejeter ou déprioriser. Le résultat réel dépendrait de l'autorisation historique, de la longueur du préfixe, des données de validation et de la politique de routage locale.

Plusieurs limites s'ensuivent.

Premièrement, RPKI ne prouve pas l'intention. Une route peut échouer à la validation d'origine en raison d'une annonce hostile, d'une erreur d'opérateur, d'une autorisation obsolète, d'une ROA mal dimensionnée ou d'une autre discordance. Le signal concerne l'autorisation de l'origine, pas l'état mental ou l'identité de la personne derrière la mise à jour.

Deuxièmement, la validation d'origine n'explique pas le déclencheur interne. Elle peut identifier un conflit à une frontière réceptrice tout en laissant sans réponse si la route provenait d'une configuration manuelle, d'une automatisation, d'un client, d'un accès compromis ou d'un chemin de redistribution non intentionnel.

Troisièmement, RPKI ne valide pas par elle-même le chemin AS complet. Une déclaration d'origine autorisée n'est pas une preuve cryptographique que chaque relation de transit ou segment de chemin est légitime. La classification des fuites de routes du RFC 7908 et les conseils de filtrage du RFC 7454 abordent des préoccupations politiques et opérationnelles plus larges qui ne peuvent être réduites à une seule vérification d'origine. [9][10]

Quatrièmement, une affirmation rétrospective nécessite des données rétrospectives. La couverture RPKI actuelle, la pratique de validation ou les conseils de registre ne peuvent pas être projetés en arrière sans preuves. Les questions pertinentes sont de savoir quels préfixes affectés disposaient de ROA appropriées le 26 avril 2017, quelles longueurs de préfixe elles autorisaient, quelles données de validation chaque pair a reçues, et comment chaque pair a traité l'état résultant.

Cinquièmement, un contrôle n'est aussi utile que son intégration opérationnelle. Les enregistrements d'autorisation doivent être précis et maintenus. Les validateurs et la distribution des données doivent être surveillés. La politique de routage doit définir ce qui se passe lorsqu'un signal est présent ou absent. Les opérateurs ont besoin de procédures d'exception, de retour en arrière et de contact d'urgence. MANRS et les conseils du NIST placent le filtrage, la validation, la coordination et l'hygiène globale du routage dans une pratique opérationnelle plus large plutôt que de présenter RPKI comme une réponse complète. [15]-[17]

Ces limitations n'affaiblissent pas l'argument en faveur de la sécurité de l'origine des routes. Elles clarifient ce que le contrôle peut prouver. RPKI peut réduire la dépendance à une revendication d'origine non authentifiée et peut aider les réseaux récepteurs à prendre une décision plus éclairée. Il ne peut pas déterminer pourquoi AS12389 a annoncé les routes, si le trafic a été inspecté ou qui devrait porter toute la responsabilité.

Le cas d'avril 2017 est donc un argument en faveur de contrôles en couches. L'autorisation d'origine peut contraindre l'acceptation. Les filtres de préfixes peuvent contraindre ce qu'un voisin exporte. La surveillance des plus spécifiques et des changements d'origine peut réduire le temps de détection. La coordination entre pairs peut accélérer le retrait. La mesure active peut montrer l'impact sur le chemin. Les journaux de service peuvent évaluer les préjudices. Les enregistrements de l'opérateur peuvent expliquer la cause.

Aucune couche ne fournit le récit complet. La conception institutionnelle la plus solide fait en sorte que les couches produisent des preuves qui peuvent être conciliées après un événement.

Les normes de sécurité de routage créent des devoirs de capacité, pas des verdicts rétroactifs

Les normes et documents de bonnes pratiques sont ici les plus utiles en tant que cartes de contrôle. Le RFC 7908 fournit un vocabulaire pour les fuites de routes. Le RFC 7454 traite de la sécurité BGP opérationnelle et du filtrage. Le RFC 6811 et le RFC 7115 décrivent la validation d'origine et son utilisation opérationnelle. Le RFC 6480 et le RFC 6482 définissent les fondations RPKI et ROA. Le NIST SP 800-189 et MANRS relient le filtrage, la validation, la coordination et la surveillance à des opérations inter-domaines résilientes. Le RIPE NCC explique la validation d'origine BGP et ses limites. [9]-[18]

Ensemble, ils soutiennent des devoirs institutionnels qui sont mesurables sans revendiquer une violation légale en 2017. Un réseau d'origine devrait contraindre les préfixes qu'il peut créer et exporter. Un réseau récepteur devrait maintenir des contrôles d'importation proportionnés et utiliser des données d'autorisation fiables lorsqu'elles sont disponibles. Un détenteur de préfixe devrait maintenir des enregistrements précis et surveiller les origines inattendues. Les opérateurs devraient conserver les journaux et les contacts permettant un retrait rapide et une explication ultérieure.

Les devoirs sont des capacités, pas des slogans. « Nous utilisons RPKI » est incomplet sans la ROA historique, l'état de validation et la réponse locale. « Nous filtrons les clients » est incomplet sans l'ensemble de préfixes autorisé et la preuve que le filtre a fonctionné. « Nous surveillons BGP » est incomplet sans seuils d'alerte, horodatages et escalade. « La route a été retirée » est incomplet sans le dossier de détection et de décision.

Les documents n'établissent pas que Rostelecom ou un pair nommé a échoué à un contrôle spécifique pendant l'événement. Cela nécessiterait une comparaison entre l'exigence historique, l'architecture réelle de l'opérateur et les preuves de l'incident. Les normes actuelles peuvent encore définir les questions qu'une institution responsable devrait maintenant pouvoir répondre.

Cette approche évite deux erreurs. L'une est le fatalisme technologique, dans lequel la conception distribuée de BGP devient une raison pour laquelle personne ne peut être responsable. L'autre est la certitude technologique, dans laquelle un contrôle moderne est déclaré une prévention historique garantie. Les preuves ne soutiennent ni l'un ni l'autre.

La responsabilité institutionnelle demande plutôt si chaque acteur pouvait démontrer son contrôle au point qu'il possédait. Cette norme reste valable même lorsque le système mondial n'a pas d'opérateur central et que le motif original n'est pas résolu.

Le préjudice devrait être mesuré sans inventer une violation

L'ensemble affecté comprenait des services financiers, de paiement, de commerce électronique, de sécurité web et liés aux certificats. Les rapports ont nommé Mastercard, Visa, BNP Paribas, HSBC, Symantec et GeoTrust parmi les exemples associés aux préfixes affectés. Ces noms expliquent pourquoi les observateurs ont pris le motif au sérieux. Ils ne prouvent pas la compromission des organisations ou de leurs clients. [1][2]

Le préjudice confirmé est un préjudice de routage. Une partie du trafic a perdu son chemin prévu et a traversé un réseau de transit non autorisé. Cela a modifié la frontière de confiance pour les connexions affectées et réduit le contrôle des détenteurs de préfixes sur la façon dont les utilisateurs atteignaient leurs services.

Les préjudices secondaires possibles nécessitent des preuves distinctes. La fraude de transaction nécessiterait des enregistrements de transaction. Le vol d'identifiants nécessiterait des preuves d'authentification, d'utilisateur ou médico-légales. La compromission TLS nécessiterait des preuves de session et de certificat. La modification de données nécessiterait des enregistrements de paquets, d'application ou d'intégrité. Une panne nécessiterait des mesures de disponibilité liées aux utilisateurs affectés. Les dommages financiers nécessiteraient des enregistrements de pertes et une analyse causale.

Aucune de ces conclusions ne découle simplement du passage d'une route par AS12389. La livraison ultérieure peut permettre au service de rester disponible, et le chiffrement peut limiter le contenu lisible. Aucun de ces faits n'élimine le risque. Aucun ne prouve la sécurité pour chaque connexion.

Le rapport sur les préjudices devrait donc utiliser une échelle en couches. La perte de contrôle de routage est établie. L'exposition à un chemin de transit non intentionnel est établie pour le trafic mesuré. La visibilité du contenu est possible mais non prouvée. L'interception active est contestée et non prouvée. La compromission des données, les effets transactionnels et les pertes sont inconnus.

Cette échelle donne aux organisations affectées la possibilité de rendre compte honnêtement. Elles peuvent reconnaître un événement sérieux de contrôle réseau tandis que les enquêtes se poursuivent. Elles peuvent ajouter plus tard des conclusions côté service sans réécrire les observations de routage. Si aucun préjudice applicatif n'est trouvé, ce résultat devrait être rapporté comme une preuve dans le périmètre examiné, non comme une preuve que la fausse origine était inoffensive.

La même discipline s'applique aux agences publiques et aux chercheurs. Un cadrage fort de la menace peut motiver de meilleurs contrôles, mais il ne devrait pas transformer des catégories de préjudice possible en faits d'incident. La crédibilité du plaidoyer pour la sécurité du routage dépend du maintien de cette ligne.

La divulgation devrait répondre aux questions de contrôle même lorsque l'attribution reste non résolue

Un rapport d'incident n'a pas besoin d'identifier un acteur hostile pour être utile. Il peut indiquer ce que l'opérateur sait sur la création de route, l'exportation, la propagation, la détection et le retrait tout en marquant le motif comme non résolu.

Pour AS12389, le récit minimum utile identifierait la classe source des annonces, l'ensemble de routes et le périmètre d'exportation, le canal de détection, la décision de retrait, la période affectée et les changements de contrôle effectués par la suite. Il pourrait expliquer si l'événement impliquait une configuration, une automatisation, une entrée client ou un autre mécanisme interne sans exposer de commandes ou d'identifiants sensibles.

Les réseaux acceptants pourraient divulguer si les routes ont été traitées comme des annonces de client, de pair ou de transit; si des vérifications de préfixe, d'origine ou de chemin ont été appliquées; si les données historiques RPKI ont produit un signal utilisable; et comment les routes ont été supprimées. Les détenteurs de préfixes pourraient divulguer quand ils ont été alertés, quels fournisseurs ils ont contactés et si les preuves de service montraient des effets clients mesurables.

Le dossier public fourni par les moniteurs sépare déjà certains faits des interprétations. BGPMon et ThousandEyes ont documenté le timing, les ensembles de routes, les plus spécifiques, la propagation et les effets de chemin, puis ont discuté de la raison pour laquelle le motif cible semblait suspect. BGPMon a également préservé des preuves soutenant une hypothèse de défaillance accidentelle. [1][2]

C'est le modèle pour une incertitude responsable. Un rapport ne devrait pas cacher des preuves suspectes pour éviter un risque de réputation. Il ne devrait pas présenter la suspicion comme une intention. Il devrait nommer les enregistrements qui trancheraient la question et indiquer si ces enregistrements ont été examinés.

La divulgation a également besoin d'un test de remédiation durable. Une déclaration selon laquelle les routes ont été retirées décrit le confinement. Elle ne démontre pas que les permissions ont changé, que les filtres se sont resserrés, que les alertes se sont améliorées, que les journaux ont été conservés ou que la coordination entre pairs a été testée. Les preuves de remédiation devraient identifier le contrôle qui a échoué, le changement, le test et le résultat de la surveillance.

Les institutions ont des contraintes de divulgation différentes. Les opérateurs peuvent protéger les informations sensibles à la sécurité et confidentielles des clients. Les fournisseurs de services financiers et de sécurité peuvent éviter d'exposer les modèles de trafic. Les pairs peuvent traiter les politiques comme commercialement sensibles. Ces contraintes justifient l'agrégation et la censure, pas une conclusion sans preuves.

L'intérêt public est le plus fort à la frontière entre l'opération confirmée et le but allégué. Un récit clair peut dire qu'AS12389 a originait de fausses routes, que des pairs en ont propagé certaines et que le trafic mesuré a changé de chemin. Il peut également dire que le ciblage délibéré, l'interception et l'espionnage ne sont pas établis. Cette combinaison est plus responsable que le déni par vague ou l'accusation par inférence.

Preuves qui pourraient modifier l'évaluation

Plusieurs enregistrements pourraient matériellement renforcer, réduire ou inverser des parties de l'évaluation actuelle.

L'historique de configuration d'AS12389 pourrait identifier la source exacte de la route et le changement. Les journaux d'authentification et d'autorisation pourraient identifier le compte ou le système impliqué et si l'action a suivi un flux de travail approuvé. Les enregistrements d'exportation et de session BGP pourraient établir quels voisins ont reçu quelles annonces. Les journaux d'alerte et de réponse aux incidents pourraient montrer comment l'événement a été détecté et pourquoi le retrait a eu lieu.

Un rapport d'analyse des causes racines de Rostelecom pourrait relier ces enregistrements, distinguer l'erreur de l'action non autorisée et documenter la remédiation. Sa crédibilité dépendrait de la méthode, de la conservation des preuves et de l'examen d'hypothèses concurrentes. Une simple affirmation d'accident ou d'attaque ne résoudrait pas la question d'attribution.

Les journaux de filtres, de validation et de sélection des pairs acceptants pourraient montrer pourquoi des routes spécifiques ont été acceptées. Des instantanés politiques historiques pourraient distinguer un contrôle manquant de données d'autorisation manquantes. Les enregistrements d'exportation pourraient montrer la frontière de propagation, tandis que les enregistrements de contact et de ticket pourraient montrer quand les pairs ont coordonné le retrait.

Une réanalyse reproductible des mises à jour archivées de RIPE RIS et Route Views pourrait réconcilier les cadres de comptage de BGPMon et ThousandEyes ou expliquer pourquoi ils diffèrent. Elle pourrait également cartographier la propagation dans le temps et les points de vue. L'analyse nécessiterait des collecteurs déclarés, des horodatages, une déduplication et des méthodes de classification des préfixes. [7][8]

Les enregistrements historiques de ROA pour chaque préfixe affecté pourraient montrer si la validation d'origine aurait produit un résultat utile à l'époque. L'analyse nécessiterait l'origine autorisée pertinente, le préfixe et le périmètre de longueur maximale, plus des preuves de quelles données de validation chaque réseau récepteur avait et comment sa politique locale a répondu.

Les journaux de trafic, TLS, d'authentification, d'application et de transaction des services affectés pourraient établir si les connexions détournées se sont terminées, ont échoué ou ont montré des effets suspects. Les captures de paquets pourraient fournir des preuves plus directes dans leur point de vue limité et leur période de conservation. Les enregistrements d'incidents et de pertes clients pourraient relier les effets techniques à des personnes ou organisations.

Des preuves que le chemin mesuré ne transportait pas de trafic de production resserreraient la conclusion de préjudice. Des preuves d'inspection de paquets, de modification ou d'utilisation d'identifiants l'étendraient. Des preuves d'un changement de route délibéré et authentifié lié à un acteur responsable modifieraient matériellement l'évaluation d'attribution. Des preuves d'une erreur interne et d'un contrôle correctif testé renforceraient l'explication de défaillance accidentelle.

Jusqu'à ce que ces enregistrements soient disponibles, la conclusion devrait rester délimitée. Les annonces AS12389 et le détournement de chemin sont confirmés. Une défaillance de routage ou de configuration est plausible. Le ciblage délibéré, l'interception et l'identité de l'acteur sont non résolus. La compromission des données et les pertes ne sont pas prouvées.

La responsabilité commence là où les preuves sont contrôlées

L'événement d'avril 2017 n'est pas principalement une histoire sur la question de savoir si une étiquette alarmante en bat une autre. C'est un test de la manière dont la responsabilité est attribuée dans une infrastructure conçue de manière distribuée.

Rostelecom contrôlait la création de routes, la politique d'exportation et les enregistrements internes les plus proches de la cause. Les pairs acceptants contrôlaient les filtres, la validation, la propagation et leurs propres preuves. Les détenteurs de préfixes contrôlaient les données d'autorisation, la surveillance et l'escalade. Les moniteurs indépendants contrôlaient l'observation externe et la transparence analytique. Les services affectés contrôlaient les preuves de l'impact client et applicatif.

Aucun acteur ne contrôlait tout le chemin. Chacun contrôlait un point de contrôle où la prévention, la limitation, la détection ou l'explication étaient possibles. C'est suffisant pour une responsabilité opérationnelle même lorsque le motif reste inconnu.

L'événement montre également pourquoi RPKI doit être traitée comme un contrôle délimité. L'autorisation d'origine peut aider les réseaux récepteurs à rejeter ou à réduire la confiance dans une fausse origine lorsque les données historiques et la politique soutiennent ce résultat. Elle ne peut pas identifier la personne derrière la mise à jour, prouver l'interception ou remplacer le filtrage d'exportation, la coordination entre pairs, la mesure de chemin et l'enquête côté service.

La conclusion la plus solide est donc à la fois ferme et limitée. Les observations publiques prouvent qu'AS12389 a originait de fausses routes, que plusieurs pairs ont propagé certaines annonces et que le trafic mesuré a changé de chemin. Elles ne prouvent pas que la Russie ou Rostelecom avait l'intention d'espionner, que le trafic a été inspecté, ou que des données financières ou de l'argent ont été perdus.

La responsabilité n'exige pas d'inventer ces faits. Elle exige que les opérateurs qui contrôlaient les preuves décisives les préservent, les testent et expliquent ce qu'elles montrent.

Sources

Accès vérifié: 2026-07-25

1. ThousandEyes, mécanisme de l'événement, preuves de chemin et surface de service affectée:https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
2. BGPMon, timing de l'événement, décomptes, exemple plus spécifique et hypothèses concurrentes:https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
3. Internet Society, contexte annuel de sécurité de routage indépendant:https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
4. CERT-EU, résumé ultérieur d'incident et de préjudice institutionnel:https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
5. ENISA, analyse de sécurité BGP et recommandations de contrôle:https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
6. CERT-EU, évaluation ultérieure de la menace attribuée:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
7. Moriano et co-auteurs, reconstruction historique examinée par les pairs:https://pmoriano.com/docs/COMNET21.pdf
8. CAIDA BGPStream, accès aux données historiques de Route Views et RIPE RIS:https://bgpstream.caida.org/data
9. IETF RFC 7908, définitions et classification des fuites de routes:https://datatracker.ietf.org/doc/html/rfc7908
10. IETF RFC 7454, sécurité BGP opérationnelle et conseils de filtrage:https://datatracker.ietf.org/doc/html/rfc7454
11. IETF RFC 6811, états de validation d'origine BGP:https://datatracker.ietf.org/doc/html/rfc6811
12. IETF RFC 7115, utilisation opérationnelle de la validation d'origine RPKI:https://datatracker.ietf.org/doc/html/rfc7115
13. IETF RFC 6480, architecture RPKI:https://datatracker.ietf.org/doc/html/rfc6480
14. IETF RFC 6482, profil d'autorisation d'origine de route:https://datatracker.ietf.org/doc/html/rfc6482
15. NIST SP 800-189, sécurité BGP et conseils d'échange résilient:https://csrc.nist.gov/pubs/sp/800/189/final
16. MANRS, actions des opérateurs réseau:https://manrs.org/netops/
17. MANRS, guide de mise en œuvre pour les opérateurs réseau:https://manrs.org/netops/bcop/
18. RIPE NCC, explication et limites de la validation d'origine BGP:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/