2. Operation (Funzionamento)

Quando un client è configurato per usare RADIUS Accounting, all'inizio dell'erogazione del servizio genererà un Accounting Start packet (pacchetto Accounting Start) che descrive il tipo di servizio erogato e l'utente a cui è erogato, e lo invierà al server RADIUS Accounting, che risponderà con un acknowledgement (ricevuta) che il pacchetto è stato ricevuto. Alla fine dell'erogazione del servizio il client genererà un Accounting Stop packet (pacchetto Accounting Stop) che descrive il tipo di servizio erogato e, facoltativamente, statistiche come tempo trascorso, octet (ottetti) in ingresso e in uscita, o pacchetti in ingresso e in uscita. Lo invierà al server RADIUS Accounting, che risponderà con un acknowledgement che il pacchetto è stato ricevuto.

L'Accounting-Request (sia per Start che per Stop) viene inviato al server RADIUS accounting tramite la rete. Si raccomanda che il client continui a tentare l'invio del pacchetto Accounting-Request finché non riceve un acknowledgement, usando una forma di backoff. Se non viene restituita alcuna risposta entro un intervallo di tempo, la richiesta viene reinviata un certo numero di volte. Il client può anche inoltrare le richieste a un server alternativo o a più server nel caso in cui il server primario sia non disponibile o irraggiungibile. Un server alternativo può essere usato dopo un certo numero di tentativi falliti verso il server primario, oppure in modo round-robin. Gli algoritmi di retry e fallback sono oggetto di ricerca in corso e non sono specificati in dettaglio in questo documento.

Il server RADIUS accounting PUÒ effettuare richieste ad altri server per soddisfare la richiesta, nel qual caso agisce come client.

Se il server RADIUS accounting non è in grado di registrare con successo il pacchetto di accounting, NON DEVE inviare al client un acknowledgement Accounting-Response.

2.1. Proxy

Si veda la RFC «RADIUS» [2] per informazioni su Proxy RADIUS. Il Proxy Accounting RADIUS funziona allo stesso modo, come illustrato dal seguente esempio.

1. Il NAS invia un accounting-request al forwarding server (server di inoltro).

2. Il forwarding server registra l'accounting-request (se desiderato), aggiunge il suo Proxy-State (se desiderato) dopo eventuali altri attributi Proxy-State, aggiorna il Request Authenticator e inoltra la richiesta al remote server (server remoto).

3. Il remote server registra l'accounting-request (se desiderato), copia tutti gli attributi Proxy-State in ordine e non modificati dalla richiesta al pacchetto di risposta, e invia l'accounting-response al forwarding server.

4. Il forwarding server rimuove l'ultimo Proxy-State (se ne aveva aggiunto uno al passo 2), aggiorna il Response Authenticator e invia l'accounting-response al NAS.

Un forwarding server NON DEVE modificare attributi Proxy-State o Class già presenti nel pacchetto.

Un forwarding server può svolgere la funzione di inoltro in modalità pass-through, inviando le ritrasmissioni non appena le riceve, oppure può assumersi la responsabilità delle ritrasmissioni, ad esempio nei casi in cui il collegamento di rete tra forwarding e remote server ha caratteristiche molto diverse dal collegamento tra NAS e forwarding server.

Occorre prestare estrema cautela nell'implementare un proxy server che si assuma la responsabilità delle ritrasmissioni, affinché la sua politica di ritrasmissione sia robusta e scalabile.