Summary

  • Der RADEXT-Entwurf soll RADIUS-Paketcode 52, Protocol-Error, standardisieren. RFC 7930 führte ihn experimentell ein; das IANA-Verzeichnis verweist derzeit noch auf diese RFC.
  • Ein solches Paket muss Error-Cause und Original-Packet-Code enthalten. Der ursprüngliche Paketcode verknüpft die Diagnose mit dem richtigen offenen Auftrag, wenn verschiedene Anfragetypen dieselbe Identifier-Zahl tragen.
  • Die Fehlermeldung gilt von einem Nachbarn zum nächsten. Bei Ursache 502 oder 505 soll der Proxy einen anderen Anschluss oder ein anderes Ziel versuchen; den fehlgeschlagenen Anschluss darf er nicht erneut verwenden.

RADIUS lässt Zugangsgeräte seit Langem mit einem vieldeutigen Schweigen arbeiten. Der Server antwortet vielleicht nicht, weil er überlastet ist, weil die Anfrage unbrauchbar ist oder weil hinter einem Proxy die nächste Verbindung versagt. Aus Sicht des Zugangsgeräts läuft in jedem Fall ein Timer ab. Seine lokale Wiederholungsregel springt an. Viele solcher Regeln können in der Störung genau den Pfad füllen, der schon keine Antworten mehr liefert.

Paketcode 52 formuliert einen engeren Befund: Die Anfrage ist angekommen, ihre Verarbeitung ist gescheitert. Der Entwurf nennt Zugangs-, Abrechnungs-, Änderungs- und Trennungsanfragen. Wenn ein Abrechnungsvorgang nicht geschrieben werden konnte, ist eine Verarbeitungsdiagnose ehrlicher als eine Quittung. Ein technischer Fehler bei der Anmeldung braucht ebenso wenig als Entscheidung über die Berechtigung des Nutzers getarnt zu werden. Die 2016 veröffentlichte RFC 7930 führte Code 52 im Rahmen eines Experiments ein. Der neue WG-Text will das Verhalten für einen größeren Teil von RADIUS festlegen.

Zwei Attribute geben der Diagnose eine Adresse im Arbeitsablauf. Error-Cause bezeichnet den Grund. Original-Packet-Code bezeichnet die Art der Anfrage, auf die sich der Fehler bezieht. Eine RADIUS-Identifier-Zahl kann bei unterschiedlichen Anfragetypen wiederkehren. Der Wert allein identifiziert die betroffene Operation daher nicht zuverlässig. Die Antwort übernimmt den Identifier; passt der ursprüngliche Paketcode zu keiner noch offenen Anfrage, muss der Client die Antwort verwerfen. Ein präziser Fehler am falschen Vorgang kann gefährlicher werden als ein Timeout, weil Software dann mit falscher Sicherheit reagiert.

Der kaputte Anschluss ist Sache des Proxys

Abschnitt 4 bezeichnet Protocol-Error als Hop-by-Hop-Paket. Ein Proxy darf die empfangene Fehlermeldung nicht unverändert weiterreichen. Er muss Error-Cause lesen und zwischen einer Störung seines Proxy-Netzes und einer Meldung des Home-Servers unterscheiden. Der Proxy besitzt den ausgehenden Anschluss. Das Zugangsgerät besitzt nur die Verbindung zu diesem Proxy. Für eine Wiederherstellung muss zuerst der Betreiber entscheiden, der den fehlerhaften Abschnitt tatsächlich steuert.

Der Entwurf benennt 502, Request Not Routable (Proxy), und 505, Other Proxy Processing Error, als Ursachen im Proxy-Netz. Der empfangende Proxy soll eine andere Verbindung zum selben Ziel oder ein anderes Ziel versuchen. Er darf die ursprüngliche Anfrage nicht über den Anschluss wiederholen, der gerade den Fehler lieferte. Genau dort scheitert manche vollmundige „Selbstheilung“: Eine Schleife aus wiederholten Paketen macht aus einem defekten Weg keinen gesunden. Wie viele Alternativen und Sekunden zulässig sind, legt der Entwurf noch nicht vollständig fest; Betreiber müssen diese Budgets selbst definieren.

Die übrigen Ursachen soll der Proxy im Regelfall dem Home-Server zuordnen. Er sendet dann seinem eigenen Client ein neues Protocol-Error mit der übernommenen Ursache. Das ist eine neue Nachricht des Proxys nach seiner Auswertung, kein unveränderter Durchlauf des alten Pakets. Eine brauchbare Spur verbindet ursprüngliche Anfrage, Antwort des nächsten Servers, Proxy-Entscheidung und endgültige Antwort am Zugangsgerät. Eine Diagnose an einer Stelle bestätigt weder die Anmeldung eines Nutzers noch die Buchung eines Abrechnungsereignisses.

Abschnitte zur Migration, Aushandlung und genauen Auswahl der Fehlerantwort enthalten noch TBD. Eine dokumentierte Betriebsspur über zwei Proxys liegt im offiziellen Paket ebenfalls nicht vor. Ein kontrollierter Test müsste Anfragecode und Identifier, Ursache, aufgegebenen Anschluss, neue Route und Endergebnis am Zugangsgerät zusammenführen. Erst damit lässt sich beurteilen, ob die vorgeschlagene Zuständigkeit im gemischten Betrieb trägt.

RADEXT-Entwurf · Datatracker · RFC 7930 · IANA-Verzeichnis