Résumé

  • Le projet personnel déposé en septembre propose un registre distinct de délégations IPv4/IPv6 protégées ; il n’impose pas aux utilisateurs de remplacer leurs données RPKI.
  • Supprimer des VRP existantes avant que les nouvelles autorisations soient confirmées et définitives peut conduire, pour l’utilisateur qui active le filtre, à NotFound malgré une ROA valable. Le document décrit un risque, pas une panne constatée.

Dans une infrastructure de confiance, l’endroit où l’on retire une preuve compte autant que l’endroit où l’on en crée une. Joseph Gersch a déposé le 18 septembre un Internet-Draft individuel visant une délégation de ressources que l’échelon supérieur ne pourrait plus reprendre, doubler ou neutraliser une fois certaines conditions remplies. L’idée répond à une limite connue : le détenteur de la clé privée d’une autorité de certification déléguée n’empêche pas, à lui seul, l’émetteur parent de révoquer son certificat.

La nouveauté à examiner ici n’est pourtant pas cette autonomie des clés, déjà discutée ailleurs, mais le traitement des anciennes autorisations d’origine.

Le registre proposé serait distinct de la hiérarchie RPKI. Il n’attribuerait ni titre de propriété légal ni nouvelle consigne universelle aux routeurs, qui continueraient la validation habituelle. Une délégation protégée ne deviendrait irréversible qu’après état final, confirmation par le détenteur et expiration de la phase provisoire. La politique de récupération choisie par celui-ci devrait exister avant ce verrouillage. Les données importées d’un RIR, de RDAP ou de RPKI resteraient de simples assertions tant qu’elles ne seraient pas vérifiées. Seul un état confirmé et final pourrait produire les autorisations d’origine exportées.

C’est au point de consommation que deux gestes apparemment semblables se séparent. La RFC 8416 permet déjà des exceptions locales SLURM, avec des ajouts et des filtres. Ajouter une VRP issue du nouveau registre ne revient pas à charger un filtre qui masque une VRP RPKI en place. La section 10.6 du projet avertit qu’un filtre fautif peut priver un titulaire légitime de son autorisation existante. Son chargement reste donc une politique locale, non un passage obligé du projet. La section 10.5 complique encore un filtrage par préfixe : une ROA portant sur un préfixe moins spécifique peut, par son maxLength, couvrir la plage protégée. Une suppression partielle exige une représentation plus précise.

Le scénario le plus sensible est temporel. Si le filtre élimine d’abord les VRP en place tandis que les nouvelles autorisations n’ont pas atteint l’état final et confirmé, la route peut apparaître NotFound à cet utilisateur, malgré la validité persistante de la ROA antérieure. Ce n’est pas Invalid et cela ne prédit pas, à lui seul, le sort du trafic ; l’opérateur fixe aussi sa politique de routage. Un agrégateur qui ne reçoit que les VRP exportées doit en outre faire confiance à l’exportateur, puisque ces données ne portent pas ici la signature du détenteur.

L’auteur signale une preuve de concept sur une chaîne à accès restreint, sans prétendre disposer d’implémentations indépendantes, de profils de finalité en production ou de mesures à l’échelle d’Internet. Un participant de SIDROPS a contesté l’adéquation du sujet au groupe ; l’auteur a renvoyé la question aux présidents. Cette discussion n’est pas une décision du groupe. Datatracker présente toujours le texte comme projet individuel sans statut de norme. Le choix immédiatement vérifiable est celui du consommateur de données : quelles preuves existantes accepte-t-il de soustraire ?

Sources