Résumé

  • Le RFC 10065 ajoute aux ACL YANG des critères fondés sur des groupes et des conditions horaires ; il définit aussi un attribut RADIUS qui transporte l’identifiant d’un groupe d’utilisateurs.
  • Cet identifiant ne dit pas à lui seul qui a affecté le groupe, comment il correspond aux champs des paquets ni si chaque point d’application a reçu la règle voulue.

Analyse

Une adresse IP décrit mal, à elle seule, le rôle durable d’un utilisateur ou d’un appareil. Les clients VPN changent de réseau, les machines virtuelles migrent et les adresses IPv6 temporaires évoluent. Une ACL indexée sur une adresse ou un quintuplet reste utilisable, mais elle doit suivre ces déplacements. Le RFC 10065 propose un autre point d’ancrage : un groupe d’extrémités partageant une politique.

Le document étend le modèle YANG des ACL défini par le RFC 8519. Le module ietf-ucl-acl peut déclarer des groupes d’utilisateurs, d’appareils ou d’applications, puis faire correspondre un groupe source ou destination dans une entrée d’ACL. Il ajoute aussi un effective-schedule sous forme de période ou de récurrence, en réutilisant le modèle de planification du RFC 9922. Une valeur par défaut mérite une vérification particulière : sans calendrier configuré, l’entrée s’applique immédiatement et reste active en permanence.

Pour un accès utilisateur, l’attribut RADIUS User-Access-Group-ID transporte l’identifiant de groupe dans le parcours d’authentification. Le RFC 10065 lui attribue le type étendu 241.12 ; sa valeur est une chaîne d’au plus 64 octets. Un Access-Accept peut fournir un ou plusieurs identifiants après l’authentification. Un Access-Request peut exprimer une préférence, que le serveur n’est pas tenu de respecter. L’attribut peut aussi apparaître dans une demande Change-of-Authorization ou dans une demande de comptabilisation. Cette dernière peut permettre au NAS d’accuser réception de l’attribut et de signaler qu’il applique la règle.

Ce message ne constitue qu’un maillon. Le serveur AAA classe l’utilisateur selon des critères configurés localement. Un contrôleur peut ensuite associer l’identifiant de groupe aux champs des paquets et pousser des ACL classiques, fondées sur l’adresse ou le quintuplet, vers les points d’application. Autre option : les équipements appliquent eux-mêmes les critères de groupe. Le contrôleur central évite d’exiger une logique particulière sur chaque équipement, mais il doit propager les changements à temps.

L’application au niveau des équipements réduit certaines interactions avec le contrôleur, au prix d’éventuelles mises à niveau logicielles ou matérielles ; une exécution directe par le NAS peut également peser sur le débit de transfert.

La limite est essentielle : le RFC définit une interface, pas l’autorité d’identité d’une entreprise. Il ne fixe ni méthode d’authentification, ni preuve exigée pour affecter une personne à un groupe, ni correspondance entre identifiant de groupe et champs de paquet dans un encapsulage. Il exige qu’une configuration adéquate réalise cette correspondance et demande de la cohérence quand plusieurs mécanismes, dont RADIUS, coexistent. Le nom d’un groupe n’est donc pas une preuve autonome d’identité ou de droit ; sa portée dépend des systèmes locaux qui le créent et l’interprètent.

La surface de configuration a des conséquences directes. La liste des groupes, les critères de correspondance et les calendriers sont des données YANG modifiables. Un changement non autorisé peut créer ou supprimer un groupe, ouvrir un trafic qui devrait être refusé, bloquer un flux légitime ou déplacer une règle dans la mauvaise plage horaire. La lecture des calendriers peut révéler quand les règles sont actives. Le RFC demande une gestion NETCONF ou RESTCONF protégée par un transport sûr et une authentification mutuelle ; il renvoie au NACM pour limiter les opérations accessibles à chaque opérateur.

Pour RADIUS, il suppose une relation de confiance entre client et serveur ; IPsec ou TLS restent des protections facultatives dans ce document.

Le RFC est une Proposed Standard, pas une preuve d’adoption. Son apport est un vocabulaire commun pour des terminaux mobiles et des politiques conditionnées dans le temps. La question opérationnelle est de savoir si chaque installation conserve la chaîne complète entre authentification, affectation du groupe, correspondance de politique, installation de la règle et observation du trafic.

Sources