Résumé

  • Publiée en octobre 2026 comme Proposed Standard, la RFC 10065 étend le modèle YANG de l’IETF pour les ACL avec des correspondances par groupe de terminaux et des règles limitées à une période ou à une récurrence.
  • Son attribut RADIUS User-Access-Group-ID donne une place définie au groupe d’un utilisateur authentifié. Relier cet identifiant aux champs des paquets ou à l’application effective sur les équipements reste une tâche de déploiement.

La règle peut avoir des heures de bureau

Imaginons un compte de maintenance qui ne doit accéder à un sous-réseau d’administration que pendant une intervention de 90 minutes. Une liste de contrôle d’accès classique peut comparer adresses et ports ; la RFC 10065 ajoute une façon d’exprimer l’appartenance à un groupe de terminaux et le moment où une entrée de contrôle d’accès prend effet. La règle peut couvrir une période précise ou suivre une récurrence. Sans calendrier configuré, l’entrée s’applique immédiatement et en permanence.

Cette dernière valeur par défaut est le genre de petite ligne qui coûte cher lorsqu’on la recopie dans un modèle. Une condition horaire ne contrôle l’accès que si elle arrive jusqu’à l’équipement chargé de l’appliquer.

La RFC 10065 étend le modèle de l’IETF pour les listes de contrôle d’accès. Son module User-group-based Control List peut comparer l’identifiant d’un groupe source ou destination et associer une période ou une récurrence à une entrée. Ces deux formes réutilisent la RFC 9922. Le modèle partagé prévoit aussi un identifiant de fuseau horaire lorsqu’il est nécessaire.

Pour l’accès des personnes, le texte définit User-Access-Group-ID, l’attribut RADIUS 241.12. Après authentification, un serveur RADIUS peut renvoyer un ou plusieurs identifiants de groupe dans un Access-Accept. Un Access-Request peut transmettre l’attribut à titre de préférence, mais le serveur n’est pas tenu de la suivre. La demande de connexion ne choisit donc pas elle-même ses permissions.

La chaîne dépasse le libellé

Entre la connexion et le paquet, plusieurs décisions s’enchaînent. Un utilisateur s’authentifie auprès d’un Network Access Server ; un serveur d’authentification, d’autorisation et de comptabilité lui attribue un groupe ; un contrôleur ou un équipement d’application doit ensuite relier ce groupe au trafic observé. La RFC décrit deux voies générales. Un contrôleur peut convertir le groupe en champs de paquets, par exemple une adresse IP ou un cinq-tuple, puis installer des règles ACL classiques aux points d’application. Un équipement peut aussi comparer directement l’identifiant de groupe, si son logiciel ou son matériel le permet.

La norme ne définit ni la correspondance entre groupe et champs de paquet, ni la notification exacte qui la transmet à un contrôleur. Elle demande explicitement aux opérateurs de vérifier la cohérence des correspondances lorsque plusieurs mécanismes coexistent. Le groupe d’un utilisateur peut également changer si les attributs qui servent à le classer évoluent. Une réponse RADIUS propre ne constitue pas une liaison d’identité permanente.

Le choix est opérationnel. La traduction côté contrôleur permet à des équipements existants de continuer à appliquer des règles d’adresse familières, mais elle doit suivre les changements d’identité, d’adresse et de politique. La correspondance directe par groupe peut éviter des mises à jour fréquentes quand une personne ou une charge de travail se déplace ; elle exige des équipements compatibles et peut influer sur le débit d’acheminement. La RFC signale que certains appareils auront besoin d’une mise à niveau logicielle ou matérielle. Elle ne publie ni taux d’adoption ni mesure de performance.

Le champ horaire ajoute une autre frontière de gestion. La RFC avertit qu’un rédacteur non autorisé pourrait modifier l’appartenance aux groupes, les critères de correspondance ou le calendrier. Lire ce calendrier peut révéler les heures d’activation d’une règle. Une horloge à côté d’une ACL est utile ; une horloge dont personne ne contrôle les réglages devient une autre voie d’accès.

La prochaine preuve utile serait une déclaration d’équipement ou de contrôleur indiquant les fonctions de groupe et de calendrier prises en charge, puis une trace montrant le groupe renvoyé, la règle installée et son état au début et à la fin de la plage. En attendant, la RFC 10065 fournit un vocabulaire commun pour les politiques de groupe temporisées. La correspondance et l’application restent dans les systèmes en fonctionnement de l’opérateur.

Sources