Résumé

  • Avec les nouveaux OID de politique et d’extensions, RFC 8360 permet à un validateur compatible de calculer un ensemble de ressources vérifiées et de ne pas rejeter automatiquement toute une branche lorsqu’un certificat d’AC surdéclare ses droits.
  • La partie excédentaire ne devient jamais valable : chaque préfixe d’une ROA et chaque ASN d’un certificat de routeur doivent rester inclus dans l’intersection vérifiée, tandis que l’ancien profil conserve sa règle de rejet.

Quand l’héritage devient une panne

La RPKI organise la délégation de préfixes IP et de numéros de systèmes autonomes sous forme de certificats. Le certificat d’un enfant ne vaut pas par sa seule signature : les ressources qu’il revendique doivent aussi découler de celles que détient valablement son émetteur, puis l’émetteur de celui-ci, jusqu’à l’ancre de confiance. RFC 3779 fournit les extensions de ressources ; RFC 6487 en a fait le profil de certificats de la RPKI.

La validation initiale imposait une conséquence binaire. Si une autorité de certification revendiquait ne serait-ce qu’une ressource absente du certificat qui l’avait émise, son propre certificat était rejeté. Tous les certificats et objets situés plus bas perdaient alors leur chemin de validation. Plus l’erreur était proche du sommet, plus son rayon pouvait être vaste.

Or une surdéclaration peut naître sans attaque. Un transfert de ressources modifie les droits du parent ; l’enfant ne renouvelle pas son certificat assez vite ; deux bases de gestion divergent ; une opération de réduction est appliquée dans le mauvais ordre. Les auteurs de RFC 8360 estimaient en 2018 cette situation peu probable, mais potentiellement très dommageable. Leur problème n’était donc pas de rendre l’excès acceptable, mais d’empêcher qu’il contamine des délégations sans rapport avec lui.

Le document réunit Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton et Donald Shaw. Sa réponse collective consiste à dissocier ce qui est écrit dans le certificat de ce que la chaîne permet réellement d’utiliser. Le validateur construit un Verified Resource Set, ou VRS : l’ensemble qui demeure après intersection des ressources à chaque étage du chemin validé.

Une intersection, deux familles de ressources

Le calcul ne mélange pas les objets. VRS-IP porte sur les adresses ; VRS-AS sur les numéros d’AS. Sans surdéclaration, l’algorithme alternatif et celui de RFC 6487 produisent le même résultat. En présence d’un excès, le VRS ne retient que la partie soutenue par toute la chaîne.

Cette nouvelle conduite ne s’active pas implicitement. RFC 8360 introduit une politique de certificat de version 2 et de nouveaux OID pour les extensions de ressources. Si le certificat les emploie, un validateur compatible signale les ressources surdéclarées puis poursuit avec l’intersection. Si le certificat relève encore de l’ancien profil RFC 6487, la surdéclaration impose toujours son rejet. Les OID portent donc une promesse de sémantique, pas un simple numéro de version décoratif.

Même un VRS vide illustre la discipline de la solution. Le certificat d’AC n’est pas forcément rejeté sur-le-champ, car l’état peut être transitoire. Mais il ne reste aucune ressource avec laquelle un descendant puisse valider un objet. Le nœud demeure observable ; il ne reçoit aucun droit de secours.

L’exemple du RFC rend la frontière tangible. Une AC enfant annonce 192.0.2.0/24, bien délégué, et 198.51.100.0/24, absent de sa chaîne. Son VRS conserve le premier bloc et élimine le second. Une ROA portant sur le premier peut être valable. Une ROA portant sur le second ne l’est pas. Le validateur sauve une autorisation prouvée, jamais l’affirmation erronée.

Le certificat survivant n’absout pas ses objets

Une ROA demeure soumise à son propre contrôle. Selon RFC 6482 et RFC 8360, tous ses préfixes doivent être contenus dans le VRS-IP du certificat de bout de chaîne qui signe l’objet. Une seule ressource extérieure à ce périmètre peut donc rendre la ROA invalide, même si le certificat d’AC situé au-dessus a survécu à sa surdéclaration.

Ce détail influence l’architecture opérationnelle. Regrouper de nombreux préfixes dans une même ROA fabrique un destin commun. Les séparer peut préserver les autorisations encore légitimes lorsqu’un seul préfixe sort du périmètre. Les certificats de routeurs BGPsec obéissent à la même logique : chaque ASN revendiqué doit appartenir au VRS-AS, et des certificats distincts par ASN peuvent limiter les dommages collatéraux.

Le mécanisme ne tranche pas tous les conflits possibles. Son calcul reste à l’intérieur d’une seule ancre de confiance. Les revendications qui se chevauchent entre plusieurs ancres sont explicitement hors périmètre. RFC 8360 ne transforme pas non plus une préférence locale du validateur en preuve cryptographique ; il resserre l’échec autour d’une erreur dans un chemin donné.

La compatibilité fait partie de la sécurité

Un nouveau profil n’aide que si les relying parties le comprennent. Un logiciel qui ne connaît pas les nouveaux OID rejettera le certificat. Les auteurs demandent donc que les outils de validation soient mis à niveau avant que les AC ne commencent à publier sous le nouveau régime. L’ordre de déploiement appartient au mécanisme de sûreté lui-même.

La migration peut cependant être graduelle. Chaque certificat choisit son profil. Une racine peut rester sous l’ancienne politique tandis qu’une AC subordonnée adopte la version 2, dès lors que les validateurs savent la traiter. Le confinement peut ainsi être introduit aux endroits où une erreur aurait le plus de descendants, sans bascule universelle en une nuit.

RFC 8488 documente un instant historique de cette transition. La description, en 2018, du validateur RIPE NCC mentionnait un mode strict choisi par l’opérateur et une utilisation configurée de l’algorithme alternatif hors de ce mode. Ce témoignage montre comment une implémentation présentait alors le choix ; il ne décrit ni un comportement actuel garanti ni la sémantique normative de tous les produits.

L’apport de Bruijnzeels et de ses coauteurs tient finalement à une séparation nette. L’erreur doit rester visible. La ressource indue doit rester inutilisable. Mais les ressources correctement héritées n’ont pas à disparaître avec elle. La confiance n’est pas élargie ; son domaine de panne est réduit.

Sources