Résumé

  • L’incident d’Orange España a relié quatre surfaces différentes : la prise de contrôle d’un compte, l’écriture de ROA hostiles, le rafraîchissement progressif des validateurs et le choix local de rejeter des routes devenues Invalid.
  • La bonne réponse est d’associer l’extension de RPKI à une véritable garde transactionnelle : nouvelle authentification au moment de l’acte, approbation indépendante selon le rayon d’impact, reçu hors bande, état de repli vérifié et exercice de restauration mesuré dans le routage réel.

La preuve était vraie, la décision ne l’était pas

Le matin du 3 janvier 2024, rien ne ressemblait encore à une panne uniforme. La reconstruction publiée par Kentik situe une première activité RPKI liée aux ressources d’Orange España vers 09 h 28 UTC, puis l’apparition de trois autorisations importantes vers 09 h 42. La forte baisse du trafic observée plus tard ne fut pas le premier acte de l’incident, mais une conséquence différée.

Une Route Origin Authorisation n’achemine aucun paquet. Elle affirme, sous une forme signée, qu’un système autonome est autorisé à annoncer certains préfixes et, éventuellement, jusqu’à quelle longueur. Les validateurs récupèrent ces objets et calculent un état. Les opérateurs décident ensuite comment utiliser cet état dans leur politique BGP.

L’intrus n’avait donc pas besoin de modifier les routeurs de milliers de réseaux. En agissant depuis le compte d’Orange España, il pouvait altérer une preuve commune consultée par ces réseaux. Les annonces légitimes d’AS12479 ne correspondaient plus aux nouvelles autorisations et pouvaient être classées Invalid.

Le RFC 6811 réserve précisément ce verdict au cas où une charge validée couvre le préfixe mais où aucune autorisation ne correspond à l’origine observée. Il précise aussi que le résultat n’est pas une commande universelle. Le rejet de la route dépend d’une configuration explicite chez l’opérateur. La preuve est distribuée ; la décision d’exploitation reste locale.

Dire que « RPKI a coupé Orange » serait donc trompeur. Le système de signature a transporté un état produit avec une autorité reconnue. Des validateurs ont calculé le résultat attendu. Des opérateurs ont appliqué la défense qu’ils avaient choisie contre les détournements d’origine. Le défaut se trouve en amont de la signature : le droit d’écrire était trop facile à exercer pour une opération dont le rayon d’impact était immense.

Trois observateurs, trois fenêtres temporelles

Les mesures publiques ne désignent pas une seconde unique où « Internet » aurait changé d’état. Kentik constate une réduction prononcée du trafic entrant vers AS12479 approximativement entre 14 h 20 et 18 h UTC. Cloudflare place sa baisse entre 16 h 45 et 19 h 45, heure locale, et note une diminution substantielle de l’espace IPv4 annoncé. bgp.tools voit un préfixe affecté perdre de la visibilité vers 14 h 11 UTC, puis en retrouver à partir de 17 h 47.

Ces fenêtres décrivent des points d’observation et des phénomènes différents. Le trafic mesuré par un fournisseur n’est pas identique à la visibilité BGP captée par un ensemble de pairs. Les fuseaux horaires, les intervalles d’échantillonnage et les relations d’interconnexion comptent également. Aucune de ces sources ne constitue un recensement exhaustif du réseau mondial.

Leur convergence porte sur le mécanisme. Une première horloge marque l’écriture du ROA. Une deuxième marque l’instant où chaque validateur télécharge et traite le nouvel état. Une troisième marque l’application de la politique par chaque réseau. L’effet apparaît quand ces horloges se rencontrent, pas au seul moment où l’attaquant clique.

La visibilité observée par bgp.tools recule par paliers. Certains réseaux ont actualisé leur validation avant d’autres ; certains rejetaient Invalid, d’autres non ; des interconnexions directes ont pu conserver des chemins limités. Cette descente graduelle est un indice de propagation distribuée, non la preuve que tous les utilisateurs ont subi exactement la même interruption.

La restauration obéit à la même géométrie. Corriger un objet n’efface pas instantanément toutes les copies et tous les résultats dérivés. Un défenseur doit compter avec les cycles de récupération, les caches et les politiques des réseaux. La marge créée par cette asynchronie peut aider à arrêter une modification avant son plein effet, mais elle prolonge aussi les traces d’un état déjà corrigé.

Le compte d’administration était une autorité de production

Les interfaces de registre donnent souvent l’impression de gérer des dossiers. Dans la chaîne RPKI, une écriture approuvée alimente pourtant des décisions automatiques prises bien au-delà de l’organisation. Le compte n’est pas seulement un accès administratif : il détient un pouvoir de production sur un bien partagé.

La cryptographie ne peut pas deviner l’intention humaine. Elle établit que les données ont été signées dans la chaîne attendue et qu’elles n’ont pas été altérées en route. Si un attaquant utilise une session reconnue, la signature reste valide. L’analyse de Ben Cartwright-Cox résume ce paradoxe par une formule utile : signé ne veut pas dire sûr.

Une étude systématique de la sécurité de RPKI distingue elle aussi plusieurs surfaces : identité, publication, validateurs, logiciels et déploiement opérateur. Cette vue empêche de réduire l’incident à une opposition simple entre « protocole sûr » et « utilisateur imprudent ». La sécurité de la chaîne dépend de la manière dont chaque pouvoir est créé, limité, observé et révoqué.

L’authentification à deux facteurs est indispensable. D’après les comptes rendus publics, RIPE NCC l’a rendue obligatoire après l’incident. Cette mesure élimine une partie des attaques par mot de passe, mais elle ne constitue pas une autorisation transactionnelle. Une session volée, un facteur faible, une erreur interne ou un rôle trop large peuvent encore mener à une écriture valide et dangereuse.

Il faut donc séparer quatre questions. Qui a ouvert la session ? Qui est habilité à effectuer cette opération précise ? Qui a vu et approuvé son effet attendu ? Qui peut vérifier ensuite que l’état publié correspond toujours au réseau exploité ? Une seule réponse « utilisateur connecté » ne peut plus couvrir les quatre.

Reprendre le compte ne rétablit pas la route

La chronologie de Kentik montre que le contrôle et des ROA correctifs étaient revenus avant 18 h UTC, alors que des Invalid résiduels restaient visibles ensuite. Cette dissociation change la définition d’une restauration réussie. Réinitialiser un mot de passe ou révoquer une session ne suffit pas si les dépendances continuent à consommer un état hostile.

La réponse doit d’abord dresser l’inventaire de toutes les écritures réalisées pendant la période compromise. Elle doit ensuite comparer les autorisations présentes aux annonces BGP réellement voulues, depuis plusieurs validateurs et plusieurs observateurs. Enfin, elle doit suivre la visibilité des préfixes et le trafic jusqu’à ce que les écarts restants soient compris, non simplement jusqu’à la fermeture d’un ticket.

Le retour arrière exige un état sûr prédéfini. « Annuler la dernière modification » est insuffisant si l’attaquant a produit une séquence de changements ou si l’état précédent était déjà incohérent. Une organisation devrait conserver des instantanés explicitement validés, accompagnés des annonces attendues et de leur date de contrôle.

Un exercice crédible traverse également les frontières institutionnelles. Le détenteur des ressources, le service RPKI hébergé, le support du registre, les opérateurs de validateurs et les réseaux qui appliquent ROV ne disposent pas des mêmes journaux. Les réunir sur une ligne temporelle commune est le seul moyen de savoir qui détecte, qui bloque, qui corrige et qui peut attester la fin de l’impact.

Six propriétés d’une écriture proportionnée

La solution ne consiste pas à imposer une bureaucratie identique à chaque modification. Les opérateurs doivent pouvoir créer ou ajuster rapidement des ROA lorsque leur réseau change. Un contrôle trop lourd encouragerait les contournements et transformerait la sécurité en obstacle opérationnel.

Il faut plutôt estimer le rayon d’impact avant l’exécution. Le nombre d’adresses concernées, un nouvel ASN d’origine, un agrégat inhabituellement large, une longueur maximale plus restrictive que les annonces actuelles ou la suppression simultanée de nombreuses autorisations sont des signaux concrets. Le passage prévu de routes observées de Valid ou NotFound vers Invalid doit peser particulièrement lourd.

Première propriété : une nouvelle authentification au moment de l’écriture à fort impact. Un contrôle effectué plusieurs heures auparavant ne devrait pas suffire. Deuxième propriété : une approbation indépendante, montrant au second décideur les différences exactes, les préfixes concernés et l’effet de validation attendu.

Troisième propriété : une notification envoyée à un contact protégé que la session active ne peut pas remplacer silencieusement. Quatrième propriété : un reçu vérifiable qui contient l’avant, l’après, les identités d’exécution et d’approbation, l’heure et le chemin de restauration.

Cinquième propriété : une courte période de contestation pour les changements exceptionnels, assortie d’une voie d’urgence plus fortement approuvée. Sixième propriété : l’expiration automatique des dérogations et objets provisoires. Une mesure conçue pour quelques heures ne doit pas devenir une dette permanente de confiance.

Les recommandations opérationnelles publiées par CENIC après l’incident insistent à juste titre sur l’authentification forte, les alertes et la préparation à la récupération. Pour une direction, la question supplémentaire est de savoir si ces contrôles entourent la transaction dangereuse elle-même, et si leur efficacité a été démontrée dans une répétition réelle.

Une limite nécessaire au pouvoir institutionnel

La thèse de Running-Code Primacy défendue publiquement par Heng Lu fournit ici une contrainte normative, pas une preuve factuelle sur l’attaque. Elle affirme que l’ordre réel d’Internet repose sur les protocoles publics, le code déployé et l’interconnexion opérationnelle ; un registre ne doit pas transformer ses enregistrements en titre de propriété sur le réseau mondial.

Renforcer la garde des écritures reste compatible avec cette limite. Le registre ou le fournisseur hébergé protège mieux l’exercice de son propre pouvoir, tandis que chaque opérateur conserve le choix d’appliquer ROV. Le détenteur de ressources conserve des preuves portables et vérifiables. Aucun acteur central ne reçoit un bouton universel de routage.

Après Orange España, relâcher partout le rejet d’Invalid serait une mauvaise conclusion. Cela réduirait l’effet d’une autorisation erronée, mais rendrait de nouveau acceptables davantage de détournements. La réponse cohérente est de conserver la défense distribuée tout en sécurisant plus rigoureusement l’entrée signée dont elle dépend.

Ce que les sources ne permettent pas d’affirmer

Les observations disponibles ne montrent pas que chaque client, chaque préfixe ou chaque réseau partenaire a été touché de la même manière. Elles ne révèlent pas non plus toute la chaîne technique par laquelle l’attaquant a obtenu le compte. Une compromission est établie ; un scénario détaillé de logiciel malveillant, d’aide interne ou de vol particulier ne l’est pas.

Le nombre de routes et l’amplitude du trafic diffèrent selon les plateformes. Ces différences doivent rester visibles, car elles reflètent à la fois des couvertures distinctes et la nature distribuée de l’événement. Les agréger en une mesure mondiale précise donnerait une certitude que les sources n’offrent pas.

Enfin, rendre le deuxième facteur obligatoire ne prouve pas que la surface est désormais fermée. Il faut suivre la qualité des facteurs, la protection des codes de récupération, la révocation des sessions, la séparation des rôles et l’autorisation des opérations sensibles. L’identité et le consentement restent deux objets de contrôle différents.

Conclusion : sécuriser l’instant qui précède la signature

Orange España n’a pas démontré l’échec de la validation d’origine. L’incident a démontré qu’un mécanisme de confiance peut fidèlement amplifier une autorité de compte mal gardée. L’écriture hostile a précédé la panne ; les validateurs ont propagé ses conséquences ; les opérateurs les ont matérialisées selon leurs propres règles.

Le progrès ne se mesurera donc pas seulement au nombre de ROA ou de réseaux rejetant Invalid. Il faudra aussi mesurer le nombre d’écritures à fort impact soumises à une preuve renforcée, le délai de contestation, la protection des contacts, le temps de retour à un état sûr et le temps de disparition des Invalid observés.

Une signature répond à la question « ce système a-t-il bien émis cette affirmation ? ». La gouvernance doit encore répondre à la question plus difficile : « le pouvoir qui l’a émise était-il suffisant pour les conséquences qu’elle pouvait déclencher ? »

Sources