Zusammenfassung

  • draft-ietf-radext-radiusdtls-bis-18 definiert Erreichbarkeit pro Verbindung und nächstem Hop. Ein RADIUS-Proxy verbirgt den Betriebszustand nachgelagerter Realms, Home-Server und Credential-Backends.
  • Status-Server, TLS/DTLS-Zustand und Keepalives bleiben wichtige Belege mit begrenzter Reichweite. Routing, Retry-Eigentum, Autorisierungsentscheidung und Zugangsergebnis brauchen eigene Nachweise.

Ein NAS sendet Access-Requests für mehrere Organisationen durch denselben RadSec-Pool. Acht Realms liefern Antworten, das neunte schweigt. Die TLS-Verbindung zum Proxy ist offen, das Zertifikat passt, und ein Status-Server-Paket wird sofort beantwortet. Welcher Zustand soll im Dashboard erscheinen?

Die richtige Antwort lautet nicht rot oder grün, sondern dreiteilig: Der Peer ist erreichbar. Die Verbindung ist verwendbar. Der angefragte Dienstpfad ist für dieses Realm nicht belegt.

RADIUS arbeitet Hop für Hop. Gegenüber dem NAS tritt ein Proxy als Server auf; gegenüber dem Home-Server als Client. Er kann anhand des Realms eine Route auswählen, weitere Proxys durchlaufen, den Transport wechseln und verschiedene Credential-Backends ansprechen. Der erste Client kennt diese Topologie nicht. Ein erfolgreicher Austausch mit dem Nachbarn kann deshalb weder die nächste Leitung noch den Zustand der letzten Datenbank bescheinigen.

Abschnitt 3.8 der Revision 18 macht daraus eine konkrete Betriebsregel. RadSec-Implementierungen müssen den Zustand von TCP, TLS oder DTLS mit dem Application-Layer-Watchdog aus RFC 3539 kombinieren. Eine Verbindung darf als down gelten, wenn der Netzwerk-Stack sie für nicht mehr brauchbar hält, wenn D(TLS) keine nutzbare Verbindung bietet oder wenn der Watchdog sie entsprechend markiert.

Der Prüfgegenstand ist jede einzelne Verbindung. Antwortet eine von mehreren Verbindungen zum Server nicht, dürfen die anderen nicht pauschal ausfallen. Eine verlorene DTLS-Sitzung oder ein fehlerhafter Load-Balancer-Knoten soll seinen eigenen Blast Radius behalten.

Diese Granularität gilt in beide Richtungen. Ein Fehler darf nicht den ganzen Peer belasten; ein Erfolg darf nicht den ganzen Peer und alle dahinterliegenden Dienste legitimieren.

RFC 5997 begrenzt Status-Server noch deutlicher. Ein RADIUS-Server oder -Proxy darf das Paket nicht weiterleiten. Es prüft nur das Ziel aus IP-Adresse und Port. Weil der Server die Anfrage nicht anhand des User-Name an ein bestimmtes Realm routet, lässt sich aus der Antwort keine Erreichbarkeit dieses Realms ableiten.

Gerade das Weiterleitungsverbot macht den Watchdog diagnostisch sauber. Bleibt ein Access-Request unbeantwortet, während Status-Server zurückkommt, ist der erste Proxy nicht automatisch tot. Der Ausfall kann hinter ihm liegen. Der Watchdog lokalisiert ihn jedoch nicht weiter; er sagt nichts über die Realm-Tabelle, den nächsten Hop, den Home-Server oder dessen Credential Store.

Der Entwurf verlangt Status-Server bei RadSec-Clients und die Antwortfähigkeit bei Servern. Da RADIUS pro Verbindung nur 256 gleichzeitig nutzbare Identifier-Werte hat, wird Identifier null für den Watchdog empfohlen. TCP-Keepalives oder DTLS-Heartbeats können einen Transportbruch früher melden. Auch sie bleiben Verbindungssignale.

Aus einem zu groben Status entstehen zwei gegensätzliche Fehlsteuerungen.

Bei der ersten führt das Timeout eines Realms zum kompletten Failover. Gesunder Verkehr wandert zum Ersatzproxy, Verbindungen werden neu aufgebaut und der Sekundärstandort erhält die Last eines einzelnen verborgenen Fehlers. RFC 3539 beschreibt das Grundproblem: Zwischen Client und Home-Server steht ein Agent, sodass der Client keine End-to-End-Transportparameter für einen verlässlichen Failover-Timer besitzt.

Bei der zweiten bleibt das kaputte Realm auf seiner Route, weil der Proxy den Watchdog beantwortet. Das grüne Signal ist wahr, nur die daraus abgeleitete Zuständigkeit ist falsch. Eine Realm-Entscheidung braucht Realm-Auswahl, Routingregel, Downstream-Übergabe, Home-Server-Antwort, Backend-Ergebnis, Autorisierung und NAS-Wirkung.

Auch Protocol-Error ist strikt hop-lokal. Die Antwort signalisiert ein unerwünschtes oder nicht routbares Paket auf der aktuellen Verbindung, stoppt dort weitere Retransmits und kann eine Alternativroute ermöglichen. Sie darf nicht weitergeleitet werden. Was ein späterer Server entschieden hätte, bleibt offen.

Verschlüsselung erweitert die Sicht nicht. TLS oder DTLS authentisiert den benachbarten RadSec-Peer und schützt dieses Segment. Laut Sicherheitsbetrachtung kann ein Zwischenproxy dasselbe Paket anschließend über RADIUS/UDP senden. Der ursprüngliche Client kann einen geschützten Transport für die gesamte Kette nicht protokollseitig erzwingen. End-to-End-Vertraulichkeit verlangt organisatorische Kontrolle jedes Vermittlers.

An Transportgrenzen wechselt außerdem die Verantwortung für Wiederholungen. RADIUS/TCP und RADIUS/TLS verwenden einen zuverlässigen Transport und wiederholen RADIUS-Pakete nicht auf derselben Verbindung. UDP und DTLS benötigen anwendungsseitige Retransmission. Nimmt ein Proxy über einen unzuverlässigen Transport an und leitet zuverlässig weiter, darf er eingehende Wiederholungen nicht nochmals senden. In der Gegenrichtung übernimmt er selbst die Wiederholungen zum unzuverlässigen Hop.

Schließt die zuverlässige Eingangsverbindung, muss der Proxy ausstehende Downstream-Versuche beenden, weil keine Antwort mehr zugestellt werden kann. Verwendet der Client einen Identifier neu und gibt damit die alte Anfrage auf, gilt dasselbe. Client, Proxy und Home-Server können daher zu demselben Zeitpunkt unterschiedliche, jeweils korrekte Zustände halten.

Die Accounting-Regeln zeigen, wie ein fehlender Zuständigkeitsbeleg Last erzeugt. Der Entwurf empfiehlt einen unveränderten Event-Timestamp für den tatsächlichen Ereigniszeitpunkt. Wird stattdessen Acct-Delay-Time bei jedem Versuch aktualisiert, entsteht jeweils ein neues Paket mit fast gleichem Inhalt und möglicherweise neuem Identifier. An einem TLS-zu-UDP-Proxy erhält jede Version eine eigene Downstream-Retry-Folge.

Anhang A.2 verfolgt ein einziges Ereignis, das beim Server als ID 101, 102 und 103 erscheint. Ein stabiler Ereigniszeitpunkt hilft bei der Duplikaterkennung, ist aber keine globale Transaktionskennung und garantiert keine genau einmalige Verarbeitung. Dafür müssen Ereignis, Paket, Hop, Retry-Eigentümer, Serverentscheidung und Anwendungsergebnis verbunden bleiben.

Selbst eine fehlgeschlagene kryptographische Prüfung ist kein pauschales Peer-Urteil. Anhang A.1 beschreibt eine spät eintreffende Antwort, nachdem der Identifier für eine neue Anfrage wiederverwendet wurde. Der Response Authenticator wird gegen den falschen aktuellen Request geprüft und scheitert. Der Client soll die Antwort verwerfen, die Verbindung aber offen lassen. Paketrennen, Verbindungsfehler und bösartiger Peer sind verschiedene Befunde.

Revision 18 wurde am 30. September 2026 als aktiver RADEXT-Internet-Draft eingestellt. Das beabsichtigte Niveau ist Proposed Standard, das Ablaufdatum der 3. April 2027; eine RFC-Nummer existiert nicht. Erst Genehmigung und Veröffentlichung würden die experimentellen RFC 6614 und RFC 7360 ablösen. Der Datensatz belegt weder Verbreitung noch Interoperabilität oder einen Vorfall bei einem benannten Betreiber.

Eine belastbare Aussage bleibt deshalb eng: Dieser RadSec-Peer antwortete zu diesem Zeitpunkt über diese Verbindung. Für eine Dienstaussage kommen Realm, gewählte Route, Downstream-Server oder Backend, Autorisierung, NAS-Ausführung und beobachteter Zugang hinzu. Ein gemeinsamer Mindeststandard koordiniert den Nachbarn; die tatsächlich betriebene Kette muss ihre weiteren Belege selbst erzeugen.

Quellen