Résumé

  • BGPMon a situé l'événement AS12389 entre 22h36 et environ 22h43 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, a traité environ 100 comme ordinaires ou associés à des organisations russes, et a identifié 36 préfixes extérieurs. Ces dénominateurs décrivent des sélections différentes et ne doivent pas être fusionnés. [1][2]
  • Le mécanisme d'infrastructure direct était la fausse origine et propagation de routes. Certaines annonces étaient des routes plus spécifiques. BGPMon a souligné 203.112.90.0/24 par rapport à un /23 normalement annoncé, une distinction qui aide à expliquer pourquoi la sélection de route ordinaire pourrait préférer la fausse route sans compromettre le service affecté lui-même. [2]
  • ThousandEyes a observé des pairs, dont Cogent, Hurricane Electric et Tata, acceptant et propageant les annonces AS12389. Ses mesures de chemin ont montré que le trafic pour au moins un service de commerce électronique affecté entrait dans Rostelecom et atteignait ensuite la destination prévue. Cela soutient le détournement d'une partie du trafic de production, pas une affirmation selon laquelle chaque route, utilisateur ou paquet a été détourné. [1]
  • Des 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 incluent Mastercard, Visa, BNP Paribas, HSBC, Symantec et GeoTrust. Les preuves de routage ne montrent pas que les systèmes internes de ces organisations ont été compromises. [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 les 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 de transaction, la perte et la remédiation durable restent inconnus.
  • La concentration de destinations financières et liées à la sécurité a rendu le motif suspect pour BGPMon et ThousandEyes. BGPMon a également observé des annonces impliquant d'autres systèmes autonomes liés à Rostelecom, ce qui soutient une défaillance interne accidentelle comme hypothèse concurrente. Aucune des organisations de surveillance ne disposait des enregistrements internes de changement, d'authentification ou de configuration de l'opérateur. [1][2]
  • La responsabilité suit le contrôle pratique, pas une conclusion non étayée sur le mobile. Rostelecom contrôlait la création et l'exportation de routes à l'intérieur 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 ne prouve pas l'intention ou le mécanisme interne. L'événement est également antérieur à l'application généralisée de la validation de l'origine de la 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 de 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 pas fournir: les journaux de modification et d'authentification AS12389, un rapport de cause racine, les journaux de filtrage et de sélection de route des pairs, une analyse d'archive reproductible, l'état historique des ROA, les enregistrements de trafic et TLS côté service, les captures de paquets, les enregistrements d'incidents clients et des 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 placé le début à 22h36 UTC et la fin vers 22h43 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 à Internet: AS12389 s'est présenté comme une origine pour des routes qui ne faisaient pas partie de son ensemble autorisé ordinaire, y compris l'espace d'adressage utilisé par des organisations extérieures à Rostelecom.

Les mêmes observations établissent moins que ce que beaucoup de 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é utilisé à mauvais escient, 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.

Cette distinction importe parce que 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 origine ou une route qui détourne le trafic, mais il est souvent interprété comme une preuve d'intention hostile. Le relevé observable soutient de fausses annonces d'origine et un détournement de trafic. Il n'établit pas en soi une saisie délibérée, un espionnage ou un plan pour cibler des institutions financières.

Les é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é du routage. Ces descriptions sont utiles en tant qu'évaluations institutionnelles attribuées. Elles ne remplacent pas les journaux 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 de routage publiques peuvent être observées et reproduites de manière indépendante. La cause interne et le but dépendent en grande partie 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 solides, plus les questions internes sans réponse deviennent spécifiques. Pourtant, les preuves externes ne doivent pas être étirées en réponses qu'elles ne peuvent pas 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 distincts: l'une 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 contenue, 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é que AS12389 a annoncé 137 préfixes pendant la fenêtre pertinente, puis a séparé environ 100 qui semblaient ordinaires ou associés à des organisations russes des 36 préfixes appartenant à des organisations extérieures. [1][2]

Les chiffres sont suffisamment proches pour tenter un nombre unique et suffisamment différents pour rendre cette démarche peu fiable. Le décompte de BGPMon de 50 préfixes concerne son ensemble affecté dans 37 systèmes autonomes. ThousandEyes a commencé avec 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 de 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 de population non étayée.

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, a traité environ 100 comme probablement ordinaires ou associés à la Russie, et a identifié 36 préfixes d'entreprises extérieures. La différence peut refléter des points de vue, des choix de synchronisation, 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 évalué par les pairs de Moriano et co-auteurs a utilisé les données historiques de BGPStream, tandis que CAIDA décrit l'accès de BGPStream aux archives Route Views et RIPE RIS. Ces sources rendent une réanalyse reproductible possible en principe. Elles n'effacent pas le besoin 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 décompte 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 consiste à concilier les méthodes ou à préserver la différence, pas à choisir le chiffre qui rend l'événement le plus grand ou le plus petit.

Les routes plus spécifiques expliquent pourquoi la sélection ordinaire a pu détourner le trafic

BGP est le système inter-domaines par lequel les réseaux échangent des revendications d'accessibilité à des blocs d'adresses IP. Le mécanisme crucial de l'événement n'était pas simplement qu'AS12389 est apparu 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 souligné 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 tombe dans ce bloc plus petit. Cette préférence se produit avant de nombreuses autres comparaisons de meilleur chemin. Le faux /24 pourrait 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, un service de paiement ou un fournisseur de certificats distant a été compromis. Le système de sélection de route peut envoyer le trafic vers la fausse origine parce que 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 propres systèmes normalement tandis que certains utilisateurs atteignent ces systèmes via un chemin de transit non intentionnel.

L'observation de routes plus spécifiques distingue également l'événement d'une affirmation vague selon laquelle AS12389 a 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 de sécurité et de filtrage. Ces normes aident les opérateurs à décrire les défaillances de politique de route 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 ou 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 à l'intérieur d'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 de routes et d'authentification seraient les plus proches de l'origine. Les politiques d'exportation et les journaux 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 de vue externes. Les mesures actives montreraient les effets de chemin de bout en bout. Les opérateurs de services détiendraient des preuves de trafic et d'application.

Cette chaîne empêche une attribution simpliste de toute 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 d'Internet, mais plusieurs contrôlaient des points spécifiques où l'événement aurait pu être évité, 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 la destination du trafic. ThousandEyes a rapporté que certains pairs, dont Cogent, Hurricane Electric et Tata, ont accepté et propagé les annonces AS12389. Ses mesures pour au moins un service de commerce électronique affecté ont indiqué que le trafic entrait dans le réseau de Rostelecom et continuait ensuite vers la destination prévue. [1]

Cette forme de chemin importe. Elle soutient plus qu'un risque théorique qu'une fausse route puisse attirer le 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 compatible 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 pas ê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 moment et la politique.

La livraison ultérieure ne prouve pas non plus l'interception. Le passage du trafic 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 a utilisé un.

Le chiffrement complique davantage l'évaluation des dommages. 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 étayé le plus sûr est donc une perte de 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 comptent sur le 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é, probable, contesté et inconnu. Mélanger ces classes est la principale voie d'une observation technique à une accusation non fondée.

Les preuves confirmées incluent les observations d'origine AS12389, la fenêtre de 22h36 à environ 22h43 UTC, les fausses annonces, certaines routes plus spécifiques, la propagation par plusieurs pairs et les changements de chemin mesurés. Les catégories de services nommés 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 doivent rester conditionnelles. Une défaillance interne de routage ou de configuration est un candidat plausible de cause racine. BGPMon a observé des annonces simultanées impliquant d'autres systèmes autonomes liés à Rostelecom, un schéma qui peut soutenir l'hypothèse d'une erreur interne plus large plutôt qu'un ensemble de cibles externes soigneusement limité. Les preuves n'établissent pas la configuration exacte, la commande ou le système défaillant.

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 de sécurité, combinée à de nouvelles routes plus spécifiques, a rendu le schéma 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 dessein.

Les inconnus 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 des transactions ont été affectées, si des utilisateurs ont perdu des données ou de l'argent, la population totale affectée 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 orienté 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 AS12389 ou aux enregistrements de paquets des services affectés. Une étiquette catégorique ultérieure ne doit pas être traitée comme une nouvelle preuve primaire concernant l'intention d'un opérateur en 2017. [4]-[6]

La revue annuelle de la sécurité du routage de l'Internet Society place l'épisode dans un schéma beaucoup plus large d'incidents de routage et de préoccupations de prévention. Ce contexte aide à montrer pourquoi l'affaire importe au-delà d'un seul opérateur. Il ne doit 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 origine. Les données de propagation multi-points de vue peuvent établir la portée. Les mesures de chemin actives peuvent établir le détournement depuis des points de vue particuliers. Les journaux de services peuvent établir les connexions reçues, l'état TLS et les effets applicatifs. Les captures de paquets peuvent établir le contenu du trafic et sa modification dans leur périmètre. Les journaux de changement et d'authentification des opérateurs peuvent identifier l'action interne.

Une enquête de cause racine peut relier ces enregistrements à la responsabilité et à l'intention.

Les archives publiques d'avril 2017 atteignent les trois premiers niveaux pour certaines parties de l'événement. Elles n'atteignent pas les niveaux ultérieurs. Cette limite permet une responsabilité opérationnelle ferme sans attribuer un mobile non étayé. Rostelecom peut être tenu responsable d'expliquer les routes annoncées 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 doivent également être symétriques. Les preuves qui soutiennent une hypothèse hostile doivent ê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 doivent également être préservées, y compris les annonces impliquant des systèmes autonomes connexes. Un récit crédible explique pourquoi une hypothèse s'adapte finalement mieux ou déclare que les archives disponibles ne peuvent pas trancher entre elles.

Cette discipline n'est pas de l'indécision. Elle attribue une responsabilité claire pour des 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 annoncer et exporter les routes. Cela ne prouve pas que la direction supérieure a dirigé l'événement ou qu'un individu a agi intentionnellement. Cela identifie l'organisation la plus proche du processus de génération de 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 seconde vérification sur des 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 de sortie peut empêcher une route de quitter le système autonome. La surveillance peut détecter une origine inattendue ou un ensemble soudain de routes 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. Les archives publiques ne divulguent pas quels contrôles existaient, lesquels ont échoué, ou lesquels ont été contournés. Elles ne divulguent 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 s'il était autorisé. Les journaux de session et d'exportation BGP pourraient montrer quelles routes ont été envoyées à quels voisins. Les enregistrements d'alerte pourraient montrer quand le personnel a eu connaissance pour la première fois. Les dossiers 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'alarme, 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 rapport public d'incident utile distinguerait les faits de route observés de la conclusion 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, client ou autre source de route, identifierait le contrôle défaillant, 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 compte rendu, les observateurs externes peuvent toujours attribuer la responsabilité opérationnelle pour l'origine et l'exportation. Ils ne peuvent pas attribuer de manière fiable la responsabilité personnelle, l'intention ou l'allocation de faute interne. 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 combler 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 annoncé 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 limite 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 transportant les annonces AS12389. Cette observation ne montre pas la politique complète ou le processus de décision à 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 à son 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 des 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 ou 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 acceptait un avertissement.

Le RFC 7454, NIST SP 800-189 et les documents de référence des opérateurs MANRS fournissent des références de contrôle pour le filtrage, la coordination et l'échange résilient de routes. Ils soutiennent l'attente que les réseaux devraient connaître les routes qu'un voisin peut annoncer, rejeter les publicités invraisemblables là où 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é une obligation spécifique en avril 2017.

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

La propagation crée un devoir proportionnel de preuve. Un pair qui a transporté une route plus spécifique inattendue devrait pouvoir montrer ce qu'il a reçu, quels filtres ou validations 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. Des preuves conservées permettent une distinction ultérieure entre une limitation inévitable dans les données d'autorisation disponibles et une défaillance de politique contrôlable.

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 étroit, 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 à interroger; 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 dans l'effet sans devenir identiques dans la 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, pas le blâme pour l'origine.

Les détenteurs de préfixes peuvent maintenir des enregistrements précis de routage et d'autorisation, organiser une surveillance externe de l'origine, définir des contacts d'escalade pour les fournisseurs et conserver des preuves de service lorsqu'une alerte se produit. Lorsque cela est opérationnellement approprié, ils peuvent envisager d'annoncer une route plus spécifique atténuante via des fournisseurs légitimes. Toute atténuation doit être évaluée avec soin car les changements de route effectués 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 de l'origine de la route. Les archives disponibles n'établissent pas quels préfixes affectés avaient des ROA valides en avril 2017, quelles longueurs maximales ces ROA autorisaient, ou 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 de route 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 co-auteurs illustrent comment les archives 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 linguistique. Ils peuvent décrire une sélection suspecte et expliquer pourquoi les routes plus spécifiques suscitent des inquiétudes. Ils doivent indiquer séparément s'ils possèdent des preuves de dessein, d'accès interne ou d'interception de contenu. Cette séparation permet à un moniteur d'alerter 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 dommages 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 enregistrements d'application et de transaction peuvent montrer des erreurs, des fraudes 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 route.

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 mobile

RPKI est central dans la discussion de contrôle parce que 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 (ROA) identifie un système autonome autorisé à annoncer des préfixes spécifiés dans le cadre de l'objet. La validation de l'origine de la 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 des preuves utiles 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 en découlent.

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 cadrée ou d'une autre divergence. 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 RFC 7908 et les conseils de filtrage RFC 7454 abordent des préoccupations politiques et opérationnelles plus larges qui ne peuvent pas ê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 preuve. Les questions pertinentes sont de savoir quels préfixes affectés avaient des 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 route 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 arrière et de contact d'urgence. MANRS et les conseils NIST placent le filtrage, la validation, la coordination et l'hygiène de routage globale 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 le cas pour la sécurité de l'origine de route. 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 pour des 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 routes 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 dommages. Les enregistrements des opérateurs peuvent expliquer la cause.

Aucune couche ne fournit le compte rendu 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é du routage créent des devoirs de capacité, pas des verdicts rétroactifs

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

Ensemble, ils soutiennent des devoirs institutionnels qui sont mesurables sans prétendre à une violation juridique de 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 qui permettent 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 les seuils d'alerte, les horodatages et l'escalade. "La route a été retirée" est incomplet sans l'enregistrement 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 toujours 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 que personne ne soit responsable. L'autre est la certitude technologique, dans laquelle un contrôle moderne est déclaré garantie de prévention historique. Les preuves ne soutiennent ni l'une ni l'autre.

La responsabilité institutionnelle demande plutôt si chaque acteur pourrait démontrer son contrôle au point qu'il possédait. Cette norme reste valide même lorsque le système global 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 compromission

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 schéma 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 séparées. 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. L'altération des 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 telle conclusion ne découle simplement d'une route passant 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 de préjudice devrait donc utiliser une échelle en couches. La perte de contrôle de route 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 de transaction et les pertes sont inconnus.

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

La même discipline s'applique aux agences publiques et aux chercheurs. Un cadrage fort de 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 mobile comme non résolu.

Pour AS12389, le compte rendu utile minimal 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 client, pair ou transit; si des vérifications de préfixe, d'origine ou de chemin ont été appliquées; si les données RPKI historiques 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 routes plus spécifiques, la propagation et les effets de chemin, puis ont discuté pourquoi le schéma de cibles semblait suspect. BGPMon a également conservé 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 nécessite également 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é, les filtres se sont resserrés, les alertes se sont améliorées, les journaux ont été conservés ou la coordination entre pairs a été testée. Les preuves de remédiation devraient identifier le contrôle défaillant, le changement, le test et le résultat de surveillance.

Les institutions ont différentes contraintes de divulgation. Les opérateurs peuvent protéger les informations sensibles de sécurité et confidentielles client. 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 rédaction, pas une conclusion sans preuve.

L'intérêt public est le plus fort à la frontière entre l'opération confirmée et le dessein allégué. Un compte rendu clair peut dire qu'AS12389 a annoncé 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 soit le déni par le vague, soit l'accusation par inférence.

Des preuves qui pourraient changer l'évaluation

Plusieurs enregistrements pourraient matériellement renforcer, restreindre 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 de cause racine 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 filtrage, de validation et de sélection des pairs acceptants pourraient montrer pourquoi des routes spécifiques sont passées. Des instantanés de politique historique pourraient distinguer un contrôle manquant de données d'autorisation manquantes. Les enregistrements d'exportation pourraient montrer la limite 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 archives RIPE RIS et Route Views pourrait 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 de 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, la portée du préfixe et de la longueur maximale, ainsi que des preuves de ce que chaque réseau récepteur avait comme données de validation et comment sa politique locale a répondu.

Les enregistrements 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 aux personnes ou organisations.

Des preuves que le chemin mesuré ne transportait pas de trafic de production restreindraient la conclusion de préjudice. Des preuves d'inspection de paquets, de modification ou d'utilisation d'identifiants l'élargiraient. 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 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 ne sont pas résolus. La compromission et la perte de données 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 pour savoir si une étiquette alarmante bat une autre. C'est un test de la manière dont la responsabilité est assignée dans une infrastructure conçue pour être 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 d'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 mobile reste inconnu.

L'événement montre également pourquoi RPKI doit être traité comme un contrôle 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 annoncé 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é ne nécessite pas d'inventer ces faits. Elle nécessite que les opérateurs qui contrôlaient les preuves décisives les conservent, les testent et expliquent ce qu'elles montrent.

Sources

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

  1. ThousandEyes, mécanisme d'événement, preuve de chemin et surface de service affectée:https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
  2. BGPMon, timing d'événement, décomptes, exemple de route 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é du 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 de menace attribuée ultérieure:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  7. Moriano et co-auteurs, reconstruction historique évaluée par les pairs:https://pmoriano.com/docs/COMNET21.pdf
  8. CAIDA BGPStream, accès aux données historiques 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é opérationnelle BGP 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, conseils 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/