Résumé

  • src-members lève l’ambiguïté d’une référence RPSL en nommant un registre IRR, mais cette portée s’éteint au prochain objet et ne s’impose pas à ses descendants.
  • Tant que les anciens et les nouveaux résolveurs coexistent, la preuve utile n’est pas seulement la liste finale : c’est le reçu de résolution qui conserve chaque choix de registre, chaque version d’objet et l’écart entre les deux lectures.

Le ticket de changement paraît complet : un nom d’ensemble, une liste de préfixes générée, un approbateur et une heure de déploiement. Puis un ingénieur relance la même commande avec un autre résolveur IRR. Le nombre d’entrées est proche, l’exécution réussit, mais quelques préfixes ne sont plus les mêmes. Quel résultat correspond à l’intention de l’auteur ? Le ticket n’a gardé aucune des décisions intermédiaires capables de répondre.

C’est dans cet espace que s’inscrit draft-ietf-grow-rpsl-registry-scoped-members-00. Le document de travail du groupe GROW ajoute l’attribut src-members aux objets as-set et route-set de RPSL. Une valeur comme RIPE::AS-EXAMPLE associe un nom d’ensemble au registre dans lequel il doit être recherché. La proposition corrige une ambiguïté réelle. Elle ne transforme pas pour autant une expansion récursive en chaîne de provenance complète.

Une précision locale dans un graphe distribué

Les politiques RPSL ne se résument pas à une liste plate. Un ensemble peut contenir des numéros d’AS ou des préfixes, mais aussi renvoyer vers d’autres ensembles, qui en appellent encore d’autres. Plusieurs registres IRR importants fonctionnent séparément. Rien ne garantit l’unicité globale de leurs clés primaires. Un serveur qui réplique plusieurs sources peut donc connaître plusieurs objets portant le même nom.

La révision 00 expose deux conséquences. Le résolveur peut choisir l’objet homonyme d’un registre que l’opérateur ne visait pas, puis calculer une politique involontaire. Il peut aussi ne pas retrouver l’objet attendu et exclure des routes qui auraient dû être acceptées. Le projet relie ces erreurs à des fuites, à des détournements possibles ou à une perte de joignabilité. Il faut conserver cette attribution : le texte ne documente pas un nouvel incident précis et ne mesure pas l’adoption de la solution.

src-members apporte la source qui manquait à la référence. Pour un logiciel compatible, la résolution d’un membre qualifié doit faire correspondre à la fois le nom du registre et la clé primaire. Si ce registre n’est pas connu, aucun ensemble ne correspond. Choisir silencieusement une copie non qualifiée nierait l’information fournie par l’auteur.

La portée s’arrête pourtant à cet objet. Une fois le fils sélectionné, ses propres membres sont interprétés selon ce qu’ils contiennent. Une autre valeur src-members peut préciser une nouvelle source. Une ancienne valeur members ou mp-members rend au résolveur son algorithme habituel de sélection. Le préfixe du parent ne se propage pas.

La requête initiale obéit à la même règle. Le projet exige un paramètre permettant de chercher l’objet racine dans un registre déterminé, mais interdit que cette restriction s’applique automatiquement aux recherches suivantes. Lancer une expansion depuis RIPE::RS-FIRST ne prouve donc pas que tous les objets descendants proviennent du registre RIPE.

La compatibilité maintient deux interprétations

Le changement doit être progressif. Des logiciels anciens ignoreront src-members, et des objets existants pourront rester partiellement migrés. Pour les alimenter, les attributs members et mp-members demeurent présents. Lorsqu’un objet contient src-members, le registre faisant autorité doit vérifier que chaque référence, privée de son préfixe de registre, figure aussi dans les anciens attributs.

Si l’utilisateur omet ces anciens champs, le logiciel faisant autorité est invité à les générer à partir de src-members. Il retire alors le préfixe. Il ne doit pas modifier les valeurs historiques que l’utilisateur a expressément soumises. Un serveur non autoritatif ne doit pas produire cette projection. Dans l’autre sens, aucune génération fiable n’est possible : une clé sans source ne révèle pas dans quel registre l’auteur voulait chercher.

Un même objet valide présente dès lors deux surfaces. Le résolveur récent lit RIPE::RS-SECOND. L’ancien lit RS-SECOND et suit son ordre de préférence entre registres. La validation garantit la cohérence des noms après retrait du préfixe ; elle ne garantit pas l’identité de l’objet sélectionné par les deux consommateurs.

Le projet interdit même d’inscrire ensemble RIPE::AS-OTHER et ARIN::AS-OTHER dans src-members. Ces deux chaînes qualifiées désignent des objets distincts, mais leur projection historique devient deux fois AS-OTHER. L’ancien format ne peut préserver cette différence. La compatibilité impose donc une limite au langage plus précis.

Ce compromis facilite l’adoption. Il rend aussi trompeuse une conclusion trop simple : un objet accepté par le registre n’est pas encore une politique identique pour tous les outils qui le consomment.

Reconstituer le chemin avant d’autoriser le résultat

Le produit final d’une résolution — une collection d’AS ou de préfixes — a perdu son historique. Deux listes de même taille peuvent contenir des membres différents. Deux listes identiques peuvent avoir été obtenues depuis des instantanés ou des choix de source différents, et diverger à la mise à jour suivante. Une coche verte ne restitue ni les embranchements ni les limites de récursion.

Le reçu de provenance de résolution proposé ici commence par la clé racine et le registre éventuellement imposé par la requête. Il conserve l’implémentation du résolveur, sa version, l’activation de src-members, les registres visibles et, pour chacun, un numéro de série, un instantané ou un condensat de contenu vérifiable.

Chaque arête récursive est ensuite enregistrée : objet parent et registre, attribut lu, référence telle qu’écrite, choix explicite ou implicite de la source, objet effectivement sélectionné et condensat de sa version. Un registre inconnu, un objet absent, un cycle, une collision, une limite de profondeur ou de volume doivent devenir des résultats structurés. Ils ne sont pas de simples messages de diagnostic.

Pendant la transition, le reçu contient deux condensats de sortie. Le premier correspond à la lecture consciente de src-members. Le second reproduit le comportement historique réellement présent dans la chaîne de production. L’écart porte sur les identités exactes des membres, pas seulement sur leur nombre. Toute divergence acceptée reçoit un responsable, une justification, une échéance et une autorité de retour arrière.

Enfin, la preuve relie la résolution à la version du compilateur de politique, à ses filtres et normalisations, au condensat de la configuration produite, à la cible de déploiement et au changement approuvé. Sans ce lien, on prouve la collecte des données mais pas l’installation de l’artefact examiné.

Ce reçu ne confère pas d’autorité au registre

La traçabilité n’authentifie pas magiquement un objet IRR. Elle ne démontre ni l’origine d’une route, ni une relation commerciale, ni la validité RPKI. Elle ne remplace aucune de ces couches. Elle rend contrôlable une décision qui utilise des données de registre.

Il n’est pas non plus nécessaire de publier des politiques confidentielles, des identifiants ou des configurations complètes. Les condensats, les identifiants de sources, les rôles et les différences de résultats suffisent à préserver la séquence de décision.

Une divergence entre les deux résolutions n’est pas automatiquement une faute. La référence qualifiée peut corriger l’ambiguïté que l’ancien outil perpétue. Mais si cet ancien outil fabrique encore un filtre de production, son résultat appartient à la réalité opérationnelle. Le désaccord déclenche une revue : quels consommateurs restent concernés, quel résultat représente l’intention, à quel rythme migrer, comment revenir en arrière ?

Le projet rappelle enfin que les cycles doivent être détectés et que la profondeur ou la taille d’une résolution devrait être bornée. Ces paramètres changent parfois la politique sans aucune modification des objets RPSL. Ils doivent donc entrer dans la preuve.

Le préfixe de registre améliore la qualité d’une référence. Il ne signe pas tout le graphe. La gouvernance commence lorsque l’opérateur refuse que la liste finale efface les choix qui l’ont construite.

Sources

  1. Fiche Datatracker du projet sur les membres RPSL qualifiés
  2. Historique du projet courant
  3. Révision 00 en HTML
  4. Révision 00 en texte
  5. Source XML de la révision 00
  6. Fiche du projet antérieur
  7. Historique du projet antérieur
  8. Révision 01 du projet antérieur
  9. Mandat du groupe GROW
  10. Documents actifs de GROW
  11. Annonce d’adoption par GROW
  12. Dépôt source des auteurs
  13. RFC 2622 : Routing Policy Specification Language
  14. RFC 4012 : RPSL nouvelle génération
  15. RFC 2725 : sécurité du système de politique de routage
  16. RFC 2650 : utilisation pratique de RPSL
  17. RFC 7682 : considérations sur les IRR
  18. RFC 7909 : RPKI et validation de l’origine
  19. Lu Heng : spécification initiale minimale, décision future localisée, adoption volontaire
  20. Lu Heng : The Policy Mirror