1. Einführung

1. Einführung

Authentifizierungs-, Autorisierungs- und Abrechnungsprotokolle (AAA) wie TACACS [RFC1492] und RADIUS [RFC2865] wurden ursprünglich bereitgestellt, um Einwahl-PPP [RFC1661] und Terminalserver-Zugriff bereitzustellen. Im Laufe der Zeit wurde AAA-Unterstützung für viele neue Zugangstechnologien benötigt, die Größe und Komplexität von AAA-Netzwerken wuchs, und AAA wurde auch für neue Anwendungen (wie Voice over IP) verwendet. Dies führte zu neuen Anforderungen an AAA-Protokolle.

Die Netzwerkzugriffsanforderungen für AAA-Protokolle sind in Aboba, et al. [RFC2989] zusammengefasst. Diese umfassen:

Failover

[RFC2865] definiert keine Failover-Mechanismen, und daher unterscheidet sich das Failover-Verhalten zwischen Implementierungen. Um ein klar definiertes Failover-Verhalten bereitzustellen, unterstützt Diameter Bestätigungen auf Anwendungsebene und definiert Failover-Algorithmen und die zugehörige Zustandsmaschine.

Übertragungsebenen-Sicherheit

RADIUS [RFC2865] definiert ein Authentifizierungs- und Integritätsschema auf Anwendungsebene, das nur für Antwortpakete erforderlich ist. Während [RFC2869] einen zusätzlichen Authentifizierungs- und Integritätsmechanismus definiert, ist die Verwendung nur während EAP-Sitzungen (Extensible Authentication Protocol) [RFC3748] erforderlich. Obwohl Attributverschleierung unterstützt wird, bietet [RFC2865] keine Unterstützung für paketweise Vertraulichkeit. Bei der Abrechnung wird in [RFC2866] angenommen, dass Replay-Schutz vom Backend-Abrechnungsserver und nicht innerhalb des Protokolls selbst bereitgestellt wird.

Während [RFC3162] die Verwendung von IPsec mit RADIUS definiert, ist die Unterstützung von IPsec nicht erforderlich. Um universelle Unterstützung für Übertragungsebenen-Sicherheit bereitzustellen und sowohl domäneninterne als auch domänenübergreifende AAA-Bereitstellungen zu ermöglichen, bietet Diameter Unterstützung für TLS/TCP und DTLS/SCTP. Sicherheit wird in Abschnitt 13 diskutiert.

Zuverlässiger Transport

RADIUS läuft über UDP und definiert kein Neuübertragungsverhalten; daher variiert die Zuverlässigkeit zwischen Implementierungen. Wie in [RFC2975] beschrieben, ist dies ein Hauptproblem bei der Abrechnung, wo Paketverlust sich direkt in Umsatzverlust übersetzen kann. Um ein klar definiertes Transportverhalten bereitzustellen, läuft Diameter über zuverlässige Transportmechanismen (TCP, Stream Control Transmission Protocol (SCTP)), wie in [RFC3539] definiert.

Agenten-Unterstützung

RADIUS bietet keine explizite Unterstützung für Agenten, einschließlich Proxys, Weiterleitungen und Relays. Da das erwartete Verhalten nicht definiert ist, variiert es zwischen Implementierungen. Diameter definiert das Agentenverhalten explizit; dies wird in Abschnitt 2.8 beschrieben.

Vom Server initiierte Nachrichten

Während vom Server initiierte Nachrichten in RADIUS [RFC5176] definiert sind, ist die Unterstützung optional. Dies erschwert die Implementierung von Funktionen wie unaufgeforderte Trennung oder erneute Authentifizierung/erneute Autorisierung auf Anfrage über eine heterogene Bereitstellung hinweg. Um dieses Problem anzugehen, ist die Unterstützung für vom Server initiierte Nachrichten in Diameter obligatorisch.

Übergangsunterstützung

Obwohl Diameter keine gemeinsame Protokolldateneinheit (PDU) mit RADIUS teilt, wurden erhebliche Anstrengungen unternommen, um die Rückwärtskompatibilität mit RADIUS zu ermöglichen, damit die beiden Protokolle im selben Netzwerk bereitgestellt werden können. Zunächst wird erwartet, dass Diameter in neuen Netzwerkgeräten sowie in Gateways bereitgestellt wird, die die Kommunikation zwischen Legacy-RADIUS-Geräten und Diameter-Agenten ermöglichen. Diese Fähigkeit ermöglicht es, Diameter-Unterstützung zu Legacy-Netzwerken hinzuzufügen, indem ein Gateway oder Server hinzugefügt wird, der sowohl RADIUS als auch Diameter spricht.

Zusätzlich zur Erfüllung der oben genannten Anforderungen bietet Diameter auch Unterstützung für Folgendes:

Fähigkeitsverhandlung

RADIUS unterstützt keine Fehlermeldungen, Fähigkeitsverhandlung oder ein obligatorisches/nicht obligatorisches Flag für Attribute. Da RADIUS-Clients und -Server sich der Fähigkeiten des anderen nicht bewusst sind, können sie möglicherweise keinen gegenseitig akzeptablen Dienst erfolgreich aushandeln oder in einigen Fällen nicht einmal wissen, welcher Dienst implementiert wurde. Diameter umfasst Unterstützung für Fehlerbehandlung (Abschnitt 7), Fähigkeitsverhandlung (Abschnitt 5.3) und obligatorische/nicht obligatorische Attribut-Wert-Paare (AVPs) (Abschnitt 4.1).

Peer-Erkennung und -Konfiguration

RADIUS-Implementierungen erfordern typischerweise, dass der Name oder die Adresse von Servern oder Clients manuell konfiguriert wird, zusammen mit den entsprechenden gemeinsamen Geheimnissen. Dies führt zu einer großen Verwaltungslast und schafft die Versuchung, das gemeinsame RADIUS-Geheimnis wiederzuverwenden, was zu erheblichen Sicherheitslücken führen kann, wenn der Request Authenticator nicht global und zeitlich eindeutig ist, wie in [RFC2865] gefordert. Über DNS ermöglicht Diameter die dynamische Erkennung von Peers (siehe Abschnitt 5.2). Die Ableitung dynamischer Sitzungsschlüssel wird über Übertragungsebenen-Sicherheit ermöglicht.

Im Laufe der Zeit sind die Fähigkeiten von Network Access Server (NAS)-Geräten erheblich gewachsen. Daher ist es zwar ein erheblich ausgefeilteres Protokoll als RADIUS, aber es bleibt machbar, Diameter in eingebetteten Geräten zu implementieren.

1.1. Diameter-Protokoll

Das Diameter-Basisprotokoll bietet folgende Funktionen:

• Fähigkeit zum Austausch von Nachrichten und zur Übermittlung von AVPs
• Fähigkeitsverhandlung
• Fehlerbenachrichtigung
• Erweiterbarkeit, erforderlich in [RFC2989], durch Hinzufügung neuer Anwendungen, Befehle und AVPs
• Basisdienste, die für Anwendungen erforderlich sind, wie die Handhabung von Benutzersitzungen oder Abrechnung

Alle vom Protokoll übermittelten Daten liegen in Form von AVPs vor. Einige dieser AVP-Werte werden vom Diameter-Protokoll selbst verwendet, während andere Daten übermitteln, die mit bestimmten Anwendungen verbunden sind, die Diameter verwenden. AVPs können beliebig zu Diameter-Nachrichten hinzugefügt werden, die einzige Einschränkung besteht darin, dass die Command Code Format (CCF)-Spezifikation (Abschnitt 3.2) erfüllt sein muss. AVPs werden vom Diameter-Basisprotokoll verwendet, um die folgenden erforderlichen Funktionen zu unterstützen:

• Transport von Benutzerauthentifizierungsinformationen, um es dem Diameter-Server zu ermöglichen, den Benutzer zu authentifizieren
• Transport von dienstspezifischen Autorisierungsinformationen zwischen Client und Servern, damit die Peers entscheiden können, ob die Zugriffsanforderung eines Benutzers gewährt werden soll
• Austausch von Ressourcennutzungsinformationen, die für Abrechnungszwecke, Kapazitätsplanung usw. verwendet werden können
• Routing, Weiterleitung, Proxying und Umleitung von Diameter-Nachrichten durch eine Serverhierarchie

Das Diameter-Basisprotokoll erfüllt die Mindestanforderungen für ein AAA-Protokoll, wie in [RFC2989] spezifiziert. Das Basisprotokoll kann allein nur für Abrechnungszwecke verwendet werden, oder es kann mit einer Diameter-Anwendung verwendet werden, wie Mobile IPv4 [RFC4004] oder Netzwerkzugang [RFC4005]. Es ist auch möglich, das Basisprotokoll für die Verwendung in neuen Anwendungen zu erweitern, durch Hinzufügung neuer Befehle oder AVPs. Der anfängliche Fokus von Diameter lag auf Netzwerkzugangs- und Abrechnungsanwendungen. Ein wirklich generisches AAA-Protokoll, das von vielen Anwendungen verwendet wird, könnte Funktionalität bieten, die Diameter nicht bietet. Daher ist es unerlässlich, dass die Designer neuer Anwendungen ihre Anforderungen verstehen, bevor sie Diameter verwenden. Siehe Abschnitt 1.3.4 für weitere Informationen zu Diameter-Anwendungen.

Jeder Knoten kann eine Anforderung initiieren. In diesem Sinne ist Diameter ein Peer-to-Peer-Protokoll. In diesem Dokument ist ein Diameter-Client ein Gerät am Rand des Netzwerks, das Zugangskontrolle durchführt, wie ein Network Access Server (NAS) oder ein Foreign Agent (FA). Ein Diameter-Client generiert Diameter-Nachrichten, um Authentifizierungs-, Autorisierungs- und Abrechnungsdienste für den Benutzer anzufordern. Ein Diameter-Agent ist ein Knoten, der keine lokalen Benutzerauthentifizierungs- oder Autorisierungsdienste bereitstellt; Agenten umfassen Proxys, Weiterleitungen und Relay-Agenten. Ein Diameter-Server führt die Authentifizierung und/oder Autorisierung des Benutzers durch. Ein Diameter-Knoten kann als Agent für bestimmte Anforderungen fungieren, während er für andere als Server fungiert.

Das Diameter-Protokoll unterstützt auch vom Server initiierte Nachrichten, wie eine Anforderung, den Dienst für einen bestimmten Benutzer abzubrechen.

1.1.1. Beschreibung des Dokumentensatzes

Die Diameter-Spezifikation besteht aus einer aktualisierten Version der Basisprotokollspezifikation (dieses Dokument) und dem Transportprofil [RFC3539]. Dieses Dokument macht sowohl RFC 3588 als auch RFC 5719 obsolet. Eine Zusammenfassung der in diesem Dokument enthaltenen Basisprotokoll-Updates finden Sie in Abschnitt 1.1.3.

Dieses Dokument definiert die Basisprotokollspezifikation für AAA, die Unterstützung für Abrechnung umfasst. Es gibt auch eine Vielzahl von Anwendungsdokumenten, die Anwendungen beschreiben, die diese Basisspezifikation für Authentifizierung, Autorisierung und Abrechnung verwenden. Diese Anwendungsdokumente spezifizieren, wie das Diameter-Protokoll im Kontext ihrer Anwendung zu verwenden ist.

Das Transportprofil-Dokument [RFC3539] diskutiert Transportschichtprobleme, die bei AAA-Protokollen auftreten, und Empfehlungen zur Überwindung dieser Probleme. Dieses Dokument definiert auch den Diameter-Failover-Algorithmus und die Zustandsmaschine.

"Klarstellungen zum Routing von Diameter-Anforderungen basierend auf dem Benutzernamen und dem Realm" [RFC5729] definiert spezifisches Verhalten zum Routing von Anforderungen basierend auf dem Inhalt des User-Name-AVP (Attribut-Wert-Paar).

1.1.2. In diesem Dokument verwendete Konventionen

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

1.1.3. Änderungen gegenüber RFC 3588

Dieses Dokument macht RFC 3588 obsolet, ist aber vollständig rückwärtskompatibel mit diesem Dokument. Die in diesem Dokument eingeführten Änderungen konzentrieren sich auf die Behebung von Problemen, die während der Implementierung von Diameter (RFC 3588) aufgetreten sind. Nachfolgend finden Sie einen Überblick über einige der wichtigsten Änderungen.

• Die Verwendung des Inband-Security-AVP für die Aushandlung von Transport Layer Security (TLS) [RFC5246] wurde als veraltet markiert. Es wurde allgemein angenommen, dass das Bootstrapping von TLS über Inband-Security-AVP bestimmte Sicherheitsrisiken birgt, da es die im CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer) übertragenen Informationen nicht vollständig schützt. Diese Version von Diameter übernimmt den gängigen Ansatz, einen bekannten gesicherten Port zu definieren, den Peers bei der Kommunikation über TLS/TCP und DTLS/SCTP verwenden sollten. Dieser neue Ansatz ergänzt die bestehende In-Band-Sicherheitsverhandlung, ersetzt sie jedoch nicht vollständig. Die alte Methode wird aus Gründen der Rückwärtskompatibilität beibehalten.

• Der Austausch von CER/CEA-Nachrichten im offenen Zustand wurde als veraltet markiert. Diese Funktion wurde in der Peer-Zustandsmaschinen-Tabelle von RFC 3588 impliziert, aber nirgendwo sonst in diesem Dokument klar definiert. Als die Arbeit an diesem Dokument voranschritt, wurde klar, dass die Vielfalt der Bedeutungen und Verwendungen von Application-Id-AVPs in den CER/CEA-Nachrichten (und den Nachrichten selbst) als Missbrauch der Diameter-Erweiterbarkeitsregeln angesehen wird und daher eine Vereinfachung erforderlich ist. Der Fähigkeitsaustausch im offenen Zustand wurde in einer separaten Spezifikation [RFC6737] wieder eingeführt, die neue Befehle für diese Funktion klar definiert.

• Die Sicherheitsanforderungen wurden vereinfacht. Die Verwendung eines gesicherten Transports für den Austausch von Diameter-Nachrichten bleibt obligatorisch. TLS/TCP und DTLS/SCTP sind jedoch zu den primären Methoden zur Sicherung von Diameter geworden, wobei IPsec als sekundäre Alternative dient. Einzelheiten finden Sie in Abschnitt 13. Die Unterstützung für das End-to-End-Sicherheitsframework (E2E-Sequence-AVP und 'P'-Bit im AVP-Header) wurde ebenfalls als veraltet markiert.

• Die Diameter-Erweiterbarkeit wurde geändert. Dies umfasst Korrekturen an der Beschreibung der Diameter-Erweiterbarkeit (Abschnitt 1.3 und andere), um Diameter-Anwendungsdesignern besser zu helfen; darüber hinaus lockert die neue Spezifikation die Richtlinie hinsichtlich der Zuweisung von Befehlscodes für herstellerspezifische Verwendungen.

• Die Verwendung der Anwendungs-ID wurde geklärt. Die ordnungsgemäße Verwendung von Anwendungs-ID-Informationen, die an mehreren Stellen innerhalb einer Diameter-Nachricht gefunden werden können, wird geklärt. Dies umfasst die Korrelation von Anwendungs-IDs, die in Nachrichtenheadern und AVPs gefunden werden. Diese Änderungen spezifizieren auch klar den geeigneten Anwendungs-ID-Wert für spezifische Basisprotokollnachrichten (ASR/ASA, STR/STA) und klären den Inhalt und die Verwendung von Vendor-Specific-Application-Id.

• Routing-Korrekturen wurden geklärt. Dieses Dokument spezifiziert klarer, welche Informationen (AVPs und Anwendungs-IDs) für allgemeine Routing-Entscheidungen verwendet werden können. Eine Regel für die Priorisierung von Umleitungs-Routing-Kriterien, wenn mehrere Routeneinträge über Umleitungen gefunden werden, wurde ebenfalls hinzugefügt (siehe Abschnitt 6.13).

• Die Diameter-Peer-Erkennung wurde vereinfacht. Der Diameter-Erkennungsprozess unterstützt jetzt nur noch weit verbreitete Erkennungsschemata; der Rest wurde als veraltet markiert (siehe Abschnitt 5.2 für Details).

Es gibt viele andere verschiedene Korrekturen, die in diesem Dokument eingeführt wurden und möglicherweise nicht als bedeutend angesehen werden, aber dennoch wertvoll sind. Beispiele sind die Entfernung veralteter Typen, Korrekturen an der Zustandsmaschine, Klarstellung des Wahlprozesses, Nachrichtenvalidierung, Korrekturen an Failed-AVP- und Result-Code-AVP-Werten usw. Alle vor der Veröffentlichung dieses Dokuments gegen RFC 3588 eingereichten Errata wurden behandelt. Eine umfassende Liste der Änderungen wird hier aus praktischen Gründen nicht angezeigt.

1.2. Terminologie

AAA

Authentifizierung, Autorisierung und Abrechnung.

ABNF

Augmented Backus-Naur Form [RFC5234]. Eine Metasprache mit eigener formaler Syntax und Regeln. Sie basiert auf der Backus-Naur-Form und wird verwendet, um Nachrichtenaustausch in einem bidirektionalen Kommunikationsprotokoll zu definieren.

Abrechnung (Accounting)

Der Akt des Sammelns von Informationen über die Ressourcennutzung zum Zweck der Kapazitätsplanung, Prüfung, Abrechnung oder Kostenzuordnung.

Abrechnungsdatensatz (Accounting Record)

Ein Abrechnungsdatensatz stellt eine Zusammenfassung des Ressourcenverbrauchs eines Benutzers während der gesamten Sitzung dar. Abrechnungsserver, die den Abrechnungsdatensatz erstellen, können dies tun, indem sie Zwischenabrechnungsereignisse oder Abrechnungsereignisse von mehreren Geräten verarbeiten, die demselben Benutzer dienen.

Authentifizierung (Authentication)

Der Akt der Überprüfung der Identität einer Entität (Subjekt).

Autorisierung (Authorization)

Der Akt der Bestimmung, ob einer anfordernden Entität (Subjekt) Zugriff auf eine Ressource (Objekt) gewährt wird.

Attribut-Wert-Paar (Attribute-Value Pair, AVP)

Das Diameter-Protokoll besteht aus einem Header, gefolgt von einem oder mehreren Attribut-Wert-Paaren (AVPs). Ein AVP umfasst einen Header und wird verwendet, um protokollspezifische Daten (z. B. Routing-Informationen) sowie Authentifizierungs-, Autorisierungs- oder Abrechnungsinformationen zu kapseln.

Befehlscode-Format (Command Code Format, CCF)

Eine modifizierte Form von ABNF, die zur Definition von Diameter-Befehlen verwendet wird (siehe Abschnitt 3.2).

Diameter-Agent (Diameter Agent)

Ein Diameter-Agent ist ein Diameter-Knoten, der Relay-, Proxy-, Weiterleitungs- oder Übersetzungsdienste bereitstellt.

Diameter-Client (Diameter Client)

Ein Diameter-Client ist ein Diameter-Knoten, der Diameter-Clientanwendungen sowie das Basisprotokoll unterstützt. Diameter-Clients werden oft in Geräten implementiert, die sich am Rand eines Netzwerks befinden und Zugangskontrolldienste für dieses Netzwerk bereitstellen. Typische Beispiele für Diameter-Clients sind der Network Access Server (NAS) und der Mobile IP Foreign Agent (FA).

Diameter-Knoten (Diameter Node)

Ein Diameter-Knoten ist ein Host-Prozess, der das Diameter-Protokoll implementiert und als Client, Agent oder Server fungiert.

Diameter-Peer (Diameter Peer)

Zwei Diameter-Knoten, die eine direkte TCP- oder SCTP-Transportverbindung teilen, werden als Diameter-Peers bezeichnet.

Diameter-Server (Diameter Server)

Ein Diameter-Server ist ein Diameter-Knoten, der Authentifizierungs-, Autorisierungs- und Abrechnungsanforderungen für einen bestimmten Realm verarbeitet. Naturgemäß muss ein Diameter-Server zusätzlich zum Basisprotokoll Diameter-Serveranwendungen unterstützen.

Downstream

Downstream wird verwendet, um die Richtung einer bestimmten Diameter-Nachricht vom Home-Server zum Diameter-Client zu identifizieren.

Home-Realm

Ein Home-Realm ist die administrative Domäne, mit der der Benutzer eine Kontobeziehung unterhält.

Home-Server

Ein Diameter-Server, der dem Home-Realm dient.

Zwischenabrechnung (Interim Accounting)

Eine Zwischenabrechnungsnachricht liefert eine Momentaufnahme der Nutzung während der Sitzung eines Benutzers. Typischerweise wird sie implementiert, um eine teilweise Abrechnung der Sitzung eines Benutzers bereitzustellen, falls ein Geräteneustart oder ein anderes Netzwerkproblem die Zustellung einer Sitzungszusammenfassungsnachricht oder eines Sitzungsdatensatzes verhindert.

Lokaler Realm (Local Realm)

Ein lokaler Realm ist die administrative Domäne, die einem Benutzer Dienste bereitstellt. Eine administrative Domäne kann für bestimmte Benutzer als lokaler Realm fungieren, während sie für andere als Home-Realm fungiert.

Multi-Sitzung (Multi-session)

Eine Multi-Sitzung stellt eine logische Verknüpfung mehrerer Sitzungen dar. Multi-Sitzungen werden mithilfe der Acct-Multi-Session-Id verfolgt. Ein Beispiel für eine Multi-Sitzung wäre ein Multi-Link-PPP-Bündel. Jede Verbindung des Bündels wäre eine Sitzung, während das gesamte Bündel eine Multi-Sitzung wäre.

Netzwerkzugangsidentifikator (Network Access Identifier)

Der Netzwerkzugangsidentifikator oder NAI [RFC4282] wird im Diameter-Protokoll verwendet, um die Identität und den Realm eines Benutzers zu extrahieren. Die Identität wird verwendet, um den Benutzer während der Authentifizierung und/oder Autorisierung zu identifizieren, während der Realm für Nachrichtenrouting-Zwecke verwendet wird.

Proxy-Agent oder Proxy (Proxy Agent or Proxy)

Zusätzlich zur Weiterleitung von Anforderungen und Antworten treffen Proxys politische Entscheidungen in Bezug auf Ressourcennutzung und Bereitstellung. Typischerweise wird dies durch Verfolgung des Zustands von NAS-Geräten erreicht. Während Proxys normalerweise nicht auf Clientanforderungen antworten, bevor sie eine Antwort vom Server erhalten, können sie in Fällen, in denen Richtlinien verletzt werden, Ablehnungsnachrichten initiieren. Daher müssen Proxys die Semantik der durch sie laufenden Nachrichten verstehen, und sie unterstützen möglicherweise nicht alle Diameter-Anwendungen.

Realm

Die Zeichenfolge im NAI, die unmittelbar auf das '@'-Zeichen folgt. NAI-Realm-Namen müssen eindeutig sein und werden auf der Verwaltung des DNS-Namensraums aufgebaut. Diameter verwendet den Realm, auch lose als Domäne bezeichnet, um zu bestimmen, ob Nachrichten lokal erfüllt werden können oder ob sie geroutet oder umgeleitet werden müssen. In RADIUS sind Realm-Namen nicht unbedingt auf dem DNS-Namensraum aufgebaut, sondern können davon unabhängig sein.

Echtzeit-Abrechnung (Real-Time Accounting)

Echtzeit-Abrechnung umfasst die Verarbeitung von Informationen über die Ressourcennutzung innerhalb eines definierten Zeitfensters. Typischerweise werden Zeitbeschränkungen auferlegt, um finanzielle Risiken zu begrenzen. Die Diameter-Kreditkontrollanwendung [RFC4006] ist ein Beispiel für eine Anwendung, die Echtzeit-Abrechnungsfunktionalität definiert.

Relay-Agent oder Relay (Relay Agent or Relay)

Relays leiten Anforderungen und Antworten basierend auf Routing-bezogenen AVPs und Routing-Tabelleneinträgen weiter. Da Relays keine politischen Entscheidungen treffen, untersuchen oder ändern sie keine Nicht-Routing-AVPs. Daher initiieren Relays niemals Nachrichten, müssen die Semantik von Nachrichten oder Nicht-Routing-AVPs nicht verstehen und sind in der Lage, jede Diameter-Anwendung oder jeden Nachrichtentyp zu verarbeiten. Da Relays Entscheidungen basierend auf Informationen in Routing-AVPs und Realm-Weiterleitungstabellen treffen, halten sie keinen Zustand über NAS-Ressourcennutzung oder laufende Sitzungen.

Weiterleitungs-Agent (Redirect Agent)

Anstatt Anforderungen und Antworten zwischen Clients und Servern weiterzuleiten, verweisen Weiterleitungs-Agenten Clients auf Server und ermöglichen ihnen die direkte Kommunikation. Da Weiterleitungs-Agenten sich nicht im Weiterleitungspfad befinden, ändern sie keine AVPs, die zwischen Client und Server übertragen werden. Weiterleitungs-Agenten initiieren keine Nachrichten und sind in der Lage, jeden Nachrichtentyp zu verarbeiten, obwohl sie möglicherweise so konfiguriert sind, dass sie nur Nachrichten bestimmter Typen weiterleiten, während sie für andere Typen als Relay- oder Proxy-Agenten fungieren. Wie bei Relay-Agenten halten Weiterleitungs-Agenten keinen Zustand in Bezug auf Sitzungen oder NAS-Ressourcen.

Sitzung (Session)

Eine Sitzung ist eine zusammenhängende Abfolge von Ereignissen, die einer bestimmten Aktivität gewidmet sind. Diameter-Anwendungsdokumente bieten Richtlinien dazu, wann eine Sitzung beginnt und endet. Alle Diameter-Pakete mit derselben Session-Id werden als Teil derselben Sitzung betrachtet.

Zustandsbehafteter Agent (Stateful Agent)

Ein zustandsbehafteter Agent ist einer, der Sitzungszustandsinformationen aufrechterhält, indem er alle autorisierten aktiven Sitzungen verfolgt. Jede autorisierte Sitzung ist an einen bestimmten Dienst gebunden, und ihr Zustand wird als aktiv betrachtet, entweder bis eine andere Benachrichtigung erfolgt oder bis zum Ablauf.

Untersitzung (Sub-session)

Eine Untersitzung stellt einen unterschiedlichen Dienst (z. B. QoS oder Datenmerkmale) dar, der einer bestimmten Sitzung bereitgestellt wird. Diese Dienste können gleichzeitig (z. B. gleichzeitige Sprach- und Datenübertragung während derselben Sitzung) oder seriell auftreten. Diese Änderungen in Sitzungen werden mit der Accounting-Sub-Session-Id verfolgt.

Transaktionszustand (Transaction State)

Das Diameter-Protokoll erfordert, dass Agenten den Transaktionszustand aufrechterhalten, der für Failover-Zwecke verwendet wird. Transaktionszustand bedeutet, dass beim Weiterleiten einer Anforderung der Hop-by-Hop-Identifier gespeichert wird; das Feld wird durch einen lokal eindeutigen Identifier ersetzt, der auf seinen ursprünglichen Wert wiederhergestellt wird, wenn die entsprechende Antwort empfangen wird. Der Zustand der Anforderung wird beim Empfang der Antwort freigegeben. Ein zustandsloser Agent ist einer, der nur den Transaktionszustand aufrechterhält.

Übersetzungs-Agent (Translation Agent)

Ein Übersetzungs-Agent (TLA in Abbildung 4) ist ein zustandsbehafteter Diameter-Knoten, der Protokollübersetzung zwischen Diameter und einem anderen AAA-Protokoll, wie RADIUS, durchführt.

Upstream

Upstream wird verwendet, um die Richtung einer bestimmten Diameter-Nachricht vom Diameter-Client zum Home-Server zu identifizieren.

Benutzer (User)

Die Entität oder das Gerät, das eine Ressource anfordert oder nutzt, für die ein Diameter-Client eine Anforderung generiert hat.

1.3. Ansatz zur Erweiterbarkeit

Das Diameter-Protokoll ist so konzipiert, dass es erweiterbar ist, unter Verwendung mehrerer Mechanismen, einschließlich:

• Definition neuer AVP-Werte
• Erstellung neuer AVPs
• Erstellung neuer Befehle
• Erstellung neuer Anwendungen

Aus Sicht der Erweiterbarkeit werden Diameter-Authentifizierungs-, Autorisierungs- und Abrechnungsanwendungen gleich behandelt.

Hinweis: Protokolldesigner sollten versuchen, vorhandene Funktionalität wiederzuverwenden, nämlich AVP-Werte, AVPs, Befehle und Diameter-Anwendungen. Wiederverwendung vereinfacht die Standardisierung und Implementierung. Um potenzielle Interoperabilitätsprobleme zu vermeiden, ist es wichtig sicherzustellen, dass die Semantik der wiederverwendeten Funktionen gut verstanden wird. Da Diameter auch RADIUS-Attribute als Diameter-AVPs tragen kann, gelten solche Wiederverwendungsüberlegungen auch für vorhandene RADIUS-Attribute, die in einer Diameter-Anwendung nützlich sein können.

1.3.1. Definition neuer AVP-Werte

Um einen neuen AVP-Wert für AVPs zuzuweisen, die im Diameter-Basisprotokoll definiert sind, muss die IETF einen neuen RFC genehmigen, der den AVP-Wert beschreibt. IANA-Überlegungen für diese AVP-Werte werden in Abschnitt 11.3 diskutiert.

Die Zuweisung von AVP-Werten für andere AVPs wird von den IANA-Überlegungen des Dokuments geleitet, das diese AVPs definiert. Typischerweise würde die Zuweisung neuer Werte für einen in einem RFC definierten AVP eine IETF-Überprüfung [RFC5226] erfordern, während Werte für herstellerspezifische AVPs vom Hersteller zugewiesen werden können.

1.3.2. Erstellung neuer AVPs

Ein neuer AVP, der definiert wird, MUSS einen der in den Abschnitten 4.2 oder 4.3 aufgeführten Datentypen verwenden. Wenn bereits ein geeigneter abgeleiteter Datentyp definiert ist, SOLLTE er anstelle eines Basisdatentyps verwendet werden, um Wiederverwendbarkeit und gute Designpraxis zu fördern.

Für den Fall, dass eine logische Gruppierung von AVPs erforderlich ist und mehrere "Gruppen" in einem bestimmten Befehl möglich sind, wird empfohlen, einen gruppierten AVP zu verwenden (siehe Abschnitt 4.4).

Die Erstellung neuer AVPs kann auf verschiedene Weise erfolgen. Der empfohlene Ansatz besteht darin, einen neuen allgemeinen AVP in einem von der IETF genehmigten Standards Track RFC zu definieren. Wie jedoch in Abschnitt 11.1.1 beschrieben, gibt es andere Mechanismen.

1.3.3. Erstellung neuer Befehle

Ein neuer Befehlscode MUSS zugewiesen werden, wenn erforderliche AVPs (diejenigen, die in der CCF-Definition als {AVP} angegeben sind) zu einem vorhandenen Befehl hinzugefügt, aus ihm gelöscht oder darin neu definiert werden (z. B. durch Ändern eines erforderlichen AVP in einen optionalen).

Darüber hinaus MUSS ein neuer Befehlscode registriert werden, wenn sich die Transportmerkmale eines Befehls ändern (z. B. in Bezug auf die Anzahl der erforderlichen Rundfahrten).

Eine Änderung des CCF eines Befehls, wie oben beschrieben, MUSS zur Definition eines neuen Befehlscodes führen. Dies führt anschließend zur Notwendigkeit, eine neue Diameter-Anwendung für jede Anwendung zu definieren, die diesen neuen Befehl verwenden wird.

Die IANA-Überlegungen für Befehlscodes werden in Abschnitt 3.1 diskutiert.

1.3.4. Erstellung neuer Diameter-Anwendungen

Diameter-Anwendungen können neue Befehlscodes, AVPs und zugehörige Semantiken definieren. Die Erstellung neuer Diameter-Anwendungen erfordert typischerweise einen von der IETF genehmigten Standards Track RFC. Siehe Abschnitt 11.2.1 für Details.