8. Diameter-Benutzersitzungen
Im Allgemeinen kann Diameter Anwendungen zwei Arten von Diensten bereitstellen. Die erste betrifft Authentifizierung und Autorisierung und kann optional Accounting nutzen. Die zweite nutzt nur Accounting.
Nutzt ein Dienst den Authentifizierungs- und/oder Autorisierungsteil einer Anwendung und fordert ein Benutzer Netzzugang an, sendet der Diameter-Client eine Autorisierungsanfrage an seinen lokalen Server. Die Anfrage ist in einer dienstspezifischen Diameter-Anwendung (z. B. NASREQ) definiert. Sie enthält ein Session-Id AVP, das in nachfolgenden Nachrichten (weitere Autorisierung, Accounting usw.) zur Benutzersitzung verwendet wird. Das Session-Id AVP ordnet Diameter-Nachrichten und Benutzersitzungen zu.
Autorisiert ein Diameter-Server einen Benutzer für begrenzte Nutzung von Netzressourcen und ist er bereit, die Autorisierung später zu verlängern, MUSS er das Authorization-Lifetime AVP in der Antwort aufnehmen. Dieses AVP legt die Höchstzahl Sekunden fest, in denen der Benutzer die Ressourcen nutzen DARF, bevor der Server eine neue Autorisierungsanfrage erwartet. Das Auth-Grace-Period AVP gibt die Sekunden nach Ablauf des Authorization-Lifetime an, nach denen der Server den gesamten zur Sitzung gehörenden Zustand freigibt. Erwartet der Serving-Realm Zahlung vom Home-Realm des Benutzers, legen Authorization-Lifetime und Auth-Grace-Period zusammen die maximale Sitzungsdauer fest, für die der Home-Realm finanziell haftet. Dienste nach Ablauf dieser AVPs liegen beim Zugangsgerät. Die tatsächlichen Kosten liegen außerhalb des Protokolls.
Ein Zugangsgerät, das keine erneute Autorisierung oder Sitzungsbeendigungsanfrage senden wird, KANN das Auth-Session-State AVP mit NO_STATE_MAINTAINED als Hinweis setzen. Akzeptiert der Server den Hinweis, gilt: Nach Dienstende gibt es keine Sitzungsbeendigungsnachricht, daher kann kein Zustand gehalten werden. Weicht der Wert in der Serverantwort ab (oder der Standardwert bei fehlendem AVP), MUSS das Zugangsgerät den Anweisungen folgen. NO_STATE_MAINTAINED DARF in späteren Re-Autorisierungsanfragen und -antworten nicht gesetzt werden.
Das Basisprotokoll enthält keine Autorisierungsanfragen; diese sind anwendungsspezifisch in Diameter-Anwendungsdokumenten definiert. Es definiert jedoch Nachrichten zum Beenden von Benutzersitzungen, damit zustandshaltende Server Ressourcen freigeben.
Nutzt ein Dienst nur den Accounting-Teil von Diameter (auch mit einer Anwendung), dient das Session-Id weiter zur Identifikation von Sitzungen. Sitzungsbeendigungsnachrichten entfallen; das Ende wird durch eine Accounting-Stop-Nachricht signalisiert.
Diameter kann auch für Dienste genutzt werden, die sich nicht klar als Authentifizierung, Autorisierung oder Accounting einordnen (z. B. einige 3GPP-IMS-Schnittstellen). Dann gelten die endlichen Automaten der folgenden Abschnitte ggf. nicht; die Anwendung MUSS ggf. einen eigenen definieren. Solche automaten SOLLTEN dem allgemeinen Rahmen dieses Dokuments folgen (Session-Id AVP, STR/STA, ASR/ASA bei zustandsbehafteten Sitzungen).
8.1. Autorisierungssitzungs-Zustandsautomat
Dieser Abschnitt enthält endliche Automaten für den Lebenszyklus von Diameter-Sitzungen; sie MÜSSEN von allen Diameter-Implementierungen eingehalten werden, die den Authentifizierungs- und/oder Autorisierungsteil einer Diameter-Anwendung nutzen. „Service-Specific“ bezeichnet hier eine in einer Diameter-Anwendung definierte Nachricht (z. B. Mobile IPv4, NASREQ).
Das Diameter-Basisprotokoll unterstützt vier Autorisierungssitzungs-Automaten. Die ersten beiden beschreiben eine Sitzung, deren Zustand der Server hält (Wert des Auth-Session-State AVP oder dessen Fehlen), aus Client- bzw. Server-Sicht. Die anderen beiden gelten, wenn der Server keinen Zustand hält, ebenfalls aus Client- und Server-Sicht.
Wechselt eine Sitzung in den Zustand Idle, sind alle zugewiesenen Ressourcen freizugeben. Jedes nicht aufgeführte Ereignis MUSS als Fehler behandelt werden; falls zutreffend MUSS eine Antwort an den Absender zurückgegeben werden.
Unterstützt eine Anwendung keine Re-Authentifizierung, DÜRFEN die Übergänge zur serverinitiierten Re-Authentifizierung bei gleichzeitig zustandshaltendem Client und Server (RAR senden, Pending, RAA empfangen) ignoriert werden.
In der Tabelle bedeutet „Failure to send X“, dass der Diameter-Agent Befehl X nicht zum Ziel senden kann (Peer ausgefallen oder transitorischer Fehler bzw. temporärer Protokollfehler DIAMETER_TOO_BUSY oder DIAMETER_LOOP_DETECTED im Result-Code AVP der zugehörigen Antwort). „X successfully sent“ ist das Komplement zu „Failure to send X“.
Wenn der Server den Zustand hält, befolgt der Client folgenden Automaten (Tabelle wie im englischen RFC-6733-Text) :
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
Server-Automat, wenn der Server den Sitzungszustand hält:
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
Client-Automat, wenn der Server keinen Zustand hält:
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
Server-Automat, wenn der Server keinen Sitzungszustand hält:
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. Abrechnungssitzungs-Zustandsautomat
Anwendungen mit Accounting-Teil oder die nur Accounting benötigen, MÜSSEN die folgenden Automaten unterstützen. Der erste gilt für Clients.
Accounting-Befehlscodes: Abschnitt 9.7; Accounting-AVPs: Abschnitt 9.8.
Die Serverseite des Accounting-Automaten hängt teils von der Anwendung ab. Das Basisprotokoll definiert einen Standard-Serverautomaten, den ALLE Anwendungen ohne eigenen Automaten MÜSSEN befolgen – der zweite Automat in diesem Abschnitt.
Der Standard-Serverautomat erlaubt Accounting-Datensätze in beliebiger Reihenfolge und zu beliebiger Zeit ohne normative Vorgaben zur Verarbeitung. Implementierungen können prüfen, sortieren, korrelieren, Betrug erkennen usw.; AVPs können geprüft werden. Verarbeitung sofort oder nachgelagert; oft anwendungs- oder policyabhängig und nicht normiert. Anwendungen KÖNNEN festlegen, wann Datensätze akzeptiert werden, z. B. nach Accounting-Realtime-Required AVP oder Kreditlimits.
Ein dritter, optionaler Serverautomat KANN genutzt werden, wenn der Accounting-Server Sitzungszustand führen soll. Das widerspricht längeren Konnektivitätsstörungen. Empfohlen nur, wenn Accounting-Realtime-Required den Wert DELIVER_AND_GRANT hat, sodass der Nutzer bei Accounting-Ausfall getrennt werden muss. Sonst können vom Client erzeugte Datensätze nach Wiederherstellung der Verbindung vom Server nicht mehr akzeptiert und verloren gehen. Der Automat wird von einem Überwachungs-Timer Ts beaufsichtigt, der deutlich über Acct_Interim_Interval liegen sollte; Ts KANN das Doppelte von Acct_Interim_Interval sein, um nach kurzen transienten Ausfällen nicht in Idle zu wechseln.
Nicht gelistete Ereignisse MÜSSEN als Fehler gelten; falls zutreffend MUSS eine passende Antwort gesendet werden.
„Failure to send“: Der Diameter-Client erreicht das Ziel nicht (Peer aus oder transitorischer Fehler DIAMETER_OUT_OF_SPACE, DIAMETER_TOO_BUSY, DIAMETER_LOOP_DETECTED in der Accounting-Antwort).
„Failed answer“: Nicht-transitorische Fehlermeldung in der Accounting-Antwort.
Die Aktion „Disconnect user/dev“ MUSS auch die Autorisierungs-Sitzungstabelle beeinflussen (z. B. STR senden), wenn die Anwendung Authentifizierung/Autorisierung und Accounting kombiniert.
PendingS, PendingI, PendingL, PendingE und PendingB sind Wartezustände auf Antworten zu Accounting-Anfragen Start, Interim, Stop, Event oder gepuffert (Tabelle wie im englischen RFC-6733-Text).
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. Serverinitierte erneute Authentifizierung
Ein Diameter-Server kann für eine Sitzung eine erneute Authentifizierung und/oder Autorisierung durch eine Re-Auth-Request (RAR) starten.
Beispiel Prepaid: Der Server, der die Sitzung autorisiert hat, muss ggf. prüfen, ob der Nutzer den Dienst noch nutzt.
Empfängt ein Zugangsgerät ein RAR mit einem Session-Id einer aktiven Sitzung, MUSS es – wenn unterstützt – beim Nutzer eine Re-Authentifizierung auslösen. Jede Diameter-Anwendung MUSS angeben, ob serverinitiierte Re-Authentifizierung unterstützt wird; manche verbieten eine Aufforderung zur Re-Authentifizierung.
8.3.1. Re-Auth-Request
Die Re-Auth-Request (RAR), Befehlscode 258 und gesetztes „R“-Bit in den Flags, kann von jedem Server an das zugangsseitige Gerät gesendet werden, um Re-Authentifizierung und/oder Re-Autorisierung zu verlangen.
Nachrichtenformat
::= < 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
Die Re-Auth-Answer (RAA), Befehlscode 258 und gelöschtes „R“-Bit, antwortet auf das RAR. Das Result-Code AVP MUSS vorhanden sein und beschreibt die Bearbeitung.
Nach einer erfolgreichen RAA MUSS eine anwendungsspezifische Authentifizierungs- und/oder Autorisierungsnachricht folgen.
Nachrichtenformat
::= < 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. Sitzungsbeendigung
Ein Diameter-Server, der eine Sitzung autorisiert hat und deren Zustand führt, muss informiert werden, wenn sie nicht mehr aktiv ist – zur Nachverfolgung und damit zustandshaltende Agenten bereitgestellte Ressourcen freigeben. Sitzungen ohne Zustand nutzen diesen Abschnitt nicht.
Endet eine Benutzersitzung, die eine Diameter-Autorisierung erforderte, MUSS das Zugangsgerät, das den Dienst bereitstellte, eine Session-Termination-Request (STR) an den autorisierenden Server senden. Ein STR MUSS bei jeder Beendigung ausgegeben werden: Abmeldung, Ablauf von Session-Timeout, administrative Maßnahme, Empfang eines Abort-Session-Request (siehe unten), geordnetes Herunterfahren usw.
Ein STR MUSS auch für eine autorisierte, aber nie gestartete Sitzung gesendet werden (Ressourcenmangel, verweigerte Dienstart, nicht unterstützte Pflicht-AVP usw.).
Ein Proxy kann verhindern, dass eine autorisierte Sitzung startet (z. B. Autorisierungsantwort von Erfolg auf Fehler ändern). Enthielt die Antwort kein Auth-Session-State mit NO_STATE_MAINTAINED, MUSS der Proxy dem autorisierenden Server ein STR senden, da das Zugangsgerät nicht wissen kann, dass autorisiert wurde.
Der Server, der ein STR empfängt, MUSS die zum Session-Id gehörenden Ressourcen bereinigen und eine Session-Termination-Answer (STA) zurücksenden.
Der Server MUSS Ressourcen auch bei Ablauf des Session-Timeout oder wenn Authorization-Lifetime und Auth-Grace-Period ohne Re-Autorisierung ablaufen, bereinigen – unabhängig davon, ob ein STR eintrifft. Nach diesen Timern wird kein Dienst mehr erwartet; ihr Ablauf deutet auf ein unerwartetes Ausfallen des Zugangsgeräts hin.
8.4.1. Session-Termination-Request
Die Session-Termination-Request (STR), Befehlscode 275 und gesetztes „R“-Bit, wird von einem Diameter-Client oder -Proxy gesendet, um mitzuteilen, dass eine authentifizierte und/oder autorisierte Sitzung endet.
Nachrichtenformat
::= < 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
Die Session-Termination-Answer (STA), Befehlscode 275 und gelöschtes „R“-Bit, sendet der Server zur Bestätigung des Sitzungsendes. Das Result-Code AVP MUSS vorhanden sein und KANN einen Fehler bei STR-Verarbeitung anzeigen.
Nach Senden oder Empfang der STA MUSS der Server alle Ressourcen der im Session-Id AVP genannten Sitzung freigeben. Ein Zwischenserver in der Proxy-Kette KANN bei Bedarf ebenfalls Ressourcen freigeben.
Nachrichtenformat
::= < 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. Abbrechen einer Sitzung
Ein Diameter-Server kann mit einer Abort-Session-Request (ASR) verlangen, dass das Zugangsgerät einen Sitzungsdienst beendet.
Beispiel: Der ursprünglich autorisierende Server muss die Sitzung wegen fehlendem Guthaben oder anderer bei der Erstautorisierung nicht vorhergesehener Gründe stoppen.
Empfängt ein Zugangsgerät ein ASR mit Session-ID einer aktiven Sitzung, KANN es die Sitzung beenden; dies hängt von Implementierung und Konfiguration ab (z. B. ASR nur von bestimmten Agenten). In jedem Fall MUSS es mit einer Abort-Session-Antwort und Result-Code AVP antworten.
8.5.1. Abort-Session-Request
Die Abort-Session-Request (ASR), Befehlscode 274 und gesetztes „R“-Bit, kann von jedem Diameter-Server oder -Proxy an das Zugangsgerät gesendet werden, um die durch Session-Id identifizierte Sitzung zu beenden.
Nachrichtenformat
::= < 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
Die Abort-Session-Answer (ASA), Befehlscode 274 und gelöschtes „R“-Bit, antwortet auf das ASR. Das Result-Code AVP MUSS vorhanden sein.
Erfolgreich beendet: DIAMETER_SUCCESS. Sitzung nicht aktiv: DIAMETER_UNKNOWN_SESSION_ID. Sonstige Verweigerung: DIAMETER_UNABLE_TO_COMPLY.
Nachrichtenformat
::= < 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. Ableiten der Sitzungsbeendigung aus Origin-State-Id
Origin-State-Id dient dazu, beendete Sitzungen ohne STR zu erkennen, wenn ein Zugangsgerät unerwartet ausfällt.
Client oder Zugangsgerät erhöht Origin-State-Id bei jedem Start und sendet den neuen Wert in CER/CEA nach Verbindungsaufbau. Der Server vergleicht den gespeicherten alten Wert mit dem neuen und prüft nicht beendete Sitzungen dieses Clients, um einen harten Absturz abzuleiten.
Origin-State-Id kann auch in anderen Anfragen vorkommen, wenn Relays oder Proxys dazwischen liegen; ein Neustart wird erst bei neuer Anfrage erkannt – eher opportunistisch.
Der Server KANN annehmen, dass alle vor einem Client-Neustart aktiven Sitzungen beendet sind, den Zustand bereinigen und STR an vorgelagerte Server senden, um global aufzuräumen.
8.7. Auth-Request-Type AVP
Das Auth-Request-Type AVP (Code 274) vom Typ Enumerated steht in anwendungsspezifischen Autorisierungsanfragen und teilt mit, ob der Benutzer nur authentifiziert, nur autorisiert oder beides werden soll. Jeder andere Wert als „beides“ KANN RADIUS-Interop-Probleme verursachen. Definierte Werte:
AUTHENTICATE_ONLY 1
Nur Authentifizierung; die Anfrage MUSS die vom Server benötigten anwendungsspezifischen Authentifizierungs-AVPs enthalten.
AUTHORIZE_ONLY 2
Nur Autorisierung; die Anfrage MUSS die zur Identifikation des angefragten/angebotenen Dienstes nötigen Autorisierungs-AVPs enthalten.
AUTHORIZE_AUTHENTICATE 3
Beides; die Anfrage MUSS relevante Authentifizierungs- und Autorisierungsinformationen enthalten.
8.8. Session-Id AVP
Das Session-Id AVP (Code 263), UTF8String, identifiziert eine Sitzung (Abschnitt 8). Jede Nachricht zu einer Sitzung MUSS genau ein Session-Id AVP mit demselben Wert über die Lebensdauer enthalten. Wenn vorhanden, SOLLTE das Session-Id unmittelbar auf den Diameter-Header folgen (Abschnitt 3).
Das Session-Id MUSS global und dauerhaft eindeutig sein, um eine Benutzersitzung ohne weitere Informationen zu identifizieren, und kann Authentifizierung und Abrechnung korrelieren. Es besteht aus einem verpflichtenden und einem implementierungsdefinierten Teil; empfohlenes Format unten.
Das Session-Id MUSS mit der in DiameterIdentity codierten Absenderidentität beginnen (Abschnitt 4.3.1). Der Rest ist durch „;“ getrennt und KANN jede dauerhaft eindeutige Sequenz sein; empfohlenes Format ([] optional):
<high>;<low>[;<optional>]
<high> und <low> sind die dezimalen Darstellungen der oberen und unteren 32 Bits eines streng monoton wachsenden 64-Bit-Werts, aufgeteilt für 32-Bit-Prozessoren. Beim Start KÖNNEN die oberen 32 Bits auf NTP-Zeit [RFC5905] und die unteren auf Null gesetzt werden, was nach Reboot praktisch Kollisionen vermeidet, wenn der Reboot länger als eine Sekunde dauert. Alternativ KANN der wachsende Wert in nichtflüchtigem Speicher gehalten werden.
<optional> ist implementierungsabhängig (Modem-Geräte-ID, Layer-2-Adresse, Zeitstempel usw.).
Beispiel ohne optionalen Teil:
accesspoint7.example.com;1876543210;523
Beispiel mit optionalem Teil:
accesspoint7.example.com;1876543210;523;[email protected]
Das Session-Id wird von der Diameter-Anwendung erzeugt, die die Sitzung eröffnet (in den meisten Fällen der Client). Dasselbe Session-Id KANN für Authentifizierungs-, Autorisierungs- und Accounting-Befehle einer Anwendung genutzt werden.
8.9. Authorization-Lifetime AVP
Das Authorization-Lifetime AVP (Code 291), Unsigned32, enthält die Höchstzahl Sekunden Dienst vor Re-Authentifizierung und/oder Re-Autorisierung. Ein kleiner, von Null verschiedener Wert kann den Diameter-Verkehr stark erhöhen.
Der Wert 0 erfordert sofortige Re-Authentifizierung. Fehlt das AVP oder sind alle 32 Bits auf 1, wird keine Re-Authentifizierung erwartet.
Sind dieses AVP und Session-Timeout gleichzeitig vorhanden, DARF Session-Timeout nicht kleiner als Authorization-Lifetime sein.
Re-Autorisierungsnachrichten KÖNNEN dieses AVP enthalten: Sekunden ab Empfang der Re-Autorisierungsantwort.
Der Client KANN einen Hinweis auf die maximal akzeptierte Lebensdauer senden; der Server MUSS einen Wert kleiner oder gleich zurückgeben.
8.10. Auth-Grace-Period AVP
Das Auth-Grace-Period AVP (Code 276), Unsigned32, ist die Wartezeit in Sekunden nach Ablauf des Authorization-Lifetime, bevor der Server Sitzungsressourcen bereinigt.
8.11. Auth-Session-State AVP
Das Auth-Session-State AVP (Code 277), Enumerated, gibt an, ob Zustand geführt wird. Der Client KANN es als Hinweis senden; maßgeblich ist der Wert in der Serverantwort.
STATE_MAINTAINED 0 — Zustand wird geführt; bei Dienstende MUSS eine Sitzungsbeendigungsnachricht gesendet werden (Standard).
NO_STATE_MAINTAINED 1 — Keine Sitzungsbeendigungsnachrichten bei Ablauf des Authorization-Lifetime.
8.12. Re-Auth-Request-Type AVP
Das Re-Auth-Request-Type AVP (Code 285), Enumerated, steht in anwendungsspezifischen Autorisierungsantworten und beschreibt die erwartete Aktion bei Ablauf des Authorization-Lifetime. Enthält die Antwort ein positives Authorization-Lifetime, MUSS dieses AVP vorhanden sein.
AUTHORIZE_ONLY 0 — Bei Ablauf nur autorisierende Re-Auth erwartet (Standard, wenn AVP fehlt, aber Authorization-Lifetime gesetzt ist).
AUTHORIZE_AUTHENTICATE 1 — Vollständige Re-Auth erwartet.
8.13. Session-Timeout AVP
Das Session-Timeout AVP (Code 27) [RFC2865], Unsigned32, ist die Höchstzahl Sekunden vor Sitzungsende. In einer Antwort mit beiden MUSS Session-Timeout mindestens Authorization-Lifetime sein.
Endet eine Sitzung am Zugangsgerät durch Session-Timeout-Ablauf, MUSS ein STR gesendet werden, sofern Zugangsgerät und Home-Server nicht vereinbart haben, keine Beendigungsnachrichten zu senden (Abschnitt 8).
In Re-Autorisierungsantworten KANN es die verbleibenden Sekunden seit Beginn der Re-Auth enthalten.
Null oder fehlendes AVP bedeutet unbegrenzte Dauer vor Beendigung.
Der Client KANN einen Hinweis senden; der Server KANN einen Wert kleiner oder gleich zurückgeben.
8.14. User-Name AVP
Das User-Name AVP (Code 1) [RFC2865], UTF8String, enthält den Benutzernamen im NAI-Format [RFC4282].
8.15. Termination-Cause AVP
Das Termination-Cause AVP (Code 295), Enumerated, gibt den Grund für das Ende der Sitzung am Zugangsgerät an. Aktuelle Werte: IANA-Registrierung Termination-Cause AVP Values [IANATCV].
8.16. Origin-State-Id AVP
Das Origin-State-Id AVP (Code 278), Unsigned32, steigt monoton bei jedem Neustart mit Zustandsverlust. Es KANN in jeder Diameter-Nachricht inkl. CER vorkommen.
Die Entität MUSS bei jedem Zustandsreset einen höheren Wert erzeugen; Startzeit oder nichtflüchtiger Zähler sind zulässig.
Wenn vorhanden, MUSS es den Zustand der durch Origin-Host bezeichneten Entität widerspiegeln. Ändert ein Proxy Origin-Host, MUSS er Origin-State-Id entfernen oder anpassen. Typisch startet ein Zugangsgerät ohne aktive Sitzungen; niedrigere Werte erlauben Rückschlüsse auf inaktive Sitzungen. Um das zu vermeiden, AVP weglassen oder auf 0 setzen.
8.17. Session-Binding AVP
Das Session-Binding AVP (Code 270), Unsigned32, KANN in anwendungsspezifischen Autorisierungsantworten vorkommen und KANN festlegen, dass künftige Re-Auths und STR für diese Sitzung zum selben Autorisierungsserver gehen.
Bitmaskenbits:
RE_AUTH 1 — Gesetzt: kein Destination-Host in künftigen Re-Auths; gelöscht (Standard): Destination-Host erforderlich.
STR 2 — Entsprechend für STR.
ACCOUNTING 4 — Entsprechend für Accounting, wenn der Host bekannt ist.
8.18. Session-Server-Failover AVP
Das Session-Server-Failover AVP (Code 271), Enumerated, KANN erscheinen, wenn Session-Binding fehlt oder ein Bit darin Null ist. Es KANN vorgeben, dass bei Zustellungsfehlern von Re-Auth oder STR eine Folgenachricht ohne Destination-Host gesendet werden SOLL. Standard bei Fehlen: REFUSE_SERVICE.
REFUSE_SERVICE 0 — Bei Fehler Dienst beenden, kein erneuter Versuch.
TRY_AGAIN 1 — Ohne Destination-Host erneut senden.
ALLOW_SERVICE 2 — Re-Auth-Zustellungsfehler: Re-Autorisierung als erfolgreich annehmen; STR-Fehler: Sitzung beenden.
TRY_AGAIN_ALLOW_SERVICE 3 — Wie TRY_AGAIN, zweiter Fehler wie bei ALLOW_SERVICE.
8.19. Multi-Round-Time-Out AVP
Das Multi-Round-Time-Out AVP (Code 272), Unsigned32, SOLLTE vorhanden sein, wenn Result-Code DIAMETER_MULTI_ROUND_AUTH ist. Maximale Sekunden, die das Zugangsgerät dem Nutzer zur Antwort auf eine Authentifizierungsanfrage geben MUSS.
8.20. Class AVP
Das Class AVP (Code 25), OctetString, transportiert Zustand vom Server zum Zugangsgerät. Ist es in einer Autorisierungsantwort enthalten, MUSS es in folgenden Re-Auths, Sitzungsende und Accounting wieder erscheinen. Werte aus Re-Autorisierungsantworten ersetzen frühere. Server SOLLTEN nicht mehr als 4096 Byte Speicher auf dem Client erfordern; kann der Client nicht speichern, MUSS er die Sitzung beenden.
8.21. Event-Timestamp AVP
Das Event-Timestamp AVP (Code 55), Time, KANN in Accounting-Request und -Answer stehen und den Zeitpunkt des Ereignisses in Sekunden seit dem 1. Januar 1900, 00:00 UTC angeben.