Résumé

  • draft-ietf-idr-bgp-rpki-yang-02 place des jauges de validation d'origine à cinq endroits distincts de la chaîne BGP. Le chemin YANG, le voisin et la famille d'adresses font partie de la preuve.
  • Un total identique peut recouvrir un ensemble de routes différent. La validation ne démontre pas davantage la sélection, l'exportation, l'acceptation distante ou le passage effectif des paquets.

La maintenance est terminée. Avant l'intervention : 10 000 routes dont l'origine est valide. Après : 10 000. Le chiffre donne envie d'écrire « aucun changement » dans le compte rendu.

Mais un préfixe client a pu disparaître et être remplacé, dans le total, par une route sans rapport. La cardinalité est la même ; le réseau que l'entreprise croit protéger ne l'est plus.

C'est la lecture opérationnelle de draft-ietf-idr-bgp-rpki-yang-02, daté du 30 septembre 2026. Le document du groupe IDR définit trois modèles YANG : validation de l'AS d'origine, BGPsec et ASPA. Pour la validation d'origine, quatre jauges—non vérifié, inconnu, invalide et valide—apparaissent à cinq surfaces du traitement BGP.

Le lieu de mesure change le sens

Les statistiques se trouvent dans adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre et adj-rib-out-post, séparément pour IPv4 et IPv6.

Avant la politique d'entrée, on observe ce que le voisin a présenté. Après cette politique, on observe ce que le routeur a conservé. Le RIB local décrit sa vue locale sélectionnée. Les deux surfaces de sortie encadrent la politique appliquée pour un voisin donné.

Une jauge à l'entrée ne prouve donc pas l'état du RIB local. Une jauge dans le RIB local ne prouve pas l'annonce à un pair particulier. Une jauge après politique de sortie ne prouve ni l'installation par ce pair ni le trajet des paquets.

Le chemin YANG n'est pas un détail de collecte : il borne l'affirmation. Le voisin et l'AFI/SAFI la bornent aussi. Agréger plusieurs pairs peut masquer la perte d'un transit par l'arrivée de routes d'un autre. Mélanger IPv4 et IPv6 transforme deux réalités en une moyenne sans propriétaire.

Une jauge compte ; elle n'identifie pas

Le type gauge32 représente une quantité courante. Il ne transporte ni la liste des routes ni l'empreinte de cette liste.

Deux ensembles de même taille peuvent avoir des membres différents. Une route sort, une autre entre : la courbe reste plate. Une politique remplace une classe entière de préfixes par une autre : le total peut encore rester plat. La jauge n'est pas fausse ; c'est l'interprétation « même total, donc même état » qui l'est.

Une preuve de continuité doit conserver l'identité des membres. Selon le risque, il peut s'agir d'une empreinte canonique sur le préfixe, l'origine, l'AS_PATH et le prochain saut, d'une liste bornée ou de tests d'appartenance pour les préfixes critiques. Le principe est simple : si l'on promet de protéger certaines routes, le reçu doit dire lesquelles ont été comptées.

La synchronisation compte également. Le projet figé ne promet pas qu'une lecture des cinq chemins constitue un instantané transactionnel. Pendant la convergence, comparer une entrée lue à 02:00:01 et une sortie lue à 02:00:08 peut créer une différence artificielle ou en effacer une réelle.

« Valide » reste une conclusion limitée

La validation d'origine RPKI compare le préfixe et l'AS d'origine avec des données ROA validées. RFC 6811 en donne la base ; RFC 8481 précise notamment quelles routes sont validées et distingue la validation d'une politique non configurée.

Une route valide selon ce test n'est pas forcément la route la moins coûteuse, la plus rapide ou celle qui a gagné la sélection. Elle n'est pas, pour cette seule raison, protégée contre toute fuite, valide selon BGPsec ou conforme à ASPA. Le libellé ne prouve pas que le cache était frais, que la route a été exportée, que le voisin l'a acceptée ni que le plan de données l'utilise.

Le projet maintient justement trois modèles distincts. Les réduire à un voyant « sûr » supprimerait l'information la plus utile : la nature de l'assertion vérifiée.

Les décisions se trouvent à côté des compteurs

La validation d'origine peut être activée par famille d'adresses et limitée par une eligible-prefix-policy. Un conteneur séparé décide si le résultat participe au calcul du meilleur chemin. allow-invalid et allow-not-found déterminent quels états restent admissibles, avec leurs valeurs par défaut et leur propre périmètre de politique.

L'annonce de l'état, via la communauté étendue de RFC 8097, est encore une décision indépendante. L'exportation en est une autre : le modèle peut tenir compte de l'état lors de la sortie, autoriser ou non les routes « not-found » et appliquer une politique d'éligibilité spécifique, conformément au cadre de RFC 8893.

Ainsi, la même distribution de validation peut produire des comportements différents. Modifier allow-invalid, allow-not-found ou une politique d'éligibilité peut changer les candidats et les annonces sans modifier le nombre de routes valides.

Une capture d'écran ne suffit donc pas à l'audit. L'observation doit être liée à la configuration effectivement appliquée et à son époque de politique. RFC 8342 rappelle pourquoi : la configuration voulue et l'état opérationnel utilisé peuvent diverger pendant ou après le traitement.

Huit reçus au lieu d'un voyant plus grand

Une chaîne défendable sépare : les données de validation et leur fraîcheur ; la configuration appliquée ; le chemin exact et l'heure de la jauge ; l'identité des routes comptées ; la décision de sélection ; l'ensemble exporté et le message émis ; l'acceptation par le pair ; enfin le résultat de transfert et de service.

Chaque reçu répond à une question. Aucun ne prouve automatiquement le suivant. Des VRP frais ne prouvent pas l'application d'une politique. Une jauge correcte n'identifie pas ses membres. Un ensemble local ne prouve pas la sélection. La sélection ne prouve pas l'exportation. L'exportation ne prouve pas l'acceptation. Et l'acceptation ne prouve pas que les paquets arrivent.

Cette séparation évite aussi les faux débats en incident. Si le service échoue alors que le total reste stable, l'équipe cherche la première frontière divergente. Le compteur peut avoir été parfaitement juste sur son objet limité, tout en restant muet sur la promesse faite par la direction.

Un projet de norme, pas un rapport de déploiement

Datatracker classe la révision 02 comme Internet-Draft actif, destiné à la voie Standards Track, avec l'état I-D Exists. Ce n'est pas un RFC. Les sources figées ne prouvent l'implémentation par aucun fournisseur ni le déploiement dans un réseau nommé.

Cette prudence n'interdit pas d'agir. Les outils existants peuvent déjà conserver l'étape, le pair, la famille, l'époque de politique et l'identité de l'ensemble. Le projet offre une forme commune prometteuse ; le besoin de preuve existe avant son adoption générale.

La Minimum Initial Specification et la Running-Code Primacy de Heng Lu donnent ici un cadre utile. Des règles de validation déterministes peuvent être communes, tandis que sélection et exportation restent des décisions locales visibles. La publication d'un modèle ne le rend pas réel : l'implémentation, la configuration et l'usage le font.

La bonne question de clôture n'est donc pas « le compteur est-il resté vert ? ». C'est : quelles routes, à quelle étape, sous quelle politique appliquée, ont été sélectionnées et annoncées—et qu'ont fait les paquets ?

Sources