Résumé

  • La RFC 3169 traite les informations transmises par un Network Access Server (NAS) comme des éléments indicatifs, non comme des ordres ; le serveur AAA garde la décision finale d’autorisation.
  • Cette décision doit encore être appliquée au NAS. L’état des ressources, les journaux de comptabilité et le service effectivement reçu sont trois vérifications distinctes.

Le partage des rôles figure dans un document que l’on peut facilement prendre à tort pour une norme. Publiée en septembre 2001, la RFC 3169 est de catégorie Informational et précise qu’elle ne spécifie aucune norme Internet. Son titre — « Criteria for Evaluating Network Access Server Protocols » — annonce une grille d’évaluation plutôt qu’un nouveau format de paquet. Le texte répartit les protocoles liés aux NAS entre accès, réseau, AAA et gestion des équipements, puis se concentre sur l’AAA. Le modèle envisagé rassemble des accès téléphoniques, haut débit et par tunnel, parfois des milliers de sessions simultanées.

L’intérêt historique tient moins à l’étendue de la grille qu’à la manière dont elle distribue l’autorité. La section sur l’autorisation indique que les données envoyées par le NAS au serveur AAA doivent être comprises comme des « informations » ou des « indices », et non comme des directives. Le serveur prend la décision finale ; il ne doit pas présumer qu’un état existe simplement parce que le NAS s’y attend. Le texte refuse ainsi une confusion fréquente : l’équipement en bordure décrit une session, mais cette description ne l’autorise pas.

Une décision côté serveur n’est pourtant pas une politique déjà appliquée. La RFC 3169 prévoit que le protocole transporte un profil d’accès que le NAS devra mettre en œuvre. Le serveur AAA décide ce que la politique permet ; l’équipement doit encore installer ou appliquer le profil dans son propre contexte d’exécution. Un Access-Accept valide, une réponse de politique ou un message d’autorisation dynamique atteste donc une décision ou une demande. À lui seul, il ne prouve ni le changement d’état de l’interface, ni l’activation d’un filtre, ni l’obtention d’un service utilisable.

Les règles de gestion des ressources rendent cette différence tangible. La RFC 3169 envisage l’allocation et la libération de ressources partagées pendant une session : adresses, limites d’usage simultané, ports ou tunnels. Elle précise que cette fonction vise d’abord les ressources locales au NAS. Dans une configuration avec proxy ou plusieurs domaines administratifs, le serveur qui a alloué une ressource du domaine distant — ainsi que ses éventuels serveurs de secours — doit en conserver l’état. Les changements d’autorisation à distance relèvent des fonctions d’autorisation dynamique.

Décider d’un accès et détenir le registre courant qui permettra de reprendre ou de restaurer une ressource sont donc deux responsabilités différentes.

Cette séparation se voit lors des pannes. Le basculement vers un serveur secondaire peut préserver la politique d’autorisation sans reconstruire un quota de tunnels ou un pool d’adresses détenu par l’allocateur. Après le redémarrage d’un NAS, son état local peut diverger du registre de l’allocateur. Une demande de déconnexion peut être livrée sans être exécutée. C’est pourquoi la RFC 3169 demande des mécanismes de synchronisation et de reprise et déconseille de faire dépendre la gestion des ressources du flux de comptabilité.

Ce flux peut consigner l’usage ; il ne devient pas automatiquement le registre de verrouillage des ressources en cours.

La comptabilité est une autre voie de preuve, non le substitut des trois précédentes. La RFC 3169 demande une transmission fiable, qualifie de temps réel une livraison qui commence dans la seconde suivant l’événement déclencheur et exige des horodatages sans ambiguïté. Ce sont des critères pour évaluer les protocoles, pas des résultats constatés dans un réseau. Recevoir un rapport à temps ne prouve pas qu’un paquet est arrivé, que chaque événement a été enregistré ni qu’un consommateur ultérieur a correctement reconstitué la session. La réception en temps réel n’est pas une vérité de terrain en temps réel.

Les protocoles voisins éclairent le contexte sans prouver qu’un successeur satisfait l’ensemble de la grille. RADIUS avait déjà des spécifications distinctes pour l’authentification/autorisation et la comptabilité. La RFC 3169 demande aux protocoles AAA candidats de prendre en charge ces ensembles d’attributs, l’interopérabilité, l’extensibilité, plusieurs serveurs et les relations entre domaines. Publiée plus tard, la RFC 6733 présente Diameter comme protocole de base pour des applications AAA ; l’autorisation dynamique, le transport d’EAP et la protection des transports ont également évolué dans des textes séparés.

Leur existence ne constitue pas un audit de conformité à toutes les exigences de la RFC 3169. Les guides ultérieurs de conception RADIUS reconnaissent d’ailleurs les limites de taille et de modèle de données, plutôt que de traiter un espace immense d’attributs comme une capacité d’implémentation illimitée.

Lue comme une source d’histoire d’Internet, la RFC 3169 cartographie les frontières de contrôle : le NAS apporte des observations de session, le serveur AAA détient le rôle d’autorisation finale, le NAS applique la politique, l’allocateur conserve l’état courant des ressources et la comptabilité produit un relevé distinct. Ces acteurs peuvent échanger au sein d’une famille de protocoles, mais aucun message unique n’atteste toute la chaîne. Ce texte ne conclut rien sur les taux d’adoption, les produits ou les déploiements actuels.

Il retient la leçon plus étroite de la RFC : dans une opération distribuée, une décision centrale n’est qu’un reçu parmi d’autres.

Sources : RFC 3169 ; notice actuelle de RFC 3169 ; fiche Datatracker de RFC 3169 ; modèle NAS de RFC 2881 ; RADIUS, RFC 2865 ; comptabilité RADIUS, RFC 2866 ; extensions RADIUS, RFC 2869 ; évaluation des protocoles AAA, RFC 2989 ; EAP dans RADIUS, RFC 3579 ; autorisation dynamique, RFC 5176 ; guide de conception RADIUS, RFC 6158 ; RADIUS sur TLS, RFC 6614 ; protocole de base Diameter, RFC 6733 ; RADIUS/1.1, RFC 9765 ; Lu Heng, « Quand le comptable tente l’Olympe ».