Résumé

  • Les notes d’OpenBSD 8.0, publiée le 20 octobre, indiquent que rpki-client applique désormais correctement les contraintes d’ancre de confiance aux certificats de routeur BGPsec.
  • Cette barrière locale peut limiter les ressources qu’un validateur accepte. Elle ne bloque ni la publication par l’ancre ni l’acceptation par les autres validateurs.

Une porte de plus dans le périmètre

La ligne tient en une phrase dans les notes de version d’OpenBSD 8.0 : les contraintes s’appliquent désormais correctement aux certificats de routeur BGPsec de rpki-client. Le journal détaillé reprend la même correction. La version est sortie le 20 octobre.

Ce détail compte parce qu’une famille de certificats peut rester en dehors d’une règle que l’exploitant croyait générale. Un certificat de routeur BGPsec associe une clé à l’usage BGPsec et à des ressources. La note d’OpenBSD dit que le contrôle de contraintes atteint désormais correctement cette famille. Elle ne décrit aucun incident ni aucun réseau exposé ; la preuve disponible porte sur une correction de code.

La correction rejoint un projet plus vaste du groupe SIDROPS de l’IETF : « Constraining RPKI Trust Anchors ». La version -02 propose que chaque partie utilisatrice de RPKI (RP) fixe localement l’espace de ressources qu’elle attend d’une ancre de confiance (TA). Le validateur compare les adresses IP et numéros AS du certificat d’entité finale aux ressources permises. Si le certificat sort du périmètre, ce RP rejette l’objet signé concerné.

« Toutes les ressources » laisse une grande marge

Le projet indique que les cinq registres régionaux (RIR) inscrivent toutes les ressources sous leurs certificats TA dans leur fonctionnement courant. Cette portée évite certaines invalidations liées aux incohérences temporaires, notamment lors de transferts de ressources. Elle permet aussi à un validateur de recevoir une chaîne de certification plus large que le portefeuille actuel du registre.

Le fichier local donne au RP un second point de décision. Chaque fichier .constraints correspond au fichier .tal portant le même nom. L’exploitant peut autoriser des préfixes, plages d’adresses et numéros AS, puis tailler des exceptions avec des règles deny. Un refus l’emporte sur une autorisation ; toute ressource sans règle allow est refusée par défaut. Ce format évite d’énumérer l’Internet entier pour en exclure un seul bloc.

La simplicité du format ne pardonne pas les erreurs de syntaxe. Si le fichier de contraintes comporte une erreur, le projet exige que le RP rejette le fichier entier et ne vérifie pas les certificats d’entité finale avec ces règles. Jusqu’à la correction du fichier, cette couche locale ne fournit donc plus son filtre. La validation du fichier, sa distribution et sa mise à jour relèvent directement de la sécurité.

Le contrôle vise des objets dont le profil exige des extensions explicites de ressources IP ou AS : ROA, ASPA, RSC et certificat de routeur BGPsec. Les manifestes et les TAL signés figurent parmi les objets exclus, car ils ne portent pas ce type de déclaration de ressources. Le filtre encadre une décision de validation locale ; il ne remplace pas la hiérarchie RPKI ni la politique de routage du routeur.

Le code a précédé le dernier mot des normes

Le projet -02 reste un Internet-Draft actif, pas un RFC. Le Datatracker indique pour SIDROPS : « Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC ». L’annexe sur les implémentations doit disparaître avant la publication éventuelle d’un RFC.

Pour autant, le mécanisme tourne déjà dans du code. L’annexe rapporte une implémentation C dans rpki-client, activée par défaut depuis 2023, ainsi que des versions Rust et Go. Les auteurs disent que les trois donnent les mêmes résultats sur les fixtures d’OpenBSD. L’IETF précise qu’il n’a pas vérifié ces informations fournies par les contributeurs : elles documentent des implémentations et un jeu de tests commun, pas un audit indépendant de compatibilité. Le manuel OpenBSD décrit les fichiers .constraints propres à chaque TA et les règles locales allow/deny.

La correction d’OpenBSD 8.0 rappelle qu’une fonction ancienne peut encore laisser une famille de certificats dans une voie de validation différente. Le journal public ne donne ni les versions antérieures touchées ni le chemin de code précis ; ces informations détermineraient l’ampleur de l’exposition. La note établit que le contrôle des certificats de routeur BGPsec a été corrigé en 8.0. Elle montre aussi pourquoi une simple mention « contraintes activées » ne suffit pas : les tests doivent couvrir chaque type d’objet.

Un délai de six mois pour un petit fichier

Le projet conseille aux mainteneurs qui distribuent ces fichiers avec un système d’exploitation ou un paquet tiers de prévoir six mois avant la mise à jour par l’utilisateur. Or les politiques de transfert et les ressources gérées peuvent évoluer. Un fichier local doit suivre le périmètre qu’il prétend appliquer. Une liste allow périmée peut refuser des ressources devenues légitimes ; une politique absente ou incomplète peut laisser passer plus que ce que l’exploitant voulait accepter.

La stratégie 2026–2028 du NRO prévoit la livraison d’un document sur les contraintes des ancres de confiance. Son programme RPKI avait déjà inscrit en 2025 la consultation de la communauté sur la configuration des ancres parmi ses objectifs. Le travail institutionnel avance donc à côté de l’implémentation. OpenBSD 8.0 fournit une autre pièce : un correctif récent dans un validateur qui applique déjà les règles locales.

Pour un exploitant, la question pratique tient à des tâches vérifiables : le fichier exprime-t-il le périmètre voulu, correspond-il au bon TAL, survit-il aux mises à jour du paquet, se charge-t-il correctement, et couvre-t-il chaque classe de certificats utilisée ? La note d’OpenBSD vient de rendre la dernière question impossible à laisser dans les petites lignes.

Sources