Résumé

  • La RFC 9647 normalise le module YANG 1.1 ietf-babel, compatible NMDA, pour configurer et observer Babel sur IPv6 : activation, constantes, interfaces, protections MAC et DTLS, voisinage et routes.
  • Le modèle distingue utilement l’intention administrative de l’état opérationnel, mais la présence des attributs obligatoires en lecture seule dépend encore de l’implémentation. Une réponse YANG valide peut donc rester insuffisante comme preuve d’exploitation.
  • Les valeurs par défaut des liens filaires et sans fil réduisent le travail de configuration, mais deviennent risquées lorsque la topologie physique et la réalité opérationnelle divergent : radio derrière Ethernet, tunnel, accès facturé ou liaison de secours.
  • Les objets MAC et DTLS décrivent les identités et leurs rattachements. Ils ne prouvent ni la réussite de l’authentification, ni l’identité du pair réellement accepté, ni l’absence de trafic Babel non protégé.
  • Une assurance sérieuse exige dix reçus corrélés : module, datastore, état obligatoire, classification d’interface, politique effective, identité cryptographique, résultat d’authentification, chronologie de contrôle, installation RIB/FIB et comportement mesuré des paquets.

Ce que normalise réellement la RFC

Publiée sur le Standards Track en octobre 2024, la RFC 9647 définit le module YANG 1.1 ietf-babel. Celui-ci est compatible avec la Network Management Datastore Architecture, ou NMDA, de la RFC 8342, s’appuie sur le modèle d’information Babel de la RFC 9046 et retient les nœuds utiles à la gestion de Babel sur IPv6.

Cette portée est importante. La RFC ne redéfinit pas le protocole de routage de la RFC 8966. Elle fournit un contrat de gestion commun : noms, types, relations, possibilités de configuration et états opérationnels qu’un serveur YANG peut exposer. Le module augmente le modèle de gestion du routage afin d’inscrire Babel dans une structure commune aux protocoles de contrôle et aux bases d’information de routage.

Au niveau supérieur, le modèle expose la version de l’implémentation, l’activation de Babel, l’identifiant du routeur, le numéro de séquence et l’option de collecte de statistiques. Ses sous-arbres couvrent les constantes du protocole, les interfaces, les ensembles de clés MAC, les objets DTLS et les routes. Les constantes comprennent notamment le port UDP et le groupe multicast utilisés par Babel sur IPv6.

Cette normalisation rend les systèmes comparables sans les rendre identiques. Deux équipements peuvent présenter la même arborescence YANG tout en différant par les fonctions annoncées, la complétude de leur état, leur calcul de métrique, leur intégration à la RIB, leur programmation de la FIB ou leurs capacités de télémétrie. La conformité syntaxique du datastore n’abolit pas ces écarts.

Intention, application et réalité

La feuille enable illustre la frontière centrale du modèle. Dans les datastores <running> ou <intended>, sa lecture indique la valeur administrative configurée : Babel devrait être activé ou désactivé. Dans <operational>, elle indique si le protocole fonctionne effectivement.

Cette distinction évite de confondre une écriture acceptée avec un état appliqué. Elle ne suffit cependant pas à établir toute la causalité. Une valeur vraie dans <running> constitue une intention ; une valeur vraie dans <operational> confirme que l’implémentation déclare Babel actif. Ni l’une ni l’autre ne prouve, à elle seule, qu’une interface précise échange des messages, que ces messages sont authentifiés, qu’une route a été installée dans le matériel ou que le trafic atteint sa destination.

L’origine et l’heure de l’observation comptent donc autant que la valeur. Un opérateur doit conserver le datastore interrogé, les métadonnées d’origine disponibles, l’horodatage, l’identité du nœud et, si possible, un identifiant de transaction ou de changement. Sans cela, deux instantanés vrais mais pris à des moments différents peuvent produire une chaîne causale fictive.

NMDA fournit le vocabulaire nécessaire pour séparer configuration voulue et état opérationnel. Elle ne garantit ni la fraîcheur d’une collecte, ni la synchronisation des horloges, ni l’atomicité d’une série de requêtes effectuées par un outil extérieur.

Le problème discret des données absentes

La limite la plus explicite de la RFC 9647 concerne les attributs en lecture seule. Le modèle d’information dont elle dérive impose la définition de certains attributs, tels que la version de l’implémentation ou l’identifiant propre du routeur. Or YANG ne permet pas au module d’exiger qu’un nœud en lecture seule soit effectivement présent. Il revient à chaque implémentation de peupler les attributs marqués à la fois obligatoires dans le modèle d’information et non configurables dans le module.

L’absence ne doit donc pas être traitée comme une valeur neutre. Elle peut révéler une fonction inactive, un état indisponible, une collecte incomplète ou une non-conformité de l’implémentation. Le modèle seul ne permet pas de choisir entre ces explications.

Cette contrainte change les pratiques d’audit. Valider une réponse contre le schéma ne suffit pas. Il faut aussi tester la présence conditionnelle des données attendues : version, identifiant de routeur, état d’interface, voisinage, statistiques et attributs de route lorsque leurs conditions d’existence sont remplies. Un tableau de bord qui transforme silencieusement un nœud absent en zéro, false ou « sans objet » détruit précisément l’information nécessaire au diagnostic.

L’interface est une hypothèse opérationnelle

Le sous-arbre des interfaces relie Babel aux interfaces du modèle YANG commun. Il décrit notamment l’activation par interface, l’algorithme de calcul de métrique, l’usage du split horizon, les temporisations et les références aux protections MAC ou DTLS.

La RFC prévoit des comportements par défaut adaptés aux cas ordinaires. Pour un lien filaire, l’algorithme attendu est « two-out-of-three » avec split horizon activé. Pour un lien sans fil, le défaut est ETX sans split horizon. Ces choix traduisent une classification du média en politique de routage.

Le risque apparaît aux frontières de cette classification. Un port Ethernet raccordé à une radio ressemble à un lien filaire du point de vue du système, alors que son comportement est celui d’un média radio partagé ; la RFC prévoit explicitement la possibilité de forcer ETX et de désactiver le split horizon. Un tunnel ne peut pas toujours être caractérisé à partir de son nom et requiert des paramètres explicites. Une liaison mobile facturée servant de secours peut justifier des intervalles mcast-hello et update sensiblement plus longs afin de limiter le trafic de contrôle.

Il faut donc distinguer trois objets : le type d’interface déclaré, le chemin physique ou virtuel réellement emprunté, et la politique Babel effective. L’inventaire donne le premier ; l’ingénierie et la découverte de topologie établissent le deuxième ; une lecture de l’état appliqué et des temporisations démontre le troisième. Déduire les deux derniers du seul nom eth0, wlan0 ou tun0 serait une commodité, non une preuve.

Sécuriser la configuration n’est pas prouver l’échange

Le modèle contient des ensembles de clés pour le mécanisme MAC de la RFC 8967 et des objets de certificats pour Babel sur DTLS, défini par la RFC 8968. Une propriété default-apply peut ajouter les références de ces objets à toute nouvelle interface Babel.

Ce mécanisme facilite une politique sûre par défaut, mais il ne termine pas le travail de vérification. Après la création d’une interface, il faut confirmer qu’elle est activée, que les références attendues ont bien été matérialisées, que mac-verify ou dtls-enable a la valeur voulue et que l’identité appropriée est utilisable. La présence d’une clé ou d’un certificat dans un magasin n’établit pas son emploi sur une interface donnée.

Les valeurs de clés MAC et les clés privées DTLS portent des annotations NACM restrictives. La valeur secrète est protégée par default-deny-all; plusieurs attributs de certificat ou de format sont protégés contre les écritures ordinaires. Ces dispositions s’inscrivent dans le contrôle d’accès normalisé par la RFC 8341. Elles réduisent l’exposition par l’interface de gestion, sans démontrer que les rôles locaux sont correctement attribués, que les journaux sont intègres ou que les secrets ne sont pas accessibles par une autre voie.

Surtout, la RFC 9647 borne expressément sa section de sécurité au modèle YANG. Les risques du protocole Babel, de l’authentification MAC et de DTLS demeurent traités respectivement par les RFC 8966, 8967 et 8968. La preuve opérationnelle doit donc inclure les résultats de vérification MAC, les succès et échecs de handshake, l’identité du pair, les rejets et leur chronologie. Un objet cryptographique configuré est une capacité ; un échange authentifié est un événement.

Ce que signifie — et ne signifie pas — selected

Pour chaque préfixe, l’état de route peut exposer l’identifiant du routeur, le voisin à l’origine de l’annonce, la métrique reçue, la métrique calculée, le numéro de séquence, le prochain saut et les indicateurs feasible et selected. Cette vue est particulièrement utile pour reconstruire une décision du processus Babel.

Elle reste une projection de l’état interne de l’implémentation. selected = true signifie que cette route est indiquée comme sélectionnée par Babel ; ce booléen n’est pas une mesure indépendante du transfert de paquets. Le modèle n’affirme pas, par cette seule valeur, que la route se trouve dans la RIB globale, qu’elle a remporté une compétition avec d’autres protocoles, qu’elle a été programmée dans la FIB ou qu’une politique ultérieure ne l’a pas supprimée. Il n’établit pas davantage la résolution du prochain saut, la disponibilité de l’interface de sortie ou la joignabilité de bout en bout.

Les métriques reçues et calculées peuvent aider à comprendre la sélection. Une valeur maximale peut signaler une route récemment rétractée et temporairement inaccessible ; une route injectée depuis l’extérieur de Babel peut ne pas avoir de métrique reçue. Ces nuances expliquent un état de contrôle, mais elles ne remplacent pas une observation du plan de données.

Les exemples XML annexés à la RFC montrent comment encoder des configurations. Ils ne sont ni des captures d’un réseau vivant ni des résultats de test. Les citer comme preuve de déploiement reviendrait à confondre une grammaire avec un reçu d’exécution.

Une chaîne pratique de dix reçus

L’assurance exploitable peut être organisée en dix preuves distinctes, chacune répondant à une question différente.

  1. Révision et fonctions du module. Relever le module ietf-babel, sa révision 2024-10-10 et les fonctionnalités annoncées : algorithmes, MAC, DTLS, types de certificats. Le registre des paramètres YANG de l’IANA permet de vérifier l’enregistrement, non la qualité de l’implémentation locale.

  2. Datastore, origine et temps. Identifier <running>, <intended> ou <operational>, conserver les métadonnées d’origine disponibles et horodater la lecture. Une valeur sans provenance ne suffit pas pour relier intention et application.

  3. Présence de l’état obligatoire. Tester explicitement les objets en lecture seule attendus. L’absence doit rester un résultat visible, jamais être convertie automatiquement en valeur négative.

  4. Classification vérifiée des interfaces. Relier l’interface logique au média, au tunnel ou au chemin de secours réel. Documenter les radios placées derrière un port filaire et les liens dont le coût d’usage change la politique souhaitée.

  5. Valeurs effectives et dérogations. Lire l’algorithme de métrique, le split horizon et les temporisations réellement appliqués. Conserver la justification des exceptions aux valeurs par défaut.

  6. Identité et rattachement MAC ou DTLS. Vérifier les références présentes sur chaque interface, l’activation du mécanisme, les identités utilisables et leur période de validité, sans extraire inutilement les secrets.

  7. Résultat cryptographique. Collecter succès, rejets, erreurs de certificat, échecs de handshake et vérifications MAC. Associer ces événements à l’interface, au pair et à l’heure.

  8. Chronologie des voisins et des routes. Corréler apparition du voisin, annonces, changements de numéro de séquence, métriques, faisabilité, sélection et retrait. Un instantané isolé masque les transitions.

  9. Installation RIB et FIB. Vérifier que la route sélectionnée par Babel est admise dans la RIB puis programmée dans la FIB, avec le prochain saut et l’interface attendus. Documenter les filtres, préférences et échecs de programmation.

  10. Paquets, reprise et observation indépendante. Mesurer le transfert réel, provoquer une défaillance contrôlée, chronométrer la perte et la récupération, puis confirmer la joignabilité depuis un point extérieur au routeur observé.

Aucun reçu ne remplace les autres. Leur valeur vient de la corrélation : mêmes préfixes, interfaces, voisins, identités et fenêtres temporelles. La RFC 9647 rend les six à huit premiers plus structurés ; elle ne produit pas automatiquement les deux derniers.

Limite de preuve et décision d’exploitation

Le progrès apporté par la RFC 9647 n’est donc pas une promesse de vérité de bout en bout. C’est une réduction du coût de collecte et de comparaison de l’état Babel. Les exploitants peuvent construire des contrôles portables, rechercher des écarts entre intention et opération, vérifier des rattachements cryptographiques et suivre la décision de route sans dépendre entièrement d’une interface propriétaire.

La discipline consiste à attribuer à chaque observation la force qu’elle possède réellement. Une configuration prouve une intention enregistrée. <operational> rapporte l’état que l’implémentation expose. Un journal cryptographique rapporte un résultat de validation. La RIB et la FIB rapportent des étapes d’installation. Une capture ou un test actif rapporte un comportement sur un chemin et pendant une fenêtre donnés. Une mesure externe ajoute une indépendance précieuse, mais elle n’établit pas à elle seule la cause d’une panne.

Le dossier probant devient solide lorsque ces couches convergent. S’il manque une couche, la conclusion doit rester conditionnelle : « route sélectionnée par Babel », « installée dans la FIB » ou « joignabilité observée », plutôt que l’affirmation plus large « le service fonctionne ».

Sources