Zusammenfassung

  • RFC 3169 behandelte Angaben eines Network Access Server (NAS) als Hinweise und nicht als Anweisungen; die abschließende Autorisierungsentscheidung sollte der AAA-Server treffen.
  • Der NAS musste diese Entscheidung dennoch umsetzen. Ressourcenzustand, Abrechnungsdaten und tatsächlich erbrachter Dienst sind getrennt nachzuweisen.

Diese Zuständigkeitsaufteilung steht in einem Dokument, das leicht für eine Norm gehalten werden kann. RFC 3169 erschien im September 2001 als Informational und erklärt ausdrücklich, keinen Internet-Standard festzulegen. Schon der Titel „Criteria for Evaluating Network Access Server Protocols“ verspricht eine Bewertungsgrundlage, kein neues Paketformat. Das Papier unterscheidet für NAS vier Protokollbereiche: Zugang, Netzwerk, AAA und Gerätemanagement. Sein Schwerpunkt liegt auf AAA. Das zugrunde liegende Modell umfasst Geräte, die Einwahl-, Breitband- und Tunnelverbindungen bündeln und Tausende Sitzungen gleichzeitig bedienen können.

Bemerkenswert ist weniger die Länge der Kriterien als die Verteilung der Entscheidungsbefugnis. Im Autorisierungsteil heißt es, Informationen, die der NAS an den AAA-Server sendet, seien als „information or hints“ zu behandeln, nicht als Weisung. Die endgültige Entscheidung liegt beim Server; er soll keinen Zustand voraussetzen, nur weil der NAS ihn erwartet. Der Randknoten kann also über eine Sitzung berichten, aber mit diesem Bericht allein keinen Zugang freigeben.

Eine Entscheidung des Servers ist jedoch noch keine angewandte Regel. RFC 3169 beschreibt Zugangsprofile, die an den NAS übermittelt und dort umgesetzt werden. Der AAA-Server bestimmt, was die Richtlinie erlaubt; der NAS muss das Profil weiterhin in seiner lokalen Laufzeitumgebung installieren oder anwenden. Ein korrektes Access-Accept, eine Richtlinienantwort oder eine dynamische Autorisierungsnachricht belegt daher eine Entscheidung oder Aufforderung. Sie beweist für sich genommen weder einen geänderten Schnittstellenzustand noch einen wirksamen Filter oder einen nutzbaren Dienst für den Teilnehmer.

Die Ressourcenverwaltung macht die Lücke greifbar. RFC 3169 sieht vor, während einer Sitzung gemeinsam genutzte Ressourcen zuzuteilen und wieder freizugeben, darunter Adressen, Grenzwerte für gleichzeitige Nutzung, Ports und Tunnel. Diese Funktion zielt laut Dokument vor allem auf lokale NAS-Ressourcen. In Proxy- oder Mehrdomänenumgebungen soll der Server, der eine Ressource in einer entfernten Domäne zugeteilt hat, diese Informationen behalten; möglicherweise gilt das auch für seine Sicherungssysteme. Änderungen an entfernter Autorisierung sollen über dynamische Autorisierungsfunktionen laufen.

Wer den Zugang entscheidet und wer das aktuelle Verzeichnis zur Rücknahme oder Wiederherstellung einer Ressource führt, sind unterschiedliche Rollen.

Bei einem Ausfall wird die Trennung sichtbar. Ein Wechsel auf einen Ersatzserver kann die Autorisierungsrichtlinie erhalten, aber nicht notwendigerweise einen vom Zuteiler geführten Tunnelgrenzwert oder Adresspool rekonstruieren. Nach einem Neustart des NAS kann dessen lokaler Stand vom Register des Zuteilers abweichen. Ein Trennungsauftrag kann eintreffen, ohne ausgeführt zu werden. Deshalb verlangt RFC 3169 Synchronisation und Wiederherstellung und warnt davor, Ressourcenverwaltung vom Abrechnungsnachrichtenstrom abhängig zu machen.

Dieser Strom kann Nutzung protokollieren; er ist damit nicht automatisch das maßgebliche Sperrverzeichnis aktiver Zuteilungen.

Abrechnung ist ein weiterer Nachweispfad und kein Ersatz für die drei anderen. RFC 3169 fordert zuverlässige Zustellung, definiert Echtzeit als Beginn der Zustellung innerhalb einer Sekunde nach dem auslösenden Ereignis und verlangt eindeutige Zeitstempel. Das sind Prüfkriterien, keine im Feld gemessenen Ergebnisse. Ein rechtzeitig eingetroffener Datensatz beweist weder die Zustellung eines Pakets noch die Erfassung aller Ereignisse oder die korrekte Rekonstruktion einer Sitzung durch spätere Systeme. Echtzeit-Empfang ist nicht dasselbe wie Echtzeit-Wahrheit.

Die benachbarte Protokollgeschichte ordnet die Kriterien ein, belegt aber nicht, dass ein Nachfolger sie vollständig erfüllt hätte. RADIUS hatte bereits getrennte Spezifikationen für Authentisierung/Autorisierung und Abrechnung. RFC 3169 verlangt von AAA-Kandidaten Unterstützung ihrer Attributsätze, Interoperabilität, Erweiterbarkeit, mehrerer Server und domänenübergreifender Beziehungen. Das später veröffentlichte RFC 6733 beschreibt Diameter als Basisprotokoll für AAA-Anwendungen; dynamische Autorisierung, EAP-Transport und Transportschutz entwickelten sich ebenfalls in eigenen Dokumenten.

Deren Existenz ist kein Konformitätsaudit für sämtliche RFC-3169-Kriterien. Spätere RADIUS-Entwurfsleitlinien erkennen zudem Grenzen bei Paketgröße und Datenmodell an, statt einen großen Attributraum als unbegrenzte Implementierungskapazität auszulegen.

Als Internetgeschichte gelesen, kartiert RFC 3169 Kontrollgrenzen: Der NAS liefert Sitzungsangaben, der AAA-Server hat die abschließende Autorisierungsrolle, der NAS setzt um, der Zuteiler hält den aktuellen Ressourcenstand und die Abrechnung erzeugt einen getrennten Datensatz. Die Komponenten können innerhalb einer Protokollfamilie kommunizieren; keine einzelne Nachricht belegt die ganze Kette. Dieser Artikel behauptet weder Verbreitung noch Produktverhalten oder heutige Implementierung. Er hält sich an die engere Lehre des Dokuments: Bei einem verteilten Vorgang ist die zentrale Entscheidung nur ein Nachweis unter mehreren.

Quellen: RFC 3169; aktueller RFC-3169-Eintrag; Datatracker-Eintrag zu RFC 3169; NAS-Modell aus RFC 2881; RADIUS, RFC 2865; RADIUS Accounting, RFC 2866; RADIUS-Erweiterungen, RFC 2869; AAA-Protokollbewertung, RFC 2989; EAP in RADIUS, RFC 3579; dynamische Autorisierung, RFC 5176; RADIUS-Entwurfsleitlinien, RFC 6158; RADIUS über TLS, RFC 6614; Diameter-Basisprotokoll, RFC 6733; RADIUS/1.1, RFC 9765; Lu Heng, „Wenn der Buchhalter nach dem Olymp greift“.