Résumé

  • Un message de suivi sur la liste de routage indique que Ben Cartwright-Cox a été le premier à utiliser la nouvelle API de RIPE NCC pour publier un certificat de clé de routeur BGPsec. Le dépôt RIPE contient un certificat émis le 22 octobre pour l’AS212232.
  • Le RFC 8634 prévoit cinq étapes : publier le certificat de remplacement, laisser les caches RPKI le récupérer, basculer le routeur et rafraîchir les UPDATE, révoquer éventuellement l’ancien certificat, puis retirer l’ancienne clé à l’expiration de sa validation.

Le premier certificat a quitté le guichet

BGPsec n’est plus seulement une annonce de fonctionnalité : il existe désormais un fichier qu’un opérateur peut examiner. Le 22 octobre, RIPE NCC a annoncé que son API RPKI pouvait créer et gérer les certificats de routeur BGPsec. Quelques heures plus tard, un message sur la même liste de routage félicitait Ben Cartwright-Cox d’avoir utilisé l’API pour en publier le premier. Le dépôt public de RIPE contient un certificat de routeur BGPsec émis ce jour-là pour l’AS212232. Objet modeste, prochaine étape délicate : changer la clé d’un routeur en service sans faire disparaître le chemin signé.

Le certificat dit exactement ce qu’il fait. Son usage étendu est « BGPsec Router », son usage de clé est la signature numérique et la ressource AS correspond à 212232. Il a été émis à 14 h 43 min 46 s UTC le 22 octobre et expire le 1er juillet 2027. Un certificat représente la moitié publique de l’accord : les systèmes qui s’y fient peuvent associer un ASN autorisé à une clé publique. Le routeur conserve la clé privée correspondante. L’API de RIPE NCC reçoit une demande de certification PKCS#10 ; elle ne demande pas à l’opérateur de lui transmettre cette clé privée.

La documentation publique décrit le cycle de gestion : créer une clé de routeur, lister celles associées à une autorité de certification, en récupérer une, la révoquer, puis obtenir le certificat ou sa chaîne d’émission. L’accès utilise une clé API créée par LIR avec le droit Resource Certification (RPKI) API. La demande contient un ASN, un identifiant BGP nommé routerId et un CSR ; l’autorité de certification attribue l’identifiant de la clé de routeur. La frontière de garde est nette : l’opérateur garde le secret de signature ; l’AC émet et publie le certificat.

Cette frontière rend le premier certificat plus intéressant qu’une note de version. Les signatures BGPsec suivent le chemin AS dans un message BGP UPDATE. Elles ne répondent pas à la même question qu’une ROA ou la validation d’origine, qui vérifie si un AS peut créer un préfixe, ni qu’ASPA, qui décrit les relations de fournisseur et aide à repérer les fuites de routes. Le certificat autorise une clé pour BGPsec. Il faut encore que les routeurs et les pairs signent et valident le chemin.

La rotation se joue au calendrier

Le RFC 8634 découpe la rotation en cinq étapes. Publier le nouveau certificat ; laisser les caches RPKI du monde entier le récupérer ; basculer le routeur sur la nouvelle clé et rafraîchir les UPDATE BGPsec sortants ; révoquer éventuellement l’ancien certificat si les messages signés avec l’ancienne clé doivent être invalidés ; puis, à l’expiration de sa validation, signaler son retrait aux routeurs via le protocole RPKI-Router, qui suppriment les routes signées avec cette clé. Le délai de diffusion évite d’envoyer aux pairs une signature dont ils ne possèdent pas encore la clé publique correspondante.

L’API simplifie les appels ; elle ne raccourcit pas le temps de propagation. Un bon journal de changement relierait le certificat de remplacement à sa publication, sa visibilité dans les caches, au basculement du routeur, aux UPDATE rafraîchis et à toute révocation facultative. Le retrait final intervient à l’expiration de la validation de l’ancien certificat. Un script qui saute de « créer » à « révoquer » serait remarquablement efficace pour fabriquer une panne.

RIPE NCC indique que le support BGPsec des routeurs matériels tarde et cite le déploiement progressif et les performances parmi les difficultés. Le RFC 8207 relève que certains routeurs peuvent nécessiter davantage de mémoire ou des processeurs plus récents ; un déploiement partiel forme des îlots de chemins signés. Ces limites entrent dans le plan de rotation : l’opérateur doit savoir quels routeurs de bord signent, quels pairs vérifient et où la chaîne signée s’interrompt.

La documentation API publique renvoie toujours au pilote RPKI de localcert.ripe.net ; le dépôt contient le certificat AS212232 émis le 22 octobre. Le dossier public de RIPE attend encore une trace datée de rotation reliant l’empreinte et l’heure de publication du certificat au basculement d’un routeur, à un UPDATE signé renouvelé et à la validation par des pairs BGPsec nommés ; cette trace montrerait jusqu’où l’API a porté BGPsec dans le routage réel.

Sources : annonce et premier usage sur la liste de routage RIPE, 22 octobre 2026 ; certificat brut du routeur dans le dépôt RIPE ; documentation API BGPsec de RIPE NCC ; IETF RFC 8209 ; IETF RFC 8205 ; IETF RFC 8207 ; IETF RFC 8634.