Number Resource Society
Utiliser le RPKI contre les annonces non autorisées
Un guide pratique pour comprendre les vulnérabilités du BGP, créer des ROA, déployer la validation d’origine, surveiller les résultats et prévoir un retour arrière.
Sur cette page
Faire de l’autorisation cryptographique un contrôle opérationnel
Ce guide s’adresse aux détenteurs de ressources et aux opérateurs de réseaux. Il reprend le parcours de l’article original tout en séparant les données historiques des vérifications nécessaires avant une modification de production.
Le RPKI n’est pas une promesse de sécurité automatique. Sa valeur vient d’une autorisation explicite, d’une validation observable et d’une responsabilité claire à chaque étape.
Commencer par les faiblesses du BGP
Le BGP ne possède pas d’autorisation cryptographique native. Une annonce incorrecte peut détourner le trafic, provoquer un trou noir ou se propager au-delà de la relation prévue.
Le RPKI ne résout pas tout le BGP, mais il donne une base vérifiable pour décider quel AS peut être l’origine d’un préfixe.
Comment fonctionne le RPKI
Le détenteur crée une ROA signée qui associe un préfixe, un AS et éventuellement une longueur maximale. Les parties de confiance valident ces objets, produisent des VRP et les transmettent aux routeurs.
La chaîne dépend des certificats, des dépôts, des validateurs, du protocole RTR et de la politique locale. Une panne à l’un de ces niveaux doit être visible.
Réduire l’impact des annonces non autorisées
Un préfixe sans VRP couvrant reçoit l’état NotFound. Il est Invalid si un VRP le couvre mais qu’aucun ne correspond à son AS d’origine et à sa longueur ; il est Valid dès qu’un VRP correspond. Le filtrage des Invalid réduit la propagation des détournements d’origine. Le ROV ne vérifie pas tout le chemin AS et ne détecte donc pas toutes les fuites de routes.
NotFound reste un état réel pendant le déploiement. Il ne signifie ni valide ni malveillant et doit avoir une règle opérationnelle propre.
Créer des ROA
Inventoriez les préfixes et leurs véritables AS d’origine, puis utilisez le portail du registre concerné. Une mauvaise origine ou une longueur maximale mal choisie peut interrompre une annonce légitime.
Les modèles hébergés simplifient la gestion ; les modèles délégués offrent plus de contrôle. Dans les deux cas, gardez les validations, les changements et les révocations traçables.
Déployer la validation d’origine
Un validateur comme Routinator ou rpki-client fournit les résultats aux routeurs via RTR. Commencez en observation, contrôlez les résultats, puis appliquez progressivement le filtrage des Invalid.
Prévoyez plusieurs validateurs, une surveillance et une procédure lorsque le dépôt, le validateur ou RTR devient indisponible. La possibilité de revenir en arrière fait partie du contrôle.
Bonnes pratiques
Maintenez l’inventaire des préfixes, AS et ROA. Révisez les longueurs maximales, testez les changements et intégrez les résultats dans l’astreinte et la réponse aux incidents.
Une mise en œuvre par étapes, des validateurs redondants et une règle claire pour NotFound réduisent les surprises opérationnelles.
Réduire la portée réelle d’un incident
Quand une ROA correcte existe et qu’un réseau applique ROV, une origine non autorisée est plus facilement détectée et rejetée. Le contrôle n’agit toutefois que sur les réseaux qui le mettent en œuvre.
Il faut donc distinguer couverture des ressources, validation par les réseaux et résultats d’incident. Les chiffres historiques de l’article doivent être vérifiés avec des données actuelles.
Les difficultés qui restent
La couverture partielle, la disponibilité des dépôts, les logiciels et la maintenance des équipes peuvent créer des lacunes. Une ROA ancienne peut produire une erreur active, pas seulement une absence de protection.
Attribuez clairement la responsabilité, la revue et la décision de pause ou de retour arrière. Le RPKI doit faire partie de la gouvernance des actifs et du changement.
La suite de la sécurité du routage
Le RPKI progresse et des mécanismes comme ASPA explorent la validation des chemins. Ils complètent l’origine sans supprimer les responsabilités humaines et organisationnelles.
La direction utile reste une autorisation vérifiable, un fonctionnement transparent et une gouvernance remplaçable, plutôt qu’un outil présenté comme une réponse totale.
Questions fréquentes
Qu’est-ce qu’une ROA ?
C’est un objet signé qui autorise un AS à annoncer un préfixe. Elle aide les réseaux qui valident l’origine à repérer une annonce non autorisée.
Quelle différence avec l’IRR ?
L’IRR décrit des politiques de routage ; le RPKI vérifie une autorisation d’origine. Ils sont complémentaires.
Le déploiement est-il risqué ?
Un passage direct au filtrage strict peut l’être. L’observation, la redondance, les tests et un déploiement progressif rendent le changement contrôlable.
Le RPKI bloque-t-il tous les détournements ?
Non. Il traite surtout l’origine ; les chemins, les erreurs de politique et les ressources non couvertes exigent d’autres mesures.
Comment vérifier mon état RPKI ?
Utilisez le portail du registre, un validateur et un outil de mesure de routage, puis comparez la couverture et l’état Valid/Invalid/NotFound à l’heure d’observation.
Note éditoriale : une mesure doit être datée
Publié le 25 décembre 2025 et mis à jour le 15 juillet 2026. Les pourcentages, incidents et citations sont conservés comme affirmations historiques ; avant une décision de production, utilisez les données actuelles du registre et de votre réseau.
Relier le guide à une responsabilité réelle
Commencez par votre inventaire et vos annonces. NRS Shield peut aider à comprendre le risque ; une représentation dans une élection ou une affaire de politique exige une procuration séparée, avec portée, durée et révocation explicites.