{"id":1102,"date":"2026-09-09T02:25:09","date_gmt":"2026-09-09T02:25:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-09-09T02:25:09","modified_gmt":"2026-09-09T02:25:09","slug":"what-is-a-roa-in-rpki","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/fr\/what-is-a-roa-in-rpki\/","title":{"rendered":"Qu'est-ce qu'un ROA dans le RPKI ? Comment fonctionne l'Autorisation d'Origine de Route"},"content":{"rendered":"

Une Autorisation d'Origine de Route est une signature num\u00e9rique RPKI<\/a> Enregistrement qui identifie quel ASN est autoris\u00e9 \u00e0 originer une pr\u00e9fixe IP dans BGP. Il est cr\u00e9\u00e9 par, ou pour le compte de, l'organisation qui d\u00e9tient la ressource d'adresse Internet correspondante. Une ROA contient normalement trois \u00e9l\u00e9ments essentiels : le pr\u00e9fixe IP, l'ASN d'origine autoris\u00e9 et la longueur maximale du pr\u00e9fixe que l'ASN peut annoncer. Par exemple, une organisation peut contr\u00f4ler le pr\u00e9fixe IPv4 203.0.113.0\/24 et utiliser AS64500 pour l'annoncer. Une ROA correspondante peut autoriser AS64500 \u00e0 originer ce \/24. En termes simples, l'enregistrement communique l'instruction suivante \u00e0 l'\u00e9cosyst\u00e8me de routage : \u00ab Cet ASN est autoris\u00e9 \u00e0 annoncer ce pr\u00e9fixe \u00bb. Les r\u00e9seaux effectuant une validation RPKI peuvent ensuite comparer l'enregistrement avec ce qu'ils observent dans BGP. Une ROA ne transf\u00e8re pas la propri\u00e9t\u00e9 d'un bloc d'adresses IP. Elle ne remplace pas un contrat, une entr\u00e9e de registre, un enregistrement d'allocation ou un accord de transfert IPv4. Elle publie uniquement une autorisation li\u00e9e \u00e0 l'origine d'une route. Le contr\u00f4le juridique et l'autorisation de routage sont li\u00e9s, mais ils ne sont pas identiques. Les ROAs peuvent \u00eatre cr\u00e9\u00e9es pour les ressources IPv4 et IPv6. Le format est similaire, bien que les longueurs de pr\u00e9fixe et la conception op\u00e9rationnelle puissent diff\u00e9rer. Les r\u00e9seaux IPv4 travaillent souvent avec des pr\u00e9fixes tels que \/24, tandis que les r\u00e9seaux IPv6 annoncent couramment des agr\u00e9gats tels que \/32, \/36, \/48 ou toute autre longueur appropri\u00e9e \u00e0 leur allocation et plan de routage.<\/p>\n\n\n\n

Pourquoi un ROA est-il n\u00e9cessaire ?<\/h2>\n\n\n\n

Sans ROA, les autres r\u00e9seaux ne disposent pas d\u2019une autorisation bas\u00e9e sur le RPKI pour confirmer qu\u2019un ASN d\u2019origine BGP est autoris\u00e9 \u00e0 annoncer une pr\u00e9fixe. La route peut \u00eatre l\u00e9gitime, mais elle produira g\u00e9n\u00e9ralement un r\u00e9sultat \u00ab Not Found \u00bb lors de la validation RPKI, car il n\u2019existe aucune autorisation correspondante. Un r\u00e9sultat \u00ab Not Found \u00bb n\u2019est pas automatiquement un probl\u00e8me de routage. De nombreuses routes valides sur Internet ne disposent pas de ROA. Toutefois, lorsqu\u2019une organisation publie une ROA exacte, elle fournit aux autres r\u00e9seaux un signal plus fort qui permet de distinguer l\u2019origine attendue d\u2019une origine non autoris\u00e9e ou mal configur\u00e9e. Une ROA devient particuli\u00e8rement utile lorsque un pr\u00e9fixe est pr\u00e9cieux, critique pour les activit\u00e9s commerciales ou largement annonc\u00e9. Une entreprise peut utiliser son propre espace d\u2019adresses pour des services publics, une plateforme cloud peut annoncer l\u2019infrastructure de ses clients, ou un h\u00e9bergeur peut faire l\u2019annonce de grands blocs d\u2019adresses depuis plusieurs localisations. Dans ces situations, une origine incorrecte peut affecter de nombreux utilisateurs et services. Les ROA aident \u00e9galement lors de la gestion d\u2019incidents. Si un pr\u00e9fixe appara\u00eet soudainement depuis un ASN inattendu, un op\u00e9rateur r\u00e9seau peut v\u00e9rifier le statut RPKI et d\u00e9terminer rapidement si l\u2019annonce entre en conflit avec l\u2019intention publi\u00e9e par le titulaire des ressources. Cela n\u2019explique pas tous les d\u00e9tails de l\u2019incident, mais cela constitue un point de d\u00e9part important pour l\u2019enqu\u00eate. Pour les organisations utilisant plusieurs fournisseurs d\u2019acc\u00e8s, une ROA peut fournir une autorisation coh\u00e9rente, ind\u00e9pendamment du fournisseur qui transporte la route. Le fournisseur peut changer, mais l\u2019ASN d\u2019origine peut rester identique. Dans ce cas, la ROA ne n\u00e9cessite g\u00e9n\u00e9ralement pas de modification simplement parce que le chemin de transit a chang\u00e9.<\/p>\n\n\n\n

Comment fonctionne un ROA avec BGP ?<\/h2>\n\n\n\n

BGP distribue les annonces de routes entre syst\u00e8mes autonomes. Une annonce de route comprend g\u00e9n\u00e9ralement un pr\u00e9fixe IP et un ASN d'origine, ainsi que d'autres informations relatives au chemin et \u00e0 la politique de routage. L'ASN d'origine est le syst\u00e8me autonome qui se pr\u00e9sente comme la source de la route. La validation RPKI fonctionne en parall\u00e8le avec BGP. Un validateur r\u00e9cup\u00e8re des donn\u00e9es d'autorisation sign\u00e9es depuis le syst\u00e8me RPKI et v\u00e9rifie leur authenticit\u00e9 et leur actualit\u00e9. Il g\u00e9n\u00e8re ensuite un jeu de donn\u00e9es valid\u00e9 qui peut \u00eatre utilis\u00e9 par les routeurs, les serveurs de routes ou les syst\u00e8mes de politiques de routage. Lorsqu'un r\u00e9seau re\u00e7oit une annonce BGP, il compare le pr\u00e9fixe annonc\u00e9 et l'ASN d'origine avec les informations ROA valid\u00e9es. Il existe trois r\u00e9sultats principaux : Valid (Valide), Invalid (Invalide) ou Not Found (Non trouv\u00e9). Un r\u00e9sultat Valid signifie que l'annonce est couverte par une ROA et que l'ASN d'origine est autoris\u00e9. Un r\u00e9sultat Invalid signifie qu'une ROA pertinente existe, mais que l'annonce y est contradictoire. Un r\u00e9sultat Not Found signifie qu'aucune ROA applicable n'a \u00e9t\u00e9 trouv\u00e9e. Le r\u00e9seau r\u00e9cepteur d\u00e9cide de la mani\u00e8re de traiter ces r\u00e9sultats. Certains op\u00e9rateurs rejettent les routes Invalides. D'autres leur attribuent une pr\u00e9f\u00e9rence inf\u00e9rieure, g\u00e9n\u00e8rent une alerte ou appliquent diff\u00e9rentes politiques en fonction de la source. Il n'existe pas de politique universelle unique pour tous les r\u00e9seaux, mais de nombreux fournisseurs consid\u00e8rent les annonces Invalides comme un probl\u00e8me grave de s\u00e9curit\u00e9 du routage. L'essentiel est que la ROA ne contr\u00f4le pas directement Internet mondial ; elle publie des informations d'autorisation. L'effet pratique d\u00e9pend de la capacit\u00e9 des autres r\u00e9seaux \u00e0 r\u00e9cup\u00e9rer, valider et utiliser ces informations dans leurs d\u00e9cisions de routage.<\/p>\n\n\n\n

Les trois principales parties d'un ROA<\/h2>\n\n\n\n

La premi\u00e8re partie d'une ROA est le pr\u00e9fixe IP autoris\u00e9, qui identifie la plage d'adresses que l'ASN d'origine peut annoncer. Pour IPv4, un pr\u00e9fixe pourrait \u00eatre 198.51.100.0\/24 ; pour IPv6, il pourrait s'agir de 2001:db8:1234::\/48. Le pr\u00e9fixe doit correspondre \u00e0 une ressource que l'organisation est autoris\u00e9e \u00e0 g\u00e9rer via le registre pertinent ou la relation de parrainage. Le pr\u00e9fixe doit \u00eatre saisi avec pr\u00e9cision, car une erreur de frappe, une limite de r\u00e9seau incorrecte ou une longueur de pr\u00e9fixe erron\u00e9e peuvent rendre la ROA inefficace ou autoriser une plage diff\u00e9rente de celle pr\u00e9vue.<\/p>\n\n\n\n

La deuxi\u00e8me partie est l'ASN d'origine autoris\u00e9 \u00e0 originer le pr\u00e9fixe, correspondant \u00e0 l'ASN qui appara\u00eet comme l'origine de l'annonce BGP. Si une entreprise poss\u00e8de un bloc d'adresses mais l'annonce via l'ASN d'un fournisseur de transit, l'origine correcte d\u00e9pend de la conception r\u00e9elle du routage. L'ASN dans la ROA devrait normalement \u00eatre 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 \u00eatre l'origine ; si l'ASN du client origine le pr\u00e9fixe et que le fournisseur ne fait que le transporter, l'ASN du client est g\u00e9n\u00e9ralement la valeur qui doit \u00eatre autoris\u00e9e.<\/p>\n\n\n\n

La troisi\u00e8me partie est la longueur maximale du pr\u00e9fixe, souvent appel\u00e9e maxLength, qui d\u00e9finit \u00e0 quel point une annonce peut \u00eatre sp\u00e9cifique 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\u00e9 peut annoncer exactement le \/24, mais il n'est pas autoris\u00e9 \u00e0 annoncer des sous-pr\u00e9fixes plus petits tels que \/25 ou \/26. Si le m\u00eame pr\u00e9fixe est autoris\u00e9 avec une longueur maximale de \/26, les annonces pour les \/24, \/25 et \/26 peuvent \u00eatre consid\u00e9r\u00e9es comme couvertes selon la route exacte et les r\u00e8gles de validation. Cela offre de la flexibilit\u00e9, mais permet \u00e9galement des annonces plus sp\u00e9cifiques. La longueur maximale doit donc refl\u00e9ter le plan de routage r\u00e9el, car la d\u00e9finir trop courte peut rendre Invalides des routes plus sp\u00e9cifiques l\u00e9gitimes, tandis que la d\u00e9finir trop longue peut autoriser des annonces que l'organisation n'a jamais eu l'intention de permettre.<\/p>\n\n\n\n

Pourquoi la longueur maximale est-elle importante ?<\/h2>\n\n\n\n

La longueur maximale du pr\u00e9fixe est l'un des param\u00e8tres ROA les plus importants et les plus souvent mal compris, car elle contr\u00f4le le niveau de sp\u00e9cificit\u00e9 que l'ASN autoris\u00e9 peut utiliser lors de l'annonce de la ressource. De nombreux op\u00e9rateurs de r\u00e9seau annoncent un pr\u00e9fixe agr\u00e9g\u00e9 afin de limiter la croissance de la table de routage ; par exemple, une organisation peut d\u00e9tenir un \/20 mais l'annoncer comme un seul agr\u00e9gat. Dans certains cas, l'organisation peut \u00e9galement avoir besoin d'annoncer des pr\u00e9fixes plus sp\u00e9cifiques pour l'ing\u00e9nierie du trafic, la connectivit\u00e9 r\u00e9gionale ou la s\u00e9paration des services. Si le ROA ne couvre que l'agr\u00e9gat tandis que le r\u00e9seau annonce des routes plus sp\u00e9cifiques, ces routes peuvent \u00eatre class\u00e9es comme Invalides. L'annonce BGP peut \u00eatre techniquement correcte du point de vue de l'organisation, mais elle ne correspond pas \u00e0 l'autorisation publi\u00e9e dans RPKI. D'un autre c\u00f4t\u00e9, autoriser chaque route plus sp\u00e9cifique possible peut affaiblir la pr\u00e9cision de la politique, car un \/20 autoris\u00e9 avec une longueur maximale extr\u00eamement large permet \u00e0 un sous-pr\u00e9fixe beaucoup plus petit d'appara\u00eetre comme autoris\u00e9, m\u00eame s'il se trouve en dehors de la conception pr\u00e9vue. Une approche pratique consiste \u00e0 n'autoriser que les longueurs de pr\u00e9fixe que le r\u00e9seau s'attend r\u00e9ellement \u00e0 annoncer, en fonction de son plan d'adressage, des exigences des fournisseurs, de la conception de la reprise apr\u00e8s incident et de la strat\u00e9gie d'ing\u00e9nierie du trafic. Les modifications apport\u00e9es \u00e0 la longueur maximale doivent \u00eatre test\u00e9es soigneusement, en confirmant que toutes les annonces en production retournent le r\u00e9sultat de validation attendu avant d'appliquer un filtrage strict.<\/p>\n\n\n\n

ROAs for IPv4 and IPv6<\/h2>\n\n\n\n

Les ROA peuvent \u00eatre cr\u00e9\u00e9s pour les r\u00e9seaux IPv4 et IPv6, et le principe de s\u00e9curit\u00e9 sous-jacent est le m\u00eame : associer un pr\u00e9fixe \u00e0 un ASN d'origine autoris\u00e9. La principale diff\u00e9rence op\u00e9rationnelle r\u00e9side dans la structure d'adressage. Les ressources IPv4 sont rares et sont souvent annonc\u00e9es via des pr\u00e9fixes relativement petits, une taille d'annonce minimale courante sur l'Internet public \u00e9tant \/24. Les r\u00e9seaux IPv6 re\u00e7oivent g\u00e9n\u00e9ralement des allocations plus importantes et peuvent les diviser en segments par site, service ou g\u00e9ographie, annon\u00e7ant un agr\u00e9gat tout en utilisant plusieurs pr\u00e9fixes internes. Le ROA doit correspondre aux pr\u00e9fixes annonc\u00e9s publiquement. Les op\u00e9rateurs IPv6 ne doivent pas supposer qu'un grand espace d'adresses \u00e9limine les risques de routage, car une annonce IPv6 non autoris\u00e9e peut toujours entra\u00eener des probl\u00e8mes de connectivit\u00e9, une redirection du trafic ou un routage mondial incoh\u00e9rent. RPKI offre aux op\u00e9rateurs IPv6 la m\u00eame possibilit\u00e9 de publier une autorisation d'origine qu'aux op\u00e9rateurs IPv4. Avant de cr\u00e9er des ROA IPv6, l'\u00e9quipe r\u00e9seau doit documenter quels pr\u00e9fixes agr\u00e9g\u00e9s seront annonc\u00e9s, si des annonces plus sp\u00e9cifiques sont attendues, et quel ASN les originera, afin d'\u00e9viter des enregistrements soit trop restrictifs, soit inutilement larges.<\/p>\n\n\n\n

Quand devez-vous cr\u00e9er un ROA ?<\/strong><\/h2>\n\n\n\n

Un ROA doit \u00eatre cr\u00e9\u00e9 avant qu\u2019un pr\u00e9fixe ne soit annonc\u00e9 en production, chaque fois que le d\u00e9tenteur des ressources dispose d\u2019un plan de routage clair, afin de donner aux r\u00e9seaux de validation le temps de r\u00e9cup\u00e9rer l\u2019information avant que la route ne devienne largement visible. Les organisations doivent \u00e9galement examiner les ROA lorsqu\u2019elles re\u00e7oivent une nouvelle allocation, acqui\u00e8rent un bloc IPv4, effectuent un transfert d\u2019adresses, modifient l\u2019ASN d\u2019origine ou commencent \u00e0 utiliser une nouvelle allocation IPv6, car ces \u00e9v\u00e9nements modifient la relation entre le pr\u00e9fixe et le r\u00e9seau d\u2019origine. Une migration de fournisseur est un autre d\u00e9clencheur courant : si l\u2019organisation conserve le m\u00eame ASN d\u2019origine et change uniquement de fournisseur amont, le ROA peut rester valide ; si la migration modifie l\u2019ASN d\u2019origine, l\u2019enregistrement doit \u00eatre mis \u00e0 jour avant ou simultan\u00e9ment au changement de routage. Les ROA doivent \u00eatre examin\u00e9s lors de fusions-acquisitions, de d\u00e9m\u00e9nagements de centres de donn\u00e9es, de changements de parrainage d\u2019ASN et de grandes refontes de r\u00e9seau, afin de garantir que l\u2019autorisation publique corresponde \u00e0 la r\u00e9alit\u00e9 op\u00e9rationnelle. Un examen p\u00e9riodique est utile m\u00eame en l\u2019absence de changement connu, car la documentation r\u00e9seau devient obsol\u00e8te, les responsabilit\u00e9s du personnel \u00e9voluent et les anciennes autorisations peuvent rester actives longtemps apr\u00e8s que la conception initiale du routage a \u00e9t\u00e9 remplac\u00e9e.<\/p>\n\n\n\n

Erreurs courantes de configuration ROA<\/h2>\n\n\n\n

L\u2019une des erreurs les plus courantes consiste \u00e0 saisir le mauvais ASN d\u2019origine, ce qui se produit lorsque les ing\u00e9nieurs confondent l\u2019ASN du client avec celui du fournisseur de transit ou lorsqu\u2019un ancien ASN reste dans la configuration apr\u00e8s une migration. Une autre erreur fr\u00e9quente est d\u2019oublier de mettre \u00e0 jour la ROA apr\u00e8s un transfert IPv4 : le nouveau d\u00e9tenteur annonce le pr\u00e9fixe depuis son propre ASN tandis que l\u2019ancienne autorisation pointe toujours vers l\u2019ancien origine, ce qui rend la route Invalid. Une longueur maximale incorrecte cr\u00e9e des probl\u00e8mes similaires lorsqu\u2019une organisation n\u2019autorise qu\u2019un \/24 mais annonce ult\u00e9rieurement un \/25 pour l\u2019ing\u00e9nierie du trafic. Certaines organisations cr\u00e9ent plusieurs ROA chevauchantes sans en documenter l\u2019objectif ; bien que valides dans certaines architectures, elles peuvent produire des r\u00e9sultats inattendus et compliquer le d\u00e9pannage. Ne pas supprimer les records obsol\u00e8tes permet \u00e0 un ASN d\u2019originer un pr\u00e9fixe longtemps apr\u00e8s que la conception du r\u00e9seau a chang\u00e9. Enfin, certaines organisations activent parfois le rejet strict des routes Invalides sans avoir test\u00e9 au pr\u00e9alable leurs propres annonces ; les pr\u00e9fixes de production, les longueurs maximales et les ASN d\u2019origine doivent toujours \u00eatre v\u00e9rifi\u00e9s avant de s\u2019appuyer sur un filtrage automatis\u00e9.<\/p>\n\n\n\n

ROA and IPv4 Transfer Planning<\/h2>\n\n\n\n

Les transferts IPv4 n\u00e9cessitent une attention particuli\u00e8re car le titulaire administratif, l\u2019accord de parrainage et l\u2019origine du routage peuvent changer \u00e0 diff\u00e9rentes \u00e9tapes du processus. Avant un transfert, le titulaire actuel doit documenter les ROAs existantes et confirmer quel ASN origine actuellement le pr\u00e9fixe, tandis que l\u2019acheteur pr\u00e9pare les informations d\u2019origine pr\u00e9vues et coordonne avec les fournisseurs de transit. Pendant la transition, les deux parties doivent avoir un plan clair pour mettre \u00e0 jour ou remplacer les enregistrements d\u2019autorisation : laisser l\u2019ancienne ROA active trop longtemps autorise l\u2019ancienne origine apr\u00e8s le transfert, tandis que sa suppression trop t\u00f4t entra\u00eene la mise \u00e0 Invalidit\u00e9 de la route existante avant que la nouvelle route ne soit pr\u00eate. Le processus exact d\u00e9pend du registre, du type de ressource, de l\u2019accord de transfert et de la conception op\u00e9rationnelle, ce qui fait de RPKI un \u00e9l\u00e9ment essentiel de la liste de contr\u00f4le, aux c\u00f4t\u00e9s de la v\u00e9rification du registre, de l\u2019examen contractuel, des annonces BGP, des objets de route, de la DNS inverse et du screening de r\u00e9putation. Un v\u00e9rificateur de disponibilit\u00e9 public permet d\u2019identifier l\u2019ASN d\u2019origine actuelle, l\u2019\u00e9tat RPKI, les informations du registre et la visibilit\u00e9 BGP d\u2019un pr\u00e9fixe pour des v\u00e9rifications techniques pr\u00e9alables, bien qu\u2019il ne confirme pas la propri\u00e9t\u00e9 l\u00e9gale ni ne garantisse l\u2019\u00e9ligibilit\u00e9 au transfert.<\/p>\n\n\n\n

Modifications de ROA et ASN<\/h2>\n\n\n\n

Un changement d\u2019ASN a un impact direct sur la validation RPKI. Si un pr\u00e9fixe pr\u00e9c\u00e9demment annonc\u00e9 par l\u2019AS64500 est d\u00e9sormais annonc\u00e9 par l\u2019AS64510, la ROA doit autoriser le nouvel origin avant que l\u2019annonce BGP ne soit accept\u00e9e comme Valide. Cela est particuli\u00e8rement important lorsqu\u2019une organisation passe d\u2019un ASN g\u00e9r\u00e9 par un fournisseur \u00e0 son propre ASN ou modifie son arrangement avec un LIR sponsor, ce qui n\u00e9cessite de r\u00e9examiner conjointement la relation avec le registre et l\u2019autorisation de routage. Une transition soigneusement planifi\u00e9e peut pr\u00e9voir d\u2019autoriser temporairement \u00e0 la fois les anciens et nouveaux origins afin de cr\u00e9er une fen\u00eatre de migration contr\u00f4l\u00e9e, \u00e0 condition que cela soit document\u00e9 et que l\u2019autorisation obsol\u00e8te soit supprim\u00e9e une fois la migration achev\u00e9e. L\u2019\u00e9quipe r\u00e9seau doit tester l\u2019ordre des op\u00e9rations avant d\u2019apporter des modifications en production, en veillant \u00e0 ce que la nouvelle autorisation soit publi\u00e9e et valid\u00e9e avant d\u2019annoncer la nouvelle route BGP.<\/p>\n\n\n\n

Comment v\u00e9rifier si un ROA fonctionne ?<\/h2>\n\n\n\n

La premi\u00e8re \u00e9tape consiste \u00e0 confirmer que le ROA contient le pr\u00e9fixe pr\u00e9vu, l\u2019ASN d\u2019origine et la longueur maximale de pr\u00e9fixe via le portail du RIR pertinent, l\u2019interface LIR sponsor ou le syst\u00e8me de gestion RPKI. Ensuite, comparez l\u2019autorisation avec l\u2019annonce BGP r\u00e9elle, en v\u00e9rifiant que la longueur de pr\u00e9fixe annonc\u00e9e est couverte et que l\u2019ASN d\u2019origine correspond \u00e0 celui du ROA. Un validateur RPKI externe peut ensuite confirmer le statut public, o\u00f9 une annonce correctement configur\u00e9e renvoie Valid. Si le r\u00e9sultat est Invalid, inspectez d\u2019abord l\u2019ASN d\u2019origine et la longueur de pr\u00e9fixe ; si le statut est Not Found, v\u00e9rifiez que le ROA a bien \u00e9t\u00e9 publi\u00e9 et que les validateurs ont eu le temps de le r\u00e9cup\u00e9rer. Les r\u00e9sultats ne se mettent pas \u00e0 jour instantan\u00e9ment car les d\u00e9p\u00f4ts, les validateurs et les syst\u00e8mes de routage s\u2019appuient sur des intervalles d\u2019actualisation, ce qui rend les courts d\u00e9lais normaux lors de la propagation. La comparaison de plusieurs sources publiques \u2013 y compris les donn\u00e9es du registre, les r\u00e9sultats des validateurs et les observations BGP actuelles \u2013 permet d\u2019\u00e9viter de d\u00e9pendre d\u2019informations mises en cache et offre une vue compl\u00e8te.<\/p>\n\n\n\n

Que se passe-t-il lorsqu'un ROA est invalide ?<\/h2>\n\n\n\n

Lorsqu'une annonce BGP entre en conflit avec une ROA existante, les validateurs RPKI la classent comme \u00ab Invalid \u00bb (non valide). La route n'est pas automatiquement supprim\u00e9e de l'Internet mondial, mais les r\u00e9seaux appliquant des politiques bas\u00e9es sur le RPKI peuvent la rejeter ou lui attribuer une pr\u00e9f\u00e9rence inf\u00e9rieure. L'impact op\u00e9rationnel d\u00e9pend de l'\u00e9tendue de l'application : certains r\u00e9seaux filtrent strictement, tandis que d'autres utilisent ce statut \u00e0 des fins de surveillance, ce qui signifie qu'une route \u00ab Invalid \u00bb peut rester visible dans certaines parties de l'Internet tout en devenant inaccessible via d'autres. Si une route l\u00e9gitime devient \u00ab Invalid \u00bb, l'organisation doit consid\u00e9rer cela comme un probl\u00e8me de configuration urgent, en priorisant la v\u00e9rification de l'ASN d'origine, de la longueur du pr\u00e9fixe annonc\u00e9 et de la longueur maximale de la ROA. La route ne doit pas \u00eatre suppos\u00e9e malveillante, car la plupart des r\u00e9sultats \u00ab Invalid \u00bb proviennent d'erreurs courantes telles que des migrations incompl\u00e8tes, des enregistrements obsol\u00e8tes, des d\u00e9tails incorrects du fournisseur ou des annonces accidentelles de sous-pr\u00e9fixes plus sp\u00e9cifiques. Une fois corrig\u00e9e, les syst\u00e8mes ont besoin de temps pour se rafra\u00eechir, et l'\u00e9quipe r\u00e9seau doit surveiller la route jusqu'\u00e0 ce qu'elle se stabilise sur tous les points d'observation.<\/p>\n\n\n\n

Comment les organisations devraient-elles g\u00e9rer les ROA ?<\/h2>\n\n\n\n

La gestion des ROA n\u00e9cessite un propri\u00e9taire clair, qu\u2019il s\u2019agisse de l\u2019\u00e9quipe d\u2019ing\u00e9nierie r\u00e9seau, de l\u2019\u00e9quipe de s\u00e9curit\u00e9, du LIR sponsor, du prestataire de services manag\u00e9s ou d\u2019un autre groupe responsable des ressources de num\u00e9rotation Internet. L\u2019organisation doit maintenir un inventaire d\u00e9taillant chaque pr\u00e9fixe, l\u2019ASN d\u2019origine, la longueur maximale, les lieux d\u2019annonce et les contacts responsables, afin de simplifier les examens des modifications et les r\u00e9ponses aux incidents. Les modifications des ROA doivent \u00eatre int\u00e9gr\u00e9es aux proc\u00e9dures standard de changement r\u00e9seau, en traitant le RPKI comme une exigence explicite lors des migrations ASN, des changements de fournisseur, des transferts IPv4 ou des d\u00e9ploiements IPv6. La surveillance et les alertes doivent \u00eatre configur\u00e9es pour d\u00e9tecter les r\u00e9sultats Invalid, les origines inattendues, les autorisations supprim\u00e9es ou les variations de visibilit\u00e9 BGP. Crucialement, les organisations doivent \u00e9viter les autorisations trop larges : les ROA pr\u00e9cises restent plus faciles \u00e0 comprendre, plus simples \u00e0 auditer et bien moins susceptibles de permettre des annonces non intentionnelles.<\/p>\n\n\n\n

Foire aux questions<\/h2>\n\n\n\n

Un ROA est-il identique \u00e0 un document de propri\u00e9t\u00e9 d'adresse IP ?<\/strong> <\/p>\n\n\n\n

Non. Une ROA est une autorisation de routage indiquant quel ASN peut originer un pr\u00e9fixe dans BGP. Elle ne remplace pas les enregistrements du registre, les contrats, les documents de transfert ou les preuves de propri\u00e9t\u00e9 l\u00e9gale.<\/p>\n\n\n\n

Un pr\u00e9fixe peut-il avoir plusieurs ROA ?<\/strong> <\/p>\n\n\n\n

Oui. Plusieurs ROA peuvent \u00eatre appropri\u00e9es lorsqu\u2019un pr\u00e9fixe est intentionnellement originaire de plusieurs ASN ou lorsqu\u2019une migration contr\u00f4l\u00e9e n\u00e9cessite une autorisation temporaire pour plusieurs origines, bien que les enregistrements chevauchants doivent \u00eatre soigneusement document\u00e9s.<\/p>\n\n\n\n

Une annonce ROA publie-t-elle mon pr\u00e9fixe dans BGP ?<\/strong><\/p>\n\n\n\n

Non. La cr\u00e9ation d'un ROA ne g\u00e9n\u00e8re pas une annonce BGP ; le r\u00e9seau doit toujours configurer BGP via ses routeurs et ses fournisseurs en amont.<\/p>\n\n\n\n

Un fournisseur de transit doit-il \u00eatre r\u00e9pertori\u00e9 dans l'ROA ?<\/strong><\/p>\n\n\n\n

En g\u00e9n\u00e9ral, le ROA devrait identifier l'ASN qui est \u00e0 l'origine de la route. Un fournisseur qui ne fait que transporter la route n'est pas n\u00e9cessairement l'ASN d'origine, et la valeur correcte d\u00e9pend de l'architecture de routage r\u00e9elle.<\/p>\n\n\n\n

Combien de temps faut-il pour qu'un ROA devienne visible ?<\/strong> <\/p>\n\n\n\n

Le timing d\u00e9pend du syst\u00e8me RIR, du d\u00e9p\u00f4t de publication, des intervalles d'actualisation du validateur et de la mise en cache. Les mises \u00e0 jour sont souvent visibles relativement rapidement, mais les modifications de production doivent laisser suffisamment de temps pour la validation.<\/p>\n\n\n\n

Chaque pr\u00e9fixe IPv4 et IPv6 doit-il avoir un ROA ?<\/strong><\/p>\n\n\n\n

Il est fortement recommand\u00e9 de publier des ROAs exacts pour les pr\u00e9fixes annonc\u00e9s dans BGP. L'organisation doit d'abord confirmer sa conception de routage afin que l'autorisation ne rende pas accidentellement invalides les annonces l\u00e9gitimes.<\/p>\n\n\n\n

Une ROA peut-elle prot\u00e9ger contre toutes les attaques BGP ?<\/strong> <\/p>\n\n\n\n

Non. Un ROA prend principalement en charge la validation de l'origine. Il ne valide pas chaque partie du chemin BGP, n'emp\u00eache pas toutes les fuites de routes, ne chiffre pas le trafic et ne garantit pas que le trafic suit un itin\u00e9raire physique s\u00e9curis\u00e9.<\/p>\n\n\n\n

Une Autorisation d'Origine de Route (ROA) est un composant central du RPKI, \u00e9tablissant une relation cryptographiquement sign\u00e9e entre un pr\u00e9fixe IP et l'ASN autoris\u00e9 \u00e0 originer ce pr\u00e9fixe dans BGP. L'enregistrement comprend normalement le pr\u00e9fixe, l'ASN d'origine et une longueur maximale de pr\u00e9fixe \u2014 chacun jouant un r\u00f4le d\u00e9cisif dans l'identification de la ressource, l'autorisation de l'origine et la d\u00e9finition de la sp\u00e9cificit\u00e9 de l'annonce. Des ROAs pr\u00e9cises aident les r\u00e9seaux \u00e0 identifier les annonces non autoris\u00e9es ou mal configur\u00e9es, s'av\u00e9rant vitales lors des transferts IPv4, des changements d'ASN, des migrations de fournisseur, des d\u00e9ploiements IPv6 et des op\u00e9rations sur des r\u00e9seaux multi-hommes. En m\u00eame temps, une ROA n'est ni une preuve de propri\u00e9t\u00e9 l\u00e9gale ni une solution autonome de s\u00e9curit\u00e9 de routage ; elle fonctionne mieux en conjonction avec des registres pr\u00e9cis, des configurations BGP disciplin\u00e9es, des donn\u00e9es IRR, une surveillance des routes et des processus document\u00e9s de changement. Pour toute organisation annon\u00e7ant de l'espace public IPv4 ou IPv6, la r\u00e8gle pratique est simple : publier uniquement les origines que vous avez l'intention d'utiliser, autoriser uniquement les longueurs de pr\u00e9fixe que vous pr\u00e9voyez r\u00e9ellement d'annoncer, et examiner les enregistrements chaque fois que le r\u00e9seau change. Cela maintient les donn\u00e9es RPKI align\u00e9es avec l'environnement r\u00e9el de routage et r\u00e9duit la possibilit\u00e9 qu'une route l\u00e9gitime soit class\u00e9e comme Invalid.<\/p>","protected":false},"excerpt":{"rendered":"

A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and […]<\/p>\n","protected":false},"author":1,"featured_media":1104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is a ROA in RPKI? How Route Origin Authorization Works","_seopress_titles_desc":"Learn what a ROA is in RPKI, how it authorizes an ASN to announce an IPv4 or IPv6 prefix, why maxLength matters, and how to avoid common routing errors.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":2,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/media\/1104"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}