1. Introduction (Einführung)
Die Verwaltung verteilter serieller Leitungen und Modem-Pools (modem pools) für sehr viele Nutzer kann einen erheblichen administrativen Aufwand erzeugen. Modem-Pools sind definitionsgemäß eine Verbindung in die Außenwelt; sie erfordern daher sorgfältige Beachtung von Sicherheit (Security), Autorisierung (Authorization) und Accounting (Abrechnung). Am besten lässt sich dies erreichen, indem eine einzige „Datenbank" von Nutzern verwaltet wird, die sowohl Authentifizierung (Authentication) (Überprüfung von Benutzername und Passwort) als auch Konfigurationsinformationen bereitstellt, die die Art der dem Nutzer bereitzustellenden Dienste beschreiben (zum Beispiel SLIP, PPP, Telnet, rlogin).
Das RADIUS-Dokument (Remote Authentication Dial In User Service) [2] spezifiziert das RADIUS-Protokoll für Authentifizierung und Autorisierung. Dieses Memo erweitert die Verwendung des RADIUS-Protokolls auf die Zustellung von Accounting-Informationen vom Network Access Server (NAS) zu einem RADIUS-Accounting-Server.
Dieses Dokument ersetzt RFC 2139 [1]. Eine Zusammenfassung der Änderungen zwischen diesem Dokument und RFC 2139 findet sich im Anhang „Change Log" (Änderungsprotokoll).
Wesentliche Merkmale von RADIUS Accounting sind:
Client/Server-Modell (Client/Server Model)
Ein Network Access Server (NAS) arbeitet als Client des RADIUS-Accounting-Servers. Der Client ist dafür verantwortlich, Nutzer-Accounting-Informationen an einen bestimmten RADIUS-Accounting-Server weiterzugeben.
Der RADIUS-Accounting-Server ist dafür verantwortlich, die Accounting-Anfrage (accounting request) zu empfangen und dem Client eine Antwort zu senden, die anzeigt, dass die Anfrage erfolgreich empfangen wurde.
Der RADIUS-Accounting-Server kann als Proxy-Client (proxy client) gegenüber anderen Arten von Accounting-Servern agieren.
Netzwerksicherheit (Network Security)
Transaktionen (Transactions) zwischen dem Client und dem RADIUS-Accounting-Server werden durch die Verwendung eines Shared Secret (gemeinsamen Geheimnisses) authentifiziert, das niemals über das Netzwerk gesendet wird.
Erweiterbares Protokoll (Extensible Protocol)
Alle Transaktionen bestehen aus Attribut-Länge-Wert-Tupeln (Attribute-Length-Value 3-tuples) variabler Länge. Neue Attributwerte können hinzugefügt werden, ohne bestehende Implementierungen des Protokolls zu stören.
1.1. Specification of Requirements (Festlegung der Anforderungen)
Die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLL, SOLL NICHT, SOLLTE, SOLLTE NICHT, EMPFOHLEN, KANN und OPTIONAL in diesem Dokument sind wie in RFC 2119 [3] beschrieben zu interpretieren. Diese Schlüsselwörter haben dieselbe Bedeutung, unabhängig davon, ob sie groß oder klein geschrieben werden.
1.2. Terminology (Terminologie)
Dieses Dokument verwendet die folgenden Begriffe:
service (Dienst)
Der NAS stellt einem Einwahlbenutzer (dial-in user) einen Dienst bereit, z. B. PPP oder Telnet.
session (Sitzung)
Jeder vom NAS für einen Einwahlbenutzer bereitgestellte Dienst bildet eine Sitzung; der Beginn der Sitzung ist der Zeitpunkt, zu dem der Dienst erstmals bereitgestellt wird, und das Ende der Sitzung der Zeitpunkt, zu dem der Dienst beendet wird. Ein Nutzer kann mehrere Sitzungen parallel oder nacheinander haben, wenn der NAS dies unterstützt; jede Sitzung erzeugt einen separaten Start- und Stop-Accounting-Datensatz mit einer eigenen Acct-Session-Id.
silently discard (stilles Verwerfen)
Die Implementierung verwirft das Paket ohne weitere Verarbeitung. Die Implementierung SOLLTE die Fähigkeit bieten, den Fehler zu protokollieren, einschließlich des Inhalts des still verworfenen Pakets, und SOLLTE das Ereignis in einem Statistikzähler (statistics counter) festhalten.