Résumé

  • La révision 15 du projet OPSAWG UCL ajoute au modèle ACL de RFC 8519 des groupes de terminaux, des correspondances par Group ID et des horaires d’activation. Elle définit aussi l’attribut RADIUS User-Access-Group-ID.
  • La cohérence ne découle pas de l’identité du libellé. Elle exige la même décision de groupe, la même carte vers les champs de paquet, la même ACL, le même calendrier et une preuve d’activation pour chaque point d’application.

Deux équipements affichaient R&D. L’équipe de changement en a conclu qu’ils appliquaient la même politique. Le premier équipement avait reçu la carte 218, produite après le renouvellement de l’adresse IPv6 temporaire d’une utilisatrice. Le second fonctionnait encore avec la carte 217. Les journaux de haut niveau étaient cohérents ; les paquets ne l’étaient pas.

Ce type d’incident ne contredit pas l’intérêt d’un contrôle d’accès fondé sur les groupes. Il montre au contraire pourquoi l’abstraction est utile et pourquoi elle doit conserver son histoire. Une identité de groupe évite de réécrire l’intention chaque fois qu’une adresse, une session ou une application bouge. Mais la traduction de cette identité vers ce que voit un équipement reste une opération datée, distribuée et faillible.

La révision 15 de A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control propose un cadre précis pour cette abstraction. Le module YANG ietf-ucl-acl augmente les ACL de RFC 8519. Il introduit des groupes de terminaux de type utilisateur, appareil ou application, permet de référencer un groupe source ou destination dans une ACE et ajoute un calendrier effectif.

Le texte se trouve à un stade avancé : document de groupe OPSAWG, soumis à l’IESG, dans la file du RFC Editor et en revue finale. L’examen IANA est marqué comme terminé avec des actions à réaliser. La révision 15 date du 2 avril 2026 et expire le 4 octobre 2026. Son statut visé est Proposed Standard. Pourtant, elle reste un Internet-Draft sans numéro RFC. La proximité de la publication n’est ni la publication elle-même ni une preuve de déploiement.

La carte est une donnée de production

Le modèle répond à une difficulté familière. Un utilisateur n’a pas toujours une adresse stable. Les adresses temporaires IPv6, la mobilité et NAPT rendent l’adresse insuffisante comme identité durable. Une application peut migrer d’une machine virtuelle à une autre ; un appareil peut changer de point d’accès ; une session peut survivre à un changement de coordonnées.

Le Group ID place donc l’intention au-dessus de ces mouvements. Mais un PEP ne filtre pas une intention abstraite sans mécanisme. Il doit reconnaître le groupe dans le paquet ou recevoir une ACL traduite en champs ordinaires. Le projet décrit ces deux modèles de déploiement.

Dans le premier, un contrôleur de domaine maintient dynamiquement la relation entre le groupe et des champs IP ou transport, par exemple un cinq-tuple. Il programme ensuite des ACL classiques dans les PEP. Les équipements peuvent rester simples, mais le contrôleur doit suivre chaque déplacement et distribuer la nouvelle projection avant que l’ancienne ne devienne dangereuse.

Dans le second, les PEP comprennent le groupe. Ils associent eux-mêmes les paquets à un groupe source ou destination et appliquent une ACL correspondante. Cette souplesse peut nécessiter un support matériel ou logiciel particulier et affecter les performances de transfert. Le projet laisse l’évaluation de ce compromis aux implémentations.

Dans les deux cas, dire « le groupe est R&D » ne suffit pas. Il faut préciser la version de la carte, sa source, sa durée de validité, le type de groupe, le PEP concerné et la méthode de classification. Le même libellé peut rester stable alors que la réalité qu’il référence change plusieurs fois.

Le texte dit même que l’étiquette placée dans un paquet n’a pas besoin de reproduire exactement la chaîne du Group ID. La manière de transformer cette chaîne en étiquette ou en champ d’en-tête est hors périmètre. RFC 9638 fournit un exemple avec GBP, pas une correspondance universelle. Deux domaines peuvent donc afficher le même nom humain et coder des valeurs différentes.

Plusieurs PEP, plusieurs vérités locales

L’architecture reconnaît explicitement que plusieurs Policy Enforcement Points peuvent intervenir. Cette pluralité est souvent la raison opérationnelle du déploiement : un NAS contrôle l’entrée, un pare-feu limite l’accès aux services, un commutateur ou une passerelle applique une segmentation supplémentaire.

Elle interdit toutefois de prendre l’état du contrôleur pour l’état du parc. Le contrôleur peut avoir calculé la carte 218 et commencé sa distribution. Un PEP l’a validée et activée ; un autre l’a placée dans une transaction en attente ; un troisième ne supporte pas la correspondance de groupe et attend une ACL classique ; un quatrième est isolé.

Un tableau de bord qui agrège ces états en deployed=true perd l’information décisive. La bonne unité de preuve est le couple (PEP, révision), complété par validation, installation, activation et lecture de retour. Le jeu de PEP attendu doit lui-même être versionné : un nouvel équipement absent de la liste n’apparaîtra jamais comme échec.

La section 8.3 demande une configuration adéquate pour relier le Group ID aux champs de paquet et une attention particulière lorsque plusieurs mécanismes, dont RADIUS, coexistent. Cette consigne identifie le problème sans pouvoir le résoudre pour chaque architecture. La cohérence doit devenir une propriété vérifiée localement.

Le cas d’une carte expirée est instructif. Le second PEP n’a pas nécessairement une configuration invalide au sens syntaxique. Son ACL peut être parfaitement acceptée, compilée et active. Elle protège simplement l’ancienne projection du groupe. Une validation YANG réussie ne détecte pas ce décalage temporel.

RADIUS transporte une décision située

Le projet définit User-Access-Group-ID comme chaîne de caractères pour les scénarios centrés sur l’utilisateur. Dans un Access-Accept, l’attribut peut indiquer le groupe dont la politique sera appliquée après authentification. Dans un Access-Request, il peut apparaître seulement comme indice ou préférence ; le serveur n’est pas obligé de l’accepter.

Cette asymétrie doit survivre aux systèmes d’événements. Si une plateforme extrait seulement user, group et timestamp, elle transforme deux actes différents en un même fait : d’un côté une préférence avancée par le demandeur, de l’autre une décision émise par le serveur. L’origine et le type du paquet sont une partie de la signification.

Plusieurs occurrences dans Access-Accept signifient que l’utilisateur appartient à plusieurs groupes. Le modèle ne donne pas, par cette phrase, une politique universelle de priorité entre toutes les ACE produites par différents fournisseurs. Conserver une seule valeur « principale » peut rendre l’audit impossible si une permission et une interdiction se croisent.

User-Access-Group-ID peut aussi figurer dans une demande CoA. La modification d’autorisation ajoute une course : décision du serveur, réception par le NAS, recalcul du contrôleur, propagation et activation sur chaque PEP. Il faut pouvoir montrer une convergence partielle au lieu de déclarer l’état nouveau dès le premier accusé.

Enfin, l’attribut peut être inclus dans une Accounting-Request. Le NAS peut ainsi reconnaître qu’il l’a reçu et qu’il applique la politique. Cette déclaration a une valeur réelle. Elle reste la déclaration d’un observateur déterminé. Elle ne prouve pas que la passerelle de service, le pare-feu latéral et le commutateur ont la même carte.

L’horaire donne une seconde dimension à la divergence

L’augmentation YANG ajoute un effective-schedule à l’ACE. La règle peut être bornée par une période ou une récurrence fondée sur RFC 9922. Sans calendrier configuré, elle est appliquée immédiatement et en permanence.

Avec un calendrier, deux PEP possédant la même ACL peuvent encore diverger. Ils peuvent avoir des versions différentes de la récurrence, des identifiants de fuseau distincts, une horloge dégradée ou un instant d’activation différent. Une lecture de configuration montre ce qui est stocké ; elle ne montre pas forcément quelle branche gouvernait le paquet à la limite de l’intervalle.

Le projet considère l’écriture non autorisée du calendrier comme une source possible d’indisponibilité. Il considère aussi sa lecture comme sensible, car connaître les heures d’application peut aider à préparer une attaque. L’horaire n’est donc ni une décoration d’interface ni une simple annotation documentaire. C’est une partie du contrôle et une information opérationnelle à protéger.

Une preuve utile doit conserver la règle, la zone, la version des exceptions, la santé de l’horloge et l’état actif observé par PEP. Elle doit éviter de publier les fenêtres sensibles sur des surfaces qui n’en ont pas besoin.

La forme validée n’est pas le comportement

Le Datatracker affiche zéro erreur et zéro avertissement pour la validation YANG de la révision 15. Cela apporte une preuve sur la structure vérifiée. Cela ne démontre pas que deux implémentations calculent une récurrence de manière identique, qu’un contrôleur choisit les bons PEP ou qu’un équipement traite les paquets attendus.

La comparaison des révisions 14 et 15 montre surtout des corrections éditoriales : date, expiration, formulation, développement de NVO3 et référence aux recommandations YANG publiées dans RFC 9907. Aucun résultat d’interopérabilité ou de mesure en production n’apparaît. L’article doit donc résister à la tentation de transformer un document mûr en résultat déjà acquis.

Les protections de gestion restent indispensables. NETCONF et RESTCONF doivent utiliser un transport sûr et une authentification mutuelle ; NACM peut limiter les opérations et les données. Un accès non autorisé à la liste des groupes peut fabriquer ou supprimer un groupe. Une modification des critères de correspondance peut ouvrir ce qui devait rester fermé ou fermer ce qui devait rester ouvert.

Mais une écriture correctement authentifiée peut encore appliquer une décision dépassée ou incomplète. La sécurité du canal répond à « qui a envoyé cette opération ? ». L’audit d’exécution répond à « quelle autorité, quelle carte, quelle politique, quels appareils et quel résultat ? ».

Composer un reçu de cohérence

Le reçu commence par l’affectation : identité authentifiée, contexte de session, autorité de groupe, type de paquet RADIUS, toutes les valeurs reçues et décision effective. Il ne confond pas l’indice de l’Access-Request avec le contenu de l’Access-Accept.

Il conserve ensuite la carte. Dans un modèle centralisé : révision, sources d’inventaire, adresses ou cinq-tuples, intervalle de validité et déclencheur de mise à jour. Dans un modèle à étiquette : liaison entre chaîne et valeur de paquet, domaine d’encapsulation et origine de confiance. Dans un PEP classificateur : version de la logique et entrées utilisées.

Viennent l’ACL et le calendrier : révision, actions, ordre, politique de conflit pour les groupes multiples, période ou récurrence, fuseau et exceptions. Puis le jeu de PEP : pourquoi chacun est nécessaire, quelle capacité il annonce et quel format il doit recevoir.

Chaque PEP produit enfin ses propres étapes. Envoyé, validé, installé, actif et relu ne sont pas des synonymes. Un identifiant de transaction et une empreinte de lecture permettent de relier l’intention centrale à l’état local. Un échec sur un seul PEP ne doit pas disparaître dans une moyenne.

La dernière couche vient du trafic. Compteurs de règle, échantillons, tests de permission et d’interdiction, chemin emprunté et résultat applicatif ne répondent pas à la même question. Le but n’est pas de collecter toutes les données sans limite, mais de choisir assez de preuves pour ne pas faire parler un accusé de réception au nom d’un paquet.

Une norme minimale, des décisions locales

La Minimum Initial Specification de Heng Lu invite à partager le plus petit contrat qui protège l’interopérabilité et la vérité des transitions. Ici, il peut tenir en quelques identifiants : sujet, décision de groupe, version de carte, version d’ACL et de calendrier, jeu de PEP, état par PEP et observation du résultat.

Les opérateurs restent libres de choisir contrôleur, technologie de marquage, ordre des ACL et politique d’échec. Cette liberté locale n’exige pas une ambiguïté globale sur le sens de enforced.

La séparation des couches de réalité éclaire le diagnostic. R&D est un symbole. L’affectation AAA et l’ACL sont des décisions et des objets de contrôle. La règle installée est un état exécutable. Le paquet traversé ou rejeté est une observation. La cohérence doit être gagnée entre les couches, pas déduite du nom commun.

La primauté du running code impose des essais de mouvement et de panne. Faire tourner une adresse IPv6 temporaire, migrer une VM, envoyer un CoA pendant l’indisponibilité d’un PEP, traverser une limite horaire et redémarrer le contrôleur révèlent davantage qu’une démonstration statique. Le résultat attendu n’est pas toujours « tout vert » ; c’est un état qui expose correctement le partiel et l’inconnu.

Dans l’incident initial, les deux PEP pouvaient honnêtement afficher le même groupe. L’erreur était de ne pas afficher la carte à laquelle chacun se référait. Une abstraction protège l’intention seulement si le système garde la preuve de sa projection. Sans cela, le Group ID devient un rideau posé devant la divergence qu’il devait aider à gérer.

Sources