2. Fonctionnement

Lorsqu'un client est configuré pour utiliser RADIUS Accounting, au début de la fourniture du service il génère un paquet Accounting Start décrivant le type de service fourni et l'utilisateur auquel il est fourni, et l'envoie au serveur RADIUS Accounting, qui renvoie un accusé de réception indiquant que le paquet a été reçu. À la fin de la fourniture du service, le client génère un paquet Accounting Stop décrivant le type de service qui a été fourni et, éventuellement, des statistiques telles que la durée écoulée, les octets d'entrée et de sortie, ou les paquets d'entrée et de sortie. Il l'envoie au serveur RADIUS Accounting, qui renvoie un accusé de réception indiquant que le paquet a été reçu.

L'Accounting-Request (qu'il s'agisse de Start ou de Stop) est soumis au serveur de comptabilité RADIUS via le réseau. Il est recommandé que le client continue à tenter d'envoyer le paquet Accounting-Request jusqu'à réception d'un accusé de réception, en utilisant une forme de temporisation avec recul progressif (backoff). Si aucune réponse n'est renvoyée dans un certain délai, la demande est renvoyée un certain nombre de fois. Le client peut également transmettre les demandes à un ou plusieurs serveurs de secours lorsque le serveur principal est indisponible ou inaccessible. Un serveur de secours peut être utilisé soit après un certain nombre d'échecs vers le serveur principal, soit selon une répartition round-robin. Les algorithmes de nouvelle tentative et de repli font l'objet de recherches en cours et ne sont pas spécifiés en détail dans ce document.

Le serveur de comptabilité RADIUS PEUT adresser des demandes à d'autres serveurs afin de satisfaire la requête ; dans ce cas, il agit comme un client.

Si le serveur de comptabilité RADIUS ne parvient pas à enregistrer correctement le paquet de comptabilité, il NE DOIT PAS envoyer au client d'accusé de réception Accounting-Response.

2.1. Proxy

Voir la RFC « RADIUS » [2] pour des informations sur Proxy RADIUS. Le mandataire de comptabilité RADIUS (Proxy Accounting RADIUS) fonctionne de la même manière, comme l'illustre l'exemple suivant.

1. Le NAS envoie un accounting-request au serveur de relais (forwarding server).
2. Le serveur de relais enregistre l'accounting-request (s'il le souhaite), ajoute son Proxy-State (s'il le souhaite) après tout autre attribut Proxy-State, met à jour le Request Authenticator et transmet la demande au serveur distant.
3. Le serveur distant enregistre l'accounting-request (s'il le souhaite), copie tous les attributs Proxy-State dans l'ordre et sans modification de la demande vers le paquet de réponse, et envoie l'accounting-response au serveur de relais.
4. Le serveur de relais retire le dernier Proxy-State (s'il en avait ajouté un à l'étape 2), met à jour le Response Authenticator et envoie l'accounting-response au NAS.

Un serveur de relais NE DOIT PAS modifier les attributs Proxy-State ou Class déjà présents dans le paquet.

Un serveur de relais peut soit assurer sa fonction de relais en mode pass-through, en renvoyant les retransmissions dès qu'il les reçoit, soit prendre en charge les retransmissions, par exemple lorsque la liaison réseau entre le relais et le serveur distant a des caractéristiques très différentes de la liaison entre le NAS et le serveur de relais.

Une extrême prudence s'impose lors de l'implémentation d'un serveur mandataire qui prend en charge les retransmissions, afin que sa politique de retransmission soit robuste et évolutive (scalable).