8. Sessions utilisateur Diameter
En général, Diameter peut fournir aux applications deux types de services distincts. Le premier concerne l'authentification et l'autorisation, et peut éventuellement utiliser la comptabilité. Le second n'utilise que la comptabilité.
Lorsqu'un service emploie la partie authentification et/ou autorisation d'une application et qu'un utilisateur demande l'accès au réseau, le client Diameter envoie une demande d'autorisation à son serveur local. Cette demande est définie dans une application Diameter spécifique au service (par ex. NASREQ). Elle contient un Session-Id AVP, utilisé dans les messages ultérieurs (autorisation ultérieure, comptabilité, etc.) relatifs à la session utilisateur. Le Session-Id AVP permet au client et aux serveurs de corréler un message Diameter avec une session utilisateur.
Lorsqu'un serveur Diameter autorise un utilisateur à utiliser des ressources réseau pendant une durée finie et accepte de prolonger l'autorisation par une demande ultérieure, il DOIT ajouter l'Authorization-Lifetime AVP au message de réponse. Cet AVP définit le nombre maximal de secondes pendant lesquelles l'utilisateur PEUT utiliser les ressources avant qu'une nouvelle demande d'autorisation ne soit attendue par le serveur. L'Auth-Grace-Period AVP indique le nombre de secondes après l'expiration de l'Authorization-Lifetime avant que le serveur ne libère toute l'état lié à la session. Si le domaine de service attend un paiement du domaine d'origine de l'utilisateur, l'Authorization-Lifetime combiné à l'Auth-Grace-Period implique la durée maximale de session dont le domaine d'origine accepte la responsabilité financière. Les services fournis après expiration de ces AVP relèvent de l'équipement d'accès. Le coût réel des services est hors du champ du protocole.
Un équipement d'accès qui n'envisage pas d'envoyer une re-autorisation ou une demande de fin de session au serveur PEUT inclure l'Auth-Session-State AVP à la valeur NO_STATE_MAINTAINED comme indication. Si le serveur accepte, il convient qu'aucun message de fin de session ne sera reçu après l'arrêt du service et qu'il ne peut pas maintenir l'état. Si la réponse du serveur porte une autre valeur (ou la valeur par défaut si l'AVP est absent), l'équipement d'accès DOIT suivre les directives du serveur. La valeur NO_STATE_MAINTAINED NE DOIT PAS être utilisée dans les demandes et réponses de re-autorisation ultérieures.
Le protocole de base n'inclut pas de messages de demande d'autorisation, car ils sont surtout spécifiques à l'application et définis dans un document d'application Diameter. Il définit toutefois des messages pour terminer les sessions utilisateur, afin que les serveurs qui maintiennent l'état libèrent des ressources.
Lorsqu'un service n'utilise que la partie comptabilité de Diameter, même avec une application, le Session-Id identifie toujours les sessions. Les messages de fin de session ne sont pas utilisés : l'arrêt de session est signalé par un message accounting stop.
Diameter peut aussi servir pour des services difficiles à classer (par ex. certaines interfaces IMS 3GPP). Les automates finis des sections suivantes peuvent alors ne pas s'appliquer ; l'application PEUT devoir définir le sien. Ces automates DEVRAIENT suivre le cadre général du présent document (Session-Id AVP, messages STR/STA, ASR/ASA pour les sessions avec état).
8.1. Machine à états de session d'autorisation
Cette section décrit des automates finis représentant le cycle de vie des sessions Diameter ; ils DOIVENT être respectés par toute implémentation Diameter utilisant la partie authentification et/ou autorisation d'une application Diameter. Le terme « Service-Specific » désigne ci-dessous un message défini dans une application Diameter (par ex. Mobile IPv4, NASREQ).
Le protocole de base Diameter prend en charge quatre automates de session d'autorisation. Les deux premiers décrivent une session dont l'état est maintenu par le serveur (valeur de l'Auth-Session-State AVP ou son absence) : l'un côté client, l'autre côté serveur. Les deux suivants s'appliquent lorsque le serveur ne maintient pas l'état, également selon les perspectives client et serveur.
Lorsqu'une session passe à l'état Idle, toutes les ressources allouées à cette session doivent être libérées. Tout événement non listé DOIT être traité comme une erreur et, le cas échéant, une réponse DOIT être renvoyée à l'origine du message.
Si une application ne prend pas en charge la ré-authentification, les transitions liées à la ré-authentification initiée par le serveur lorsque client et serveur maintiennent l'état (envoi RAR, Pending, réception RAA) PEUVENT être ignorées.
Dans le tableau, « Failure to send X » signifie que l'agent Diameter ne peut pas envoyer la commande X vers la destination : pair indisponible ou échec transitoire / erreur de protocole temporaire DIAMETER_TOO_BUSY ou DIAMETER_LOOP_DETECTED dans le Result-Code AVP de la réponse correspondante. « X successfully sent » est le complément de « Failure to send X ».
Lorsque l'état est maintenu côté serveur, le client suit l'automate suivant (table identique au texte anglais de la 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
Automate côté serveur lorsque ce dernier maintient l'état de la session :
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
Côté client lorsque le serveur ne maintient pas l'état :
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
Côté serveur lorsque le serveur ne maintient pas l'état de la session :
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. Machine à états de session de comptabilité
Les applications disposant d'une partie comptabilité ou n'exigeant que la comptabilité DOIVENT prendre en charge les automates suivants. Le premier s'applique aux clients.
Codes de commande de comptabilité : section 9.7 ; AVP de comptabilité : section 9.8.
Le côté serveur de l'automate de comptabilité dépend parfois de l'application. Le protocole de base définit un automate par défaut que TOUTES les applications n'en ayant pas défini d'autre DOIVENT suivre : c'est le deuxième automate de cette section.
L'automate serveur par défaut accepte des enregistrements de comptabilité dans tout ordre et à tout moment, sans exigence normative sur leur traitement. Les implémentations peuvent effectuer contrôles, tri, corrélation, détection de fraude, etc. Des AVP peuvent être inspectées. Le traitement peut être immédiat ou différé ; ces tâches dépendent souvent de l'application ou de la politique et ne sont pas normalisées. Les applications PEUVENT préciser quand accepter des enregistrements selon la valeur de l'Accounting-Realtime-Required AVP, les plafonds de crédit, etc.
Un troisième automate serveur, facultatif, PEUT être suivi si l'état de session doit être suivi sur le serveur de comptabilité. Ce suivi est incompatible avec la tolérance aux pannes de connectivité prolongées. Il est donc recommandé seulement lorsque l'Accounting-Realtime-Required vaut DELIVER_AND_GRANT, ce qui impose de déconnecter l'utilisateur en cas de problème de connectivité de comptabilité. Sinon des enregistrements produits par le client peuvent être perdus lorsque le serveur ne les accepte plus après rétablissement. Cet automate est supervisé par un temporisateur de session Ts, supérieur de façon raisonnable à Acct_Interim_Interval ; Ts PEUT valoir le double d'Acct_Interim_Interval pour éviter de passer à Idle après une courte panne transitoire.
Tout événement non listé DOIT être considéré comme une erreur ; une réponse appropriée DOIT être renvoyée si applicable.
« Failure to send » : le client Diameter ne peut pas joindre la destination (pair indisponible ou échec transitoire DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, DIAMETER_LOOP_DETECTED dans le Accounting Answer).
« Failed answer » : notification d'échec non transitoire dans le Accounting Answer.
L'action « Disconnect user/dev » DOIT aussi impacter la table d'état d'autorisation (par ex. envoi STR) si l'application combine authentification/autorisation et comptabilité.
PendingS, PendingI, PendingL, PendingE et PendingB désignent l'attente de réponse pour une requête de comptabilité Start, Interim, Stop, Event ou tamponnée (table identique au texte anglais de la 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. Réauthentification initiée par le serveur
Un serveur Diameter peut lancer une ré-authentification et/ou une ré-autorisation pour une session donnée en émettant une Re-Auth-Request (RAR).
Par exemple, en prépayé, le serveur qui a autorisé la session peut devoir vérifier que l'utilisateur utilise encore le service.
Un équipement d'accès recevant un RAR dont le Session-Id correspond à une session active DOIT lancer une ré-authentification vers l'utilisateur si la fonctionnalité est prise en charge. Chaque application Diameter DOIT indiquer si la ré-authentification initiée par le serveur est supportée ; certaines interdisent d'inviter l'utilisateur à se ré-authentifier.
8.3.1. Re-Auth-Request
La Re-Auth-Request (RAR), code de commande 258 et bit « R » des drapeaux positionné, peut être envoyée par tout serveur vers l'équipement d'accès qui fournit la session, pour demander la ré-authentification et/ou la ré-autorisation.
Format du message
::= < 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), code 258 et bit « R » effacé, répond au RAR. Le Result-Code AVP DOIT être présent et indique le traitement de la demande.
Après un RAA réussi DOIT suivre un message d'authentification et/ou d'autorisation spécifique à l'application.
Format du message
::= < 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. Terminaison de session
Un serveur Diameter qui a autorisé une session et en maintient l'état doit être informé lorsqu'elle n'est plus active, pour le suivi et pour permettre aux agents avec état de libérer les ressources fournies. Les sessions sans état maintenu n'utilisent pas cette section.
Lorsqu'une session utilisateur ayant nécessité une autorisation Diameter se termine, l'équipement d'accès qui a fourni le service DOIT envoyer une Session-Termination-Request (STR) au serveur qui a autorisé le service. Un STR DOIT être émis pour toute fin de session : déconnexion utilisateur, expiration du Session-Timeout, action administrative, réception d'un Abort-Session-Request (voir ci-dessous), arrêt ordonné de l'équipement, etc.
Un STR DOIT aussi être émis pour une session autorisée mais jamais démarrée (manque de ressources, refus du type de service, AVP obligatoire non supportée, etc.).
Un proxy peut empêcher le démarrage d'une session autorisée (par ex. en modifiant une réponse d'autorisation de succès en échec). Si la réponse ne contenait pas d'Auth-Session-State à NO_STATE_MAINTAINED, le proxy DOIT envoyer un STR au serveur ayant autorisé la session, car l'équipement d'accès ne peut pas savoir qu'elle avait été autorisée.
Le serveur qui reçoit un STR DOIT libérer les ressources liées au Session-Id et renvoyer une Session-Termination-Answer (STA).
Le serveur DOIT aussi libérer les ressources à l'expiration du Session-Timeout ou lorsque l'Authorization-Lifetime et l'Auth-Grace-Period expirent sans ré-autorisation, que le STR soit reçu ou non. Aucun service n'est attendu après ces temporisations ; leur expiration suggère un arrêt inattendu de l'équipement d'accès.
8.4.1. Session-Termination-Request
La Session-Termination-Request (STR), code 275 et bit « R » des drapeaux positionné, est envoyée par un client ou un proxy Diameter pour indiquer qu'une session authentifiée et/ou autorisée se termine.
Format du message
::= < 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), code 275 et bit « R » effacé, est renvoyée par le serveur pour accuser réception de la fin de session. Le Result-Code AVP DOIT être présent et PEUT signaler une erreur lors du traitement du STR.
Après envoi ou réception de la STA, le serveur DOIT libérer toutes les ressources de la session indiquée par le Session-Id AVP. Un serveur intermédiaire de la chaîne de proxy PEUT aussi libérer des ressources si nécessaire.
Format du message
::= < 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. Abandon d'une session
Un serveur Diameter peut demander l'arrêt du service pour une session en émettant une Abort-Session-Request (ASR).
Par exemple, le serveur ayant autorisé la session peut devoir l'arrêter pour insuffisance de crédit ou autres motifs non prévus à l'autorisation initiale.
Un équipement d'accès recevant un ASR pour un Session-ID de session active PEUT arrêter la session ; cela dépend de l'implémentation et de la configuration (par ex. ASR acceptés seulement de certains agents). Dans tous les cas, il DOIT répondre par une Abort-Session-Answer avec un Result-Code AVP décrivant l'action.
8.5.1. Abort-Session-Request
L'Abort-Session-Request (ASR), code 274 et bit « R » positionné, peut être envoyée par tout serveur ou proxy Diameter vers l'équipement d'accès pour demander l'arrêt de la session identifiée par le Session-Id.
Format du message
::= < 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), code 274 et bit « R » effacé, répond à l'ASR. Le Result-Code AVP DOIT être présent.
Session terminée avec succès : DIAMETER_SUCCESS. Session inactive : DIAMETER_UNKNOWN_SESSION_ID. Autre refus d'arrêt : DIAMETER_UNABLE_TO_COMPLY.
Format du message
::= < 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. Inférence de terminaison à partir de Origin-State-Id
L'Origin-State-Id permet de détecter des sessions terminées sans STR suite à un arrêt imprévu d'un équipement d'accès.
Le client ou équipement d'accès incrémente l'Origin-State-Id à chaque démarrage ou mise sous tension et l'envoie dans CER/CEA dès la connexion. Le serveur compare l'ancienne valeur mémorisée pour ce client à la nouvelle et vérifie s'il reste des sessions non terminées provenant de ce client pour déduire un arrêt brutal.
L'Origin-State-Id peut aussi figurer dans d'autres requêtes s'il existe relais ou proxy ; le serveur ne détecte alors un redémarrage qu'à réception d'une nouvelle requête — mécanisme plus opportuniste.
Le serveur PEUT supposer que toutes les sessions actives avant redémarrage client sont terminées, libérer leur état et émettre des STR vers les serveurs en amont pour un nettoyage global.
8.7. AVP Auth-Request-Type
L'AVP Auth-Request-Type (code 274), de type Enumerated, figure dans les demandes d'autorisation spécifiques à l'application pour indiquer si l'utilisateur doit être uniquement authentifié, uniquement autorisé, ou les deux. Toute valeur autre que « les deux » PEUT poser des problèmes d'interopérabilité RADIUS. Valeurs définies :
AUTHENTICATE_ONLY 1
Authentification seule ; la demande DOIT contenir les AVP d'authentification nécessaires au serveur.
AUTHORIZE_ONLY 2
Autorisation seule ; la demande DOIT contenir les AVP d'autorisation pour identifier le service demandé/offert.
AUTHORIZE_AUTHENTICATE 3
Les deux ; la demande DOIT inclure les informations d'authentification et d'autorisation pertinentes.
8.8. AVP Session-Id
L'AVP Session-Id (code 263), UTF8String, identifie une session (section 8). Chaque message relatif à une session DOIT contenir un seul Session-Id AVP, avec la même valeur pendant toute la durée de vie. S'il est présent, le Session-Id DEVRAIT suivre immédiatement l'en-tête Diameter (section 3).
Le Session-Id DOIT être globalement et durablement unique pour identifier une session utilisateur sans autre information, et peut servir à corréler authentification et comptabilité. Il comprend une partie obligatoire et une partie définie par l'implémentation ; format recommandé ci-dessous.
Le Session-Id DOIT commencer par l'identité de l'émetteur encodée en DiameterIdentity (section 4.3.1). Le reste est délimité par « ; » et PEUT être toute séquence garantie durablement unique ; format recommandé ([] = optionnel) :
<high>;<low>[;<optional>]
<high> et <low> sont les parties haute et basse (32 bits) d'une valeur 64 bits strictement croissante, en décimal, scindée pour les processeurs 32 bits. Au démarrage, la partie haute PEUT être l'heure NTP [RFC5905] et la basse zéro, ce qui évite pratiquement les collisions après reboot si celui-ci dure plus d'une seconde. L'implémentation PEUT aussi conserver un compteur en mémoire non volatile.
<optional> est spécifique à l'implémentation (ID modem, adresse couche 2, horodatage, etc.).
Exemple sans partie optionnelle :
accesspoint7.example.com;1876543210;523
Exemple avec partie optionnelle :
accesspoint7.example.com;1876543210;523;[email protected]
Le Session-Id est créé par l'application Diameter qui ouvre la session (souvent le client). Un même Session-Id PEUT servir pour les commandes d'authentification, d'autorisation et de comptabilité.
8.9. AVP Authorization-Lifetime
L'AVP Authorization-Lifetime (code 291), Unsigned32, indique le nombre maximal de secondes de service avant ré-authentification et/ou ré-autorisation. Une valeur faible non nulle peut fortement augmenter le trafic Diameter.
La valeur 0 impose une ré-authentification immédiate. L'absence de l'AVP ou une valeur « tous les bits à 1 » signifie qu'aucune ré-authentification n'est attendue.
Si Session-Timeout et Authorization-Lifetime coexistent, le Session-Timeout NE DOIT PAS être inférieur à l'Authorization-Lifetime.
Les messages de ré-autorisation PEUVENT porter cet AVP : secondes autorisées à partir de la réception de la réponse de ré-autorisation.
Le client PEUT l'envoyer comme indication de durée maximale acceptée ; le serveur DOIT renvoyer une valeur inférieure ou égale.
8.10. AVP Auth-Grace-Period
L'AVP Auth-Grace-Period (code 276), Unsigned32, est le délai en secondes après expiration de l'Authorization-Lifetime avant que le serveur ne libère l'état de la session.
8.11. AVP Auth-Session-State
L'AVP Auth-Session-State (code 277), Enumerated, indique si l'état de session est maintenu. Le client PEUT l'inclure comme indication ; la valeur dans la réponse du serveur fait foi.
STATE_MAINTAINED 0 — État maintenu ; un message de fin de session DOIT être émis à l'arrêt du service (défaut).
NO_STATE_MAINTAINED 1 — Aucun message de fin de session à l'expiration de l'Authorization-Lifetime.
8.12. AVP Re-Auth-Request-Type
L'AVP Re-Auth-Request-Type (code 285), Enumerated, figure dans les réponses d'autorisation pour indiquer l'action attendue à l'expiration de l'Authorization-Lifetime. Si la réponse contient un Authorization-Lifetime strictement positif, cet AVP DOIT être présent.
AUTHORIZE_ONLY 0 — Ré-authentification « autorisation seule » attendue (défaut si l'AVP est absent alors qu'Authorization-Lifetime est présent).
AUTHORIZE_AUTHENTICATE 1 — Ré-authentification complète attendue.
8.13. AVP Session-Timeout
L'AVP Session-Timeout (code 27) [RFC2865], Unsigned32, est le nombre maximal de secondes avant fin de session. S'il coexiste avec Authorization-Lifetime dans une réponse, il DOIT être supérieur ou égal à ce dernier.
Une fin de session sur équipement d'accès par expiration du Session-Timeout DOIT entraîner un STR, sauf accord préalable de ne pas envoyer de messages de fin (section 8).
Il PEUT apparaître dans une réponse de ré-autorisation avec les secondes restantes depuis le début de la ré-authentification.
Zéro ou absence = durée illimitée avant terminaison.
Le client PEUT l'envoyer comme indication ; le serveur PEUT renvoyer une valeur inférieure ou égale.
8.14. AVP User-Name
L'AVP User-Name (code 1) [RFC2865], UTF8String, contient le nom d'utilisateur au format NAI [RFC4282].
8.15. AVP Termination-Cause
L'AVP Termination-Cause (code 295), Enumerated, indique la cause d'arrêt sur l'équipement d'accès. Valeurs IANA : registre Termination-Cause AVP Values [IANATCV].
8.16. AVP Origin-State-Id
L'AVP Origin-State-Id (code 278), Unsigned32, croît à chaque redémarrage avec perte d'état. Elle PEUT figurer dans tout message Diameter, y compris CER.
L'entité DOIT augmenter la valeur à chaque réinitialisation d'état ; elle PEUT utiliser l'heure de démarrage ou un compteur non volatile.
Si présente, elle DOIT refléter l'état de l'entité désignée par Origin-Host. Si un proxy modifie Origin-Host, il DOIT supprimer ou ajuster Origin-State-Id. En général, un équipement d'accès redémarre sans session active : une valeur plus faible suggère des sessions inactives. Pour éviter cette inférence, omettre l'AVP ou la mettre à 0.
8.17. AVP Session-Binding
L'AVP Session-Binding (code 270), Unsigned32, PEUT figurer dans une réponse d'autorisation ; elle PEUT indiquer que toutes les futures ré-authentifications et STR pour cette session DOIVENT aller au même serveur d'autorisation.
Masque de bits :
RE_AUTH 1 — Si positionné, pas de Destination-Host dans les ré-authentifications futures ; sinon (défaut), Destination-Host obligatoire.
STR 2 — Idem pour le STR.
ACCOUNTING 4 — Idem pour la comptabilité si l'hôte est connu.
8.18. AVP Session-Server-Failover
L'AVP Session-Server-Failover (code 271), Enumerated, PEUT apparaître si Session-Binding est absent ou si un bit de Session-Binding vaut zéro. Elle PEUT indiquer qu'en cas d'échec de livraison d'une ré-authentification ou d'un STR, le client DEVRAIT renvoyer un message sans Destination-Host. Défaut si absent : REFUSE_SERVICE.
REFUSE_SERVICE 0 — Échec : arrêt du service, pas de nouvelle tentative.
TRY_AGAIN 1 — Réexpédier sans Destination-Host.
ALLOW_SERVICE 2 — Échec ré-auth : considérer la ré-autorisation réussie ; échec STR : terminer la session.
TRY_AGAIN_ALLOW_SERVICE 3 — Réessai sans Destination-Host puis mêmes règles que ci-dessus au second échec.
8.19. AVP Multi-Round-Time-Out
L'AVP Multi-Round-Time-Out (code 272), Unsigned32, DEVRAIT être présente lorsque le Result-Code vaut DIAMETER_MULTI_ROUND_AUTH. Délai maximal en secondes laissé à l'utilisateur pour répondre à une demande d'authentification ; l'équipement d'accès DOIT le respecter.
8.20. AVP Class
L'AVP Class (code 25), OctetString, renvoie de l'état au serveur vers l'équipement d'accès. Si présente dans une réponse d'autorisation, elle DOIT être reprise dans les ré-autorisations, fins de session et comptabilité ultérieures. Les Class d'une réponse de ré-autorisation remplacent les précédentes. Les serveurs NE DEVRAIENT PAS exiger plus de 4096 octets côté client ; un client qui ne peut stocker DOIT terminer la session.
8.21. AVP Event-Timestamp
L'AVP Event-Timestamp (code 55), Time, PEUT figurer dans Accounting-Request et Accounting-Answer pour l'heure de l'événement, en secondes depuis le 1er janvier 1900 00:00 UTC.