Résumé

  • RIPE NCC annonce que son API RPKI sait désormais créer et gérer des certificats de clés routeur BGPsec.
  • Le certificat autorise une clé associée à un ASN. Il ne fait ni signer les annonces par un routeur, ni valider leur chemin par un voisin.

BGPsec a longtemps eu un petit paradoxe administratif : la norme savait décrire le certificat d’une clé de routeur, mais l’opérateur devait encore faire entrer cette pièce dans le travail courant de la RPKI. RIPE NCC vient d’ajouter une voie par son API. La demande et la gestion du certificat passent dans un outil logiciel. Les routeurs, eux, ne se matérialisent toujours pas sur commande.

Dans sa mise à jour du 23 octobre, RIPE NCC annonce la création et la gestion de certificats de clés routeur BGPsec par l’API RPKI. La veille, Tim Bruijnzeels, ingénieur principal du RIPE NCC, expliquait à la liste Routing WG qu’un titulaire d’ASN peut autoriser une clé à signer des annonces BGP. La documentation technique publique situe l’API BGPsec dans l’environnement pilote RPKI, à localcert.ripe.net, et décrit la création des objets de clé ainsi que la récupération du certificat et de sa chaîne. Ces documents établissent une capacité de provisionnement ; ils ne donnent ni le nombre de membres déjà équipés en production ni l’accès d’un point d’entrée général à tous.

Le certificat a une fonction étroite et importante. RFC 8209 définit un certificat RPKI qui lie une clé publique à un ou plusieurs ASN. Le routeur conserve la clé privée correspondante et l’utilise, s’il sait parler BGPsec, pour signer le chemin lorsqu’il envoie une mise à jour BGPsec à un pair externe. Le routeur destinataire peut vérifier le chemin signé avec les certificats et signatures dont il dispose.

Ce mécanisme ne fait pas doublon avec les autres objets RPKI. Une ROA indique quel AS peut être à l’origine d’un préfixe ; une ASPA enregistre les fournisseurs qu’un AS autorise ; BGPsec transporte des signatures le long du chemin AS. Tim Bruijnzeels qualifie ces mécanismes de complémentaires. Le certificat de clé routeur est une pièce du système de signature, pas un nouveau nom pour la validation d’origine ou la détection des fuites de routes.

La phrase la plus utile du message du RIPE NCC n’est pas l’annonce. C’est le constat que la prise en charge par les routeurs matériels accuse du retard, tandis que le déploiement progressif et les performances restent difficiles. Une API retire de la friction à un endroit de la chaîne. Elle ne négocie pas une session BGPsec à la place du routeur, ne protège pas une clé privée dans un châssis, ne rend pas l’attribut signé intelligible pour le voisin et ne dicte pas la conduite à tenir quand le chemin signé manque.

La chaîne opérationnelle est simple à nommer : demander le certificat, protéger et installer la clé privée, activer BGPsec sur des routeurs et sessions compatibles, émettre des annonces signées, puis les faire valider par les routeurs en face. Chaque étape a son responsable. Une réponse positive de l’API prouve la première. Les sources publiques ne précisent pas encore l’adresse générale de production pour les membres ni les implémentations routeur ayant terminé les autres étapes. L’ingénieur du RIPE NCC signale lui-même le retard matériel : c’est le prochain fait attendu.

Pour les opérateurs, l’avancée est réelle. L’émission d’un certificat est une tâche de contrôle et l’API permet de l’automatiser avec le reste du travail RPKI. Le test convaincant reliera un certificat à un routeur donné, à une clé protégée, à un voisin sur session BGPsec et à une mise à jour effectivement validée. En attendant, l’API simplifie une partie du provisionnement. Elle ne signe pas le chemin à la place du routeur.

Sources : mise à jour du RIPE NCC, 23 octobre 2026 ; Tim Bruijnzeels, liste RIPE Routing WG, 22 octobre 2026 ; documentation API BGPsec du RIPE NCC ; RFC 8209 ; RFC 8205 ; RIPE-851, déclaration de pratiques de certification.