Zusammenfassung

  • RFC 3993 erlaubt einem DHCP-Relay, eine vom Anbieter vergebene Subscriber-ID anzufügen, die bei einem Wechsel des physischen Zugangswegs stabil bleiben soll.
  • Der Standard transportiert den Wert, überlässt Vergabe und Bedeutung aber der Konfiguration des Anbieters. Das kann Richtlinien über einen Pfadwechsel hinweg erhalten und zugleich eine langfristige Verknüpfung von Datensätzen erleichtern.

Der Anschluss wechselte, der Kundendatensatz musste es nicht

Ein DHCP-Server muss mitunter über einen Client entscheiden, den er selbst nicht unmittelbar sieht. In einem großen Zugangsnetz nimmt ein Relay die lokale Broadcast-Nachricht des Clients entgegen und leitet sie an einen zentralen Server weiter. Es kann ergänzen, an welcher Stelle die Anfrage in das Netz des Anbieters gelangt ist. So lassen sich Adressen und weitere Parameter zentral vergeben, ohne für jedes Zugangssegment einen eigenen Server zu betreiben.

Das Relay ist damit zugleich Beobachter und Bote. RFC 3046 schuf 2001 einen Behälter für Relay-Agent-Informationen. Zu den ersten Unteroptionen gehörten Circuit-ID und Remote-ID: Die eine konnte die ankommende Leitung beschreiben, die andere ein entferntes Modem. Damit ließen sich Leitungen und Geräte unterscheiden, doch die Werte folgten der Netztopologie. Wechselte der Kunde den Pfad, konnte sich die leitungsbezogene Kennung ändern, obwohl der Anbieter dieselbe administrative Behandlung fortsetzen wollte.

RFC 3993 ergänzte 2005 die bestehende Relay-Information um Subscriber-ID. Der Wert kann unabhängig vom physischen Zugangsnetz sein und soll stabil bleiben, wenn der Kunde einen anderen Weg nutzt oder sich das Netz ändert. Der Anbieter kann ihn neben Leitungs- und Gerätekennungen verwenden, statt einem Feld beide Aufgaben aufzubürden.

Das Format trägt einen Wert, keine Definition

Die Zurückhaltung der Spezifikation ist entscheidend. Subscriber-ID ist eine NVT-ASCII-Zeichenfolge im Unteroption-Code 6, der ein Längenfeld von einem Oktett vorangeht. Die Zeichenfolge muss mindestens ein Oktett lang sein und endet nicht mit NUL. Damit finden beide Systeme den Wert in der Nachricht. Was seine Zeichen bedeuten, steht dort nicht.

RFC 3993 erklärt die Bedeutung ausdrücklich zur Sache des Anbieters. Er vergibt die Kennung; die Verfahren zur Vergabe und Konfiguration liegen außerhalb des Dokuments. Ein Relay kann so eingerichtet werden, dass es das Feld aufnimmt. Ein unterstützender Server darf es zusammen mit anderen Relay- und Clientdaten verwenden, wenn er eine Adresse oder weitere Parameter zuweist. Weder die Aufnahme noch die Verwendung sind verpflichtend.

Diese Aufteilung macht das Kennzeichen transportierbar, aber nicht universell. Ein Anbieter könnte den Wert einem Abrechnungskonto zuordnen, ein anderer einem Dienstprofil. Die RFC verlangt keines dieser Modelle und sagt nicht, dass dieselbe Zeichenfolge in einer anderen Verwaltungsdomäne dasselbe bezeichnet. Eine DHCP-Nachricht allein belegt daher weder die Identität einer Person oder eines Geräts noch einen Vertrag oder ein Nutzungsrecht. Solche Verknüpfungen liegen in den Unterlagen und Betriebsentscheidungen des Anbieters.

Die Änderung im Paket war klein; die Kontrollgrenze war es nicht. Der Client liefert die stabile Kennung nicht als selbst erklärte Identität. Ein vom Anbieter betriebenes Relay fügt sie ein, und ein zentraler Dienst kann daraus eine Adress- oder Konfigurationsentscheidung ableiten. Das Gewicht des Werts entsteht aus der Vertrauensbeziehung und der Zuordnung des Anbieters, nicht aus der Schreibweise der Zeichenfolge.

Vertrauen macht die Bequemlichkeit folgenreich

Die Relay-Agent-Information setzt ein Vertrauensverhältnis zwischen Relay und Server voraus. RFC 3993 warnt, dass gefälschte Angaben zu Dienstmissbrauch, zur Erschöpfung knapper Adressen, zu Dienstverweigerung oder ungeeigneter Konfiguration beitragen können. RFC 3046 beschreibt den Rückweg: Ein Server, der die Option erkennt, sendet sie an das Relay zurück; dieses entfernt sie, bevor es dem Client antwortet. Der Austausch bleibt Teil der internen Steuerung des Anbieters und ist kein Identitätszertifikat für den Nutzer.

Diese Grenze lässt sich zusätzlich schützen. RFC 3993 nennt Perimeterabwehr und empfiehlt ergänzend die Authentifizierungs-Unteroption für Relays oder IPsec. RFC 4030 legt diese Authentifizierung samt Verfahren zur Replay-Erkennung fest. Sie kann helfen festzustellen, ob Relay-Daten über einen akzeptierten Pfad kamen. Die anbieterspezifische Bedeutung, die RFC 3993 offenlässt, liefert sie nicht nach.

Stabilität hat auch einen Preis für den Datenschutz. Eine Circuit-ID kann den Eintrittspunkt einer Nachricht verraten; eine Teilnehmerkennung kann denselben Verwaltungsgegenstand über mehrere Leitungen hinweg verfolgen. RFC 3993 warnt, dass der Wert bei Offenlegung einen bestimmten Host oder Nutzer identifizieren könnte. RFC 7819 behandelt Subscriber-ID als mögliche langlebige Kennung, mit der sich Aktivitäten über die Zeit verbinden lassen. Der Vorteil, weniger neu konfigurieren zu müssen, kann den Zeitraum verlängerbar machen, in dem Datensätze miteinander verknüpft werden.

RFC 4580 übertrug eine ähnliche Idee auf DHCPv6. Auch dort bleiben Vergabe und Bedeutung außerhalb der Spezifikation; der vorgesehene Austausch ist auf eine Verwaltungsdomäne beschränkt. Das bestätigt ein Entwurfsmuster, nicht die automatische Gleichheit von DHCPv4- und DHCPv6-Kennungen.

Die RFCs belegen den beschriebenen Mechanismus und die darin genannten Risiken. Sie belegen weder die Verbreitung der Implementierung noch einen tatsächlich gelungenen Pfadwechsel oder die Datenschutzmaßnahmen eines bestimmten Anbieters. Die Geschichte liegt in der Entwurfsgrenze: DHCP konnte ein stabiles Anbieterkennzeichen über eine veränderte Zugangstopologie tragen. Für seine Bedeutung und die folgenden Entscheidungen blieb der Anbieter verantwortlich.

Quellen