Zusammenfassung

  • RFC 3948 führte IKE und UDP-gekapseltes ESP über dieselbe NAT-Zuordnung; vier Null-Bytes markierten IKE, weil eine gültige ESP-SPI nicht null sein durfte.
  • Der Marker entschied nur über den Kandidaten für die weitere Verarbeitung. SA-Suche, Replay-Schutz, Kryptoprüfung, innere Adresspolitik und Anwendungsergebnis blieben eigenständige Entscheidungen.

Ein äußerer Pfad, mehrere Zuständigkeiten

ESP schützte Daten, passte aber nicht selbstverständlich in die von vielen Adressumsetzern erwartete TCP- oder UDP-Flussform. Die UDP-Kapselung gab dem NAT bekannte Portfelder. Zugleich musste IKE, das Schlüssel und Security Associations aushandelt, denselben Peer durch dieselbe Übersetzungsumgebung erreichen.

RFC 3948 entschied sich bewusst für gemeinsame Ports. Eine NAT-Zuordnung statt mehrerer Zuordnungen verbesserte die Skalierung; anderer Verkehr hielt den Pfad mit offen; Firewalls brauchten nur eine Portfreigabe; Implementierungen verwalteten weniger äußeren Zustand. RFC 3947 regelte die NAT-Traversal-Aushandlung und den Wechsel des IKE-Verkehrs auf UDP 4500.

Der gemeinsame Port machte die innere Unterscheidung erst notwendig. Der Empfänger musste nach dem UDP-Header entscheiden, ob IKE oder ESP zuständig war. Dafür nutzte der Standard einen Wert, den ESP ohnehin nicht gültig auf dem Netz verwenden konnte.

Null wurde frei, um etwas anderes zu bedeuten

Am Anfang eines ESP-Headers steht der 32-Bit-Security-Parameters-Index. Mit der SPI sucht der Empfänger den passenden SA-Zustand. RFC 2406 reserviert den Wert null für lokale Zwecke; er ist keine normale übertragene ESP-SPI. RFC 3948 schreibt deshalb für gekapseltes ESP eine von null verschiedene SPI vor.

IKE auf UDP 4500 erhält dagegen vier Null-Oktette zwischen UDP- und IKE-Header. Der Non-ESP Marker liegt genau dort, wo bei ESP die SPI stünde. Liest der Empfänger null, kann er die Nachricht IKE zuführen. Ein anderer Wert kann als ESP-SPI interpretiert werden.

Der Marker war eine Typweiche, keine Identität. Er enthielt kein Geheimnis, keine Signatur und keinen MAC. Er benannte weder einen Peer noch einen IKE SA und sagte nicht, ob der restliche Inhalt wohlgeformt war. IKE musste seinen Zustand und seine Authentifizierung anschließend selbst prüfen.

Auch „nicht null“ bedeutete nicht „gültiges ESP“. Der Empfänger brauchte einen installierten SA im richtigen Kontext, musste Sequenz und Replay-Fenster prüfen, den kryptographischen Schutz verifizieren und die Verkehrsrichtlinie anwenden. Eine unbekannte SPI oder fehlgeschlagene Integrität beendete das Paket trotz korrekter erster Klassifikation.

Ein Byte hielt die Zuordnung, nicht die Verbindung

Als dritte Form definierte RFC 3948 einen NAT-Keepalive mit genau einem Nutzlastbyte 0xFF. Er verwendete dieselben Ports wie UDP-gekapseltes ESP. Der Empfänger sollte ihn ignorieren; sein alleiniger Zweck bestand darin, die NAT-Zuordnung während Leerlauf zu erhalten.

Die Spezifikation verbietet, den Empfang als Lebenderkennung der Verbindung zu verwenden. Ein Übersetzer kann seinen Timer erneuern, obwohl der IKE-Zustand unbrauchbar, der ESP SA entfernt oder die Anwendung ausgefallen ist. Ein mittlerer Knoten erinnert sich an eine Zuordnung; das ist kein End-to-End-Ergebnis.

Die damaligen Standardwerte—bei Bedarf nach zwanzig Sekunden ohne anderen Versand und bis zu einer konfigurierbaren Fünf-Minuten-Spanne nach einem früheren SA—waren lokale Parameter. Sie sind keine universelle heutige Zusage. NAT, Endpunkt, IKE, ESP und Anwendung besitzen verschiedene Uhren und verschiedene Begriffe von Gültigkeit.

Nach der Weiche begann die eigentliche Politik

UDP ersetzte ESP nicht. Der Sender führte das gewöhnliche ESP-Verfahren aus und fügte UDP hinzu; der Empfänger entfernte UDP und setzte mit normaler ESP-Dekapselung fort. Danach blieben die Folgen der Adressumsetzung.

Im Tunnelmodus konnte lokale Politik die innere Quelladresse gegen einen erlaubten Bereich oder eine zugewiesene Peer-Adresse prüfen oder sie für das lokale Netz umsetzen. Im Transportmodus konnten geänderte IP-Adressen TCP- oder UDP-Prüfsummen ungültig machen; RFC 3948 beschrieb begrenzte Korrekturwege. Vier Null-Bytes entschieden nicht, welche innere Adresse Autorität besaß.

Die Konfliktbeispiele zeigen die Grenze des äußeren Namens. Zwei Laptops hinter verschiedenen NATs konnten dieselbe private Adresse führen, sodass ein Gateway mehrere SAs zum scheinbar gleichen inneren Ziel sah. Mehrere Clients hinter einer öffentlichen Adresse konnten überlappende Verkehrsdefinitionen aushandeln. Eine einfache Filterabfrage konnte dann den ausgehenden SA nicht eindeutig bestimmen. Eindeutige lokale Adressen, zusätzliche Umsetzung, Ablehnung oder ein anderes ausdrückliches Verfahren waren erforderlich.

RFC 3715 hatte diese Kompatibilitätsanforderungen gesammelt. RFC 3948 lieferte eine einsetzbare Kapselung, machte aber aus der äußeren NAT-Adresse keinen eindeutigen Namen für alles dahinter.

Die enge Regel blieb in IKEv2 erhalten

Der RFC-Editor-Eintrag weist RFC 3948 als Standards-Track-Dokument vom Januar 2005 aus. Das bestätigte Erratum korrigiert einen Verweis in der Einleitung und verändert den Marker nicht.

RFC 7296 bewahrt das Verfahren für IKEv2: IKE auf 4500 beginnt mit vier Nullen, ESP unmittelbar mit einer SPI, die nicht gültig null sein kann. Ein Initiator darf 4500 sogar von Beginn an verwenden, ohne zuvor NAT nachgewiesen zu haben. Der Port allein ist daher auch kein NAT-Beleg.

Die historische Leistung liegt in der Begrenzung. Der Port koordiniert Ankunft. Das erste Wort wählt einen möglichen Parser. IKE oder ESP entscheidet über Sicherheit. Lokale Politik entscheidet über inneren Verkehr. Die Anwendung belegt den Nutzen. Die vier Null-Bytes funktionierten, weil sie keine dieser späteren Kompetenzen beanspruchten.

Quellen