Zusammenfassung

  • RFC 3456 führte DHCPv4 durch eine temporäre IPsec-SA, damit Leases, Pools, Optionen, Neukonfiguration und Ausfallsicherung im vorhandenen Konfigurationssystem blieben und nicht in IKE nachgebaut wurden.
  • DHCPACK und geleaste innere Adresse waren Konfigurationsbelege, keine Zugangsnachweise: Der Host konnte eine Adresse selbst setzen, und der Weg vom Relay zum Server brauchte eigenen Schutz.

Zwei Adressen waren zwei Wirklichkeiten

Der im Januar 2003 veröffentlichte RFC 3456 beschrieb einen Remote-Host mit äußerer Internetadresse und innerer Adresse einer virtuellen Schnittstelle. Die äußere Adresse beendete den IPsec-Tunnel am Sicherheitsgateway; die innere ließ den Host hinter diesem Gateway im Unternehmensnetz erscheinen. Beide ermöglichten Weiterleitung, waren aber kein gemeinsamer Identitätsbeweis.

Der Text, der RFC-Editor-Eintrag, das Datatracker-Dokument, seine Historie, Referenzen, späteren Zitate und die Errata-Suche belegen den Standard. Sie belegen weder Benutzerberechtigung noch Anwendungserfolg.

Zuerst entstand eine IKE-SA. Danach trug eine kurzlebige, ausschließlich für DHCP bestimmte Tunnelmodus-SA DHCPDISCOVER oder DHCPREQUEST. Nach Empfang von Adresse und Optionen konnte der Host eine allgemeine VPN-SA aushandeln und die neue Adresse in der Quick-Mode-Identität verwenden. Vorläufiger Konfigurationskanal, Lease und Datentunnel waren getrennte Zustände.

DHCP-Wiederverwendung hielt IKE klein

RFC 3457 beschrieb die Anforderungen des Fernzugriffs. RFC 2131 und die Optionen in RFC 2132 brachten Pools, Leases, Erneuerung und Konfiguration bereits mit; RFC 3442 konnte klassenlose Routen liefern. RFC 3456 vermied deshalb ein zweites Adressmanagement in IKE, das schrittweise Erneuerung, Authentisierung und Failover hätte duplizieren müssen.

Die virtuelle Schnittstelle verwendete Hardwaretyp 31. Ihre Client-ID musste im virtuellen Subnetz eindeutig und sollte über Neustarts stabil sein. Das IANA-Register bewahrt die Zuweisung. Solche Eigenschaften korrelierten Transaktionen; sie bewiesen weder Person noch Recht.

Am Relay verlief eine Sicherheitsnaht

Das Gateway arbeitete gewöhnlich als DHCP-Relay. Es konnte giaddr oder Relay-Information aus RFC 3046 einsetzen, einschließlich einer Circuit ID für den virtuellen Tunnelport. Aus yiaddr im DHCPACK konnte es eine Rückroute installieren.

IPsec schützte jedoch nur den Abschnitt zwischen Host und Gateway. Der Weg vom Gateway zum DHCP-Server brauchte einen eigenen Mechanismus, etwa RFC 3118. Integrität eines Abschnitts ging nicht automatisch auf den nächsten über.

Zudem konnte ein Host seine IP-Adresse selbst wählen. Selbst authentisiertes DHCP taugte daher nicht als Zugangskontrolle. RFC 3456 verlangte, Sicherheit nicht von der zugewiesenen Adresse abhängig zu machen, sondern von tunnelbezogenen Filtern oder Quick-Mode-Selektoren. RFC 2401 und RFC 2409 liefern den damaligen IPsec- und IKE-Rahmen, aber keinen Nachweis einer korrekt installierten lokalen Regel.

Ein ACK war nur ein Beleg

DHCPACK belegte eine Konfigurationsantwort. Circuit ID benannte den vorgesehenen Rücktunnel. Eine Route dokumentierte eine lokale Weiterleitungsentscheidung. Ein Selektor band Politik an den Tunnel. Beobachteter Verkehr beantwortete eine spätere Frage. Wer alles auf die Adresse reduzierte, verlor die wirkliche Ursache des Zugangs.

Heng Lus Disziplin der Realitätsebenen trennt diese Belege. Der Vorrang laufenden Codes richtet den Blick auf tatsächliche Routen, Selektoren und Pakete. Die minimale Anfangsspezifikation erklärt den Wert der DHCP-Wiederverwendung. Das sind spätere redaktionelle Perspektiven, keine Belege privater Autorenabsicht.

RFC 3456 schwächte DHCP nicht, indem es Lease und Autorisierung trennte. Es bewahrte dessen genaue Zuständigkeit: die virtuelle Präsenz zu konfigurieren. Was diese Präsenz tun durfte, musste das Gateway weiterhin aus authentisiertem Tunnel und aktueller Politik entscheiden.

Quellen