Résumé

  • Le RIPE NCC a introduit la création et la gestion de certificats de clé de routeur BGPsec dans son API RPKI.
  • La délivrance d’un certificat ouvre la voie ; la vérification des chemins exige encore des routeurs et des sessions BGPsec compatibles.

Le certificat peut être demandé. Le voisin qui saura le vérifier se fait attendre. Dans son annonce du 22 octobre, Tim Bruijnzeels, ingénieur RPKI au RIPE NCC, présente la prise en charge des clés de routeur BGPsec par API et reconnaît le retard des équipements, les difficultés de performance et celles d’un déploiement progressif. La lettre aux membres du 23 octobre relaie cette nouveauté. Il s’agit d’une capacité de délivrance, dont l’usage sur les chemins Internet reste à mesurer.

Le mécanisme attache une clé publique de routeur à un numéro de système autonome. Le profil fixé par la RFC 8209 autorise le détenteur de la clé privée correspondante à signer des annonces au nom de cet AS. Sur une session qui utilise BGPsec, un routeur compatible peut vérifier la chaîne des AS traversés. C’est le trajet annoncé qui est contrôlé ; la permission d’annoncer l’origine relève des ROA, et les relations de fournisseur d’ASPA. Confondre ces fonctions donnerait au nouveau certificat des pouvoirs qu’il n’a pas.

Le mode d’emploi publié par le RIPE NCC détaille l’autorité du détenteur : une clé API LIR dotée du droit RPKI permet de soumettre une demande PKCS#10, de consulter les clés, de récupérer le certificat et sa chaîne, puis de révoquer une clé identifiée. Un même AS peut disposer de plusieurs clés. Les exemples de ce document pointent vers l’hôte pilote RPKI, détail utile pour délimiter ce qui est montré publiquement.

Le RIPE NCC tient maintenant le comptoir du certificat. Le détenteur doit gérer ses clés et équiper ses routeurs ; les voisins doivent accepter et vérifier des sessions BGPsec. La sécurité du chemin naîtra de cette coordination concrète, pas du seul fait qu’un formulaire API répond.