Zusammenfassung

  • RFC 4014 erlaubte einem Network Access Server, ausgewählte Attribute aus einem erfolgreichen RADIUS Access-Accept zwischenzuspeichern und später in einer DHCP-Relay-Nachricht als Suboption 7 zu übertragen.
  • Der DHCP-Server nutzte diese Attribute zur Auswahl von Konfigurationsparametern. Autorisierung, Weiterleitung und Adressvergabe blieben getrennte Aufgaben innerhalb einer lokalen Vertrauensbeziehung.

Der Zugang war frei, die Adresse noch offen

Ein Gerät verbindet sich mit einem WLAN oder steckt an einem Unternehmensswitch. Die 802.1X-Authentisierung ist erfolgreich; der Access Point oder Switch lässt die Sitzung passieren. Doch für gewöhnliche IP-Kommunikation fehlt noch die DHCP-Konfiguration. Erst sie bestimmt, welche Adresse und weiteren Parameter der Client erhält. Zwischen „Zugang erlaubt“ und „Netzwerk eingerichtet“ liegt also ein zweiter Vorgang.

RADIUS und DHCP beantworten unterschiedliche Fragen. RADIUS authentisiert und liefert Attribute, die mit der Berechtigung eines Dienstes verbunden sind. DHCP wählt die Parameter, die der Server dem Client anbietet. RFC 3580 hält ausdrücklich fest, dass IEEE 802.1X selbst keine IP-Adressvergabe bereitstellt. Ein Attribut wie Framed-Pool ist nur für Authenticatoren nutzbar, die an der Adresszuweisung mitwirken können.

In vielen Netzen waren diese Rollen auf mehrere Systeme verteilt. Ein zentraler RADIUS-Dienst konnte die Identität prüfen, während ein eigener DHCP-Server Adresspools und Optionen verwaltete. Das NAS am Netzzugang kannte die gerade zugelassene Sitzung und arbeitete zugleich als DHCP-Relay. Der Server musste den Kontext dieser Sitzung erhalten, ohne dass beide Dienste in einem Gerät oder einer gemeinsamen Entscheidungsinstanz aufgingen.

Ralph Droms und John Schnizlein veröffentlichten RFC 4014 im Februar 2005 als Standards-Track-Dokument. Nach einem erfolgreichen Access-Accept speicherte das NAS die RADIUS-Attribute lokal. Wenn später die DHCP-Anfrage des Geräts eintraf, konnte das NAS eine begrenzte Auswahl der Attribute beim Weiterleiten ergänzen. Der Standard verband die Austausche, machte aus der RADIUS-Autorisierung aber keinen DHCP-Lease.

Das Relay hatte bereits einen Informationsumschlag

Die Übertragung nutzte die schon durch RFC 3046 definierte Relay Agent Information Option, häufig Option 82 genannt. Sie schafft Platz für Angaben, die das Relay über den Zugang kennt: etwa über welchen Anschluss eine Anfrage hereinkam oder welches entfernte Gerät damit verbunden war. Ein DHCP-Server kann solche Angaben verwenden, um Adressen oder andere Parameter auszuwählen.

Auch der Rückweg war geregelt. Der Server gibt die Relay-Information in seiner Antwort zurück; das Relay entfernt sie, bevor die Antwort an den Client gelangt. Der Client muss interne Anschlusskennungen des Netzes nicht verstehen.

RFC 4014 ergänzte in diesem Umschlag Suboption 7 mit dem Namen „RADIUS Attributes“. Das NAS konnte die codierten Oktette ausgewählter Attribute aus dem Access-Accept in die spätere DHCP-Nachricht aufnehmen. Der DHCP-Server las die Suboption und nutzte sie bei der Auswahl der Konfiguration. Das Relay lieferte Kontext; die DHCP-Seite behielt die Entscheidung über die angebotene Adresse.

Der Mechanismus war nicht auf IEEE 802.1X beschränkt. Ein Relay durfte auch aus anderen Gründen erhaltene RADIUS-Attribute übertragen, sofern ihre Bedeutung der RADIUS-Semantik entsprach. Die robuste Interoperabilität blieb jedoch auf eine einzelne, lokal begrenzte Verwaltungsdomäne beschränkt. Eine weltweite gemeinsame Interpretation über unabhängige Domänen hinweg war nicht zugesagt.

Die kurze Attributliste hielt die Kopplung klein

RFC 4014 erlaubte höchstens eine RADIUS-Attributes-Suboption pro Nachricht. Falls verfügbar, musste das Relay User-Name und Framed-Pool aufnehmen; weitere Attribute waren optional. Damit die Adressvergabe nicht von zusätzlichem, nur beim RADIUS-Server vorhandenen Zustand abhing, sollte sich das Relay auf sechs Attribute beschränken: User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool und Framed-IPv6-Pool.

Der DHCP-Server verwendete die Werte zur Auswahl von Konfigurationsparametern und sollte Attribute außerhalb der Liste ignorieren. Ein Poolname konnte eine Policy-Auswahl beeinflussen, zwang den Server aber nicht, eine Adresse aus einem Pool zu vergeben, den er nicht verwaltete. RADIUS lieferte Autorisierungskontext; der DHCP-Server blieb für seine Adressressourcen verantwortlich.

Der Platz war knapp. RFC 4014 sagt, dass das Relay die Attribute kürzt, damit sie in die Suboption passen. Eine allgemeine Prioritätsregel dafür, welche Werte bei einer Kürzung erhalten bleiben, enthält das Dokument nicht. Ein Attribut aus dem Access-Accept muss daher nicht vollständig beim DHCP-Server ankommen. Entscheidend sind die tatsächlich ausgewählten und übertragenen Bytes.

Damit bekam das NAS eine eigene Zustandsverantwortung. Es musste die gespeicherten Attribute der richtigen Sitzung zuordnen, wenn später deren DHCP-Anfrage eintraf. RFC 4014 legt weder eine Sitzungsdatenbank noch den Ablauf nach einer erneuten Authentisierung oder Policy-Änderung fest. Hier endet die Protokollbeschreibung; Implementierung und Betrieb müssen die Lücke schließen.

Vertrauen gehört zum Übertragungsweg

Wenn der DHCP-Server Relay-Werte zur Konfigurationswahl nutzt, ist das Vertrauen zwischen Relay und Server Teil des Kontrollpfads. RFC 4014 übernimmt das Vertrauensmodell aus RFC 3046. Neben einer Netzgrenze, die Option 82 nur von berechtigten Relays akzeptiert, empfiehlt es weitergehenden Schutz, etwa die Authentisierung der Relay-Agent-Option oder IPsec.

Der Client sieht Option 82 normalerweise nicht. Dadurch muss er sie nicht verarbeiten; authentisch wird ihr Inhalt dadurch nicht. Der DHCP-Server braucht weiterhin Nachweise, wer die Nachricht gesendet und wie die Übertragung geschützt hat. Ein gefälschter oder veralteter Wert könnte bei versagenden Kontrollen die Policy-Auswahl beeinflussen. Das ist eine mögliche Folge der Architektur und kein Nachweis für einen konkreten Vorfall.

Die Frage „Wer wählte die Adresse?“ hat deshalb keine einzelne Antwort. RADIUS autorisiert eine Sitzung und liefert Attribute; das NAS entscheidet, was es weiterträgt; der DHCP-Server wählt eine Konfiguration und verwaltet die Pools. Der Standard beschreibt die Brücke, beweist aber weder, dass der gespeicherte Zustand aktuell ist, noch dass das Relay vertraut werden kann oder die lokale Policy richtig ist. Maßgeblich ist, was die laufenden Systeme tun.

Die Erweiterung von 2023 schuf keinen Einheitsmechanismus

RFC 9445 griff die Schnittstelle 2023 wieder auf, als neue Dienste DHCP-Parameter benötigten, die in der festen RFC-4014-Liste fehlten. Es aktualisierte RFC 4014 und ersetzte die eingefrorene Liste durch ein IANA-Register zulässiger RADIUS-Attribute, das durch ein Expertenprüfungsverfahren erweitert werden kann. Der ursprüngliche Suboption-7-Pfad blieb bestehen.

RFC 9445 definierte außerdem zwei andere RADIUS-Attribute, die DHCP-Optionen tragen: DHCPv6-Options (245.3) und DHCPv4-Options (245.4). Ein Beispiel mit verschlüsseltem DNS veranschaulicht eine mögliche Dienstkonfiguration, ist aber kein Beleg für deren Verbreitung. Diese Attribute sind nicht die alte RADIUS-Attributes-Suboption. Das aktuelle IANA-Register weist aus, was zulässig ist, nicht was Betreiber tatsächlich einsetzen.

Die Entwicklung bedeutete nicht, dass RADIUS DHCP ersetzte. Sie erweiterte die Wege, über die Autorisierungskontext in die Konfigurationsauswahl gelangen kann, während die Rollen getrennt bleiben. Mit jedem neuen Dienst wächst allerdings auch die Zahl der Kombinationen, die ein Betreiber lokal prüfen muss.

Als spätere analytische Linse lässt sich Lu Hengs Note 64 auf den begrenzten gemeinsamen Umschlag beziehen: Eine Mindestspezifikation kann den Rahmen setzen, während konkrete Entscheidungen in der lokalen Verwaltungsdomäne bleiben. Note 65 erinnert daran, dass ein veröffentlichtes Dokument noch kein Nachweis für laufendes Verhalten ist. Beide Notizen sind spätere Perspektiven und weder Ursache noch Quelle von RFC 4014. Ob der Übergang funktioniert, zeigt erst der Betrieb von NAS, Relay und DHCP-Server.

Quellen