8. Sessioni utente Diameter
In generale, Diameter può fornire alle applicazioni due tipi distinti di servizi. Il primo riguarda autenticazione e autorizzazione e può eventualmente usare l'accounting. Il secondo usa solo l'accounting.
Quando un servizio impiega la parte di autenticazione e/o autorizzazione di un'applicazione e un utente richiede l'accesso alla rete, il client Diameter invia una richiesta di autenticazione al proprio server locale. La richiesta è definita in un'applicazione Diameter specifica del servizio (ad es. NASREQ). Contiene un Session-Id AVP, usato nei messaggi successivi (autorizzazioni successive, accounting, ecc.) relativi alla sessione utente. Il Session-Id AVP consente a client e server di correlare un messaggio Diameter con una sessione utente.
Quando un server Diameter autorizza un utente a usare risorse di rete per un tempo finito ed è disposto a estendere l'autorizzazione con una richiesta futura, DEVE aggiungere l'Authorization-Lifetime AVP al messaggio di risposta. Tale AVP definisce il numero massimo di secondi in cui l'utente PUÒ usare le risorse prima che il server si aspetti un'altra richiesta di autorizzazione. L'Auth-Grace-Period AVP indica i secondi dopo la scadenza dell'Authorization-Lifetime prima che il server rilasci tutto lo stato relativo alla sessione utente. Se il realm di servizio si aspetta un pagamento dal realm home dell'utente, l'Authorization-Lifetime insieme all'Auth-Grace-Period implica la durata massima della sessione per cui il realm home accetta responsabilità finanziaria. I servizi erogati oltre la scadenza di questi AVP sono a carico del dispositivo di accesso. Il costo effettivo dei servizi è al di fuori del protocollo.
Un dispositivo di accesso che non prevede di inviare una ri-autorizzazione o una richiesta di terminazione sessione al server PUÒ includere l'Auth-Session-State AVP con valore NO_STATE_MAINTAINED come suggerimento. Se il server accetta, concorda che non riceverà messaggi di fine sessione dopo l'interruzione del servizio e non può mantenere lo stato. Se la risposta del server contiene un valore diverso (o il valore predefinito se l'AVP è assente), il dispositivo di accesso DEVE seguire le direttive del server. Il valore NO_STATE_MAINTAINED NON DEVE essere impostato in richieste e risposte di ri-autorizzazione successive.
Il protocollo base non include messaggi di richiesta di autorizzazione, poiché sono in gran parte specifici dell'applicazione e definiti in un documento di applicazione Diameter. Definisce però un insieme di messaggi per terminare le sessioni utente, così che i server che mantengono lo stato possano liberare risorse.
Quando un servizio usa solo la parte accounting di Diameter, anche in combinazione con un'applicazione, il Session-Id identifica comunque le sessioni utente. I messaggi di terminazione sessione non si usano: la sessione si considera terminata inviando un accounting stop.
Diameter può anche servire per servizi non facilmente classificabili come autenticazione, autorizzazione o accounting (ad es. alcune interfacce IMS 3GPP). In tali casi la macchina a stati finiti definita nelle sezioni seguenti può non applicarsi; l'applicazione stessa PUÒ dover definirne una propria. Tali macchine a stati specifiche Dovrebbero seguire il quadro generale di questo documento, ad es. uso di Session-Id AVP e messaggi STR/STA, ASR/ASA per sessioni con stato.
8.1. Macchina a stati per la sessione di autorizzazione
Questa sezione contiene macchine a stati finiti che rappresentano il ciclo di vita delle sessioni Diameter e che DEVONO essere osservate da ogni implementazione Diameter che usa la parte di autenticazione e/o autorizzazione di un'applicazione Diameter. Il termine "Service-Specific" qui indica un messaggio definito in un'applicazione Diameter (ad es. Mobile IPv4, NASREQ).
Il protocollo base supporta quattro macchine a stati per la sessione di autorizzazione. Le prime due descrivono una sessione il cui stato è mantenuto dal server (valore dell'Auth-Session-State AVP o sua assenza): una dal lato client, l'altra dal lato server. Le altre due si applicano quando il server non mantiene lo stato, ancora con prospettiva client e server.
Quando una sessione passa allo stato Idle, le risorse allocate per quella sessione devono essere rilasciate. Qualsiasi evento non elencato DEVE essere trattato come errore e, se applicabile, una risposta DEVE essere restituita all'origine del messaggio.
Se un'applicazione non supporta la ri-autenticazione, le transizioni relative alla ri-autenticazione avviata dal server quando client e server mantengono lo stato (invio RAR, Pending, ricezione RAA) POSSONO essere ignorate.
Nella tabella, "Failure to send X" significa che l'agent Diameter non può inviare il comando X alla destinazione desiderata: peer non raggiungibile o fallimento transitorio o errore di protocollo temporaneo DIAMETER_TOO_BUSY o DIAMETER_LOOP_DETECTED nel Result-Code AVP della risposta corrispondente. "X successfully sent" è il complemento di "Failure to send X".
La seguente macchina a stati è osservata dal client quando lo stato è mantenuto sul server (tabella come nel testo inglese RFC 6733):
CLIENT, STATEFUL
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Client or device requests access Send service-specific Pending
auth req auth req
Idle ASR Received for unknown session Send ASA with Idle
Result-Code =
UNKNOWN_SESSION_ID
Idle RAR Received for unknown session Send RAA with Idle
Result-Code =
UNKNOWN_SESSION_ID
Pending Successful service-specific authorization Grant Access Open
answer received with default
Auth-Session-State value
Pending Successful service-specific authorization Sent STR Discon
answer received,
but service not provided
Pending Error processing successful Sent STR Discon
service-specific authorization
answer
Pending Failed service-specific authorization Clean up Idle
answer received
Open User or client device requests access Send service-specific Open
auth req auth req
Open Successful service-specific authorization Provide service Open
answer received
Open Failed service-specific authorization Discon. user/device Idle
answer received.
Open RAR received and client will perform Send RAA with Open
subsequent re-auth Result-Code =
SUCCESS
Open RAR received and client will not perform Send RAA with Idle
subsequent re-auth Result-Code !=
SUCCESS,
Discon. user/device
Open Session-Timeout expires on access device Send STR Discon
Open ASR received, client will comply with Send ASA with Discon
request to end the session Result-Code =
SUCCESS,
Send STR.
Open ASR Received, client will not comply with Send ASA with Open
request to end the session Result-Code !=
SUCCESS
Open Authorization-Lifetime + Auth-Grace-Period Send STR Discon
expires on access device
Discon ASR received Send ASA Discon
Discon STA received Discon. user/device Idle
Macchina a stati osservata dal server quando mantiene lo stato della sessione:
SERVER, STATEFUL
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Service-specific authorization request Send successful Open
received, and user is authorized service-specific
answer
Idle Service-specific authorization request Send failed Idle
received, and user is not authorized service-specific
answer
Open Service-specific authorization request Send successful Open
received, and user is authorized service-specific
answer
Open Service-specific authorization request Send failed Idle
received, and user is not authorized service-specific
answer,
Clean up
Open Home server wants to confirm authentication Send RAR Pending
and/or authorization of the user
Pending Received RAA with a failed Result-Code Clean up Idle
Pending Received RAA with Result-Code = SUCCESS Update session Open
Open Home server wants to terminate the service Send ASR Discon
Open Authorization-Lifetime (and Auth-Grace-Period) Clean up Idle
expires on home server
Open Session-Timeout expires on home server Clean up Idle
Discon Failure to send ASR Wait, resend ASR Discon
Discon ASR successfully sent and ASA Received Clean up Idle
with Result-Code
Not Discon ASA Received None No Change
Discon Any STR Received Send STA, Clean up Idle
Dal lato client quando il server non mantiene lo stato:
CLIENT, STATELESS
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Client or device requests access Send service-specific Pending
auth req auth req
Pending Successful service-specific authorization Grant access Open
answer received with Auth-Session-
State set to NO_STATE_MAINTAINED
Pending Failed service-specific authorization Clean up Idle
answer received
Open Session-Timeout expires on access device Discon. user/device Idle
Open Service to user is terminated Discon. user/device Idle
Dal lato server quando il server non mantiene lo stato della sessione:
SERVER, STATELESS
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Service-specific authorization request Send successfully Idle
received, and successfully processed processed service-
specific answer
8.2. Macchina a stati della sessione di accounting
Le applicazioni che includono una parte accounting o che richiedono solo accounting DEVONO supportare le seguenti macchine a stati. La prima si applica ai client.
Codici comando accounting: sezione 9.7; AVP accounting: sezione 9.8.
Il lato server della macchina a stati accounting dipende in parte dall'applicazione. Il protocollo base definisce una macchina a stati server predefinita che TUTTE le applicazioni che non ne definiscono un'altra DEVONO seguire: è la seconda macchina in questa sezione.
La macchina server predefinita accetta record accounting in qualsiasi ordine e in qualsiasi momento, senza requisiti normativi sul loro trattamento. Le implementazioni possono eseguire controlli, ordinamento, correlazione, rilevamento frodi, ecc. Gli AVP possono essere ispezionati. L'elaborazione può essere immediata o differita; tali attività dipendono spesso dall'applicazione o dalla policy e non sono normalizzate. Le applicazioni POSSONO specificare quando accettare record in base al valore dell'Accounting-Realtime-Required AVP, ai limiti di credito, ecc.
Una terza macchina server, opzionale, PUÒ essere seguita se lo stato della sessione deve essere tracciato sul server accounting. Tale tracciamento è incompatibile con lunghi guasti di connettività. Si raccomanda solo quando Accounting-Realtime-Required vale DELIVER_AND_GRANT, così che l'utente debba essere disconnesso in caso di problemi di connettività accounting. Altrimenti i record generati dal client possono andare persi quando il server non li accetta più dopo il ripristino. La macchina è supervisionata da un timer di sessione Ts, ragionevolmente maggiore di Acct_Interim_Interval; Ts PUÒ essere il doppio di Acct_Interim_Interval per evitare di passare a Idle dopo un breve guasto transitorio.
Qualsiasi evento non elencato DEVE essere considerato errore; una risposta appropriata DEVE essere restituita se applicabile.
"Failure to send": il client Diameter non può raggiungere la destinazione (peer non raggiungibile o fallimento transitorio DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, DIAMETER_LOOP_DETECTED nell'Accounting Answer).
"Failed answer": notifica di fallimento non transitorio nell'Accounting Answer.
L'azione "Disconnect user/dev" DEVE influenzare anche la tabella di stato di autorizzazione (ad es. invio STR) se l'applicazione combina autenticazione/autorizzazione e accounting.
PendingS, PendingI, PendingL, PendingE e PendingB indicano l'attesa di risposta per richieste accounting Start, Interim, Stop, Event o bufferizzata (tabella come nel testo inglese RFC 6733).
CLIENT, ACCOUNTING
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Client or device requests access Send accounting PendingS
accounting start req. start req.
Idle Client or device requests a one-time service Send accounting PendingE
accounting event req event req
Idle Records in storage Send record PendingB
record
PendingS Successful accounting start answer received Open
PendingS Failure to send and buffer space available Store Start Open
and real time not equal to Record
DELIVER_AND_GRANT
PendingS Failure to send and no buffer space available Open
and real time equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer space available Disconnect user/dev Idle
and real time not equal to
GRANT_AND_LOSE
PendingS Failed accounting start answer received and Open
real time equal to GRANT_AND_LOSE
PendingS Failed accounting start answer received and Disconnect user/dev Idle
real time not equal to GRANT_AND_LOSE
PendingS User service terminated stop Store stop PendingS
record
Open Interim interval elapses Send accounting PendingI
interim
record
Open User service terminated Send accounting PendingL
stop req.
PendingI Successful accounting interim answer received Open
PendingI Failure to send and (buffer space available Store interim Open
or old interim record can be overwritten) record
and real time not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer space available Open
and real time equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer space available Disconnect user/dev Idle
and real time not equal to GRANT_AND_LOSE
PendingI Failed accounting interim answer received and Open
real time equal to GRANT_AND_LOSE
PendingI Failed accounting interim answer received and Disconnect user/dev Idle
real time not equal to GRANT_AND_LOSE
PendingI User service terminated stop Store stop PendingI
record
PendingE Successful accounting event answer received Idle
PendingE Failure to send and buffer space available Store event Idle
record
PendingE Failure to send and no buffer space available Idle
PendingE Failed accounting event answer received Idle
PendingB Successful accounting answer received Delete record Idle
PendingB Failure to send Idle
PendingB Failed accounting answer received Delete record Idle
PendingL Successful accounting stop answer received Idle
PendingL Failure to send and buffer space available Store stop Idle
record
PendingL Failure to send and no buffer space available Idle
PendingL Failed accounting stop answer received Idle
SERVER, STATELESS ACCOUNTING
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Accounting start request received and Send accounting Idle
successfully processed. start answer
Idle Accounting event request received and Send accounting Idle
successfully processed. event answer
Idle Interim record received and successfully Send accounting Idle
processed. interim answer
Idle Accounting stop request received and Send accounting Idle
successfully processed stop answer
Idle Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE
SERVER, STATEFUL ACCOUNTING
State Event Action New State
---------------------------------------------------------------------------------------------------
Idle Accounting start request received and Send accounting Open
successfully processed. start answer;
Start Ts
Idle Accounting event request received and Send accounting Idle
successfully processed. event answer
Idle Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE
Open Interim record received and successfully Send accounting Open
processed. interim answer;
Restart Ts
Open Accounting stop request received and Send accounting Idle
successfully processed stop answer;
Stop Ts
Open Accounting request received; no space left Send accounting Idle
to store records answer;
Result-Code =
OUT_OF_SPACE;
Stop Ts
Open Session supervision timer Ts expired Stop Ts Idle
8.3. Ri-autenticazione avviata dal server
Un server Diameter può avviare un servizio di ri-autenticazione e/o ri-autorizzazione per una particolare sessione emettendo una Re-Auth-Request (RAR).
Ad esempio, per servizi prepagati, il server Diameter che ha originariamente autorizzato la sessione può aver bisogno di conferma che l'utente stia ancora usando i servizi.
Un dispositivo di accesso che riceve un RAR con Session-Id uguale a una sessione attualmente attiva DEVE avviare una ri-autenticazione verso l'utente, se il servizio supporta questa funzionalità. Ogni applicazione Diameter DEVE dichiarare se la ri-autenticazione avviata dal server è supportata, poiché alcune applicazioni non consentono al dispositivo di accesso di sollecitare l'utente per la ri-autenticazione.
8.3.1. Re-Auth-Request
La Re-Auth-Request (RAR), indicata da Command Code 258 e bit "R" dei flag impostato, può essere inviata da qualsiasi server al dispositivo di accesso che fornisce il servizio di sessione, per richiedere che l'utente sia ri-autenticato e/o ri-autorizzato.
Formato del messaggio
::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
8.3.2. Re-Auth-Answer
La Re-Auth-Answer (RAA), indicata da Command Code 258 e bit "R" azzerato, è inviata in risposta al RAR. Il Result-Code AVP DEVE essere presente e indica l'esito della richiesta.
Dopo un RAA con successo DEVE seguire un messaggio di autenticazione e/o autorizzazione specifico dell'applicazione.
Formato del messaggio
::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
8.4. Terminazione della sessione
È necessario che un server Diameter che ha autorizzato una sessione per cui mantiene lo stato venga avvisato quando quella sessione non è più attiva, sia per il tracciamento sia per consentire agli agent con stato di rilasciare le risorse fornite per la sessione utente. Per le sessioni il cui stato non è mantenuto, questa sezione non si usa.
Quando una sessione utente che richiedeva autorizzazione Diameter termina, il dispositivo di accesso che ha fornito il servizio DEVE emettere un Session-Termination-Request (STR) al server Diameter che ha autorizzato il servizio. Un STR DEVE essere emesso quando una sessione utente termina per qualsiasi motivo, inclusi logout utente, scadenza del Session-Timeout, azione amministrativa, terminazione alla ricezione di un Abort-Session-Request (vedi sotto), spegnimento ordinato del dispositivo di accesso, ecc.
Il dispositivo di accesso DEVE emettere anche uno STR per una sessione autorizzata ma mai effettivamente avviata (ad es. per improvvisa carenza di risorse, perché il dispositivo non è disposto a fornire il tipo di servizio richiesto nell'autorizzazione, o perché non supporta un AVP obbligatorio restituito nell'autorizzazione, ecc.).
È anche possibile che una sessione autorizzata non venga mai avviata per azione di un proxy. Ad esempio un proxy può modificare una risposta di autorizzazione convertendo il risultato da successo a fallimento prima di inoltrarla al dispositivo di accesso. Se la risposta non conteneva un Auth-Session-State AVP con valore NO_STATE_MAINTAINED, un proxy che impedisce l'avvio di una sessione autorizzata DEVE emettere uno STR al server Diameter che ha autorizzato la sessione, poiché il dispositivo di accesso non ha modo di sapere che la sessione era stata autorizzata.
Un server Diameter che riceve uno STR DEVE ripulire le risorse (ad es. stato di sessione) associate al Session-Id specificato nello STR e restituire un Session-Termination-Answer.
Un server Diameter DEVE inoltre ripulire le risorse alla scadenza del Session-Timeout o quando scadono l'Authorization-Lifetime e l'Auth-Grace-Period AVP senza ricezione di una richiesta di ri-autorizzazione, indipendentemente dal fatto che sia stato ricevuto uno STR per quella sessione. Non ci si aspetta servizio oltre la scadenza di questi timer; la scadenza di uno di essi implica che il dispositivo di accesso possa essersi spento in modo imprevisto.
8.4.1. Session-Termination-Request
La Session-Termination-Request (STR), indicata da Command Code 275 e bit "R" dei Command Flags impostato, è inviata da un client Diameter o da un proxy Diameter per informare il server Diameter che una sessione autenticata e/o autorizzata sta terminando.
Formato del messaggio
::= < Diameter Header: 275, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause }
[ User-Name ]
[ Destination-Host ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
8.4.2. Session-Termination-Answer
La Session-Termination-Answer (STA), indicata da Command Code 275 e bit "R" azzerato, è inviata dal server Diameter per confermare la notifica che la sessione è terminata. Il Result-Code AVP DEVE essere presente e PUÒ contenere un'indicazione che si è verificato un errore durante l'elaborazione dello STR.
Dopo l'invio o la ricezione della STA, il server Diameter DEVE rilasciare tutte le risorse per la sessione indicata dal Session-Id AVP. Qualsiasi server intermedio nella Proxy-Chain PUÒ anche rilasciare risorse, se necessario.
Formato del messaggio
::= < Diameter Header: 275, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
* [ Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
8.5. Interruzione forzata di una sessione
Un server Diameter può richiedere che il dispositivo di accesso cessi di fornire servizio per una particolare sessione emettendo un Abort-Session-Request (ASR).
Ad esempio, il server Diameter che ha originariamente autorizzato la sessione può dover far terminare quella sessione per mancanza di credito o altri motivi non previsti quando la sessione è stata prima autorizzata.
Un dispositivo di accesso che riceve un ASR con Session-Id uguale a una sessione attualmente attiva PUÒ interrompere la sessione. Se il dispositivo interrompa o meno la sessione dipende dall'implementazione e/o dalla configurazione. Ad esempio un dispositivo può onorare gli ASR solo da certi agent. In ogni caso, il dispositivo di accesso DEVE rispondere con un Abort-Session-Answer che include un Result-Code AVP per indicare l'azione intrapresa.
8.5.1. Abort-Session-Request
L'Abort-Session-Request (ASR), indicata da Command Code 274 e bit "R" dei flag impostato, può essere inviata da qualsiasi server Diameter o proxy Diameter al dispositivo di accesso che fornisce il servizio di sessione, per richiedere che la sessione identificata dal Session-Id venga interrotta.
Formato del messaggio
::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
8.5.2. Abort-Session-Answer
L'Abort-Session-Answer (ASA), indicata da Command Code 274 e bit "R" azzerato, è inviata in risposta all'ASR. Il Result-Code AVP DEVE essere presente e indica l'esito della richiesta.
Se la sessione identificata dal Session-Id nell'ASR è stata terminata con successo, il Result-Code è DIAMETER_SUCCESS. Se la sessione non è attualmente attiva, il Result-Code è DIAMETER_UNKNOWN_SESSION_ID. Se il dispositivo di accesso non interrompe la sessione per qualsiasi altro motivo, il Result-Code è DIAMETER_UNABLE_TO_COMPLY.
Formato del messaggio
::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]
8.6. Dedurre la terminazione della sessione da Origin-State-Id
L'Origin-State-Id consente di rilevare sessioni terminate per cui non sarebbe stato emesso uno STR, a causa di uno spegnimento imprevisto di un dispositivo di accesso.
Un client Diameter o dispositivo di accesso incrementa il valore di Origin-State-Id ogni volta che viene avviato o acceso. Il nuovo Origin-State-Id viene quindi inviato nel messaggio CER/CEA immediatamente alla connessione al server. Il server Diameter che riceve il nuovo Origin-State-Id può determinare se il client Diameter si era spento bruscamente confrontando il vecchio valore di Origin-State-Id conservato per quel client specifico con il nuovo valore e verificando se ha sessioni non terminate originate da quel client.
Un dispositivo di accesso può includere Origin-State-Id anche in messaggi di richiesta diversi dal CER se tra dispositivo e server ci sono relay o proxy. In tal caso però il server non può scoprire che il dispositivo è stato riavviato finché non riceve una nuova richiesta da esso. Pertanto questo meccanismo è più opportunistico attraverso proxy e relay.
Il server Diameter può assumere che tutte le sessioni attive prima del rilevamento di un riavvio del client siano terminate. Il server Diameter PUÒ ripulire tutto lo stato di sessione associato a tali sessioni perse e PUÒ anche emettere STR per tutte tali sessioni perse autorizzate su server a monte, per consentire la ripulita globale dello stato di sessione.
8.7. Auth-Request-Type AVP
L'Auth-Request-Type AVP (AVP Code 274) è di tipo Enumerated ed è incluso nelle richieste di autenticazione specifiche dell'applicazione per informare i peer se l'utente deve essere solo autenticato, solo autorizzato, o entrambi. Nota: qualsiasi valore diverso da entrambi PUÒ causare problemi di interoperabilità con RADIUS. Sono definiti i seguenti valori:
AUTHENTICATE_ONLY 1
La richiesta inviata è solo per autenticazione e DEVE contenere gli AVP di autenticazione specifici dell'applicazione necessari al server Diameter per autenticare l'utente.
AUTHORIZE_ONLY 2
La richiesta inviata è solo per autorizzazione e DEVE contenere gli AVP di autorizzazione specifici dell'applicazione necessari a identificare il servizio richiesto/offerto.
AUTHORIZE_AUTHENTICATE 3
La richiesta contiene una richiesta sia di autenticazione sia di autorizzazione. La richiesta DEVE includere sia le informazioni di autenticazione specifiche dell'applicazione sia le informazioni di autorizzazione necessarie a identificare il servizio richiesto/offerto.
8.8. Session-Id AVP
Il Session-Id AVP (AVP Code 263) è di tipo UTF8String e identifica una sessione specifica (vedi sezione 8). Tutti i messaggi relativi a una sessione specifica DEVONO includere un solo Session-Id AVP, e lo stesso valore DEVE essere usato per tutta la vita della sessione. Quando presente, il Session-Id Dovrebbe apparire immediatamente dopo l'intestazione Diameter (vedi sezione 3).
Il Session-Id DEVE essere globalmente ed eternamente unico, poiché serve a identificare univocamente una sessione utente senza riferimento ad altre informazioni, e può essere necessario per correlare informazioni storiche di autenticazione con informazioni di accounting. Il Session-Id include una parte obbligatoria e una parte definita dall'implementazione; di seguito è delineato un formato raccomandato per la parte definita dall'implementazione.
Il Session-Id DEVE iniziare con l'identità del mittente codificata nel tipo DiameterIdentity (vedi sezione 4.3.1). Il resto del Session-Id è delimitato dal carattere ";" e PUÒ essere qualsiasi sequenza che il client possa garantire eternamente unica; tuttavia si raccomanda il seguente formato (le parentesi quadre [] indicano un elemento opzionale):
<high>;<low>[;<optional>]
<high> e <low> sono le rappresentazioni decimali dei 32 bit alti e bassi di un valore a 64 bit strettamente monotono crescente. Il valore a 64 bit è reso in due parti per semplificare la formattazione su processori a 32 bit. All'avvio, i 32 bit alti del valore a 64 bit POSSONO essere inizializzati al tempo in formato NTP [RFC5905] e i 32 bit bassi POSSONO essere inizializzati a zero. Ciò elimina in pratica la possibilità di Session-Id sovrapposti dopo un reboot, assumendo che il reboot duri più di un secondo. In alternativa, un'implementazione PUÒ tenere traccia del valore crescente in memoria non volatile.
<optional> è specifico dell'implementazione e può includere l'ID dispositivo di un modem, un indirizzo di livello 2, un timestamp, ecc.
Esempio senza valore opzionale:
accesspoint7.example.com;1876543210;523
Esempio con valore opzionale:
accesspoint7.example.com;1876543210;523;[email protected]
Il Session-Id è creato dall'applicazione Diameter che avvia la sessione, che nella maggior parte dei casi è il client. Nota: un Session-Id PUÒ essere usato per i comandi di autenticazione, autorizzazione e accounting di una data applicazione.
8.9. Authorization-Lifetime AVP
L'Authorization-Lifetime AVP (AVP Code 291), Unsigned32, indica il numero massimo di secondi di servizio prima di ri-autenticazione e/o ri-autorizzazione. Un valore piccolo ma diverso da zero può aumentare notevolmente il traffico Diameter.
Il valore 0 richiede ri-autenticazione immediata. Se l'AVP è assente o tutti i 32 bit sono a 1, non ci si aspetta ri-autenticazione.
Se coesistono Session-Timeout e Authorization-Lifetime, il Session-Timeout NON DEVE essere inferiore all'Authorization-Lifetime.
I messaggi di ri-autorizzazione POSSONO contenere questo AVP: secondi di servizio autorizzati a partire dalla ricezione della risposta di ri-autorizzazione.
Il client PUÒ inviarlo come suggerimento sulla durata massima accettabile; il server DEVE restituire un valore minore o uguale.
8.10. Auth-Grace-Period AVP
L'Auth-Grace-Period AVP (AVP Code 276), Unsigned32, è il numero di secondi dopo la scadenza dell'Authorization-Lifetime prima che il server rilasci lo stato della sessione.
8.11. Auth-Session-State AVP
L'Auth-Session-State AVP (AVP Code 277), Enumerated, indica se lo stato della sessione è mantenuto. Il client PUÒ includerlo come suggerimento; fa fede il valore nella risposta del server.
STATE_MAINTAINED 0 — Lo stato è mantenuto; alla cessazione del servizio DEVE essere emesso un messaggio di terminazione sessione (predefinito).
NO_STATE_MAINTAINED 1 — Nessun messaggio di terminazione sessione alla scadenza dell'Authorization-Lifetime.
8.12. Re-Auth-Request-Type AVP
Il Re-Auth-Request-Type AVP (AVP Code 285), Enumerated, è incluso nelle risposte di autorizzazione specifiche dell'applicazione per informare il client dell'azione attesa alla scadenza dell'Authorization-Lifetime.
Se il messaggio di risposta contiene un Authorization-Lifetime AVP con valore positivo, il Re-Auth-Request-Type AVP DEVE essere presente nel messaggio di risposta. Sono definiti i seguenti valori:
AUTHORIZE_ONLY 0 — Alla scadenza ci si aspetta solo ri-autenticazione di tipo "solo autorizzazione" (predefinito se l'AVP è assente mentre è presente Authorization-Lifetime).
AUTHORIZE_AUTHENTICATE 1 — Alla scadenza ci si aspetta ri-autenticazione completa.
8.13. Session-Timeout AVP
Il Session-Timeout AVP (AVP Code 27) [RFC2865], Unsigned32, è il numero massimo di secondi prima della fine della sessione. Se coesiste con Authorization-Lifetime in una risposta, DEVE essere maggiore o uguale a quest'ultimo.
La terminazione di una sessione sul dispositivo di accesso per scadenza del Session-Timeout DEVE comportare l'invio di uno STR, salvo accordo preventivo tra dispositivo di accesso e server home di non inviare messaggi di terminazione (sezione 8).
PUÒ comparire in una risposta di ri-autorizzazione con i secondi rimanenti dall'inizio della ri-autenticazione.
Zero o AVP assente significa durata illimitata prima della terminazione.
Il client PUÒ inviarlo come suggerimento; il server PUÒ restituire un valore minore o uguale.
8.14. User-Name AVP
Il User-Name AVP (AVP Code 1) [RFC2865], UTF8String, contiene il nome utente in formato NAI [RFC4282].
8.15. Termination-Cause AVP
Il Termination-Cause AVP (AVP Code 295), Enumerated, indica la causa della terminazione sul dispositivo di accesso. I valori attuali sono nel registro IANA Termination-Cause AVP Values [IANATCV].
8.16. Origin-State-Id AVP
L'Origin-State-Id AVP (AVP Code 278), Unsigned32, cresce monotonicamente a ogni riavvio con perdita di stato. PUÒ comparire in qualsiasi messaggio Diameter, incluso CER.
L'entità DEVE aumentare il valore a ogni reset dello stato; PUÒ usare l'ora di avvio o un contatore non volatile.
Se presente, DEVE riflettere lo stato dell'entità designata da Origin-Host. Se un proxy modifica Origin-Host, DEVE rimuovere o adattare Origin-State-Id. In genere un dispositivo di accesso riavvia senza sessioni attive: un valore più basso suggerisce sessioni inattive. Per evitare tale deduzione, omettere l'AVP o impostarlo a 0.
8.17. Session-Binding AVP
Il Session-Binding AVP (AVP Code 270), Unsigned32, PUÒ comparire in una risposta di autorizzazione specifica dell'applicazione e PUÒ indicare che tutte le future ri-autenticazioni e STR per questa sessione DEVONO essere inviate allo stesso server di autorizzazione.
Maschera di bit:
RE_AUTH 1 — Se impostato, nessun Destination-Host nelle future ri-autenticazioni; altrimenti (predefinito) Destination-Host obbligatorio.
STR 2 — Stesso discorso per lo STR.
ACCOUNTING 4 — Stesso discorso per l'accounting se l'host è noto.
8.18. Session-Server-Failover AVP
Il Session-Server-Failover AVP (AVP Code 271), Enumerated, PUÒ comparire se Session-Binding è assente o se un bit di Session-Binding è zero. PUÒ indicare che in caso di fallimento nella consegna di una ri-autenticazione o di uno STR, il client Dovrebbe reinviare un messaggio senza Destination-Host. Se assente, il predefinito è REFUSE_SERVICE.
REFUSE_SERVICE 0 — In caso di fallimento, interrompere il servizio, nessun altro tentativo.
TRY_AGAIN 1 — Reinviare senza Destination-Host.
ALLOW_SERVICE 2 — Fallimento consegna ri-auth: considerare la ri-autorizzazione riuscita; fallimento STR: terminare la sessione.
TRY_AGAIN_ALLOW_SERVICE 3 — Come TRY_AGAIN; al secondo fallimento stesse regole di ALLOW_SERVICE.
8.19. Multi-Round-Time-Out AVP
Il Multi-Round-Time-Out AVP (AVP Code 272), Unsigned32, Dovrebbe essere presente quando il Result-Code è DIAMETER_MULTI_ROUND_AUTH. È il numero massimo di secondi che il dispositivo di accesso DEVE concedere all'utente per rispondere a una richiesta di autenticazione.
8.20. Class AVP
Il Class AVP (AVP Code 25), OctetString, trasporta stato dal server al dispositivo di accesso. Se presente in una risposta di autorizzazione, DEVE comparire nelle successive ri-autorizzazioni, terminazioni sessione e accounting. I valori Class da una risposta di ri-autorizzazione sostituiscono quelli precedenti. I server Non Dovrebbero richiedere più di 4096 byte lato client; se il client non può memorizzare, DEVE terminare la sessione.
8.21. Event-Timestamp AVP
L'Event-Timestamp AVP (AVP Code 55), Time, PUÒ comparire in Accounting-Request e Accounting-Answer per l'istante dell'evento, in secondi dal 1° gennaio 1900, 00:00 UTC.