La validation de l'origine des routes est le contrôle le moins coûteux qu'un opérateur puisse ajouter en périphérie d'internet, et elle est passée d'optionnelle à attendue. Ce guide montre comment elle fonctionne sur OcNOS et comment la configurer sur un routeur de peering, avec des commandes vérifiées sur OcNOS-SP.
Qu'est-ce que la validation de l'origine des routes RPKI ?
La Resource Public Key Infrastructure (RPKI) lie un préfixe IP au réseau autorisé à l'annoncer dans un enregistrement signé cryptographiquement appelé Route Origin Authorization (ROA). La Route Origin Validation (ROV) est l'action qu'un routeur effectue lorsqu'il compare une route BGP entrante à ces ROA et la marque valid, invalid ou not-found. Une route est valid lorsque l'AS d'origine et la longueur du préfixe correspondent à une ROA, invalid lorsqu'une ROA existe mais que l'origine ou la longueur sont incorrectes, et not-found lorsqu'aucune ROA ne couvre le préfixe. La ROV arrête l'accident et l'attaque de routage les plus courants en une seule étape : un réseau qui annonce un préfixe qu'il ne détient pas et qui envoie le trafic des autres opérateurs dans la mauvaise direction.
Pourquoi RPKI compte aujourd'hui
La validation de l'origine des routes n'est plus une option. Les grands fournisseurs de transit rejettent par défaut les routes RPKI-invalid, les régulateurs nationaux font référence à la sécurité du routage dans leurs directives, et les actions MANRS considèrent la validation d'origine et le filtrage de préfixes comme des prérequis pour un réseau sérieux. Pour un opérateur qui porte la table BGP complète d'internet en périphérie de peering, le ROV élimine toute une catégorie d'origines erronées avec très peu d'effort. Vous obtenez aussi une protection immédiate, car vous bénéficiez de chaque ROA déjà existante sans attendre le reste d'internet.
Comment OcNOS valide les routes
OcNOS ne conserve pas la base de données RPKI sur le routeur. Il se connecte à un validateur RPKI externe, aussi appelé cache RPKI-to-Router (RTR), qui récupère et vérifie cryptographiquement les ROA auprès des trust anchors et remet au routeur un ensemble propre d'enregistrements préfixe-vers-origine validés. OcNOS conserve cette table validée en mémoire, la rafraîchit selon une minuterie et marque les routes au fur et à mesure qu'il les reçoit. Vous pouvez pointer le routeur vers plusieurs validateurs pour la redondance. Tout validateur qui parle le protocole RTR fonctionne, y compris Routinator, rpki-client avec StayRTR et les déploiements Krill de NLnet Labs.
Comment configurer la validation de l'origine des routes RPKI sur OcNOS
La configuration comporte trois parties : connecter le routeur à un validateur, laisser la table validée se remplir et appliquer une politique qui agit sur le résultat. OcNOS est transactionnel, donc chaque étape est appliquée avec commit.
1. Connecter le routeur aux validateurs RPKI
Dans l'instance BGP, pointez le routeur vers un ou deux caches RTR. L'adresse seule constitue une commande complète, et port est facultatif et vaut 3323 par défaut pour TCP.
configure terminal
router bgp 64500
bgp rpki server 10.0.0.10 port 3323
bgp rpki server 10.0.0.11 port 3323
commit2. Faire correspondre l'état de validation et rejeter les routes invalid
Utilisez une route-map pour agir sur l'état RPKI. Celle-ci refuse les routes invalid et autorise tout le reste, de sorte que les routes valid et not-found sont acceptées tandis que les routes invalid sont rejetées.
route-map RPKI-EDGE-IN deny 10
match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
commit3. Appliquer la politique en entrée sur la session de peering
Attachez la route-map au peer eBGP dans l'address family qu'elle doit protéger. Répétez sous address-family ipv6 unicast pour IPv6.
router bgp 64500
address-family ipv4 unicast
neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
exit
commitComment vérifier que la validation RPKI fonctionne ?
Vérifiez que la session du validateur est active, que la table validée contient des entrées et que les routes sont marquées. OcNOS fournit trois commandes pour cela.
OcNOS# show bgp rpki server
OcNOS# show bgp rpki table
OcNOS# show bgp rpkishow bgp rpki server indique chaque validateur et si sa session est établie, show bgp rpki table répertorie les enregistrements préfixe-vers-origine validés que le routeur a téléchargés, et show bgp rpki résume l'état RPKI. Une fois la session établie et la table remplie, les routes qui échouent à la validation portent l'état invalid et sont rejetées par la route-map en périphérie.
RPKI en périphérie de peering
Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the routeur de cœur IP et de peering ouvert.