1. Introduction
La gestion de pools dispersés de lignes série et de modems pour de très nombreux utilisateurs peut imposer une charge administrative importante. Les pools de modems sont, par définition, un lien vers le monde extérieur ; ils exigent une attention particulière à la sécurité, à l'autorisation et à la comptabilité (accounting). On y parvient le mieux en gérant une « base de données » unique d'utilisateurs, qui permet à la fois l'authentification (authentication, vérification du nom d'utilisateur et du mot de passe) et des informations de configuration détaillant le type de service à fournir à l'utilisateur (par exemple SLIP, PPP, telnet, rlogin).
Le document RADIUS (Remote Authentication Dial In User Service) [2] spécifie le protocole RADIUS utilisé pour l'authentification et l'autorisation. Ce mémo étend l'usage du protocole RADIUS à la transmission des informations de comptabilité du serveur d'accès réseau (Network Access Server, NAS) vers un serveur de comptabilité RADIUS.
Ce document rend obsolète la RFC 2139 [1]. Un résumé des changements entre ce document et la RFC 2139 figure dans l'annexe « Change Log » (journal des modifications).
Les caractéristiques principales de RADIUS Accounting sont les suivantes :
Modèle client/serveur
Un serveur d'accès réseau (NAS) fonctionne comme client du serveur de comptabilité RADIUS. Le client est chargé de transmettre les informations de comptabilité utilisateur à un serveur de comptabilité RADIUS désigné.
Le serveur de comptabilité RADIUS est chargé de recevoir la demande de comptabilité (Accounting-Request) et de renvoyer au client une réponse indiquant que la demande a été reçue avec succès.
Le serveur de comptabilité RADIUS peut agir comme client mandataire (proxy client) vis-à-vis d'autres types de serveurs de comptabilité.
Sécurité réseau
Les transactions entre le client et le serveur de comptabilité RADIUS sont authentifiées au moyen d'un secret partagé (shared secret), qui n'est jamais envoyé sur le réseau.
Protocole extensible
Toutes les transactions sont composées de triplets Attribute-Length-Value (attribut-longueur-valeur) de longueur variable. De nouvelles valeurs d'attribut peuvent être ajoutées sans perturber les implémentations existantes du protocole.
1.1. Spécification des exigences
Les mots-clés « MUST » (DOIT), « MUST NOT » (NE DOIT PAS), « REQUIRED » (REQUIS), « SHALL », « SHALL NOT », « SHOULD » (DEVRAIT), « SHOULD NOT » (NE DEVRAIT PAS), « RECOMMENDED » (RECOMMANDÉ), « MAY » (PEUT) et « OPTIONAL » (OPTIONNEL), lorsqu'ils apparaissent dans ce document, doivent être interprétés comme décrit dans la RFC 2119 [3]. Ces mots-clés ont la même signification qu'ils soient en majuscules ou non.
1.2. Terminologie
Ce document utilise les termes suivants :
service
Le NAS fournit un service à l'utilisateur qui se connecte, tel que PPP ou Telnet.
session
Chaque service fourni par le NAS à un utilisateur qui se connecte constitue une session ; le début de session est le point où le service est fourni pour la première fois, et la fin de session est le point où le service prend fin. Un utilisateur peut avoir plusieurs sessions en parallèle ou en série si le NAS le permet, chaque session générant un enregistrement de comptabilité Start et Stop distinct avec son propre Acct-Session-Id.
silently discard (rejet silencieux)
Cela signifie que l'implémentation rejette le paquet sans traitement ultérieur. L'implémentation DEVRAIT offrir la possibilité d'enregistrer l'erreur, y compris le contenu du paquet rejeté silencieusement, et DEVRAIT consigner l'événement dans un compteur statistique.