RPKI et ROA expliqués : comment l’autorisation d’origine de routage protège vos préfixes IPv4

RPKI et ROA : comment protéger les préfixes IP et sécuriser le routage

La RPKI (Resource Public Key Infrastructure, ou infrastructure à clés publiques pour les ressources) est un cadre de sécurité qui permet aux détenteurs d’adresses IP de publier des déclarations signées cryptographiquement indiquant qui est autorisé à annoncer leur espace d’adressage dans BGP. Une ROA (Route Origin Authorization, ou autorisation d’origine de route) est cette déclaration signée : elle indique le préfixe, l’ASN autorisé à en être l’origine et le niveau de précision maximal de l’annonce. Ensemble, ces mécanismes permettent aux routeurs du monde entier de rejeter les fausses annonces concernant vos préfixes avant même que le trafic ne soit acheminé.

Sommaire

Cette protection n’est plus facultative. Un nombre croissant de grands réseaux appliquent désormais la validation de l’origine des routes et rejettent les annonces qui contredisent une ROA publiée. La RPKI est donc à double tranchant. Une ROA correcte est l’enregistrement le plus efficace que vous puissiez publier pour protéger un préfixe contre les détournements reposant sur la falsification de l’origine, décrits dans notre guide sur le détournement BGP. Une ROA incorrecte est pire que l’absence de ROA : elle rend votre propre annonce légitime Invalid sur tous les réseaux qui appliquent la validation, provoquant une panne diffuse et difficile à diagnostiquer.

Une question de contrôle se pose également pour toute personne qui loue ou acquiert un espace d’adressage. Seul le détenteur enregistré d’un préfixe peut créer une ROA pour celui-ci. Le locataire ne peut pas la publier lui-même : toute sa protection RPKI dépend de la coopération du détenteur. La gestion des ROA doit donc être définie par écrit dans le contrat de location, plutôt que traitée ultérieurement comme un simple détail technique. Cet article explique ce que sont la RPKI et les ROA, le fonctionnement de la validation, la manière de configurer correctement les paramètres, les erreurs qui compromettent l’accessibilité, ainsi que les points précis à vérifier avant de louer ou d’acheter un espace IPv4.

Qu’est-ce que la RPKI ?

La RPKI est une infrastructure à clés publiques destinée aux ressources de numérotation Internet. Elle permet aux détenteurs d’espaces d’adressage IP et d’ASN de prouver cryptographiquement leurs autorisations, afin que les décisions de routage reposent sur des enregistrements vérifiables plutôt que sur la seule confiance.

Elle fonctionne comme une hiérarchie de certificats qui reflète la manière dont les adresses sont attribuées. Les registres Internet régionaux — RIPE NCC, ARIN, APNIC, LACNIC et AFRINIC — délivrent des certificats de ressources aux organisations qui détiennent des espaces d’adressage. Ces certificats attestent les préfixes contrôlés par chaque détenteur. Celui-ci peut ensuite utiliser son certificat pour signer des déclarations concernant ses propres ressources, notamment des ROA. N’importe quel réseau sur Internet peut récupérer ces objets signés, vérifier leur signature à partir de la hiérarchie du RIR et se fier au résultat, car l’autorisation est garantie par la cryptographie et non par la seule parole de l’annonceur.

Le changement fondamental introduit par la RPKI mérite d’être formulé clairement. Comme nous l’expliquons dans notre guide sur le fonctionnement de BGP, le protocole de routage de base accepte les annonces sur la confiance. La RPKI ajoute une couche de preuve : elle permet au détenteur légitime de publier une déclaration vérifiable automatiquement au sujet de son espace d’adressage, que les routeurs du monde entier peuvent contrôler. Elle ne remplace pas BGP ; elle lui fournit une référence à partir de laquelle valider les annonces.

Qu’est-ce qu’une ROA ?

Une ROA est un enregistrement signé cryptographiquement indiquant qu’un ASN précis est autorisé à être à l’origine d’un préfixe donné, jusqu’à une longueur maximale définie. Il s’agit de l’objet central de la RPKI, celui que vous créez concrètement pour protéger un préfixe. Chaque ROA contient trois informations ayant chacune une conséquence opérationnelle directe :

Le préfixe. Il s’agit du bloc d’adresses couvert par l’autorisation, par exemple 203.0.113.0/24. Le signataire doit réellement détenir ce préfixe, ce que garantit le certificat délivré par le RIR.

L’ASN d’origine. Il s’agit du numéro de système autonome autorisé à annoncer le préfixe dans BGP. Toute annonce du préfixe provenant d’un autre ASN devient RPKI-Invalid.

La longueur maximale (maxLength). Elle définit la taille de préfixe la plus spécifique autorisée. Une ROA couvrant 203.0.113.0/24 avec une maxLength de /24 n’autorise que ce /24 précis. Si la maxLength est définie sur /25, elle autorise également les deux /25 qu’il contient. Ce champ détermine quelles annonces plus spécifiques sont valides, et c’est le paramètre que les opérateurs configurent le plus souvent de manière incorrecte.

Une propriété des ROA constitue la clé technique permettant la location d’adresses IP et mérite d’être comprise précisément : le préfixe figurant dans une ROA doit être détenu par son signataire, mais l’ASN d’origine qui y est désigné ne doit pas nécessairement lui appartenir. Un détenteur peut publier une ROA autorisant l’ASN d’un tiers — celui d’un locataire ou de son fournisseur en amont — à être à l’origine de son préfixe. C’est précisément ce mécanisme qui permet à un espace d’adressage loué d’être annoncé légitimement depuis l’infrastructure de routage du locataire : le détenteur signe l’autorisation, mais celle-ci désigne l’annonceur. Sans ce principe, un espace loué ne pourrait jamais réussir la validation de l’origine. Grâce à lui, un préfixe loué peut bénéficier de la même protection RPKI qu’un espace détenu en propre, à condition que le détenteur publie effectivement la bonne ROA.

Comment fonctionne la validation de l’origine des routes (ROV)

La validation de l’origine des routes est l’action que les réseaux effectuent à partir des ROA. Leurs routeurs comparent chaque annonce BGP aux données ROA publiées, lui attribuent l’état Valid, Invalid ou NotFound, puis décident du traitement à appliquer.

Le mécanisme comporte deux volets, tous deux indispensables à la protection offerte par la RPKI. Premièrement, les détenteurs créent des ROA. Deuxièmement, les réseaux déploient des validateurs qui récupèrent toutes les ROA publiées, les vérifient à partir de la hiérarchie des RIR, puis transmettent les autorisations obtenues aux routeurs. Ceux-ci évaluent alors chaque annonce reçue. Trois résultats sont possibles :

Comment fonctionne la validation de l’origine des routes (ROV)

État

Signification

Traitement habituel sur un réseau appliquant la validation

Valid

Une ROA existe pour le préfixe, et l’ASN d’origine ainsi que la spécificité de l’annonce lui correspondent

Acceptation normale

Invalid

Une ROA existe, mais l’ASN d’origine est incorrect ou l’annonce est plus spécifique que ne le permet maxLength

Rejet et abandon de la route

NotFound

Aucune ROA ne couvre le préfixe

Acceptation sans protection RPKI, conformément au fonctionnement historique

Deux points doivent être soulignés. Premièrement, Invalid entraîne un rejet actif, et non un simple avertissement. Sur les réseaux qui appliquent la ROV, une annonce Invalid est ignorée comme si elle n’existait pas. C’est exactement ainsi que la RPKI empêche un pirate d’annoncer votre préfixe depuis son propre ASN, mais aussi de cette manière qu’une ROA mal configurée rend votre propre route légitime inaccessible.

Deuxièmement, l’application de la validation n’est pas universelle. La publication d’une ROA ne garantit pas que tous les réseaux rejetteront les annonces Invalid relatives à votre espace, mais seulement que les réseaux appliquant la ROV le feront. La couverture a considérablement progressé et comprend de nombreux opérateurs majeurs, mais elle reste partielle. Une ROA fait passer la probabilité qu’une falsification soit rejetée sur Internet de « rarement » à « généralement », sans rendre ce rejet universel. Cette couverture partielle, mais déjà importante, constitue le cadre réaliste dans lequel il faut comprendre la RPKI.

Ce que la RPKI protège — et ce qu’elle ne protège pas

La RPKI valide l’origine d’une route, pas son chemin, et ne couvre pas tous les problèmes susceptibles d’affecter le routage. Comprendre cette limite permet d’éviter aussi bien de sous-utiliser cette protection que de lui accorder une confiance excessive.

Les ROA et la ROV traitent efficacement le détournement le plus courant : un ASN non autorisé annonce votre préfixe, ou un sous-préfixe plus spécifique, en prétendant en être l’origine. Les réseaux qui effectuent la validation constatent que l’origine ne correspond pas à l’autorisation et rejettent l’annonce. Il s’agit de la catégorie la plus répandue d’incidents de routage, et la validation de l’origine est la protection la plus largement déployée contre ce risque. C’est pourquoi il est utile de publier des ROA, même si elles ne constituent pas une solution complète.

La RPKI présente toutefois plusieurs limites :

Elle ne valide pas le chemin AS. La RPKI vérifie qui prétend être à l’origine d’une route, mais pas la suite de réseaux que l’annonce prétend avoir traversée. Un attaquant expérimenté peut fabriquer un chemin qui se termine par votre ASN d’origine légitime et ainsi réussir la validation de l’origine. Des mécanismes d’autorisation de chemin, tels qu’ASPA, cherchent à résoudre ce problème ainsi que les fuites de routes associées, mais leur adoption n’en est qu’à ses débuts. Une analyse indépendante publiée en 2026 a directement souligné cette lacune : même avec une couverture de l’origine à un niveau record, des catégories entières d’attaques, notamment certains détournements à origine falsifiée et certaines fuites de routes, peuvent traverser la validation de l’origine.

Elle ne chiffre rien. Il s’agit d’une confusion fréquente. La RPKI est un cadre d’autorisation pour les annonces de routage et n’assure aucunement le chiffrement du trafic. La confidentialité est fournie séparément par TLS et d’autres protocoles comparables.

Elle ne remplace pas les objets de route IRR ni les LOA. Ces enregistrements remplissent des fonctions qui se recoupent en partie, mais restent distinctes. De nombreux fournisseurs construisent encore leurs filtres à partir des données IRR, tandis que les lettres d’autorisation continuent d’intervenir dans l’approbation opérationnelle des annonces. Un préfixe a généralement besoin de trois enregistrements cohérents : une ROA, un objet de route et une LOA. La RPKI ne remplace pas les deux autres. Nous consacrons un guide distinct aux LOA.

La bonne démarche consiste à publier des ROA pour contrer l’attaque la plus courante, tout en maintenant les objets IRR à jour, en choisissant des fournisseurs en amont qui appliquent des filtres et en surveillant les incidents qui échappent à ces contrôles. C’est l’approche par couches présentée dans notre section consacrée à la prévention des détournements BGP.

RPKI hébergée ou RPKI déléguée

La RPKI peut être exploitée de deux manières. Dans le modèle hébergé, le RIR administre l’autorité de certification et signe les ROA pour votre compte au moyen d’un portail Web. Dans le modèle délégué, vous exploitez votre propre infrastructure d’autorité de certification. Le choix dépend principalement de l’échelle et du niveau de contrôle recherché.

RPKI hébergée ou RPKI déléguée

Aspect

RPKI hébergée

RPKI déléguée

Entité exploitant l’autorité de certification

Le RIR

Votre organisation

Création des ROA

Depuis le portail ou l’API du RIR

Au moyen de votre propre logiciel d’autorité de certification et de votre propre dépôt

Charge opérationnelle

Faible : le RIR gère les clés, les signatures et la publication

Élevée : vous gérez l’infrastructure, les clés et la disponibilité

Solution adaptée à

La grande majorité des détenteurs, notamment les entreprises et les bailleurs

Les très grands opérateurs et les plateformes qui gèrent de nombreuses ROA ou ont besoin d’automatisation

Pour la plupart des organisations, la RPKI hébergée est le choix approprié. Elle évite d’avoir à exploiter une infrastructure de certification tout en offrant l’ensemble des avantages de la RPKI. La RPKI déléguée concerne surtout les grands réseaux et les plateformes, notamment certains opérateurs de location IPv4, qui gèrent des autorisations pour de nombreux préfixes et ont besoin de procédures automatisées de création et de révocation. Elles peuvent ainsi autoriser rapidement l’ASN d’un locataire au début du contrat, puis révoquer proprement l’autorisation à son terme. Pour le client, le modèle utilisé par le bailleur compte moins que la rapidité et la fiabilité avec lesquelles il traite les ROA.

Bien configurer maxLength

maxLength doit correspondre au préfixe le plus spécifique que vous prévoyez réellement d’annoncer, sans être plus large ni plus restrictif. Ce champ provoque plus de problèmes RPKI dus aux opérateurs que tout autre paramètre, dans les deux sens :

Une valeur trop restrictive bloque vos propres annonces. Si la ROA d’un /22 définit maxLength sur /22, mais que vous devez annoncer un /24 inclus dans ce bloc — pour l’ingénierie du trafic, un service précis ou une contre-annonce d’urgence destinée à récupérer le trafic pendant un détournement — ce /24 est plus spécifique que ne l’autorise la ROA. Il est donc évalué comme Invalid et rejeté par les réseaux qui appliquent la validation. Vous vous êtes bloqué vous-même. Cela limite directement la tactique décrite dans notre guide sur les détournements BGP : la contre-annonce de préfixes plus spécifiques ne fonctionne que si la maxLength de votre ROA les autorise.

Une valeur trop permissive aide les pirates. Si la ROA d’un /22 définit maxLength sur /24 alors que vous n’annoncez que le /22, vous avez préautorisé l’ASN désigné dans la ROA à annoncer des /23 et des /24 plus spécifiques. Vous avez surtout élargi inutilement ce qui peut être considéré comme Valid dans votre espace. La bonne pratique de sécurité consiste à autoriser exactement la spécificité que vous annoncez. Toute annonce plus spécifique que vous n’avez pas prévue apparaîtra alors comme Invalid au lieu de se confondre avec les annonces Valid.

La règle permettant d’éviter ces deux erreurs consiste à répertorier toutes les longueurs de préfixe que vous annoncez ou prévoyez d’annoncer, puis à définir maxLength ou à créer des ROA supplémentaires couvrant précisément ces longueurs. Si vous annoncez un /22 et, occasionnellement, un /24 précis à l’intérieur de celui-ci, vos données ROA doivent autoriser délibérément ce /22 et ce /24. Cette configuration doit résulter d’une décision documentée, pas d’une plage trop large choisie par facilité.

Erreurs RPKI courantes qui compromettent l’accessibilité

Les incidents RPKI les plus dommageables ne sont pas toujours des détournements. Ils proviennent souvent d’opérateurs qui rendent leurs propres routes légitimes Invalid. Comme ces routes sont rejetées par les réseaux appliquant la validation, ces erreurs provoquent un symptôme déroutant : une inaccessibilité partielle qui ressemble à une panne classique. Vos serveurs fonctionnent, vos routeurs locaux annoncent toujours le préfixe et un fournisseur de transit voit encore la route, mais un autre réseau la rejette. Vous restez accessible depuis une partie d’Internet et devenez invisible pour le reste. Les causes habituelles sont les suivantes :

La ROA désigne toujours l’ancien ASN après un changement de fournisseur ou d’annonce. Vous migrez vers un nouveau fournisseur en amont ou commencez à annoncer depuis un autre ASN, mais la ROA autorise encore l’ancien. Tous les réseaux appliquant la validation rejettent alors votre annonce légitime. Il s’agit de la cause la plus fréquente d’Invalid accidentels. Le risque est particulièrement élevé avec les espaces loués, car la ROA et l’annonce sont contrôlées par deux parties différentes.

maxLength ne couvre pas une annonce. Une route plus spécifique que vous annoncez légitimement est rejetée parce que la ROA n’autorise pas cette longueur.

Un préfixe est oublié. Vous publiez des ROA pour la majorité de votre espace, mais oubliez un bloc, qui reste alors NotFound et sans protection. Vous pouvez également annoncer un préfixe non couvert alors que les préfixes voisins le sont, créant une incohérence.

Les échéances et renouvellements ne sont pas suivis. Les ROA et les certificats sur lesquels elles reposent ont des périodes de validité. Si une ROA expire ou si un certificat n’est pas renouvelé, la protection disparaît et l’état de la route peut changer. Selon la configuration, elle peut devenir Invalid ou revenir à NotFound. La RPKI hébergée automatise une grande partie de ce processus, mais la responsabilité de maintenir les enregistrements à jour demeure.

Une ROA est supprimée ou révoquée alors que le préfixe est toujours annoncé. La suppression d’une ROA couvrant un préfixe actif le fait passer de Valid à NotFound, ce qui supprime sa protection. Si une ROA conflictuelle subsiste, il peut passer à Invalid et perdre son accessibilité. Les modifications apportées aux ROA de préfixes en production doivent suivre la même discipline de gestion du changement que toute autre modification de routage.

Un constat rassurant ne doit pas conduire à relâcher cette vigilance : des études menées en 2026 ont conclu que la grande majorité des préfixes RPKI-Invalid observés dans le monde résultaient d’erreurs de configuration plutôt que d’attaques. Leur trafic emprunte souvent des routes moins spécifiques ou des réseaux n’appliquant pas la validation, ce qui limite parfois les dommages. Mais des dommages « souvent limités » ne signifient pas une absence de risque. Une entreprise dont un service devient inaccessible depuis un opérateur majeur à cause d’une ROA obsolète subit une véritable panne, quelles que soient les statistiques globales.

RPKI pour les espaces IPv4 loués

Pour un espace d’adressage loué, le fait déterminant est que seul le détenteur enregistré peut publier la ROA. La protection RPKI du locataire dépend donc entièrement des conditions de location. Le locataire annonce le préfixe depuis son ASN ou celui de son fournisseur en amont, tandis que le détenteur doit publier une ROA autorisant cet ASN. Aucun des deux ne peut agir seul, et chaque partie ne contrôle qu’une moitié du processus.

C’est précisément pour cette raison que la possibilité de désigner n’importe quel ASN dans une ROA joue un rôle pratique essentiel : elle permet au détenteur d’autoriser légitimement l’ASN du locataire. Mais ce mécanisme n’est utile que si le détenteur l’emploie correctement, rapidement et pendant toute la durée de la location. Plusieurs éléments doivent donc être confirmés par écrit avant tout engagement :

Autorité et engagement explicites concernant la ROA. Le contrat oblige-t-il le détenteur à publier une ROA désignant votre ASN d’origine, ou celui de votre fournisseur en amont, pour le préfixe loué ? Une ambiguïté sur ce point peut transformer une route censée être Valid en route Invalid dès le premier jour.

Délai de traitement garanti. Dans quel délai le détenteur créera-t-il, modifiera-t-il ou révoquera-t-il les ROA, aussi bien pour les changements courants qu’en cas d’urgence ? Un changement de fournisseur ou une réponse à un détournement qui attend plusieurs jours la mise à jour d’une ROA constitue déjà un incident d’accessibilité. Des engagements clairs — un délai défini pour les demandes courantes et plus court en cas d’urgence — distinguent une location adaptée à la production d’une location qui ne fonctionne que tant que rien ne change.

Accord sur maxLength. Quelles longueurs de préfixe la ROA autorisera-t-elle ? Elles doivent correspondre à ce que vous prévoyez d’annoncer, y compris les préfixes plus spécifiques utilisés pour l’ingénierie du trafic ou la réponse à un détournement. La discipline relative à maxLength doit être négociée entre les parties.

Cycle de vie au début, pendant et à la fin de la location. La ROA doit être créée et vérifiée avant le début des annonces afin d’éviter une période NotFound. Elle doit être correctement mise à jour en cas de changement d’ASN ou d’annonce, puis révoquée de manière appropriée à la fin de la location afin que l’espace revienne au détenteur dans un état propre. Les opérations de location matures automatisent ce cycle de vie, tandis que les accords informels le laissent souvent indéfini.

Une organisation structurée est conçue pour gérer ces points de coordination. Une plateforme de location IPv4 administrée doit considérer la publication des ROA, les délais de traitement, maxLength et le cycle de vie comme des composantes définies du service. Sur un espace loué, le locataire ne peut pas obtenir seul une protection RPKI, quelle que soit la compétence de son équipe réseau. La même coordination s’applique à l’acquisition : lorsque vous achetez des adresses IPv4, la publication de ROA correctes sous votre propre contrôle doit faire partie du transfert, au même titre que le routage et le DNS inverse. L’espace est ainsi protégé dès son arrivée au lieu de rester NotFound.

Pourquoi la RPKI n’est plus facultative

La RPKI est passée d’une pratique de sécurité spécialisée à une composante courante de l’exploitation d’Internet, et la tendance ne va que dans une direction. À la mi-2026, le rapport d’adoption de Hurricane Electric estimait qu’environ 67 % des préfixes routés étaient couverts par une ROA signée, avec une couverture IPv6 supérieure à celle d’IPv4. Deux ans plus tôt seulement, le franchissement du seuil de 50 % pour IPv4 avait été célébré comme une étape majeure. Depuis, la progression s’est poursuivie régulièrement.

Deux évolutions survenues en 2026 illustrent cet élan. Le registre national chinois est passé d’une couverture négligeable à une couverture de la grande majorité des routes du pays en quelques semaines. Des analyses ont également montré que la part du trafic Internet destiné à des routes RPKI-Valid est nettement supérieure à la part des routes couvertes, car les grands réseaux à fort trafic sont davantage susceptibles de signer leurs routes et d’appliquer la validation. En pratique, une proportion croissante d’Internet rejettera silencieusement toute annonce Invalid concernant votre espace, qu’il s’agisse de la falsification d’un pirate ou de votre propre ROA obsolète. Ces deux effets s’intensifient à mesure que l’adoption progresse.

Les attentes des fournisseurs et des autorités évoluent dans la même direction. Les grands fournisseurs de transit appliquent de plus en plus souvent la ROV par défaut, les initiatives de sécurité du routage considèrent la publication de ROA comme une pratique fondamentale, et certaines autorités encouragent désormais les fournisseurs à adopter des protections reposant sur la RPKI. Pour une entreprise exploitant un espace IPv4 public, la question n’est plus « devons-nous publier des ROA ? », mais « nos ROA sont-elles exactes et à jour ? ». Sur un Internet qui applique la validation, l’absence de ROA vous laisse exposé, tandis qu’une ROA incorrecte peut vous rendre inaccessible.

Listes de contrôle pratiques

Si vous détenez vos propres préfixes

• Publiez des ROA pour chaque préfixe que vous annoncez, ainsi que pour les préfixes que vous détenez sans encore les annoncer, car les espaces inutilisés constituent aussi des cibles de détournement.
• Définissez maxLength de manière à correspondre exactement à la spécificité de vos annonces, y compris aux préfixes plus spécifiques prévus.
• Utilisez la RPKI hébergée, sauf si votre échelle ou vos besoins d’automatisation justifient précisément un modèle délégué.
• Maintenez les ROA en accord avec la réalité après chaque changement de fournisseur, d’ASN ou d’annonce.
• Surveillez l’état RPKI de vos préfixes afin de détecter un Invalid accidentel avant vos clients.
• Appliquez une procédure complète de gestion du changement à toute modification des ROA de préfixes en production.

Si vous louez vos préfixes

• Confirmez par écrit que le détenteur publiera une ROA désignant votre ASN d’origine pour le préfixe loué.
• Obtenez par écrit les délais de création, de modification et de révocation des ROA, pour les demandes courantes comme pour les urgences.
• Convenez d’une valeur maxLength couvrant toutes les longueurs de préfixe que vous prévoyez d’annoncer.
• Vérifiez que la ROA est publiée et Valid avant de commencer l’annonce afin d’éviter une période NotFound.
• Confirmez la procédure de mise à jour des ROA en cas de changement d’ASN ou de fournisseur en amont pendant la location.
• Confirmez la procédure de révocation des ROA à la fin de la location.

Note pratique de la part d’i.lease

La RPKI possède une asymétrie discrète qui surprend souvent les opérateurs : le même mécanisme qui protège un préfixe correctement configuré déconnecte activement un préfixe mal configuré. Publiez une ROA exacte, et une part importante et croissante d’Internet rejettera automatiquement les falsifications visant votre espace. Publiez une ROA incorrecte — un ancien ASN après un changement de fournisseur ou une maxLength qui exclut votre /24 — et cette même partie d’Internet vous rejettera. Le symptôme ressemblera davantage à une panne partielle inexplicable qu’à un problème d’enregistrement. La technologie exécute exactement ce qu’on lui demande, à l’échelle mondiale : c’est à la fois sa force et son piège.

Sur un espace loué, cette asymétrie traverse directement la relation contractuelle, car la personne qui annonce le préfixe et celle qui peut corriger la ROA sont différentes. Un locataire disposant d’un réseau parfaitement configuré peut malgré tout être Invalid sur une grande partie d’Internet parce qu’une ROA qu’il ne peut pas modifier désigne le mauvais ASN. Les questions à résoudre avant de signer ne sont donc pas seulement techniques : elles concernent l’autorité et la rapidité. Le détenteur publiera-t-il la ROA requise par votre configuration ? La mettra-t-il rapidement à jour lorsqu’un changement surviendra ? Que deviendra-t-elle à la fin de la location ? Une organisation structurée répond à ces questions par écrit et automatise le cycle de vie. Un accord informel laisse au locataire la responsabilité d’un enregistrement que seul un tiers peut créer. Quelle que soit votre manière de détenir un espace d’adressage, la RPKI récompense la même discipline que le reste de la sécurité du routage : des enregistrements exacts et à jour, maintenus par une partie disposant de l’autorité et de l’intérêt nécessaires.

Conclusion

La RPKI transforme l’autorisation de routage en faisant passer celle-ci d’une question de confiance à une question de preuve. Les RIR certifient qui détient quelles ressources, les détenteurs publient des ROA signées indiquant quel ASN peut être à l’origine de chaque préfixe et jusqu’à quel niveau de spécificité, puis les réseaux qui appliquent la validation rejettent les annonces qui ne correspondent pas. Une ROA est l’enregistrement le plus efficace qu’un préfixe puisse porter. Elle constitue la protection la plus largement déployée contre les détournements courants reposant sur la falsification de l’origine. Sur un Internet où la majorité de l’espace routé est désormais couverte et où la validation continue de progresser, publier des ROA exactes est devenu une règle élémentaire d’exploitation plutôt qu’une mesure de sécurité avancée.

La RPKI exige de la précision. La capacité qui lui permet de rejeter les fausses annonces lui permet également de rejeter les vôtres si l’ASN d’origine est incorrect ou si maxLength ne couvre pas votre route. Le travail consiste donc à maintenir les ROA exactes et à jour à chaque changement. Pour les espaces loués, cette responsabilité est partagée : seul le détenteur peut publier la ROA, le locataire annonce le préfixe, et la protection n’existe que si l’accord entre eux la rend possible. Comprenez la différence entre la validation de l’origine et celle du chemin, configurez correctement maxLength, alignez les enregistrements sur les annonces réelles et, en cas de location, inscrivez l’autorité, les délais et le cycle de vie des ROA dans le contrat avant la première annonce. La RPKI remplira alors son objectif : faire en sorte que les routeurs du monde entier protègent votre préfixe, que vous le déteniez ou le louiez.

Questions fréquentes

Que signifie RPKI ?

RPKI signifie Resource Public Key Infrastructure, ou infrastructure à clés publiques pour les ressources. Il s’agit d’un cadre cryptographique qui permet aux détenteurs d’adresses IP et d’ASN de publier des déclarations vérifiables indiquant qui est autorisé à annoncer leurs ressources dans BGP.

Qu’est-ce qu’une ROA dans le domaine des réseaux ?

Une ROA (Route Origin Authorization, ou autorisation d’origine de route) est un enregistrement signé cryptographiquement indiquant qu’un ASN précis est autorisé à être à l’origine d’un préfixe IP donné, jusqu’à une longueur maximale définie. Il s’agit de l’objet créé par les détenteurs dans la RPKI pour protéger un préfixe contre les annonces non autorisées.

Qui peut créer une ROA ?

Seul le détenteur enregistré d’un préfixe — la partie certifiée par le RIR comme contrôlant cet espace d’adressage — peut créer une ROA pour celui-ci. Un locataire ne peut pas publier lui-même une ROA pour un espace loué. Le détenteur doit le faire pour son compte, raison pour laquelle la gestion des ROA doit être confirmée par écrit dans le contrat de location.

La RPKI chiffre-t-elle mon trafic ?

Non. Il s’agit d’une confusion fréquente. La RPKI est un cadre d’autorisation pour les annonces de routage : elle contrôle qui peut annoncer vos préfixes, mais ne protège pas la confidentialité de vos données. Le chiffrement du trafic est assuré séparément par des protocoles comme TLS.

Qu’est-ce que maxLength dans une ROA ?

maxLength représente la longueur de préfixe la plus spécifique autorisée par une ROA. Une ROA couvrant un /22 avec une maxLength de /22 n’autorise que ce /22 précis. Si elle est définie sur /24, elle autorise également les /23 et /24 plus spécifiques. Elle doit correspondre exactement à la spécificité de vos annonces : une valeur trop restrictive bloque vos propres sous-préfixes, tandis qu’une valeur trop permissive élargit ce qu’un pirate pourrait annoncer avec un état Valid.

Que signifie l’état RPKI « Invalid » ?

Une annonce est RPKI-Invalid lorsqu’une ROA existe pour le préfixe, mais que l’ASN d’origine de l’annonce est incorrect ou que le préfixe annoncé est plus spécifique que ne le permet maxLength. Les réseaux appliquant la validation de l’origine rejettent les annonces Invalid. Cela bloque les détournements, mais peut aussi rendre votre propre route inaccessible si l’état Invalid résulte d’une ROA mal configurée.

La RPKI est-elle obligatoire ?

Elle n’est pas imposée partout, mais elle est désormais attendue dans les faits. En 2026, la majorité des préfixes routés disposent d’une ROA, de nombreux grands opérateurs rejettent les routes Invalid, et les attentes des fournisseurs comme des autorités continuent d’encourager une sécurité du routage fondée sur la RPKI. En pratique, la publication de ROA exactes constitue aujourd’hui une règle élémentaire d’exploitation.

Une ROA peut-elle désigner un ASN qui ne m’appartient pas ?

Oui, et cette possibilité est essentielle au fonctionnement de la location. Le préfixe d’une ROA doit appartenir au détenteur qui la signe, mais l’ASN d’origine autorisé ne doit pas nécessairement lui appartenir. Le détenteur peut ainsi publier une ROA autorisant l’ASN du locataire ou de son fournisseur en amont à annoncer légitimement son préfixe.

Qui crée les ROA pour les adresses IP louées ?

Le détenteur enregistré — le bailleur ou la partie qu’il désigne — crée la ROA en y indiquant l’ASN d’origine du locataire. Le locataire annonce le préfixe, mais ne peut pas publier lui-même la ROA. Le contrat doit explicitement engager le détenteur à publier et à maintenir la bonne ROA, avec des délais définis pour les modifications.

Que se passe-t-il si ma ROA expire ?

Les ROA et les certificats sur lesquels elles reposent ont des périodes de validité. Si une ROA expire ou si le renouvellement d’un certificat n’est pas effectué, le préfixe perd sa protection et son état RPKI peut changer. Il peut revenir à NotFound ou, si une ROA conflictuelle subsiste, devenir Invalid et être rejeté par les réseaux qui appliquent la validation. La RPKI hébergée automatise une grande partie du renouvellement, mais le maintien des enregistrements à jour reste la responsabilité du détenteur.

La RPKI remplace-t-elle une LOA ?

Non. Les ROA de la RPKI et les lettres d’autorisation remplissent des fonctions qui se recoupent, mais restent distinctes. De nombreux fournisseurs utilisent également des objets de route IRR. Un préfixe doit généralement disposer d’une ROA, d’un objet de route et d’une LOA cohérents. La RPKI renforce la sécurité du routage, mais ne remplace pas à elle seule les autres documents d’autorisation.

À lire également

• Qu’est-ce qu’un détournement BGP ? Fonctionnement des détournements de routes, incidents célèbres et méthodes de prévention
• Qu’est-ce que BGP ? Comment le protocole Border Gateway Protocol rend les services associés aux adresses IP accessibles
• Comment prévenir le détournement d’adresses IPv4 pendant un transfert : 10 mesures de sécurité
• Comment fonctionne l’atténuation des attaques DDoS : nettoyage du trafic, détournement BGP, Anycast et préparatifs nécessaires aux opérateurs réseau