En bref

  • ARTEMIS est un système open source déployé par l’opérateur lui-même. Il compare les observations BGP actuelles à une intention de routage définie localement et ajoute un contexte que les collecteurs publics seuls ne peuvent fournir.
  • L’étude menée par FORTH et CAIDA en 2018 faisait état d’une détection en quelques secondes et d’une neutralisation en moins d’une minute dans les conditions testées; il ne s’agit pas d’une garantie universelle pour l’exploitation en production.
  • Pour atténuer un incident, ARTEMIS peut annoncer des routes plus spécifiques ou déclencher des procédures personnalisées. Toutefois, les filtres, une politique obsolète, une visibilité incomplète et des autorisations trop larges peuvent transformer une réponse rapide en second incident.
  • La viabilité du projet dépend désormais de la discipline des versions, de données convaincantes sur son adoption et d’une frontière transparente avec Code BGP: le soutien commercial peut entretenir le code ouvert sans remplacer l’histoire du projet de recherche.

Un changement réel de route a montré pourquoi les secondes ne sont qu’un début

Le rapport annuel 2019 de CAIDA indique qu’ARTEMIS a détecté en quelques secondes un détournement réel de route touchant un préfixe Internet2 /30. Ce cas dépasse les annonces synthétiques préparées par les chercheurs: une route a réellement changé dans un réseau entité au déploiement, et le système a reconnu l’écart assez vite pour soutenir l’enquête.

Le rapport n’établit pas une distribution universelle du délai de détection. Il s’agissait d’un préfixe /30 précis, dans un contexte de routage précis, observé par les sources accessibles à ce déploiement. Un autre incident peut se propager autrement, durer moins longtemps ou ne jamais atteindre les collecteurs connectés. Le rapport ne prouve pas non plus une intention malveillante et ne décrit pas tous les effets sur le plan de données. La conclusion défendable est plus étroite: dans le programme de déploiement de CAIDA, ARTEMIS a détecté en quelques secondes un incident réel documenté.

Les cas pratiques sont utiles lorsqu’on en conserve les limites. Ils montrent le comportement du programme face à un changement réel, la manière dont l’opérateur reçoit l’alerte et les preuves qui subsistent après l’événement. Pour évaluer la maturité en production, des dossiers supplémentaires — faux positifs, événements manqués et résultats des mesures d’atténuation compris — seraient plus utiles qu’un nouvel indicateur spectaculaire de rapidité.

Une alerte BGP peut arriver en quelques secondes tout en laissant sans réponse les questions essentielles. Un collecteur peut montrer qu’un système autonome inconnu annonce un préfixe, ou qu’une route plus spécifique apparaît et se propage. Il indique alors que le plan de contrôle ne correspond plus à la situation attendue. Mais cette observation ne permet pas, à elle seule, d’établir qui a effectué le changement, s’il s’agit d’une erreur, si le trafic a suivi le nouveau chemin, si des utilisateurs ont été touchés ni quelle action rétablira le service sans créer un autre problème.

ARTEMIS a précisément été conçu pour l’intervalle entre la détection et l’action. Son nom signifie Automatic and Real-Time dEtection and MItigation System, mais la capitalisation inhabituelle ne doit pas masquer son modèle opérationnel. Ce n’est pas un service central qui voit tout l’Internet et répare à distance les réseaux d’autrui. Une organisation déploie le logiciel dans l’infrastructure qu’elle contrôle, définit l’état de routage qu’elle considère comme légitime, connecte des observations publiques et privées, puis décide jusqu’où le système peut aller lorsque les faits divergent de la politique.

La promesse est une réaction rapide et contextualisée; la limite est que le contexte et l’autorité restent locaux.

ARTEMIS ressemble donc davantage à un instrument dans la salle de contrôle de l’opérateur qu’à une « police de l’Internet ». Il peut organiser les preuves, réduire le temps consacré à examiner les mises à jour de routes et préparer une réaction discutée à l’avance. Il ne dispense toutefois pas l’opérateur de jugement. Une décision peut modifier le routage mondial, les relations avec les fournisseurs amont et le trafic des clients; sa qualité dépend donc autant des personnes, de la configuration et des autorisations éprouvées que du détecteur.

BGP annonce l’accessibilité avant de pouvoir prouver l’autorisation

Le Border Gateway Protocol permet à des réseaux administrés indépendamment d’échanger des informations d’accessibilité et d’appliquer leurs propres politiques. Un système autonome annonce qu’il peut acheminer du trafic vers certains préfixes IP; les réseaux voisins décident d’accepter ces routes, de les privilégier et de les propager. Ce modèle a permis à l’Internet de s’étendre entre organisations sans contrôleur unique, mais le protocole d’origine n’associe pas de preuve cryptographique à chaque affirmation sur l’origine ou le chemin.

Une exportation erronée, une configuration obsolète ou une annonce délibérée peuvent donc introduire une route qui ne devrait pas exister.

Le mécanisme de sélection peut rendre une mauvaise annonce attractive. Lorsque deux routes couvrent des préfixes de même longueur, les réseaux appliquent leurs politiques et leurs règles de choix. Lorsqu’un attaquant ou un réseau mal configuré annonce un sous-préfixe plus spécifique, la règle ordinaire de correspondance au préfixe le plus long dirige généralement le trafic vers cette route plus étroite partout où elle est acceptée. Ce n’est pas une fonction particulière d’une attaque, mais la règle normale de sélection de la destination la plus précise.

Une petite annonce peut donc attirer rapidement le trafic, même si la route agrégée légitime reste visible.

Le terme « détournement » est commode, mais peut attribuer une intention que les messages de routage ne révèlent pas. Une origine non autorisée peut être malveillante, accidentelle ou liée à un changement commercial légitime absent de la politique de surveillance. Un faux chemin peut servir à intercepter le trafic, mais une seule mise à jour du plan de contrôle ne prouve pas qu’une interception a eu lieu. ARTEMIS est surtout utile lorsqu’il traite l’alerte comme une divergence entre routage observé et routage prévu, en laissant l’attribution et l’évaluation de l’impact au processus global de réponse.

Un événement portant sur un préfixe exact concurrence la route légitime de même longueur. Sa propagation dépend des politiques et de la sélection de chemin dans les réseaux qui reçoivent les deux annonces. Certaines parties de l’Internet peuvent préférer la route inattendue, tandis que d’autres continuent d’utiliser l’origine légitime. Il peut en résulter une accessibilité partielle, des différences régionales et un mélange complexe de réussites et d’échecs plutôt qu’une panne uniforme. La détection doit donc tenir compte non seulement de l’existence de la route, mais aussi des lieux et des modalités de sa propagation.

Un sous-préfixe attire généralement davantage de trafic, car la règle du préfixe le plus long privilégie la route la plus étroite. Si un réseau annonce habituellement un /20 et qu’une autre origine annonce un /24 inclus, les routeurs ayant accepté le /24 lui enverront généralement le trafic correspondant. La désagrégation constitue aussi une défense courante: l’opérateur légitime annonce des routes aussi spécifiques, voire davantage, afin de récupérer la préférence. Cette méthode connaît cependant une limite stricte: de nombreux réseaux filtrent les routes IPv4 plus longues que /24 et les routes IPv6 plus longues que /48.

Un opérateur qui annonce déjà des préfixes de cette longueur peut ne disposer d’aucune route plus étroite acceptée mondialement.

ARTEMIS examine également le « squattage » et certaines violations de politique, dont le scénario no-export décrit dans les documents du projet. Ces catégories comptent parce qu’un incident de routage ne se réduit pas toujours à l’annonce du préfixe d’une victime par un tiers. Une route peut avoir une origine autorisée tout en sortant par une relation inattendue. Le système de surveillance doit disposer d’un contexte politique suffisant pour distinguer ces cas sans prétendre que les données BGP révèlent tous les accords privés entre réseaux.

ARTEMIS intègre l’intention de routage de l’opérateur dans le détecteur

Les services externes de surveillance ont un avantage évident: ils recueillent des données provenant de nombreuses parties de l’Internet sans obliger chaque réseau à déployer une plateforme complète. Leur faiblesse est tout aussi claire. Un tiers voit les préfixes et les chemins annoncés, mais peut ignorer quels changements d’origine, fournisseurs de secours, dispositifs d’ingénierie du trafic ou annonces d’urgence sont autorisés par l’opérateur. Des règles générales peuvent donc manquer une violation subtile ou déclencher une alerte lors d’un changement planifié.

ARTEMIS déplace le point d’observation. Le détecteur est exécuté par l’organisation dont l’espace d’adressage est exposé, et cette organisation définit la référence. Les collecteurs publics conservent une vue extérieure étendue, mais leurs observations sont interprétées à partir de connaissances privées sur les préfixes protégés, les AS d’origine autorisés, les voisins acceptables et certaines relations de chemin. Les flux locaux des routeurs ajoutent des événements invisibles aux collecteurs publics.

L’idée déterminante du projet est que des données mondiales incomplètes deviennent plus utiles lorsqu’elles sont comparées à une intention locale explicite.

Installer le détecteur dans le réseau protégé y transfère également la responsabilité. L’organisation qui exploite ARTEMIS doit décider qui possède le fichier de politique, comment les modifications sont vérifiées, quelles alertes atteignent le centre d’exploitation réseau, quelles conclusions l’équipe de sécurité peut tirer et qui peut autoriser une nouvelle route. Le logiciel rend cette responsabilité visible, sans pouvoir contraindre l’institution à bien l’exercer.

ARTEMIS demande à l’opérateur de définir les préfixes protégés, les systèmes autonomes d’origine légitimes, les relations de voisinage acceptables et les règles de routage choisies. Cette référence permet de poser une question plus précise qu’un service externe universel: au lieu de déterminer si une route paraît inhabituelle au regard de l’histoire mondiale, le système vérifie si elle viole l’intention déclarée d’un réseau donné.

L’avantage ne vaut que ce que vaut la déclaration. Les réseaux changent de fournisseurs, ajoutent des sites anycast, déplacent leurs AS d’origine, créent des chemins de secours temporaires et diffusent des annonces d’urgence pendant les pannes. Une politique exacte en janvier peut être obsolète en juin. Si un changement atteint les routeurs mais pas ARTEMIS, le détecteur peut produire un faux positif critique. Si les règles ont été excessivement élargies pour réduire le bruit, une violation réelle peut devenir « autorisée » sur le papier.

Le système transforme ainsi une configuration technique en accord institutionnel. Les ingénieurs routage, la sécurité et la gestion des changements doivent s’entendre sur le sens du fichier, les personnes autorisées à le modifier et la vitesse à laquelle il suit le réseau de production. Le contexte local ne supprime pas les faux positifs et faux négatifs; il déplace leur principale origine vers un domaine que l’opérateur peut gouverner.

Une règle de sécurité du routage mérite la même discipline qu’un code susceptible d’affecter le trafic des clients. Les changements doivent avoir des responsables, une validation, un historique de versions, des tests et une justification liée à une modification réseau approuvée. L’opérateur doit pouvoir indiquer quand un préfixe, une origine ou un voisin a été ajouté, qui l’a autorisé et quel incident ou projet justifiait la décision. Un simple fichier de configuration peut soutenir ce processus, à condition de ne pas être traité comme un élément ponctuel de l’installation.

Les tests doivent couvrir les scénarios positifs et négatifs. Une route légitime planifiée doit passer sans alerte. L’annonce d’un préfixe exact par une origine non autorisée doit recevoir la classification attendue. Un sous-préfixe doit déclencher le bon niveau de gravité, et une violation no-export ne doit pas être confondue avec un détournement d’origine. La relecture historique aide à vérifier ces cas; un environnement de test confirme que les notifications et procédures d’atténuation reçoivent les données prévues.

Cette discipline limite aussi la dérive organisationnelle. Lorsque la personne ayant initialement déployé ARTEMIS quitte l’organisation, la politique doit rester compréhensible pour son successeur. Un détecteur dont la logique repose sur une mémoire non documentée n’est pas une infrastructure fiable, même si son code est ouvert et ses sources rapides.

FORTH et CAIDA ont transformé une question de recherche en processus opérationnel

Le projet est né d’une collaboration entre des chercheurs de la Foundation for Research and Technology-Hellas, dans l’écosystème de l’Université de Crète, et CAIDA, à l’Université de Californie à San Diego. FORTH a apporté son expertise en protection du routage et en ingénierie des systèmes. CAIDA a ajouté son infrastructure de mesure de l’Internet, son expérience de BGPStream et des relations qui ont facilité le déploiement dans les réseaux de recherche et d’enseignement. ARTEMIS associait donc dès l’origine connaissances protocolaires, systèmes de mesure et accès aux opérateurs.

Le financement a suivi le même modèle institutionnel mixte. L’histoire du projet mentionne des programmes européens et américains, le Community Projects Fund de RIPE NCC, un projet de déploiement NSF EAGER, le département américain de la Sécurité intérieure et le Comcast Innovation Fund. Le soutien de RIPE en 2017 a aidé à transformer le prototype en outil destiné aux opérateurs, tandis qu’une subvention de 50 000 euros en 2019 a financé la validation du plan de données avec RIPE Atlas.

Ces financements montrent comment une recherche d’intérêt public est devenue un logiciel déployable, sans révéler le coût actuel du soutien aux installations de production.

L’histoire institutionnelle est essentielle à une attribution correcte. ARTEMIS n’est ni une fondation indépendante, ni un service de CAIDA, ni un détecteur mondial appartenant à FORTH. C’est un logiciel open source sous licence BSD 3-Clause, issu de la recherche et aujourd’hui maintenu commercialement. Son développement se décrit mieux comme une succession de collaborations que comme la propriété d’une seule organisation.

La première étape publique fut une démonstration à ACM SIGCOMM en 2016. L’avancée principale consistait à réunir surveillance et atténuation dans une même boucle. De nombreux systèmes peuvent reconnaître une route suspecte après accumulation des données. ARTEMIS posait une autre question: l’opérateur peut-il voir l’événement assez vite et disposer déjà d’une contre-mesure pratique, afin d’éviter que l’incident circule pendant des heures entre tableaux de bord, courriels et sessions manuelles sur les routeurs?

Une démonstration n’est pas un déploiement industriel mature. Elle montre que les composants peuvent fonctionner ensemble dans une configuration donnée et que le problème de recherche est assez concret pour une expérience publique. Le travail de 2016 a néanmoins fixé la direction: observations en direct, représentation interne du routage légitime, classification et annonce préparée. Cette séquence a fait du délai de réaction une propriété du système plutôt qu’une simple conséquence organisationnelle.

Le projet a été influencé par des témoignages d’opérateurs selon lesquels la réaction à un détournement pouvait prendre des heures. Le retard ne venait pas seulement de collecteurs lents. Les équipes devaient confirmer la propriété du préfixe, étudier la propagation, déterminer si le changement était prévu, trouver les bons contacts chez le fournisseur et préparer une contre-annonce sûre. ARTEMIS réduit plusieurs de ces étapes en rapprochant politique, procédures et surveillance, mais les relations humaines et commerciales entourant la route restent hors du code.

L’article publié en 2018 dans IEEE/ACM Transactions on Networking a formulé l’affirmation la plus mémorable: neutraliser un détournement BGP en moins d’une minute. Les chercheurs ont testé l’approche dans des expériences réelles et signalé une détection en quelques secondes ainsi qu’une atténuation avant une minute dans les conditions étudiées. Le résultat montrait qu’un réseau victime n’était pas nécessairement obligé d’attendre un service externe, une chaîne d’appels et une contre-annonce construite manuellement.

Cette formule devient trompeuse lorsqu’elle est séparée de l’expérience. Le délai de détection dépend de l’arrivée de l’événement chez un observateur connecté, de la vitesse de transmission de la source, de l’adéquation des règles et de l’état du système. Le délai d’atténuation dépend de la longueur du préfixe de la victime, de ses autorisations de routage, des filtres des fournisseurs, de la propagation et du processus d’approbation. Une confirmation humaine obligatoire peut être plus sûre et plus lente; une automatisation immédiate sera plus rapide mais acceptera un risque supplémentaire.

La conclusion responsable reste limitée. ARTEMIS a montré qu’un système étroitement intégré chez l’opérateur pouvait raccourcir un processus autrefois beaucoup plus long. Il n’a pas prouvé que chaque détournement est visible, que chaque contre-route est acceptée ou que toute équipe de production doit autoriser une désagrégation autonome. Le résultat constitue un objectif de conception validé expérimentalement, pas une garantie universelle.

Plusieurs vues incomplètes composent une image exploitable de l’incident

ARTEMIS peut utiliser plusieurs sources publiques parce qu’aucun collecteur ne voit toutes les routes. RIPE RIS et le projet RouteViews de l’Université de l’Oregon reçoivent des mises à jour BGP de partenaires sélectionnés dans des points de collecte distribués. CAIDA BGPStream fournit un mécanisme commun d’accès et de normalisation des données provenant de plusieurs sources. Chaque service élargit la vision de l’opérateur, mais ne reflète que les réseaux connectés à ses collecteurs, la géographie des sessions et les caractéristiques temporelles des flux.

Cette visibilité partielle a des conséquences pratiques. Un événement peut se propager dans une région sans atteindre un collecteur utilisé par le déploiement. Une annonce très brève peut être retirée avant sa livraison par le flux. Une route peut affecter les clients par une relation privée absente des données ouvertes. Combiner les collecteurs réduit certains angles morts, mais produit un échantillon plus large, non une copie omnisciente du plan de contrôle mondial.

La bonne question opérationnelle n’est donc pas « ARTEMIS a-t-il vu l’Internet? », mais « quels observateurs ont vu cette annonce, à quelle vitesse, et quelle partie de l’événement a pu rester hors de l’échantillon? ». Cette formulation encourage la conservation de la provenance de chaque alerte et évite de prendre l’absence dans un flux pour la preuve que la route n’a jamais existé.

RIPE NCC a présenté un prototype public de RIS Live en février 2019 afin de diffuser les messages BGP avec une latence bien inférieure à celle du traitement périodique des archives. ARTEMIS illustrait l’utilité d’un tel flux: un système de sécurité ne peut répondre en quelques secondes si son observation principale arrive plusieurs minutes plus tard.

La faible latence ne supprime pas les limites d’observation. RIS Live reflète toujours les partenaires connectés au RIPE Routing Information Service et les routes qu’ils exportent. Un détournement local, filtré avant le collecteur ou caché par une autre relation peut ne laisser aucune preuve décisive dans le flux. La fiabilité compte aussi: une panne du flux ou un changement de schéma ressemble à du silence si la surveillance ne distingue pas « aucune route suspecte » de « aucune donnée ».

L’état des sources fait donc partie du modèle de sécurité. L’opérateur doit savoir si chaque moniteur fonctionne à temps, accuse du retard, est déconnecté ou produit un volume inhabituel. Un détecteur qui affiche avec assurance un état normal malgré des entrées dégradées peut créer une ignorance plus dangereuse qu’une panne explicite.

La surveillance en temps réel répond à ce qui apparaît maintenant; les bases d’informations de routage et les archives donnent le contexte. RIPE RIS et RouteViews publient un historique montrant les origines et chemins antérieurs, le début du changement et sa durée. CAIDA BGPStream simplifie le traitement de ces enregistrements et permet à ARTEMIS de rejouer les événements et de tester les règles sur le comportement passé.

La relecture est utile pour la validation technique et l’analyse. Une équipe peut vérifier si une nouvelle règle aurait détecté un événement connu, reconstruire la séquence ayant conduit à l’alerte ou former les intervenants sans modifier une route en production. L’historique révèle aussi des annonces répétées qui paraissent anormales isolément mais relèvent d’un dispositif de secours établi. La limite demeure: l’archive reflète le regard des collecteurs, non l’intégralité de l’événement, et une ancienne topologie ne reproduit pas toutes les relations actuelles.

Un déploiement mature peut intégrer cette relecture à la gestion des changements. Avant de mettre en production une nouvelle origine, un nouveau fournisseur ou une règle d’exportation, l’opérateur teste la référence mise à jour sur un historique représentatif. La configuration devient alors un artefact de sécurité vérifiable plutôt qu’un fichier modifié seulement après l’apparition de bruit.

Les données publiques ne sont qu’un volet de l’architecture. ARTEMIS peut recevoir des mises à jour locales par ExaBGP ou par des sessions privées BGP Monitoring Protocol. ExaBGP agit comme un locuteur BGP programmable et transmet les événements à d’autres applications. BMP permet aux routeurs d’exporter leurs informations de routage vers un système de surveillance sans l’associer aux décisions de transfert. Ces sources montrent les voisinages et l’état des routes du réseau protégé avant que les informations n’atteignent un collecteur public.

Les flux locaux améliorent la rapidité et le contexte, mais introduisent des informations d’infrastructure sensibles. Les données BMP peuvent être volumineuses et révéler des relations internes. L’intégration d’ExaBGP exige un contrôle strict, car la même interface programmable peut observer et annoncer des routes. Identifiants, accès réseau, validation des messages et séparation entre surveillance et atténuation deviennent des frontières de sécurité.

Un bon déploiement utilise les flux publics et privés pour des tâches différentes. Les collecteurs publics montrent la propagation au-delà du voisinage immédiat de l’opérateur; les sources locales montrent ce que le réseau et ses routeurs ont vu. Leur désaccord n’est pas nécessairement une erreur: il peut révéler où la propagation s’est arrêtée ou où une politique a agi.

L’application sépare observation, détection et preuves

La plateforme actuelle est une application microservices à plusieurs conteneurs, et non un script unique lisant un flux. Les services de surveillance se connectent aux sources publiques et privées, normalisent les informations BGP et publient des événements. Les services de détection appliquent ensuite les règles de l’opérateur. Autour du noyau se trouvent le stockage, une API, une interface web, les notifications et la supervision. Cette séparation permet aux composants d’évoluer ou de tomber en panne indépendamment et facilite l’ajout de sources.

La modularité multiplie aussi les dépendances. Un moniteur peut être sain tandis que le détecteur est arrêté; le bus de messages peut recevoir des événements alors que la base est indisponible; l’interface peut afficher un ancien incident malgré une chaîne en direct défaillante; l’orchestrateur peut redémarrer un conteneur et masquer des pannes répétées. Les contrôles doivent donc couvrir tout le chemin allant de la source à l’alerte.

Docker Compose abaisse le seuil d’un déploiement contrôlé, tandis que Kubernetes convient aux organisations utilisant déjà des plateformes de conteneurs. Aucun des deux ne transforme ARTEMIS en service mondial géré. Le réseau qui le déploie reste responsable des capacités, mises à jour, secrets, données, sauvegardes et accès d’urgence.

Le bus de messages permet aux services de surveillance, de détection et de notification d’échanger sans dépendance directe. Il peut absorber des pics et laisser les consommateurs avancer à des vitesses différentes, mais soulève les questions d’ordre, de doublons et de contre-pression. Un incident peut générer des milliers de mises à jour, retraits et changements de chemin; le système doit conserver assez de séquence et de provenance pour reconstruire l’événement.

Le stockage persistant distingue ARTEMIS d’une alerte éphémère. Les mises à jour, alertes, états de configuration et décisions peuvent être conservés pour analyse. L’architecture a utilisé PostgreSQL, un stockage de type Timescale et l’écosystème d’API Hasura. Ces composants facilitent les requêtes et intégrations, mais créent une archive sensible exigeant des durées de conservation, des contrôles d’accès et des sauvegardes fiables.

L’auditabilité n’équivaut pas à la certitude. Un enregistrement complet peut montrer comment ARTEMIS a produit une alerte; il ne prouve pas que toutes les routes importantes ont été vues ni que les règles étaient correctes. La base doit donc conserver la source et le degré de confiance, pas seulement l’étiquette finale.

L’interface web présente les incidents, l’état du système et les observations sous une forme adaptée à un centre réseau ou de sécurité. Les notifications envoient les alertes par courriel, canal mobile ou intégration personnalisée, tandis que Grafana montre l’état des services et les tendances. Ces fonctions transforment un mécanisme de recherche en outil opérationnel: l’équipe a besoin de priorités, d’un historique et d’une vue unifiée, pas de mises à jour BGP brutes.

L’interface peut aussi créer une fausse assurance. Une fiche rouge représente une classification fondée sur des observations et des règles, non une preuve indépendante de malveillance. Une carte peut sembler complète tout en ne représentant que certains collecteurs. Si les changements planifiés ne figurent pas dans la politique, les notifications deviennent du bruit et la fatigue augmente le risque de manquer un événement important.

Une bonne pratique relie l’interface à la vérification. L’intervenant doit pouvoir ouvrir les mises à jour sources, comparer les flux publics et locaux, vérifier l’état RPKI, tester le plan de données et consigner pourquoi l’incident a été escaladé, ignoré ou clôturé. Le tableau de bord est utile lorsqu’il raccourcit ce parcours, pas lorsqu’il le remplace.

Un schéma de route ne prouve ni le motif ni les conséquences

La recherche ARTEMIS a élaboré une classification distinguant les événements selon les relations entre préfixes, les manipulations du chemin AS, la politique et l’effet possible sur le plan de données. L’implémentation prend en charge une partie de ces schémas à partir du plan de contrôle: préfixes exacts et sous-préfixes avec origine incorrecte, squattage et certaines violations d’exportation. Cette classification fournit un langage commun et permet d’appliquer des règles différentes.

Les catégories doivent rester liées à ce que montrent réellement les données. Un chemin commençant par un voisin inattendu peut signaler un segment falsifié, une fuite de route ou une modification autorisée absente de la politique. Une origine non autorisée peut être une erreur plutôt qu’une attaque. Même une annonce intentionnelle peut viser à mettre le trafic en trou noir, à substituer un service ou à observer le transit; les seules mises à jour BGP ne distinguent pas ces résultats.

Une terminologie prudente protège la précision et la qualité de la réponse. Au stade de l’alerte, « détournement présumé » ou « violation de politique » est généralement plus sûr que « attaque ». Une formulation plus forte devrait suivre la vérification de la propriété de la route, les contacts avec l’opérateur et les données du plan de transfert. Cette retenue empêche le classificateur de transformer une incertitude en affirmation répétée comme un fait.

Les messages BGP décrivent des déclarations d’accessibilité et les chemins échangés entre réseaux. Ils ne montrent pas tous les paquets qui suivent la route choisie. Après une annonce suspecte, le trafic peut être mis en trou noir, intercepté puis retransmis, recevoir une réponse d’un service substitué ou ne pas changer si la route n’atteint pas les réseaux des utilisateurs concernés. Différentes parties de l’Internet peuvent subir simultanément des effets différents.

Cette limite est centrale. Le détecteur peut montrer qu’une route viole la politique et apparaît dans certains points d’observation. Il ne déduit pas le motif du chemin AS et ne garantit pas qu’un traceroute suit la même direction que le trafic applicatif. Le chiffrement, le DNS, les caches, l’anycast et le basculement applicatif modifient encore l’expérience. Une alerte du plan de contrôle constitue donc une preuve d’incident, mais pas l’incident entier.

Une réponse utile combine plusieurs enregistrements. Les données BGP établissent l’annonce et sa propagation. Les tests du plan de données vérifient l’accessibilité et les chemins depuis certains lieux. La télémétrie du service montre les erreurs, la latence et l’impact client. Les contacts avec les fournisseurs établissent si l’annonce était autorisée ou erronée. Aucun élément n’est parfait, mais leur combinaison soutient une décision qu’un flux unique ne peut produire.

Une subvention du RIPE Community Projects Fund en 2019 a soutenu l’ajout de mesures traceroute RIPE Atlas afin d’évaluer l’effet des événements détectés. Ce travail reconnaissait la limite de la boucle initiale du plan de contrôle. Une route peut sembler dangereuse dans BGP tout en ayant peu d’effet sur les utilisateurs, tandis qu’une propagation réduite peut toucher un groupe de clients précieux. Les sondes du plan de données ajoutent des informations sur le chemin présumé et l’accessibilité.

RIPE Atlas dispose d’un réseau distribué de sondes, mais leur répartition est inégale et la cible peut répondre sans révéler le chemin. Le filtrage, l’équilibrage, les tunnels et le routage asymétrique influencent traceroute. Le chemin aller d’une sonde ne correspond pas nécessairement au chemin retour du trafic client. Un échec de mesure peut signifier une panne, un nœud silencieux ou une limite du test.

Le gain pratique n’est pas une certitude totale, mais un meilleur tri. Si les collecteurs montrent un sous-préfixe non autorisé et que des sondes de plusieurs régions perdent l’accès ou passent par une origine inattendue, l’escalade est mieux justifiée. Si l’événement n’est visible que chez un collecteur et que les tests restent stables, l’équipe peut poursuivre l’enquête avant de modifier les annonces mondiales.

La désagrégation ne récupère le trafic que si le système de routage l’autorise

La réponse la plus connue d’ARTEMIS est la désagrégation. Une victime annonçant un préfixe large peut diffuser des routes plus spécifiques pour que la sélection au préfixe le plus long ramène le trafic vers le réseau légitime. Cette méthode utilise le fonctionnement normal de BGP, peut se propager rapidement et convenait donc à l’objectif expérimental d’une réponse « en moins d’une minute ». Elle permet aussi à la victime d’agir sans attendre la coopération de l’origine inattendue.

La désagrégation connaît des limites strictes. Beaucoup de réseaux filtrent les routes IPv4 plus longues que /24 et les routes IPv6 plus longues que /48 afin de limiter la croissance des tables et les abus. Une victime annonçant déjà un /24 ou un /48 peut ne pas pouvoir émettre une route plus spécifique largement acceptée. Les fournisseurs limitent aussi les annonces permises à leurs clients, et les objets de route, filtres de préfixes ou données RPKI doivent autoriser l’état d’urgence. La propagation n’est ni instantanée ni uniforme.

Un opérateur préparé connaît ces limites: quels préfixes peuvent être désagrégés, quels fournisseurs les accepteront, quels filtres et Route Origin Authorisations couvrent l’état d’urgence, et comment les routes seront retirées après le rétablissement. ARTEMIS peut déclencher un script externe, mais son succès dépend d’accords situés hors de l’application.

Les documents du projet parlent d’atténuation automatique, et la recherche comprend une boucle fermée dans laquelle la détection déclenche une contre-annonce. Les descriptions opérationnelles présentent aussi une confirmation manuelle et des procédures pilotées par l’utilisateur. Ces affirmations sont compatibles: les déploiements choisissent différents degrés d’autonomie. ARTEMIS prend en charge une atténuation automatisée ou approuvée par l’opérateur au moyen de processus configurables.

Le risque est asymétrique. Un retard peut prolonger une panne ou une interception. Une réponse automatique erronée peut annoncer des routes inutiles, violer la politique d’un fournisseur, révéler des hypothèses internes ou créer de l’instabilité. Une référence obsolète peut transformer un changement prévu en fausse urgence. Si un script externe possède des autorisations étendues sur les routeurs, la compromission d’ARTEMIS devient elle-même une attaque contre le routage.

Une automatisation plus sûre procède par étapes. Le système enrichit d’abord l’alerte, vérifie plusieurs flux, l’état RPKI et le plan de données, puis prépare une modification précise. Les actions à fort impact sont approuvées par une personne; les cas moins risqués peuvent suivre automatiquement une politique. Limitation de fréquence, autorisations étroites, simulation, journal des changements et retour arrière testé comptent davantage que l’étiquette « automatique ». La vitesse ne doit pas supprimer la responsabilité.

RPKI ne renforce qu’un maillon de la chaîne de preuves

La Resource Public Key Infrastructure permet aux détenteurs d’adresses de créer des Route Origin Authorisations indiquant quels systèmes autonomes peuvent annoncer certains préfixes et longueurs maximales. La Route Origin Validation classe ensuite une route comme valide, invalide ou non couverte. Elle ajoute une preuve cryptographique à une partie de BGP autrement fondée sur la confiance distribuée. Le contrôle est proactif: d’autres réseaux peuvent rejeter ou déprioriser une origine non autorisée avant que le trafic ne la suive.

ARTEMIS intervient à un autre niveau. Il peut utiliser l’état RPKI comme preuve, mais compare aussi les routes aux règles privées de l’opérateur, enregistre l’événement, réunit flux publics et locaux et relie détection et réponse. RPKI ne valide pas l’ensemble du chemin AS et son adoption n’est pas universelle. Une route valide selon RPKI peut violer une relation de voisinage attendue ou fuir par un chemin indésirable; inversement, un changement légitime devient invalide si le ROA n’est pas mis à jour.

Les mécanismes sont donc complémentaires. RPKI réduit le nombre d’origines non autorisées acceptées par l’Internet. ARTEMIS montre à la victime les observations réelles, détecte certains schémas au-delà de la validité de l’origine et organise la réponse. De futurs mécanismes d’autorisation de chemin comme ASPA peuvent renforcer les preuves de relations, sans supprimer la nécessité d’observer les annonces et leurs effets.

Les projets pilotes ont sorti ARTEMIS du laboratoire sans prouver l’ampleur du marché

CAIDA a signalé un déploiement expérimental d’ARTEMIS soutenu par la NSF avec Internet2, Great Plains Network et Merit en 2018-2019. Ces pilotes sont importants parce que les réseaux de recherche et d’enseignement ont de vrais préfixes, fournisseurs, processus de changement et obligations de service. Les opérateurs ont pu vérifier l’intégration du logiciel, l’adéquation des règles à leur intention et l’entrée des alertes dans leur réponse.

Les preuves sont convaincantes mais limitées. Un pilote confirme l’installation, le retour technique et certains usages; il ne prouve ni une couverture continue en production, ni l’actualité de la version, ni une efficacité égale dans tous les réseaux. Le site publie aussi des témoignages d’ingénieurs liés à AMS-IX, Internet2 et ESnet ainsi que des logos. Cela indique des essais ou un usage, mais ne permet pas de qualifier chaque organisation de client payant actuel ni d’attribuer au projet une part de marché mondiale connue.

La distinction compte car les déploiements de sécurité du routage sont souvent invisibles. Un opérateur peut utiliser un fork interne, se limiter à la surveillance ou arrêter après un essai. L’absence de registre complet ne rend pas le projet insignifiant, mais empêche de mesurer précisément sa diffusion. Les cas nommés valent davantage qu’un grand chiffre non vérifié.

Le contrôle de l’opérateur implique une charge d’intégration et de sécurité de la chaîne logicielle

ARTEMIS est distribué sous licence BSD 3-Clause. L’opérateur peut examiner le code, l’exécuter dans une infrastructure contrôlée, modifier les intégrations et éviter de confier sa politique sensible à un fournisseur central obligatoire. Ce modèle correspond à l’avantage principal du projet: la référence la plus précieuse reste dans le réseau. La licence autorise aussi l’usage commercial et les forks, permettant à Code BGP et à d’autres de proposer des services autour du socle ouvert.

Ce contrôle exige du travail. La plateforme comprend conteneurs, bus de messages, bases, API, application web, notifications et connexions aux flux. Chaque composant nécessite mises à jour, identifiants, segmentation, sauvegarde et surveillance. Le système conserve une politique sensible et peut détenir des autorisations capables de modifier les annonces. La surface d’attaque d’un déploiement de production dépasse donc largement l’algorithme de détection initial.

La licence ouverte offre une sortie possible de la dépendance à un mainteneur, mais ne crée pas automatiquement un service d’assistance. Quelqu’un doit toujours examiner les mises à jour, comprendre les dépendances et intervenir lorsque les flux ou interfaces changent. Pour un petit réseau, un outil d’alerte plus simple ou un service commercial géré peut être plus pratique malgré un contrôle local moindre.

Un service ARTEMIS de production doit rester disponible pendant l’instabilité réseau qui justifie son existence. Flux, bus, base, API, interface, notifications et authentification forment une chaîne. La redondance des conteneurs n’aide que si l’état, le stockage et les dépendances externes tolèrent aussi les pannes. Un moniteur redémarré ne récupère pas les mises à jour non conservées, et une interface répliquée ne montre pas un événement que la chaîne de détection n’a pas traité.

L’architecture doit donc prévoir explicitement les modes dégradés. Si un flux public disparaît, le système doit signaler la réduction de couverture. Si la base est indisponible, le détecteur peut devoir conserver localement les événements ou suspendre l’atténuation faute de preuve d’audit. Si le fournisseur d’identité tombe en panne, un accès d’urgence doit rester possible sans compte permanent incontrôlé. Ces décisions ne relèvent pas de la taxonomie des détournements, mais déterminent si l’idée de recherche devient une infrastructure fiable.

La plateforme a également besoin d’un budget de performance. Un pic de mises à jour légitimes pendant une grande modification peut charger les moniteurs et le stockage davantage qu’un détournement. Les files internes ne doivent pas transformer silencieusement un flux presque temps réel en rapport tardif. Tests de capacité, durées de conservation et contre-pression doivent faire partie de la planification, car ils limitent la vitesse de réaction que le système peut honnêtement promettre.

ARTEMIS réunit composants web, images de conteneurs, base, messagerie, API, authentification et bibliothèques réseau. Chaque dépendance devient une vulnérabilité ou un point de panne possible. Une faille d’interface peut révéler la politique; une image compromise peut modifier les alertes; un jeton trop large peut exposer les incidents; des identifiants dans le mécanisme d’atténuation peuvent autoriser des changements de route. La sécurité du détecteur est donc indissociable de celle de son socle logiciel.

Le code ouvert aide: l’opérateur peut examiner les composants, figer les versions et construire ses propres images. Mais l’ouverture ne garantit pas l’audit de chaque dépendance transitive ni une correction conforme au calendrier d’un réseau donné. Une équipe de production a besoin d’un inventaire des images et bibliothèques, d’un processus de reconstruction, d’une séparation entre surveillance en lecture seule et atténuation en écriture, ainsi que d’une méthode de mise à jour préservant l’historique.

Ces exigences modifient les critères de maintenance. Une nouvelle fonction de détection est plus visible qu’une mise à jour de base ou un correctif d’authentification, alors que ces derniers peuvent être plus importants pour l’intégrité. Bulletins de sécurité, builds reproductibles, mises à jour des dépendances et branche de versions maintenue témoignent de la maturité, même sans nouveau bouton.

Les versions et Code BGP définissent l’épreuve actuelle de maintenance

La dernière version formellement étiquetée dans le dossier de recherche est la 2.3.0 Cadmus du 24 novembre 2022. À la date de référence du 5 août 2026, la démonstration en direct affichait un build fondé sur un commit plus récent et le site restait actif. Cela confirme la poursuite du travail après la dernière version formelle, tout en soulevant une question légitime: quelle version est testée, prise en charge et adaptée aux mises à niveau?

Les commits et la démonstration montrent une activité de développement. Une version sémantique apporte une autre assurance: base nommée, notes de version, dépendances attendues et point de référence pour les tests. Un projet peut rester actif avec un processus de publication en retard, et une démonstration peut utiliser un code qu’un réseau de production ne devrait pas adopter sans validation.

Pour une infrastructure de protection du routage, la discipline des versions appartient au modèle de sécurité. Les opérateurs doivent savoir quelles branches reçoivent des correctifs, comment les migrations se déroulent et si d’anciennes dépendances restent vulnérables. Une nouvelle étiquette ne prouvera pas la fiabilité universelle, mais une politique publique de soutien et de sécurité réduirait davantage l’incertitude qu’un site actif seul.

Le site présente Code BGP comme le mainteneur actuel d’ARTEMIS et comme une jeune entreprise issue du projet. La commercialisation peut résoudre un vrai problème du logiciel ouvert: la protection du routage exige des personnes capables d’entretenir les intégrations, de répondre aux vulnérabilités, d’aider les déploiements et de transformer les fonctions de recherche en exploitation durable après les subventions.

Code BGP reste une entreprise commerciale distincte, avec un contexte de produits et de clients plus large. Elle ne doit pas servir d’autre nom à FORTH, CAIDA ou à tout déploiement ouvert. Les documents publics ne révèlent ni ses revenus, ni sa valorisation, ni sa liste de clients, ni la frontière précise entre fonctions publiques et commerciales. Ce n’est pas un reproche, mais une limite des affirmations possibles.

Cette relation crée deux séries d’incitations susceptibles de converger ou de diverger. Le projet ouvert bénéficie du code et de la documentation apportés par les salariés commerciaux; l’entreprise bénéficie de la confiance, de la diffusion et du socle technique du projet. L’épreuve à long terme sera de savoir si versions, correctifs et décisions de feuille de route restent assez visibles pour les opérateurs qui ne sont pas clients.

La licence permissive garantit la possibilité de copier, modifier et commercialiser le code. Elle ne garantit pas qu’une autre équipe comprendra l’architecture, reproduira une version ou assurera la maintenance après le départ des spécialistes actuels. La continuité dépend de la documentation, des tests, de l’historique des problèmes, de la connaissance des dépendances et d’un parcours d’intégration pour de nouveaux contributeurs.

La maintenance par Code BGP peut renforcer cette continuité en conservant des ingénieurs expérimentés autour de la plateforme. Elle peut aussi concentrer le savoir pratique dans l’entreprise malgré un dépôt public. Les notes de version, discussions ouvertes, réponses à la communauté et informations offertes aux déploiements non clients permettront de distinguer ces trajectoires.

L’enjeu n’est pas d’interdire la valeur commerciale. Un modèle sain à cœur ouvert peut lier le support payant à l’entretien public. Le risque apparaît si le projet ouvert devient une démonstration historique tandis que la voie opérationnelle migre vers des composants privés non documentés. La portabilité doit donc être testée concrètement: un opérateur indépendant peut-il installer, mettre à jour, vérifier et restaurer le système avec les documents publics disponibles?

ARTEMIS occupe une position intermédiaire exigeante dans la protection du routage

Le domaine comprend collecteurs publics, systèmes de recherche, outils ouverts d’alerte, validateurs RPKI et plateformes commerciales. RIPE RIS, RouteViews et BGPStream fournissent des données, non un processus d’incident adapté à un opérateur. BGPalerter propose un autre modèle ouvert. MANRS définit des normes opérationnelles sans détecter les événements en direct. Les services commerciaux peuvent offrir une observation étendue et des analystes, mais manquent souvent du contexte local privé sans intégration avec le client.

La position distinctive d’ARTEMIS repose sur le contrôle de l’opérateur, une référence explicite, plusieurs flux publics et locaux, le code ouvert et une atténuation facultative. Elle est aussi exigeante. Le réseau doit disposer de spécialistes du routage, d’une politique maintenue et de la capacité d’exploiter une plateforme multicomposant. Le projet convient probablement mieux aux organisations pour lesquelles la protection du routage est une compétence interne qu’à celles qui recherchent un abonnement supplémentaire à un tableau de bord.

La comparaison ne peut se réduire à une liste de fonctions. Les modèles répartissent différemment confiance et travail. Un service géré centralise expertise et observation; un système chez l’opérateur maintient politique et action près du réseau. La question pratique est de savoir qui voit assez, agit de manière sûre et reste responsable lorsque les preuves sont incomplètes.

ARTEMIS Lite est apparu dans les documents de la communauté RIPE en 2023 comme approche allégée visant à réduire la charge de déploiement. Son existence montre que l’étendue de la plateforme complète peut peser sur une petite équipe. Une pile multiconteur avec stockage persistant, plusieurs flux et atténuation propre convient à un grand opérateur, mais peut être excessive pour un réseau qui a d’abord besoin d’une visibilité claire et d’alertes fiables.

Le système allégé ne peut être considéré comme équivalent en raison du seul nom commun. Le dossier le décrit comme une variante à fonctionnalités réduites, et les affirmations d’une présentation demandent une validation indépendante. Le compromis oppose un coût d’exploitation inférieur au contexte, aux intégrations, à l’historique ou aux mécanismes de réponse susceptibles de manquer. Un petit déploiement reste utile s’il expose honnêtement ses limites.

La diffusion dépend de la machine institutionnelle requise. Un projet peut être techniquement ouvert tout en restant inaccessible aux opérateurs sans compétences en conteneurs, bases et protection du routage. Le conditionnement, des paramètres par défaut raisonnables et une progression par étapes de la surveillance vers la détection puis l’atténuation détermineront si l’architecture dépasse le cercle d’un article de recherche.

Le véritable produit est une boucle de rétroaction gouvernée

ARTEMIS ne rend pas BGP digne de confiance en une seule action. Il construit une boucle autour d’un protocole dépourvu d’autorisation complète. L’opérateur décrit le routage souhaité; les flux publics et locaux montrent une partie de la réalité; le détecteur trouve l’écart; le stockage et les interfaces organisent les preuves; des personnes ou une automatisation autorisée choisissent la réponse; les flux indiquent ensuite si la propagation change. L’incident peut être résolu, jugé négligeable, clôturé après retrait, escaladé ou laissé sans action avec une raison enregistrée.

Cette boucle est la contribution la plus durable du projet. Elle reconnaît que la sécurité du routage n’est ni un certificat ponctuel ni une alerte distante. C’est une pratique dans laquelle la politique doit être explicite, les observations conserver leur provenance et l’autorité de réponse être préparée avant la crise. La valeur du système réside dans la réduction assez rapide de l’incertitude pour permettre l’action, non dans la prétention que l’incertitude disparaît.

Les limites sont tout aussi révélatrices. Les collecteurs ne voient qu’une partie du monde; la référence peut vieillir; le plan de contrôle ne prouve ni le motif ni tous les effets; une atténuation techniquement possible peut être filtrée ou nuisible; le code ouvert exige toujours une maintenance. ARTEMIS est le plus solide lorsque ces limites sont intégrées au processus plutôt que cachées derrière une promesse d’une minute.

Une anomalie BGP peut atteindre le centre d’exploitation réseau, le centre de sécurité ou les deux. L’équipe routage comprend les préfixes, les politiques des fournisseurs et le risque de modifier les annonces. L’équipe de sécurité est mieux préparée à corréler identité, télémétrie de service et activité potentiellement malveillante. ARTEMIS croise ces domaines. L’alerte n’est utile que si elle contient assez de preuves pour que les deux équipes travaillent sur le même événement avec les mêmes hypothèses.

Le transfert de l’incident doit distinguer observation, politique et impact. Le système a vu une route dans des flux nommés; cette route a violé une règle précise; les contrôles de service ou sondes RIPE Atlas ont montré un effet précis, ou aucun effet n’est encore établi; l’opérateur a contacté le réseau amont ou l’origine et attend une réponse. Cette structure empêche le NOC de réduire une menace à un routage ordinaire et le SOC de qualifier trop tôt une annonce d’attaque.

Un langage commun améliore aussi le retour d’expérience. Un cas peut être clôturé comme changement planifié absent de la politique, fuite accidentelle, détournement présumé, événement malveillant confirmé ou anomalie non résolue. Ces résultats doivent alimenter règles, procédures et accords avec les fournisseurs. Sans cette boucle, le détecteur risque de produire des tickets plutôt que d’améliorer le contrôle du routage.

L’alerte la plus rapide n’est pas toujours la plus utile. Un détecteur peut réagir à la première mise à jour inattendue avant de découvrir que le flux était retardé, que la route était prévue ou que la victime avait autorisé la nouvelle origine. À l’inverse, attendre tous les collecteurs et tests détruit l’avantage de la réponse précoce. ARTEMIS a besoin d’une mesure intermédiaire: le temps nécessaire pour réunir des preuves assez fiables et permettre à un opérateur autorisé de prendre une décision défendable.

Cette mesure peut être décomposée: délai de la première observation, nombre de flux indépendants, actualité de la politique, contribution de RPKI ou du BMP local, durée des contrôles de service, réception et approbation de l’alerte, propagation de l’atténuation et retrait correct. Ces questions montrent où se trouve réellement la latence au lieu d’attribuer tout le résultat à l’algorithme.

La métrique de la décision défendable empêche aussi une optimisation dangereuse. Le système ne doit pas être récompensé pour une action plus rapide fondée sur moins de preuves ou créant un changement inutile. Le meilleur déploiement réduit simultanément l’incertitude et le délai de réponse tout en conservant un dossier vérifiable.

Sources

  • Site du projet ARTEMIS
  • Architecture open source d’ARTEMIS sur RIPE Labs
  • Dépôt source et documentation d’ARTEMIS
  • « ARTEMIS: Neutralizing BGP Hijacking within a Minute »
  • Présentation opérationnelle d’ARTEMIS sur RIPE Labs
  • Article de démonstration ARTEMIS à ACM SIGCOMM 2016
  • Versions d’ARTEMIS
  • Rapport annuel 2019 de CAIDA
  • Flux de messages BGP RIPE RIS Live
  • RouteViews de l’Université de l’Oregon
  • CAIDA BGPStream
  • Dépôt ExaBGP
  • Route Origin Validation, RFC 6811
  • Bénéficiaires du RIPE Community Projects Fund 2019
  • Code BGP
  • Déploiement expérimental d’ARTEMIS chez CAIDA
  • Démonstration en direct d’ARTEMIS
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas