Une Autorisation d'Origine de Route est une signature numérique RPKI Enregistrement qui identifie quel ASN est autorisé à originer une préfixe IP dans BGP. Il est créé par, ou pour le compte de, l'organisation qui détient la ressource d'adresse Internet correspondante. Une ROA contient normalement trois éléments essentiels : le préfixe IP, l'ASN d'origine autorisé et la longueur maximale du préfixe que l'ASN peut annoncer. Par exemple, une organisation peut contrôler le préfixe IPv4 203.0.113.0/24 et utiliser AS64500 pour l'annoncer. Une ROA correspondante peut autoriser AS64500 à originer ce /24. En termes simples, l'enregistrement communique l'instruction suivante à l'écosystème de routage : « Cet ASN est autorisé à annoncer ce préfixe ». Les réseaux effectuant une validation RPKI peuvent ensuite comparer l'enregistrement avec ce qu'ils observent dans BGP. Une ROA ne transfère pas la propriété d'un bloc d'adresses IP. Elle ne remplace pas un contrat, une entrée de registre, un enregistrement d'allocation ou un accord de transfert IPv4. Elle publie uniquement une autorisation liée à l'origine d'une route. Le contrôle juridique et l'autorisation de routage sont liés, mais ils ne sont pas identiques. Les ROAs peuvent être créées pour les ressources IPv4 et IPv6. Le format est similaire, bien que les longueurs de préfixe et la conception opérationnelle puissent différer. Les réseaux IPv4 travaillent souvent avec des préfixes tels que /24, tandis que les réseaux IPv6 annoncent couramment des agrégats tels que /32, /36, /48 ou toute autre longueur appropriée à leur allocation et plan de routage.
Pourquoi un ROA est-il nécessaire ?
Sans ROA, les autres réseaux ne disposent pas d’une autorisation basée sur le RPKI pour confirmer qu’un ASN d’origine BGP est autorisé à annoncer une préfixe. La route peut être légitime, mais elle produira généralement un résultat « Not Found » lors de la validation RPKI, car il n’existe aucune autorisation correspondante. Un résultat « Not Found » n’est pas automatiquement un problème de routage. De nombreuses routes valides sur Internet ne disposent pas de ROA. Toutefois, lorsqu’une organisation publie une ROA exacte, elle fournit aux autres réseaux un signal plus fort qui permet de distinguer l’origine attendue d’une origine non autorisée ou mal configurée. Une ROA devient particulièrement utile lorsque un préfixe est précieux, critique pour les activités commerciales ou largement annoncé. Une entreprise peut utiliser son propre espace d’adresses pour des services publics, une plateforme cloud peut annoncer l’infrastructure de ses clients, ou un hébergeur peut faire l’annonce de grands blocs d’adresses depuis plusieurs localisations. Dans ces situations, une origine incorrecte peut affecter de nombreux utilisateurs et services. Les ROA aident également lors de la gestion d’incidents. Si un préfixe apparaît soudainement depuis un ASN inattendu, un opérateur réseau peut vérifier le statut RPKI et déterminer rapidement si l’annonce entre en conflit avec l’intention publiée par le titulaire des ressources. Cela n’explique pas tous les détails de l’incident, mais cela constitue un point de départ important pour l’enquête. Pour les organisations utilisant plusieurs fournisseurs d’accès, une ROA peut fournir une autorisation cohérente, indépendamment du fournisseur qui transporte la route. Le fournisseur peut changer, mais l’ASN d’origine peut rester identique. Dans ce cas, la ROA ne nécessite généralement pas de modification simplement parce que le chemin de transit a changé.
Comment fonctionne un ROA avec BGP ?
BGP distribue les annonces de routes entre systèmes autonomes. Une annonce de route comprend généralement un préfixe IP et un ASN d'origine, ainsi que d'autres informations relatives au chemin et à la politique de routage. L'ASN d'origine est le système autonome qui se présente comme la source de la route. La validation RPKI fonctionne en parallèle avec BGP. Un validateur récupère des données d'autorisation signées depuis le système RPKI et vérifie leur authenticité et leur actualité. Il génère ensuite un jeu de données validé qui peut être utilisé par les routeurs, les serveurs de routes ou les systèmes de politiques de routage. Lorsqu'un réseau reçoit une annonce BGP, il compare le préfixe annoncé et l'ASN d'origine avec les informations ROA validées. Il existe trois résultats principaux : Valid (Valide), Invalid (Invalide) ou Not Found (Non trouvé). Un résultat Valid signifie que l'annonce est couverte par une ROA et que l'ASN d'origine est autorisé. Un résultat Invalid signifie qu'une ROA pertinente existe, mais que l'annonce y est contradictoire. Un résultat Not Found signifie qu'aucune ROA applicable n'a été trouvée. Le réseau récepteur décide de la manière de traiter ces résultats. Certains opérateurs rejettent les routes Invalides. D'autres leur attribuent une préférence inférieure, génèrent une alerte ou appliquent différentes politiques en fonction de la source. Il n'existe pas de politique universelle unique pour tous les réseaux, mais de nombreux fournisseurs considèrent les annonces Invalides comme un problème grave de sécurité du routage. L'essentiel est que la ROA ne contrôle pas directement Internet mondial ; elle publie des informations d'autorisation. L'effet pratique dépend de la capacité des autres réseaux à récupérer, valider et utiliser ces informations dans leurs décisions de routage.
Les trois principales parties d'un ROA
La première partie d'une ROA est le préfixe IP autorisé, qui identifie la plage d'adresses que l'ASN d'origine peut annoncer. Pour IPv4, un préfixe pourrait être 198.51.100.0/24 ; pour IPv6, il pourrait s'agir de 2001:db8:1234::/48. Le préfixe doit correspondre à une ressource que l'organisation est autorisée à gérer via le registre pertinent ou la relation de parrainage. Le préfixe doit être saisi avec précision, car une erreur de frappe, une limite de réseau incorrecte ou une longueur de préfixe erronée peuvent rendre la ROA inefficace ou autoriser une plage différente de celle prévue.
La deuxième partie est l'ASN d'origine autorisé à originer le préfixe, correspondant à l'ASN qui apparaît comme l'origine de l'annonce BGP. Si une entreprise possède un bloc d'adresses mais l'annonce via l'ASN d'un fournisseur de transit, l'origine correcte dépend de la conception réelle du routage. L'ASN dans la ROA devrait normalement être l'ASN qui origine la route, et non simplement l'ASN du transporteur amont. Cette distinction est importante car un fournisseur de transit peut transporter une route sans en être l'origine ; si l'ASN du client origine le préfixe et que le fournisseur ne fait que le transporter, l'ASN du client est généralement la valeur qui doit être autorisée.
La troisième partie est la longueur maximale du préfixe, souvent appelée maxLength, qui définit à quel point une annonce peut être spécifique tout en restant couverte par le ROA. Supposons qu'un ROA autorise 198.51.100.0/24 avec une longueur maximale de /24 : l'ASN autorisé peut annoncer exactement le /24, mais il n'est pas autorisé à annoncer des sous-préfixes plus petits tels que /25 ou /26. Si le même préfixe est autorisé avec une longueur maximale de /26, les annonces pour les /24, /25 et /26 peuvent être considérées comme couvertes selon la route exacte et les règles de validation. Cela offre de la flexibilité, mais permet également des annonces plus spécifiques. La longueur maximale doit donc refléter le plan de routage réel, car la définir trop courte peut rendre Invalides des routes plus spécifiques légitimes, tandis que la définir trop longue peut autoriser des annonces que l'organisation n'a jamais eu l'intention de permettre.
Pourquoi la longueur maximale est-elle importante ?
La longueur maximale du préfixe est l'un des paramètres ROA les plus importants et les plus souvent mal compris, car elle contrôle le niveau de spécificité que l'ASN autorisé peut utiliser lors de l'annonce de la ressource. De nombreux opérateurs de réseau annoncent un préfixe agrégé afin de limiter la croissance de la table de routage ; par exemple, une organisation peut détenir un /20 mais l'annoncer comme un seul agrégat. Dans certains cas, l'organisation peut également avoir besoin d'annoncer des préfixes plus spécifiques pour l'ingénierie du trafic, la connectivité régionale ou la séparation des services. Si le ROA ne couvre que l'agrégat tandis que le réseau annonce des routes plus spécifiques, ces routes peuvent être classées comme Invalides. L'annonce BGP peut être techniquement correcte du point de vue de l'organisation, mais elle ne correspond pas à l'autorisation publiée dans RPKI. D'un autre côté, autoriser chaque route plus spécifique possible peut affaiblir la précision de la politique, car un /20 autorisé avec une longueur maximale extrêmement large permet à un sous-préfixe beaucoup plus petit d'apparaître comme autorisé, même s'il se trouve en dehors de la conception prévue. Une approche pratique consiste à n'autoriser que les longueurs de préfixe que le réseau s'attend réellement à annoncer, en fonction de son plan d'adressage, des exigences des fournisseurs, de la conception de la reprise après incident et de la stratégie d'ingénierie du trafic. Les modifications apportées à la longueur maximale doivent être testées soigneusement, en confirmant que toutes les annonces en production retournent le résultat de validation attendu avant d'appliquer un filtrage strict.
ROAs for IPv4 and IPv6
Les ROA peuvent être créés pour les réseaux IPv4 et IPv6, et le principe de sécurité sous-jacent est le même : associer un préfixe à un ASN d'origine autorisé. La principale différence opérationnelle réside dans la structure d'adressage. Les ressources IPv4 sont rares et sont souvent annoncées via des préfixes relativement petits, une taille d'annonce minimale courante sur l'Internet public étant /24. Les réseaux IPv6 reçoivent généralement des allocations plus importantes et peuvent les diviser en segments par site, service ou géographie, annonçant un agrégat tout en utilisant plusieurs préfixes internes. Le ROA doit correspondre aux préfixes annoncés publiquement. Les opérateurs IPv6 ne doivent pas supposer qu'un grand espace d'adresses élimine les risques de routage, car une annonce IPv6 non autorisée peut toujours entraîner des problèmes de connectivité, une redirection du trafic ou un routage mondial incohérent. RPKI offre aux opérateurs IPv6 la même possibilité de publier une autorisation d'origine qu'aux opérateurs IPv4. Avant de créer des ROA IPv6, l'équipe réseau doit documenter quels préfixes agrégés seront annoncés, si des annonces plus spécifiques sont attendues, et quel ASN les originera, afin d'éviter des enregistrements soit trop restrictifs, soit inutilement larges.
Quand devez-vous créer un ROA ?
Un ROA doit être créé avant qu’un préfixe ne soit annoncé en production, chaque fois que le détenteur des ressources dispose d’un plan de routage clair, afin de donner aux réseaux de validation le temps de récupérer l’information avant que la route ne devienne largement visible. Les organisations doivent également examiner les ROA lorsqu’elles reçoivent une nouvelle allocation, acquièrent un bloc IPv4, effectuent un transfert d’adresses, modifient l’ASN d’origine ou commencent à utiliser une nouvelle allocation IPv6, car ces événements modifient la relation entre le préfixe et le réseau d’origine. Une migration de fournisseur est un autre déclencheur courant : si l’organisation conserve le même ASN d’origine et change uniquement de fournisseur amont, le ROA peut rester valide ; si la migration modifie l’ASN d’origine, l’enregistrement doit être mis à jour avant ou simultanément au changement de routage. Les ROA doivent être examinés lors de fusions-acquisitions, de déménagements de centres de données, de changements de parrainage d’ASN et de grandes refontes de réseau, afin de garantir que l’autorisation publique corresponde à la réalité opérationnelle. Un examen périodique est utile même en l’absence de changement connu, car la documentation réseau devient obsolète, les responsabilités du personnel évoluent et les anciennes autorisations peuvent rester actives longtemps après que la conception initiale du routage a été remplacée.
Erreurs courantes de configuration ROA
L’une des erreurs les plus courantes consiste à saisir le mauvais ASN d’origine, ce qui se produit lorsque les ingénieurs confondent l’ASN du client avec celui du fournisseur de transit ou lorsqu’un ancien ASN reste dans la configuration après une migration. Une autre erreur fréquente est d’oublier de mettre à jour la ROA après un transfert IPv4 : le nouveau détenteur annonce le préfixe depuis son propre ASN tandis que l’ancienne autorisation pointe toujours vers l’ancien origine, ce qui rend la route Invalid. Une longueur maximale incorrecte crée des problèmes similaires lorsqu’une organisation n’autorise qu’un /24 mais annonce ultérieurement un /25 pour l’ingénierie du trafic. Certaines organisations créent plusieurs ROA chevauchantes sans en documenter l’objectif ; bien que valides dans certaines architectures, elles peuvent produire des résultats inattendus et compliquer le dépannage. Ne pas supprimer les records obsolètes permet à un ASN d’originer un préfixe longtemps après que la conception du réseau a changé. Enfin, certaines organisations activent parfois le rejet strict des routes Invalides sans avoir testé au préalable leurs propres annonces ; les préfixes de production, les longueurs maximales et les ASN d’origine doivent toujours être vérifiés avant de s’appuyer sur un filtrage automatisé.
ROA and IPv4 Transfer Planning
Les transferts IPv4 nécessitent une attention particulière car le titulaire administratif, l’accord de parrainage et l’origine du routage peuvent changer à différentes étapes du processus. Avant un transfert, le titulaire actuel doit documenter les ROAs existantes et confirmer quel ASN origine actuellement le préfixe, tandis que l’acheteur prépare les informations d’origine prévues et coordonne avec les fournisseurs de transit. Pendant la transition, les deux parties doivent avoir un plan clair pour mettre à jour ou remplacer les enregistrements d’autorisation : laisser l’ancienne ROA active trop longtemps autorise l’ancienne origine après le transfert, tandis que sa suppression trop tôt entraîne la mise à Invalidité de la route existante avant que la nouvelle route ne soit prête. Le processus exact dépend du registre, du type de ressource, de l’accord de transfert et de la conception opérationnelle, ce qui fait de RPKI un élément essentiel de la liste de contrôle, aux côtés de la vérification du registre, de l’examen contractuel, des annonces BGP, des objets de route, de la DNS inverse et du screening de réputation. Un vérificateur de disponibilité public permet d’identifier l’ASN d’origine actuelle, l’état RPKI, les informations du registre et la visibilité BGP d’un préfixe pour des vérifications techniques préalables, bien qu’il ne confirme pas la propriété légale ni ne garantisse l’éligibilité au transfert.
Modifications de ROA et ASN
Un changement d’ASN a un impact direct sur la validation RPKI. Si un préfixe précédemment annoncé par l’AS64500 est désormais annoncé par l’AS64510, la ROA doit autoriser le nouvel origin avant que l’annonce BGP ne soit acceptée comme Valide. Cela est particulièrement important lorsqu’une organisation passe d’un ASN géré par un fournisseur à son propre ASN ou modifie son arrangement avec un LIR sponsor, ce qui nécessite de réexaminer conjointement la relation avec le registre et l’autorisation de routage. Une transition soigneusement planifiée peut prévoir d’autoriser temporairement à la fois les anciens et nouveaux origins afin de créer une fenêtre de migration contrôlée, à condition que cela soit documenté et que l’autorisation obsolète soit supprimée une fois la migration achevée. L’équipe réseau doit tester l’ordre des opérations avant d’apporter des modifications en production, en veillant à ce que la nouvelle autorisation soit publiée et validée avant d’annoncer la nouvelle route BGP.
Comment vérifier si un ROA fonctionne ?
La première étape consiste à confirmer que le ROA contient le préfixe prévu, l’ASN d’origine et la longueur maximale de préfixe via le portail du RIR pertinent, l’interface LIR sponsor ou le système de gestion RPKI. Ensuite, comparez l’autorisation avec l’annonce BGP réelle, en vérifiant que la longueur de préfixe annoncée est couverte et que l’ASN d’origine correspond à celui du ROA. Un validateur RPKI externe peut ensuite confirmer le statut public, où une annonce correctement configurée renvoie Valid. Si le résultat est Invalid, inspectez d’abord l’ASN d’origine et la longueur de préfixe ; si le statut est Not Found, vérifiez que le ROA a bien été publié et que les validateurs ont eu le temps de le récupérer. Les résultats ne se mettent pas à jour instantanément car les dépôts, les validateurs et les systèmes de routage s’appuient sur des intervalles d’actualisation, ce qui rend les courts délais normaux lors de la propagation. La comparaison de plusieurs sources publiques – y compris les données du registre, les résultats des validateurs et les observations BGP actuelles – permet d’éviter de dépendre d’informations mises en cache et offre une vue complète.
Que se passe-t-il lorsqu'un ROA est invalide ?
Lorsqu'une annonce BGP entre en conflit avec une ROA existante, les validateurs RPKI la classent comme « Invalid » (non valide). La route n'est pas automatiquement supprimée de l'Internet mondial, mais les réseaux appliquant des politiques basées sur le RPKI peuvent la rejeter ou lui attribuer une préférence inférieure. L'impact opérationnel dépend de l'étendue de l'application : certains réseaux filtrent strictement, tandis que d'autres utilisent ce statut à des fins de surveillance, ce qui signifie qu'une route « Invalid » peut rester visible dans certaines parties de l'Internet tout en devenant inaccessible via d'autres. Si une route légitime devient « Invalid », l'organisation doit considérer cela comme un problème de configuration urgent, en priorisant la vérification de l'ASN d'origine, de la longueur du préfixe annoncé et de la longueur maximale de la ROA. La route ne doit pas être supposée malveillante, car la plupart des résultats « Invalid » proviennent d'erreurs courantes telles que des migrations incomplètes, des enregistrements obsolètes, des détails incorrects du fournisseur ou des annonces accidentelles de sous-préfixes plus spécifiques. Une fois corrigée, les systèmes ont besoin de temps pour se rafraîchir, et l'équipe réseau doit surveiller la route jusqu'à ce qu'elle se stabilise sur tous les points d'observation.
Comment les organisations devraient-elles gérer les ROA ?
La gestion des ROA nécessite un propriétaire clair, qu’il s’agisse de l’équipe d’ingénierie réseau, de l’équipe de sécurité, du LIR sponsor, du prestataire de services managés ou d’un autre groupe responsable des ressources de numérotation Internet. L’organisation doit maintenir un inventaire détaillant chaque préfixe, l’ASN d’origine, la longueur maximale, les lieux d’annonce et les contacts responsables, afin de simplifier les examens des modifications et les réponses aux incidents. Les modifications des ROA doivent être intégrées aux procédures standard de changement réseau, en traitant le RPKI comme une exigence explicite lors des migrations ASN, des changements de fournisseur, des transferts IPv4 ou des déploiements IPv6. La surveillance et les alertes doivent être configurées pour détecter les résultats Invalid, les origines inattendues, les autorisations supprimées ou les variations de visibilité BGP. Crucialement, les organisations doivent éviter les autorisations trop larges : les ROA précises restent plus faciles à comprendre, plus simples à auditer et bien moins susceptibles de permettre des annonces non intentionnelles.
Foire aux questions
Un ROA est-il identique à un document de propriété d'adresse IP ?
Non. Une ROA est une autorisation de routage indiquant quel ASN peut originer un préfixe dans BGP. Elle ne remplace pas les enregistrements du registre, les contrats, les documents de transfert ou les preuves de propriété légale.
Un préfixe peut-il avoir plusieurs ROA ?
Oui. Plusieurs ROA peuvent être appropriées lorsqu’un préfixe est intentionnellement originaire de plusieurs ASN ou lorsqu’une migration contrôlée nécessite une autorisation temporaire pour plusieurs origines, bien que les enregistrements chevauchants doivent être soigneusement documentés.
Une annonce ROA publie-t-elle mon préfixe dans BGP ?
Non. La création d'un ROA ne génère pas une annonce BGP ; le réseau doit toujours configurer BGP via ses routeurs et ses fournisseurs en amont.
Un fournisseur de transit doit-il être répertorié dans l'ROA ?
En général, le ROA devrait identifier l'ASN qui est à l'origine de la route. Un fournisseur qui ne fait que transporter la route n'est pas nécessairement l'ASN d'origine, et la valeur correcte dépend de l'architecture de routage réelle.
Combien de temps faut-il pour qu'un ROA devienne visible ?
Le timing dépend du système RIR, du dépôt de publication, des intervalles d'actualisation du validateur et de la mise en cache. Les mises à jour sont souvent visibles relativement rapidement, mais les modifications de production doivent laisser suffisamment de temps pour la validation.
Chaque préfixe IPv4 et IPv6 doit-il avoir un ROA ?
Il est fortement recommandé de publier des ROAs exacts pour les préfixes annoncés dans BGP. L'organisation doit d'abord confirmer sa conception de routage afin que l'autorisation ne rende pas accidentellement invalides les annonces légitimes.
Une ROA peut-elle protéger contre toutes les attaques BGP ?
Non. Un ROA prend principalement en charge la validation de l'origine. Il ne valide pas chaque partie du chemin BGP, n'empêche pas toutes les fuites de routes, ne chiffre pas le trafic et ne garantit pas que le trafic suit un itinéraire physique sécurisé.
Une Autorisation d'Origine de Route (ROA) est un composant central du RPKI, établissant une relation cryptographiquement signée entre un préfixe IP et l'ASN autorisé à originer ce préfixe dans BGP. L'enregistrement comprend normalement le préfixe, l'ASN d'origine et une longueur maximale de préfixe — chacun jouant un rôle décisif dans l'identification de la ressource, l'autorisation de l'origine et la définition de la spécificité de l'annonce. Des ROAs précises aident les réseaux à identifier les annonces non autorisées ou mal configurées, s'avérant vitales lors des transferts IPv4, des changements d'ASN, des migrations de fournisseur, des déploiements IPv6 et des opérations sur des réseaux multi-hommes. En même temps, une ROA n'est ni une preuve de propriété légale ni une solution autonome de sécurité de routage ; elle fonctionne mieux en conjonction avec des registres précis, des configurations BGP disciplinées, des données IRR, une surveillance des routes et des processus documentés de changement. Pour toute organisation annonçant de l'espace public IPv4 ou IPv6, la règle pratique est simple : publier uniquement les origines que vous avez l'intention d'utiliser, autoriser uniquement les longueurs de préfixe que vous prévoyez réellement d'annoncer, et examiner les enregistrements chaque fois que le réseau change. Cela maintient les données RPKI alignées avec l'environnement réel de routage et réduit la possibilité qu'une route légitime soit classée comme Invalid.