ARTEMIS et la minute entre une alerte BGP et une réponse sûre

Résumé

• ARTEMIS est un système open source exploité par l’opérateur qui compare les observations BGP en direct avec ses propres intentions de routage, apportant aux réseaux un contexte que les collecteurs publics ne peuvent fournir seuls.
• Les travaux publiés en 2018 par FORTH et CAIDA ont fait état d’une détection en quelques secondes et d’une neutralisation en moins d’une minute dans les conditions testées; ce résultat ne constitue pas une garantie universelle en production.
• Le mécanisme d’atténuation peut annoncer des routes plus spécifiques ou déclencher des procédures personnalisées, mais les filtres, les politiques obsolètes, la visibilité incomplète et les habilitations trop larges peuvent transformer une réponse rapide en second incident.
• Le projet dépend désormais de publications logicielles rigoureuses, de preuves crédibles de déploiement et d’une frontière transparente avec Code BGP, dont la maintenance commerciale peut soutenir le logiciel ouvert sans remplacer son héritage scientifique.

Un véritable changement de route a montré que les secondes ne sont qu’un début

Le rapport annuel 2019 de CAIDA indique qu’ARTEMIS a détecté en quelques secondes un véritable détournement affectant un préfixe /30 d’Internet2. Cet événement est important parce qu’il étend les preuves au-delà des annonces synthétiques conçues par les chercheurs. Une route réelle a changé dans un réseau entité au déploiement, et le système a reconnu l’écart assez rapidement pour permettre une investigation.

Le rapport n’établit pas une distribution universelle des délais de détection. Un /30 est un préfixe particulier dans un contexte de routage précis, observé au moyen des flux disponibles pour ce déploiement. Un autre événement peut se propager différemment, durer moins longtemps ou rester hors de portée des collecteurs connectés. Le rapport ne prouve pas non plus, à lui seul, une intention malveillante ni tous les effets sur le plan de données. La conclusion prudente est qu’ARTEMIS a détecté en quelques secondes un événement réel signalé pendant le programme de déploiement de CAIDA.

Les études de cas sont utiles précisément lorsque leurs limites restent explicites. Elles montrent comment le logiciel réagit à un changement réel, comment les opérateurs reçoivent l’alerte et quelles preuves demeurent disponibles ensuite. Davantage de comptes rendus d’incidents, comprenant les faux positifs, les événements manqués et les résultats des mesures d’atténuation, permettraient de mieux établir la maturité en production qu’une nouvelle affirmation spectaculaire sur la rapidité.

Une alerte BGP peut arriver en quelques secondes tout en laissant sans réponse les questions les plus importantes. Un collecteur de routes peut montrer qu’un système autonome inconnu a annoncé un préfixe, ou qu’une route plus spécifique est apparue et a commencé à se propager. Ces éléments indiquent à l’opérateur que le plan de contrôle ne correspond plus au modèle attendu. Ils n’établissent pas, à eux seuls, qui a effectué le changement, s’il était accidentel, si le trafic a suivi la nouvelle route, si des utilisateurs ont subi un préjudice ni quelle réponse rétablira le service sans créer un autre problème.

ARTEMIS a été conçu autour de cet écart entre détection et action. Son nom signifie Automatic and Real-Time dEtection and MItigation System, mais l’acronyme en capitales ne doit pas masquer son modèle opérationnel. Il ne s’agit pas d’un service central qui surveille tout Internet et répare à distance les réseaux d’autrui. Une organisation déploie le logiciel dans une 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 ces observations s’écartent de la politique.

La promesse du projet est la rapidité assortie de contexte; sa contrainte est que ce contexte et cette autorité sont locaux.

ARTEMIS ressemble donc moins à une police d’Internet qu’à un instrument de salle de contrôle appartenant à l’opérateur. Il peut organiser les preuves, réduire le temps consacré à l’examen des mises à jour de routes et préparer une réponse déjà discutée. Il ne dispense pas l’opérateur de son jugement. La décision finale peut affecter le routage mondial, les relations avec les fournisseurs amont et le trafic des clients; la qualité de la réponse dépend donc autant des personnes, de la configuration et d’une autorité préalablement exercée que du détecteur.

BGP peut transmettre l’accessibilité avant de pouvoir prouver l’autorité

Le Border Gateway Protocol permet à des réseaux exploités indépendamment d’échanger des informations d’accessibilité et d’appliquer leur politique locale. Un système autonome annonce qu’il peut atteindre un ensemble de préfixes IP; les réseaux voisins décident d’accepter, de préférer et de retransmettre ou non ces routes. Ce dispositif a permis à Internet de s’étendre entre des organisations ne partageant pas un contrôleur unique, mais le protocole d’origine n’associe pas de preuve cryptographique à chaque affirmation relative à l’origine ou au chemin.

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

La sélection des routes peut rendre une mauvaise annonce attractive. Lorsque deux routes couvrent une même longueur de préfixe, les réseaux appliquent des politiques et des règles de sélection qui varient selon l’opérateur. Lorsqu’un attaquant ou un réseau mal configuré annonce un sous-préfixe plus spécifique, la règle normale du préfixe le plus long dirige généralement le trafic vers la route la plus étroite partout où elle est acceptée. Ce mécanisme n’est pas une fonction spéciale d’attaque: c’est la règle ordinaire qui permet aux routeurs de choisir la destination la plus précise.

C’est pourquoi une annonce apparemment limitée peut rediriger rapidement le trafic même si l’agrégat légitime reste visible.

Le mot « détournement » est un raccourci utile, mais il peut suggérer une intention que les messages de routage ne révèlent pas. Une origine non autorisée peut être malveillante, accidentelle ou résulter d’un changement commercial légitime qui n’a pas été reporté dans la politique de surveillance. Un chemin fabriqué peut servir à intercepter du trafic, mais une mise à jour du plan de contrôle ne prouve pas l’interception. ARTEMIS fonctionne donc mieux lorsqu’il traite l’alerte comme un écart entre le routage observé et le routage prévu, en laissant l’attribution et l’évaluation de l’impact à un processus d’incident plus large.

Un événement portant sur le préfixe exact entre en concurrence avec la route légitime à la même longueur de préfixe. Sa portée dépend des politiques et des choix de chemin des réseaux qui reçoivent les deux annonces. Certaines parties d’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 déroutant de réussites et d’échecs plutôt qu’une panne uniforme. La détection doit donc prendre en compte non seulement l’existence d’une route, mais également les lieux et les modalités de sa propagation.

Un événement concernant un sous-préfixe exerce souvent une attraction plus directe, car la règle du préfixe le plus long donne la priorité à la route la plus étroite. Si un réseau annonce normalement un /20 et qu’une autre origine annonce un /24 inclus dans celui-ci, les routeurs qui acceptent le /24 envoient généralement le trafic destiné à ces adresses vers le sous-préfixe. La désagrégation est également une défense courante: l’opérateur légitime annonce des routes de même spécificité, voire plus spécifiques, afin de retrouver la préférence.

Cette défense rencontre toutefois une limite stricte, car de nombreux réseaux filtrent les routes IPv4 plus longues que /24 et les routes IPv6 plus longues que /48. Un opérateur annonçant déjà des préfixes de ces longueurs peut ne disposer d’aucune route plus étroite acceptée mondialement.

ARTEMIS prend aussi en compte l’occupation indue de préfixes et certaines violations de politique, notamment un modèle lié à no-export décrit dans la documentation du projet. Ces catégories sont importantes parce que les incidents de routage ne se limitent pas à un tiers qui annonce le préfixe d’une victime. Une route peut avoir une origine autorisée tout en étant exportée par l’intermédiaire d’une relation inattendue. Un 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 au détecteur les intentions de routage de l’opérateur

Les services de surveillance externes présentent un avantage évident: ils peuvent collecter des informations dans de nombreuses parties d’Internet sans que chaque réseau ait à exploiter un système complet. Leur inconvénient est tout aussi important. Un tiers peut observer les préfixes et les chemins annoncés, mais ignorer quels changements d’origine, fournisseurs de secours, chemins d’ingénierie de trafic ou annonces d’urgence l’opérateur considère comme légitimes. Des règles génériques peuvent donc manquer des violations subtiles ou déclencher des alertes lors de changements planifiés.

ARTEMIS a inversé le point de vue. Le détecteur est exploité par l’organisation dont l’espace d’adressage est menacé, et cette organisation fournit la référence de légitimité. Les collecteurs publics apportent toujours une large visibilité externe, mais leurs observations sont interprétées au regard de connaissances privées sur les préfixes protégés, les systèmes autonomes d’origine autorisés, les voisins acceptables et certaines relations de chemin. Les flux des routeurs locaux peuvent ajouter des événements que les collecteurs publics ne voient pas.

Cette combinaison constitue l’idée centrale du projet: des preuves mondiales incomplètes deviennent plus utiles lorsqu’elles sont comparées à une intention locale explicite.

Installer le détecteur dans le réseau défendu transfère également la responsabilité vers l’intérieur. Un réseau qui maintient ARTEMIS doit déterminer qui est responsable du fichier de politique, comment les changements sont examinés, quelles alertes parviennent au centre d’exploitation du réseau, ce que l’équipe de sécurité est autorisée à déduire et qui peut autoriser une nouvelle route. Le logiciel peut rendre cette responsabilité visible. Il ne peut obliger l’institution à l’exercer correctement.

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 certaines règles de routage. Cette référence permet au détecteur de poser une question plus précise qu’un service générique de surveillance. Au lieu de déterminer si une route semble inhabituelle par rapport à l’historique mondial, le système peut établir si elle enfreint l’intention déclarée du réseau.

Cet avantage n’est fiable que dans la mesure où la déclaration l’est. Les réseaux changent de fournisseurs, ajoutent des sites anycast, déplacent leurs systèmes autonomes d’origine, établissent des chemins de secours temporaires et effectuent des annonces d’urgence pendant les pannes. Une politique exacte en janvier peut être erronée en juin. Si le changement opérationnel atteint les routeurs mais pas ARTEMIS, le détecteur peut produire un faux positif de haute gravité. Si la politique est élargie sans précaution pour réduire le bruit, une véritable violation peut devenir autorisée sur le papier.

Le système transforme donc une configuration technique en contrat institutionnel. L’ingénierie du routage, les opérations de sécurité et la gestion des changements doivent s’accorder sur la signification du fichier, sur les personnes habilitées à le modifier et sur la rapidité avec laquelle il suit la production. Le contexte local du projet n’élimine ni les faux positifs ni les faux négatifs; il déplace leur principale source vers un domaine que l’opérateur peut gouverner.

Une règle de sécurité du routage mérite la même rigueur qu’un logiciel susceptible d’affecter le trafic des clients. Les changements doivent avoir des responsables nommés, faire l’objet d’un examen, conserver un historique de versions, être testés et être justifiés par une modification réseau approuvée. L’opérateur doit pouvoir dire quand un préfixe, une origine ou un voisin a été ajouté, qui l’a autorisé et quel incident ou projet justifiait cette décision. Un simple fichier de configuration peut soutenir ce processus, mais seulement si l’organisation le traite autrement que comme une étape d’installation ponctuelle.

Les tests doivent comprendre des cas positifs et négatifs. Une route légitime planifiée doit être acceptée sans alerte. Une annonce du préfixe exact provenant d’une origine non autorisée doit déclencher la classification attendue. Un événement de sous-préfixe doit recevoir le niveau de gravité approprié, et une violation no-export ne doit pas être confondue avec un détournement d’origine. La relecture historique peut soutenir ces vérifications, tandis qu’un environnement de préproduction peut confirmer que les notifications et les mécanismes d’atténuation reçoivent les données prévues.

Cette discipline limite aussi le risque de dérive organisationnelle. Lorsque la personne ayant initialement déployé ARTEMIS quitte l’organisation, la politique doit rester compréhensible pour l’opérateur suivant. Un détecteur dont la logique dépend de souvenirs non documentés n’est pas une infrastructure fiable, même si son code est ouvert et si la latence de ses flux est faible.

FORTH et CAIDA ont transformé une question de recherche en procédure opérationnelle

Le projet est né d’une collaboration entre des chercheurs de la Foundation for Research and Technology-Hellas, au sein de l’écosystème de l’Université de Crète, et CAIDA à l’Université de Californie à San Diego. FORTH a contribué aux travaux sur la sécurité du routage et les systèmes. CAIDA a apporté son infrastructure de mesure d’Internet, son expertise de BGPStream et des relations qui ont aidé à introduire la conception dans les réseaux de recherche et d’enseignement. Le projet n’a donc jamais été seulement un algorithme de détection: il a réuni connaissance des protocoles, systèmes de mesure et accès aux opérateurs.

Le financement a suivi le même modèle institutionnel mixte. Des programmes de recherche européens et américains, le Community Projects Fund de RIPE NCC, un projet de déploiement NSF EAGER, le Department of Homeland Security des États-Unis et le Comcast Innovation Fund figurent dans l’historique du projet. Le soutien de RIPE en 2017 a aidé à faire évoluer le prototype vers un outil destiné aux opérateurs, tandis qu’une dotation de 50 000 euros en 2019 a financé des travaux de vérification du plan de données utilisant RIPE Atlas.

Ces subventions montrent comment une recherche d’intérêt public est devenue un logiciel déployable, mais elles ne révèlent pas le coût actuel de la maintenance des installations en production.

L’histoire institutionnelle importe pour l’attribution. ARTEMIS n’est ni une fondation constituée séparément, ni un service de CAIDA, ni un détecteur mondial appartenant à FORTH. Il s’agit d’un logiciel open source sous licence BSD 3-Clause, doté d’une filiation scientifique et d’un mainteneur commercial actuel. Son développement se comprend mieux comme une succession de collaborations que comme la propriété d’une seule organisation.

La première étape publique a été une démonstration à ACM SIGCOMM en 2016. À ce stade, l’avancée essentielle consistait à réunir surveillance et atténuation dans une même boucle. De nombreux systèmes peuvent repérer une route suspecte après avoir recueilli suffisamment de preuves. ARTEMIS cherchait à savoir si un opérateur pouvait détecter l’événement assez rapidement tout en disposant déjà d’une contre-mesure pratique, afin que l’incident ne passe pas des heures entre tableaux de bord, courriels et sessions manuelles sur les routeurs.

Une démonstration n’est pas un déploiement en production arrivé à maturité. Elle établit que des composants peuvent fonctionner ensemble dans une configuration définie et que le problème de recherche est assez concret pour être présenté. Les travaux de 2016 ont néanmoins fixé l’orientation de tout ce qui a suivi: observations en direct, vision interne du routage légitime, classification et annonce préparée. Cette séquence a transformé le temps de réponse, auparavant considéré après coup par l’organisation, en propriété du système.

La conception s’appuyait sur des témoignages d’opérateurs indiquant qu’une réponse à un détournement pouvait prendre des heures. Le délai ne provenait pas uniquement de la lenteur des collecteurs de routes. Les équipes devaient confirmer la propriété, examiner la propagation, déterminer si l’événement était planifié, trouver les bons contacts en amont et construire une mesure d’atténuation sûre. ARTEMIS pouvait raccourcir plusieurs de ces étapes en conservant la politique et les procédures à proximité du système de surveillance, mais les relations humaines et commerciales entourant la route restaient hors du code.

L’article publié en 2018 dans IEEE/ACM Transactions on Networking a formulé l’affirmation la plus marquante concernant ARTEMIS: neutraliser un détournement BGP en moins d’une minute. Les chercheurs ont évalué l’approche au moyen d’expériences réelles et ont fait état d’une détection en quelques secondes et d’une atténuation en moins d’une minute dans les conditions testées. Ce résultat était important, car il montrait qu’un réseau victime ne devait pas nécessairement attendre un service tiers, une chaîne téléphonique et une contre-annonce assemblée manuellement.

La formule devient trompeuse lorsqu’elle est détachée de l’expérience. Le délai de détection dépend de l’arrivée de l’événement jusqu’à un observateur connecté, de la rapidité de transmission du flux, de la correspondance avec les règles du détecteur 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 son autorité de routage, des filtres en amont, de la propagation et du processus d’approbation choisi. Un réseau exigeant une confirmation humaine peut prendre une décision plus sûre mais plus lente. Un réseau qui automatise immédiatement peut réagir plus vite tout en acceptant davantage de risques.

La conclusion responsable doit rester circonscrite. ARTEMIS a démontré qu’un système étroitement intégré du côté de l’opérateur peut réduire fortement la durée d’un processus souvent beaucoup plus long. Il n’a pas prouvé que chaque détournement est visible, que chaque contre-route est acceptée ni que toutes les équipes de production devraient autoriser une désagrégation autonome. Le résultat doit être lu comme un objectif de conception étayé par une expérience, et non comme une garantie universelle.

Plusieurs vues incomplètes construisent un dossier d’incident exploitable

ARTEMIS peut s’appuyer sur plusieurs sources publiques, car 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 pairs sélectionnés à des points de collecte répartis. CAIDA BGPStream fournit un cadre permettant d’accéder aux données de routage de plusieurs sources et de les normaliser. Chaque service élargit le champ de vision de l’opérateur, mais reflète aussi les réseaux qui choisissent d’établir une session avec ses collecteurs, l’emplacement de ces sessions et le calendrier de leurs flux.

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

La bonne question opérationnelle n’est donc pas « ARTEMIS a-t-il vu Internet? », mais « Quels observateurs ont vu cette annonce, avec quel délai, et quelle partie de l’événement peut encore se situer hors de l’échantillon? ». Cette formulation encourage les opérateurs à conserver la provenance de chaque alerte et à ne pas considérer l’absence dans un flux comme la preuve qu’une route n’a pas existé.

RIPE NCC a lancé en février 2019 le prototype public RIS Live afin de diffuser les messages BGP avec beaucoup moins de retard que le traitement périodique des archives. ARTEMIS est devenu l’un des exemples montrant l’importance d’un tel flux. Un système de sécurité ne peut réagir en quelques secondes si son observation principale arrive plusieurs minutes plus tard, et un flux en direct permet au détecteur d’évaluer les mises à jour à mesure que les collecteurs les reçoivent.

La réduction de la latence ne change pas ce que les collecteurs peuvent observer. RIS Live reflète toujours les pairs connectés au RIPE Routing Information Service et les routes qu’ils exportent. Si un détournement reste local, est filtré avant d’atteindre un collecteur ou affecte un chemin masqué derrière une autre relation, le flux peut ne jamais contenir la preuve décisive. La fiabilité compte également: une interruption du flux ou un changement de format peut ressembler à du silence si le service de surveillance ne distingue pas « aucune route suspecte » de « aucune donnée ».

C’est pourquoi l’état des flux appartient au modèle de sécurité. L’opérateur doit savoir si chaque observateur est à jour, retardé, déconnecté ou produit un volume inhabituel de mises à jour. Un détecteur qui affiche un état unique et assuré alors que ses entrées sont dégradées peut créer une forme d’ignorance plus dangereuse qu’une panne déclarée.

La surveillance en temps réel répond à la question de ce qui apparaît maintenant, tandis que les bases d’informations de routage et les archives de mises à jour fournissent le contexte. RIPE RIS et RouteViews publient des données historiques permettant de voir quelles origines et quels chemins étaient visibles avant un incident, quand un changement a commencé et combien de temps il a persisté. CAIDA BGPStream facilite le traitement de ces enregistrements dans un cadre commun, ce qui permet à ARTEMIS de rejouer des événements et de tester des règles sur le comportement passé du routage.

La relecture est utile pour l’ingénierie et l’examen. Une équipe peut vérifier si une nouvelle politique aurait détecté un événement connu, reproduire la séquence ayant conduit à une alerte ou former les intervenants sans modifier une route de production. Les preuves historiques peuvent aussi révéler des annonces récurrentes qui semblent anormales isolément, mais correspondent à un dispositif de secours établi. La limite est qu’une archive conserve le point de vue des collecteurs, et non l’intégralité de l’événement, et qu’une topologie passée ne peut reproduire toutes les relations actuelles.

Un déploiement mature peut intégrer la relecture au contrôle des changements. Avant qu’une nouvelle origine, un nouveau fournisseur amont ou une nouvelle règle d’exportation n’entre en production, l’opérateur peut tester la référence révisée sur un historique représentatif et confirmer qu’elle ne transforme pas le routage ordinaire en alarme permanente. Cette pratique fait de la configuration du détecteur un artefact de sécurité vérifiable plutôt qu’un fichier modifié uniquement lorsqu’il génère du bruit.

Les données publiques ne constituent qu’un côté de la conception. ARTEMIS peut recevoir des mises à jour locales par ExaBGP ou par des sessions privées utilisant le BGP Monitoring Protocol. ExaBGP peut agir comme un locuteur BGP programmable et transmettre des événements de routage à d’autres logiciels. BMP permet aux routeurs d’exporter des informations de routage vers un système de surveillance sans intégrer celui-ci aux décisions de transfert. Ces sources peuvent montrer les adjacences et l’état des routes propres au réseau protégé avant que l’information ne devienne visible auprès d’un collecteur public.

Les flux locaux améliorent la rapidité et le contexte, mais introduisent aussi des éléments sensibles de l’infrastructure dans la plateforme. Les données BMP peuvent être volumineuses et révéler des relations internes de routage. L’intégration d’ExaBGP exige un contrôle attentif, car la même interface programmable peut servir à annoncer des routes autant qu’à les observer. Les habilitations, l’accessibilité réseau, la validation des messages et la séparation entre surveillance et atténuation deviennent donc des frontières de sécurité.

Un déploiement bien conçu utilise les flux publics et privés à des fins différentes. Les collecteurs publics montrent comment une annonce se propage au-delà du voisinage immédiat de l’opérateur. Les sources locales montrent ce que l’opérateur et ses routeurs ont vu directement. Un désaccord entre les deux n’est pas nécessairement une erreur; il peut constituer la preuve nécessaire pour comprendre où la propagation s’est arrêtée ou où une politique a pris effet.

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

La plateforme actuelle est une application de microservices répartis dans plusieurs conteneurs, plutôt qu’un script unique lisant un flux. Les services de surveillance se connectent aux flux publics et privés, normalisent les informations BGP reçues et publient des événements. Les services de détection consomment ces événements et appliquent les règles de l’opérateur. Le stockage, les API, l’interface web, les notifications et la supervision entourent ce cœur. Cette séparation permet aux composants d’évoluer ou de tomber en panne indépendamment et facilite l’ajout d’un nouveau flux sans réécrire toute l’application.

La modularité multiplie aussi les dépendances. Un observateur peut fonctionner tandis que le détecteur est bloqué. Le bus de messages peut accepter des événements alors que la base de données est indisponible. L’interface web peut charger un ancien incident alors que la chaîne de traitement en direct est interrompue. L’orchestration des conteneurs peut redémarrer un service et masquer une panne récurrente. L’exploitation exige donc des contrôles d’état décrivant le parcours complet entre le flux source et l’alerte, et non la seule exécution des conteneurs individuels.

Docker Compose abaisse la barrière d’un déploiement contrôlé, tandis que la prise en charge de Kubernetes convient aux organisations exploitant déjà des plateformes de conteneurs. Aucune de ces méthodes ne transforme le système en service mondial géré. Le réseau qui le déploie reste responsable des capacités, des mises à niveau, des secrets, du stockage, des sauvegardes et de l’accès lors des incidents.

Un bus de messages permet aux services de surveillance, de détection et de notification d’échanger des événements sans qu’un processus unique contrôle directement tous les autres. Cette conception peut absorber les rafales de mises à jour et permettre aux consommateurs de fonctionner à des rythmes différents. Elle soulève aussi des questions d’ordre, de duplication et de saturation. Un incident de routage peut comprendre des milliers de mises à jour, de retraits et de changements de chemin; le système doit donc préserver assez de séquence et de provenance pour permettre à l’opérateur de reconstituer les faits.

Le stockage persistant donne à ARTEMIS un avantage sur une alarme éphémère. Les mises à jour, alertes, états de configuration et décisions relatives aux incidents peuvent être conservés pour examen. L’architecture du projet a utilisé des composants liés à PostgreSQL, un stockage de type Timescale et l’écosystème d’API Hasura. Ces choix facilitent les requêtes et l’intégration, mais créent aussi un dépôt sensible de preuves de routage et d’exploitation qui exige des limites de conservation, un contrôle d’accès et des sauvegardes fiables.

La traçabilité n’est pas synonyme de certitude. Un enregistrement complet de ce que le système a reçu peut démontrer comment ARTEMIS est arrivé à une alerte. Il ne peut prouver que le système a reçu toutes les routes pertinentes ni que les règles de l’opérateur étaient correctes. La base de données doit donc conserver la source et le niveau de confiance, plutôt qu’une simple étiquette finale d’incident.

L’interface web présente les incidents, l’état du système et les observations de routage sous une forme utilisable par une équipe d’exploitation réseau ou de sécurité. Les notifications peuvent envoyer des alertes par courriel, canal mobile ou intégration personnalisée, tandis que les tableaux de bord Grafana peuvent exposer l’état des services et les tendances des événements. Ces fonctions transforment un mécanisme de recherche en produit opérationnel, car l’équipe d’intervention a besoin de priorités, d’un historique et d’une vue commune plutôt que de mises à jour BGP brutes.

L’interface peut également susciter une fausse confiance. Une fiche d’incident rouge représente une classification issue d’observations et de règles, et non une constatation indépendante d’intention malveillante. Une carte ou une vue de chemin peut paraître complète alors qu’elle ne représente que certains collecteurs. Les notifications peuvent devenir du bruit lorsque les changements planifiés ne sont pas intégrés à la politique, et la fatigue liée aux alertes peut conduire à ignorer l’unique événement important.

Les bonnes pratiques maintiennent un lien entre l’interface utilisateur et la vérification. L’intervenant doit pouvoir examiner les mises à jour sources, comparer les flux publics et locaux, vérifier l’état RPKI actuel, lancer des tests du plan de données et consigner la raison pour laquelle l’incident a été remonté, ignoré ou résolu. Le tableau de bord est utile lorsqu’il raccourcit ce parcours, pas lorsqu’il le remplace.

Un modèle de route ne peut prouver ni le mobile ni l’impact

Les recherches sur ARTEMIS ont développé une taxonomie distinguant les événements selon la relation entre les préfixes, la manipulation du chemin AS, la politique et les effets possibles sur le plan de données. L’implémentation prend en charge un sous-ensemble défini de ces modèles à partir des preuves du plan de contrôle, notamment les cas d’origine portant sur un préfixe exact ou un sous-préfixe, l’occupation indue et certaines violations d’exportation. Une taxonomie donne aux opérateurs un vocabulaire cohérent et aide le détecteur à appliquer des règles différentes aux divers événements.

Les catégories doivent rester liées à ce que montrent les données. Un chemin commençant par un voisin inattendu peut signaler un segment fabriqué, une fuite de route ou un changement autorisé non enregistré dans la politique. Une origine non autorisée peut être une erreur plutôt qu’une attaque. Même une annonce délibérée peut viser à mettre le trafic au rebut, à usurper un service ou à observer le trafic en transit, et les mises à jour BGP ne suffisent pas à distinguer ces résultats.

Un langage prudent protège à la fois l’exactitude et la qualité de la réponse. « Détournement présumé » ou « violation de politique » est généralement plus sûr au stade de l’alerte que « attaque ». Le terme plus fort peut être employé lorsque la propriété de la route, les contacts avec les opérateurs et les preuves du plan de données l’étayent. Cette retenue n’affaiblit pas la sécurité; elle empêche le système d’incident de transformer une incertitude en affirmation que d’autres équipes pourraient ensuite répéter comme un fait.

Les messages BGP décrivent des affirmations d’accessibilité et des informations de chemin échangées entre réseaux. Ils ne montrent pas chaque paquet empruntant la route sélectionnée. Après une annonce suspecte, le trafic peut être mis au rebut, intercepté puis retransmis, traité par un service usurpateur ou rester inchangé parce que la route ne s’est pas propagée jusqu’aux réseaux transportant les utilisateurs concernés. Différentes parties d’Internet peuvent subir simultanément des effets différents.

Cette frontière est centrale pour ARTEMIS. Le détecteur peut montrer qu’une route a enfreint la politique de l’opérateur et qu’elle est apparue à des points d’observation identifiés. Il ne peut déduire un mobile du chemin AS ni garantir qu’un traceroute suit la même direction que le trafic applicatif. Le chiffrement, le comportement du DNS, la mise en cache, l’anycast et le basculement applicatif peuvent encore modifier l’expérience des utilisateurs. L’alerte du plan de contrôle constitue donc une preuve pour l’incident, et non l’intégralité de l’incident.

Une réponse utile réunit plusieurs dossiers. Les preuves BGP établissent l’annonce et sa propagation. Les tests du plan de données examinent l’accessibilité et les chemins depuis des emplacements sélectionnés. La télémétrie des services montre les erreurs, la latence et l’impact sur les clients. Les contacts en amont permettent d’établir si la route était autorisée ou erronée. Aucun de ces dossiers n’est parfait, mais leur combinaison permet une décision qu’un seul flux ne saurait soutenir.

La dotation du RIPE Community Projects Fund accordée en 2019 a soutenu une extension d’ARTEMIS utilisant des mesures traceroute de RIPE Atlas pour examiner l’effet des événements détectés. Ces travaux reconnaissaient une limite de la boucle initiale du plan de contrôle. Une route peut paraître dangereuse dans BGP tout en ayant peu d’impact observable, tandis qu’une propagation limitée peut néanmoins affecter une clientèle importante. Les sondes du plan de données ajoutent des preuves sur la direction apparente du trafic et sur l’accessibilité des points de terminaison.

RIPE Atlas dispose d’un réseau distribué de sondes, mais leur répartition est inégale et la cible choisie peut ne pas répondre de manière à révéler le chemin. Traceroute peut être affecté par le filtrage, l’équilibrage de charge, les tunnels et le routage asymétrique. Le chemin aller d’une sonde vers la destination ne correspond pas nécessairement au chemin emprunté dans l’autre sens par le trafic des clients. L’échec d’une mesure peut signifier une panne, un saut qui ne répond pas ou une limitation propre au test.

Le gain pratique n’est pas la certitude, mais une meilleure priorisation. Si les collecteurs BGP montrent un sous-préfixe non autorisé et que des sondes situées dans plusieurs régions perdent l’accessibilité ou basculent vers l’origine inattendue, l’opérateur dispose de preuves plus solides pour remonter l’incident. Si l’événement du plan de contrôle n’est visible qu’auprès d’un collecteur et que les tests du plan de données restent stables, l’équipe peut enquêter avant de modifier les annonces mondiales. La décision reste contextuelle, mais elle est moins aveugle.

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

La réponse ARTEMIS la plus connue est la désagrégation. Une victime qui annonce un préfixe large peut générer des routes plus spécifiques afin que la sélection normale du préfixe le plus long ramène le trafic vers le réseau légitime. Cette méthode utilise le comportement existant de BGP et peut se propager rapidement, ce qui la rendait adaptée à l’objectif expérimental de réaction « en moins d’une minute ». Elle conserve aussi l’autorité entre les mains de la victime, sans exiger la coopération de l’origine inattendue avant que le service puisse commencer à se rétablir.

La désagrégation présente des limites strictes. De nombreux réseaux filtrent les routes IPv4 plus longues que /24 et les routes IPv6 plus longues que /48 afin de contenir la croissance des tables et les abus opérationnels. Une victime annonçant déjà un /24 ou un /48 peut être incapable de produire une route plus spécifique acceptée par l’ensemble d’Internet. Les fournisseurs amont peuvent aussi limiter ce qu’un client est autorisé à annoncer, et les objets de route, filtres de préfixes ou données RPKI peuvent devoir autoriser l’état d’urgence.

La propagation n’est ni instantanée ni uniforme, de sorte que les anciens et les nouveaux chemins peuvent coexister.

Un opérateur préparé doit connaître ces limites avant l’incident. Quels préfixes peuvent être désagrégés? Quels fournisseurs amont les accepteront? Quels filtres de routes et quelles autorisations d’origine de route couvrent déjà l’état d’urgence? Comment les routes seront-elles retirées après le rétablissement? ARTEMIS peut déclencher un mécanisme externe, mais sa réussite dépend d’accords qui existent hors de l’application.

La documentation du projet emploie l’expression d’atténuation automatique, et la recherche comprend une boucle fermée dans laquelle la détection peut déclencher une contre-annonce. Des descriptions opérationnelles détaillées présentent également une confirmation manuelle et des mécanismes personnalisés. Les deux peuvent être exacts, car les déploiements choisissent différents niveaux d’autonomie. La formulation prudente est qu’ARTEMIS prend en charge une atténuation automatisée ou autorisée par l’opérateur au moyen de procédures configurables.

Le risque est asymétrique. Une réponse retardée peut prolonger une panne ou une interception. Une mauvaise réponse automatique peut annoncer inutilement des routes plus spécifiques, enfreindre la politique d’un fournisseur amont, révéler des hypothèses internes ou créer de l’instabilité alors que l’événement initial reste en cours d’analyse. Une référence obsolète peut transformer un changement planifié en apparente urgence. Si le mécanisme dispose d’habilitations trop larges sur les routeurs, une compromission d’ARTEMIS peut devenir elle-même une attaque de routage.

Une automatisation plus sûre procède par étapes. Le système peut d’abord enrichir l’alerte, vérifier plusieurs flux, contrôler l’état RPKI, effectuer des tests du plan de données et préparer la modification exacte de la route. Une personne peut approuver les actions à fort impact, tandis que les cas moins risqués peuvent suivre une automatisation fondée sur la politique. Les limites de fréquence, les habilitations restreintes, la simulation, les journaux de changement et une procédure de retour arrière testée comptent davantage que l’étiquette « automatique ».

Il ne s’agit pas de préserver le travail manuel pour lui-même, mais de garantir que la rapidité ne supprime pas la responsabilité.

RPKI renforce une partie 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 être à l’origine de préfixes précis et jusqu’à quelles longueurs maximales. Les routeurs ou systèmes de politique peuvent effectuer une Route Origin Validation et classer une route comme valide, invalide ou absente des données. Cela ajoute une preuve cryptographique à une partie de BGP qui repose autrement sur une confiance distribuée. Il s’agit d’un contrôle préventif, car d’autres réseaux peuvent rejeter ou défavoriser une origine non autorisée avant que le trafic ne la suive.

ARTEMIS intervient à une autre couche de l’incident. Il peut utiliser l’état de validation RPKI comme preuve, mais il compare aussi les routes aux règles privées de l’opérateur, enregistre l’événement, combine des flux publics et locaux et relie la détection à la réponse. RPKI ne valide pas l’intégralité du chemin AS et les politiques de déploiement ne sont pas universelles. Une route peut être valide selon RPKI tout en enfreignant une relation de voisinage attendue ou en fuyant par un chemin non voulu par l’opérateur. Une route peut être invalide parce qu’un changement opérationnel légitime n’a pas été reporté dans la ROA.

Les systèmes sont donc complémentaires. RPKI peut réduire le nombre de routes d’origine non autorisées acceptées dans l’ensemble d’Internet. ARTEMIS peut montrer à la victime ce qui est observé, détecter certains modèles dépassant la simple validité de l’origine et organiser la réponse. De futurs mécanismes d’autorisation des chemins tels qu’ASPA peuvent renforcer les preuves relatives aux relations, mais ils ne supprimeront pas le besoin de surveiller ce que les réseaux annoncent réellement et la manière dont les incidents affectent les services.

Les pilotes ont conduit ARTEMIS au-delà du laboratoire sans prouver une adoption à grande échelle

CAIDA a fait état d’un déploiement expérimental d’ARTEMIS soutenu par la NSF avec Internet2, Great Plains Network et Merit en 2018-2019. Ces pilotes étaient importants parce que les réseaux de recherche et d’enseignement disposent de véritables préfixes, fournisseurs amont, processus de changement et obligations de service. Les opérateurs pouvaient vérifier si le logiciel s’intégrait à la surveillance existante, si les règles saisissaient leurs intentions de routage et comment les alertes entraient dans la réponse aux incidents.

Les éléments disponibles sont crédibles mais circonscrits. Un pilote peut établir l’installation, les retours d’ingénierie et certains usages opérationnels. Il ne prouve pas une couverture continue en production, l’état actuel des versions ni les performances pour tous les types de réseaux. Le site du projet publie aussi des déclarations d’ingénieurs associés à AMS-IX, Internet2 et ESnet et affiche des logos d’organisations.

Ces références indiquent des essais ou des usages, mais elles ne doivent pas être transformées en affirmation selon laquelle toutes les organisations nommées sont aujourd’hui des clientes payantes ou que le projet détient une part mondiale connue.

Cette distinction compte parce que les déploiements de logiciels de sécurité du routage sont souvent invisibles. Un opérateur peut utiliser une version interne dérivée, limiter son usage à la surveillance ou arrêter après un essai. L’absence de recensement complet ne rend pas le projet insignifiant, mais empêche toute déclaration précise sur son adoption. Des cas nommément documentés constituent des preuves plus solides qu’un chiffre élevé non étayé.

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

ARTEMIS est distribué sous licence BSD 3-Clause. Un opérateur peut inspecter le code, l’exécuter dans une infrastructure contrôlée, adapter les intégrations et éviter d’envoyer sa politique sensible à un fournisseur central obligatoire. Ce modèle correspond à l’avantage central du projet, puisque la référence la plus précieuse appartient au réseau. Il autorise aussi les usages commerciaux et les versions dérivées, ce qui permet à Code BGP et à d’autres acteurs de bâtir des services sur cette fondation ouverte.

Ce contrôle implique du travail. La plateforme comprend des conteneurs, un bus de messages, des bases de données, des API, une application web, des systèmes de notification et des intégrations de flux. Chaque composant nécessite des correctifs, des habilitations, une segmentation réseau, des sauvegardes et une surveillance. Le système stocke une politique de routage sensible et peut détenir des habilitations capables d’influencer les annonces. Un déploiement en production présente donc une surface de sécurité bien plus vaste que l’algorithme de détection initial.

La licence ouverte donne à l’opérateur une possibilité de sortie vis-à-vis d’un mainteneur, mais pas une organisation de soutien automatique. Quelqu’un doit toujours tester les mises à niveau, examiner les dépendances et comprendre le code lorsqu’un flux ou une interface de routeur change. Pour les réseaux plus petits, un outil d’alerte plus simple ou un service commercial géré peut être plus facile à exploiter, même s’il offre moins de contrôle local.

Un service ARTEMIS en production doit rester disponible pendant l’instabilité réseau qui le rend nécessaire. Les connexions aux flux, le bus de messages, la base de données, l’API, l’interface, le canal de notification et la couche d’authentification forment une seule chaîne de service. La redondance des conteneurs n’est utile que si l’état, le stockage et les dépendances externes sont eux aussi conçus pour résister aux pannes. Le redémarrage d’un observateur ne permet pas de récupérer des mises à jour qui n’ont jamais été conservées, et une interface répliquée ne peut afficher un incident que la chaîne de détection n’a pas traité.

La conception opérationnelle doit donc prévoir des modes dégradés explicites. Lorsqu’un flux public disparaît, le système doit indiquer que la couverture s’est réduite plutôt que de continuer à afficher un état sain indifférencié. Lorsque la base de données est indisponible, le détecteur peut devoir conserver les événements localement ou arrêter l’atténuation parce que les preuves d’audit ne peuvent être enregistrées. Lorsque le fournisseur d’identité tombe en panne, un accès d’urgence doit rester possible sans créer de compte permanent non contrôlé.

Ces choix ne sont pas décrits par la taxonomie des détournements, mais ils déterminent si l’idée de recherche devient une infrastructure fiable.

La plateforme a également besoin de son propre budget de performances. Une rafale de mises à jour légitimes pendant une modification importante du routage peut solliciter davantage les observateurs et le stockage qu’un détournement isolé. Les files d’attente internes ne doivent pas transformer un flux presque instantané en incident retardé sans rendre ce retard visible.

Les essais de capacité, la conservation en base de données et la gestion de la saturation du bus de messages appartiennent à la planification du déploiement pour la même raison que les filtres de routes et les longueurs de préfixes: ils délimitent la réponse que le système peut honnêtement promettre.

ARTEMIS réunit des logiciels web, des images de conteneurs, une base de données, des composants de messagerie, des API, l’authentification et des bibliothèques réseau. Cette architecture rend le projet extensible, mais chaque dépendance représente une vulnérabilité ou un point de panne potentiel. Une faille de l’interface peut exposer la politique de routage. Une image compromise peut modifier les alertes. Un jeton d’API trop permissif peut révéler des incidents, tandis qu’une habilitation attachée à un mécanisme d’atténuation peut permettre de modifier des routes.

La sécurité du détecteur est donc indissociable de celle des logiciels utilisés pour l’exploiter.

L’open source aide les opérateurs à inspecter les composants, figer les versions et construire eux-mêmes les images. Il ne garantit pas que toutes les dépendances indirectes ont été examinées ni qu’une vulnérabilité publique sera corrigée selon le calendrier requis par un réseau. Une équipe de production a besoin d’un inventaire des images et bibliothèques, d’un processus pour les reconstruire, d’une séparation entre la surveillance en lecture seule et l’atténuation autorisée à écrire, ainsi que d’un moyen de tester les mises à jour de sécurité sans perdre l’historique des incidents.

Cette exigence modifie la manière d’évaluer la maintenance du projet. Une nouvelle fonction de détection peut attirer davantage l’attention qu’une mise à niveau de la base de données ou une correction d’authentification, alors que ces dernières peuvent être plus importantes pour l’intégrité du service. Les avis de sécurité, les constructions reproductibles, les mises à jour de dépendances et une branche de publication prise en charge constituent des preuves de maturité opérationnelle, même lorsqu’ils n’ajoutent aucune option visible au tableau de bord.

Les publications et Code BGP définissent le test actuel de maintenance

La dernière version formelle balisée identifiée dans le dossier de recherche est la version 2.3.0, nommée Cadmus et datée du 24 novembre 2022. À la date limite du 5 août 2026, la démonstration en direct affichait une version plus récente fondée sur un commit, et le site actuel du projet restait actif. Ces faits permettent de conclure que les travaux ont continué après la dernière version formelle, mais ils soulèvent aussi une question légitime pour la production: quelle version est testée, prise en charge et adaptée à une mise à niveau?

L’activité des commits et une démonstration fonctionnelle témoignent du développement. Une version sémantique apporte une autre forme d’assurance: une référence nommée, des notes de publication, des attentes concernant les dépendances et un point de comparaison pour les tests des opérateurs. Un projet peut être actif alors que son processus formel de publication accuse du retard, et une démonstration actuelle peut exécuter un code qu’aucun opérateur de production ne devrait adopter sans examen.

Pour une infrastructure de sécurité du routage, la discipline de publication fait partie du modèle de sécurité. Les opérateurs doivent savoir quelles branches reçoivent des correctifs, comment les migrations sont gérées et si d’anciennes dépendances restent exposées. Une nouvelle balise ne prouverait pas une fiabilité universelle, mais une politique publiée de support et de sécurité réduirait davantage l’incertitude qu’un site web actuel à lui seul.

Le site du projet présente Code BGP comme le mainteneur actuel d’ARTEMIS et décrit l’entreprise comme une start-up issue du projet. La commercialisation peut résoudre un véritable problème de l’open source. Un logiciel de sécurité du routage a besoin de personnes capables de maintenir les intégrations, de répondre aux vulnérabilités, de soutenir les déploiements et de transformer les fonctions issues de la recherche en opérations fiables après la fin des subventions initiales.

Code BGP reste néanmoins une entreprise commerciale distincte, avec ses propres produits et clients. Elle ne doit pas servir d’autre nom pour FORTH, CAIDA ou tous les déploiements open source. Les preuves publiques du dossier ne révèlent ni le chiffre d’affaires, ni la valorisation, ni la liste des clients de l’entreprise, ni la frontière exacte entre les fonctions communautaires et commerciales. Cette absence n’est pas une critique; elle limite simplement ce qu’un profil peut affirmer.

Cette relation crée deux incitations susceptibles de converger ou de diverger. Le projet ouvert bénéficie des contributions de personnel commercial sous forme de code testé et de documentation. L’entreprise bénéficie de la confiance, de l’adoption et de la base technique apportées par le projet ouvert à ses services payants. Le test à long terme consiste à vérifier si les publications, les correctifs de sécurité et les décisions de feuille de route restent assez visibles pour les opérateurs qui ne sont pas clients commerciaux.

Une licence permissive garantit que le code source peut être copié, modifié et commercialisé. Elle ne garantit pas qu’une autre équipe puisse comprendre l’architecture, reproduire une version ou reprendre la maintenance lorsque les experts actuels partent. La continuité à long terme du projet dépend de la documentation, des tests, de l’historique des problèmes, de la connaissance des dépendances et d’un parcours de contribution dépassant les personnes qui ont construit le système de recherche initial.

La gestion assurée par Code BGP peut renforcer cette continuité en maintenant des ingénieurs expérimentés sur la plateforme. Elle peut aussi concentrer les connaissances pratiques dans une organisation commerciale, même si le dépôt reste public. La distinction peut être observée dans les notes de publication, les discussions publiques de conception, la réactivité aux signalements communautaires et la capacité des déploiements non clients à obtenir assez d’informations pour fonctionner en sécurité.

L’objectif n’est pas d’empêcher la création de valeur commerciale. Une relation saine entre cœur ouvert et services payants peut aligner le support commercial sur la maintenance publique. Le risque apparaît lorsque le projet ouvert devient une démonstration historique tandis que le parcours opérationnel migre vers des composants privés non documentés. La portabilité doit donc être testée en pratique: un opérateur indépendant peut-il installer, mettre à niveau, auditer et restaurer le système en utilisant les informations publiques disponibles à ce moment-là?

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

Le domaine de la sécurité du routage comprend des collecteurs publics, des systèmes d’inférence issus de la recherche, des outils d’alerte open source, des validateurs RPKI et des plateformes commerciales de surveillance. RIPE RIS, RouteViews et BGPStream fournissent des données plutôt qu’une procédure d’incident propre à l’opérateur. BGPalerter propose un autre modèle de surveillance open source. MANRS définit des normes opérationnelles, mais ne détecte pas les événements en direct. Les services commerciaux peuvent offrir une large surveillance et un soutien d’analystes, tout en manquant de contexte local privé si le client ne l’intègre pas.

La position distinctive d’ARTEMIS tient à la combinaison du contrôle par l’opérateur, d’une référence explicite, de plusieurs flux publics et locaux, d’un code ouvert et d’une atténuation facultative. Cette position est aussi exigeante. Un réseau doit disposer d’une expertise en routage, maintenir sa politique et exploiter une plateforme composée de plusieurs services. Le projet peut donc mieux convenir aux organisations qui considèrent la sécurité du routage comme une capacité centrale plutôt que comme un abonnement à un tableau de bord.

La comparaison ne doit pas se réduire à un tableau de fonctions. Les différents modèles répartissent la confiance et le travail de différentes manières. Un service géré centralise l’expertise et l’observation. Un système exploité par l’opérateur maintient la politique et l’action plus près du réseau. La question pertinente est de savoir quelle partie peut voir suffisamment de choses, agir sans danger et rester responsable lorsque les preuves sont incomplètes.

ARTEMIS Lite est apparu dans des documents communautaires de RIPE en 2023 comme une approche apparentée et allégée visant à réduire une partie de la charge de déploiement. L’existence d’une variante Lite montre que l’étendue de la plateforme complète peut être difficile à gérer pour les petites équipes. Une architecture multiconteur avec stockage persistant, plusieurs flux et une atténuation personnalisée peut convenir à un grand opérateur et être excessive pour un réseau qui a d’abord besoin d’une visibilité claire et d’alertes fiables.

Un système allégé ne doit pas être présenté comme équivalent au seul motif qu’il partage le nom et l’objectif. Le dossier de recherche décrit ARTEMIS Lite comme doté de fonctions réduites, et les affirmations des présentations doivent être confirmées de manière indépendante. Le compromis pertinent oppose la réduction du coût d’exploitation au contexte, aux intégrations, à l’historique ou aux mécanismes de réponse qui peuvent être absents. Un déploiement plus petit peut néanmoins être utile s’il définit honnêtement ces limites.

L’adoption dépend de l’ampleur de l’organisation institutionnelle exigée par l’outil. Un projet peut être techniquement ouvert tout en restant inaccessible aux opérateurs dépourvus de spécialistes des conteneurs, des bases de données et de la sécurité 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 peuvent déterminer si l’architecture se diffuse plus largement qu’un nouvel 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 étape. Il crée une boucle autour d’un protocole conçu sans autorisation complète. L’opérateur déclare le routage prévu. Les flux publics et locaux montrent une partie du routage observé. Le détecteur repère les écarts. Le stockage et les interfaces organisent les preuves. Des personnes ou une automatisation approuvée choisissent une réponse, puis les flux montrent si la propagation change. L’incident peut être résolu, ignoré, retiré, remonté ou laissé en sommeil avec une justification enregistrée.

Cette boucle constitue la contribution la plus durable du projet. Elle reconnaît que la sécurité du routage n’est ni un certificat ponctuel ni une alarme lointaine. C’est une pratique opérationnelle dans laquelle la politique doit être explicite, les observations doivent conserver leur provenance et l’autorité de réponse doit être préparée avant l’urgence. La valeur du système réside dans sa capacité à réduire assez vite l’incertitude pour permettre au réseau d’agir, et non dans la prétention de l’avoir supprimée.

Les limites sont tout aussi instructives. Les collecteurs de routes sont partiels. La référence peut être obsolète. Les preuves du plan de contrôle ne peuvent établir le mobile ni tous les effets sur le trafic. Une mesure d’atténuation techniquement valide peut être filtrée ou nuisible. Un code open source exige toujours une maintenance durable. ARTEMIS est le plus solide lorsque ces limites sont intégrées à la procédure plutôt que masquées derrière la promesse d’une réponse en une minute.

Une anomalie BGP peut arriver dans un centre d’exploitation réseau, un centre des opérations de sécurité ou les deux. L’équipe de routage comprend les préfixes, les politiques des fournisseurs amont et les risques liés à la modification des annonces. L’équipe de sécurité peut être mieux préparée à corréler l’identité, la télémétrie des services et une éventuelle activité malveillante. ARTEMIS traverse ces domaines, ce qui n’est utile que si l’alerte contient assez de preuves pour que chaque équipe travaille à partir du même événement, au lieu d’ouvrir des investigations distinctes fondées sur des hypothèses différentes.

Le transfert doit distinguer l’observation, la politique et l’impact. Le système a observé une route dans des flux nommés. Cette route a enfreint une règle précise de la référence. Les vérifications de service ou les sondes RIPE Atlas ont montré un effet défini, ou aucun effet n’a encore été établi. L’opérateur a contacté un fournisseur amont ou l’origine de la route, et la réponse reste en attente.

Cette structure empêche le centre d’exploitation réseau d’écarter un problème de sécurité comme un routage ordinaire et le centre des opérations de sécurité de qualifier une annonce non autorisée d’attaque avant que les faits opérationnels soient connus.

Un langage partagé améliore aussi l’apprentissage après l’incident. Un dossier peut être clos comme changement planifié absent de la politique, fuite de route accidentelle, détournement présumé, événement malveillant confirmé ou anomalie non résolue. Ces résultats doivent alimenter les règles, les procédures et les accords avec les fournisseurs amont. Sans cette boucle, le détecteur peut devenir une machine à produire des tickets plutôt qu’un système améliorant 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 et laisser l’intervenant découvrir que le flux est obsolète, que la route était planifiée ou que la prétendue victime avait autorisé une nouvelle origine. À l’inverse, attendre chaque collecteur et chaque test du plan de données peut faire perdre l’avantage d’une réponse précoce. ARTEMIS a besoin d’une mesure située entre la latence brute de détection et la clôture définitive de l’incident: le temps nécessaire pour réunir assez de preuves fiables afin que l’opérateur habilité puisse prendre une décision défendable.

Cette mesure peut être décomposée. Avec quel délai la première observation est-elle arrivée? Combien de flux indépendants l’ont confirmée? La politique concernée était-elle à jour? RPKI ou le BMP local ont-ils ajouté des preuves? Combien de temps les vérifications de service ont-elles pris? Quand la personne responsable a-t-elle reçu l’alerte, et quand une réponse a-t-elle été approuvée? L’atténuation a-t-elle produit la propagation prévue, et a-t-elle été retirée proprement? Ces questions révèlent où se situe réellement le délai au lieu d’attribuer l’ensemble du résultat à l’algorithme de détection.

Une mesure du délai jusqu’à une décision crédible décourage également les optimisations dangereuses. Le système ne doit pas être récompensé pour avoir agi plus vite s’il s’appuie sur moins de preuves ou crée une modification inutile du routage. Le meilleur déploiement est celui qui réduit simultanément l’incertitude et le temps de réponse, tout en conservant un dossier susceptible d’être examiné après l’incident.