2.23. NAT Traversal (NAT-Traversierung)

2.23. NAT Traversal (NAT-Traversierung)

Netzwerkadressübersetzungs-Gateways (NAT) sind umstritten. Dieser Abschnitt beschreibt kurz, was sie sind und wie sie IKE-Verkehr wahrscheinlich beeinflussen. Viele halten NAT für schädlich und meinen, Protokolle sollten nicht darauf ausgelegt werden, besser damit zu funktionieren. IKEv2 legt tatsächlich teils unintuitive Verarbeitungsregeln fest, damit NAT häufiger funktionieren.

NAT existieren vor allem wegen des IPv4-Adressmangels. Knoten „hinter“ einem NAT haben keine global eindeutigen Adressen; sie sind im Netz hinter dem NAT eindeutig, werden aber oft hinter anderen NATs wiederverwendet. Im Allgemeinen kommunizieren NAT-hintere Knoten mit anderen hinter demselben NAT und mit global eindeutigen Knoten, nicht aber mit Knoten hinter anderen NAT (Ausnahmen möglich). Beim Verbinden ins Internet „übersetzt“ das NAT-Gateway die IP-Quelladresse in eine zurück zum Gateway routbare Adresse. Nachrichten aus dem Internet zum Gateway erhalten eine „übersetzte“ Zieladresse zur internen Adresse des Endknotens.

NAT sollen für Endpunkte „transparent“ sein. Weder Software hinter dem NAT noch der Internetknoten muss für NAT-Durchleitung geändert werden. Für manche Protokolle ist diese Transparenz schwerer. Protokolle mit Endpunkt-IP-Adressen in der Nutzlast scheitern, wenn das NAT das Protokoll nicht versteht und interne Referenzen sowie Header nicht anpasst. Solches Wissen ist von Natur aus unzuverlässig, verletzt die Schichtung und führt oft zu subtilen Problemen.

IPsec-Verbindungen durch ein NAT haben besondere Probleme. Im Transportmodus brechen Prüfsummen bei geänderten IP-Adressen, und das NAT kann sie nicht korrigieren, da sie kryptografisch geschützt sind. Selbst im Tunnelmodus erfordert transparente Adressübersetzung von AH- und ESP-Paketen spezielle, heuristische und unzuverlässige NAT-Logik. IKEv2 verwendet daher UDP-Kapselung von IKE und ESP. Das ist etwas weniger effizient, aber für NAT einfacher. Firewalls können nur UDP-gekapselten IPsec-Verkehr erlauben oder umgekehrt.

NAT übersetzen oft auch TCP- und UDP-Ports und wählen anhand eingehender Ports den internen Knoten. Daher MÜSSEN IKE-Pakete zwar an/von UDP 500 oder 4500 gesendet werden, aber von jedem Port akzeptiert und Antworten an den Herkunftsport zurückgeschickt werden. IKE-Endpunktadressen stehen typischerweise nicht in IKE-Nutzlasten, da diese geschützt sind und von NAT nicht transparent geändert werden könnten.

Port 4500 ist für UDP-gekapseltes ESP und IKE reserviert. Ein IPsec-Endpunkt, der ein NAT entdeckt (siehe unten), MUSS den gesamten weiteren Verkehr von Port 4500 senden, den NAT nicht wie 500 speziell behandeln sollte.

Der Initiator KANN von Anfang an Port 4500 für IKE und ESP nutzen, mit oder ohne NAT. Nutzt eine Seite 4500, ist UDP-gekapseltes ESP-Senden nicht erforderlich, Empfang schon. UDP-Kapselung auf Port 500 ist VERBOTEN. Wird NAT-T unterstützt (NAT_DETECTION_*_IP während IKE_SA_INIT), MÜSSEN alle Geräte jederzeit UDP-gekapseltes und nicht gekapseltes ESP empfangen und verarbeiten. Jede Seite entscheidet über ESP-Kapselung unabhängig. Wird ein NAT erkannt, MÜSSEN beide UDP-Kapselung für ESP verwenden.

Die Anforderungen [NATREQ] für NAT-Traversierung sind unten aufgelistet. Support ist optional. Nur in diesem Abschnitt gelten MUST-Anforderungen für Implementierungen mit NAT-T-Support.

• Initiator und Responder IKE MÜSSEN in IKE_SA_INIT Notify NAT_DETECTION_SOURCE_IP und NAT_DETECTION_DESTINATION_IP enthalten. Sie erkennen NAT und welche Seite dahinter ist. Position: direkt nach Ni und Nr (vor optionalem CERTREQ).

• NAT_DETECTION_SOURCE_IP-Daten: SHA-1 über SPI (Header-Reihenfolge), Absender-IP und -Port.

  Mehrere NAT_DETECTION_SOURCE_IP sind erlaubt, wenn der Absender nicht weiß, welche Schnittstelle sendet.

• NAT_DETECTION_DESTINATION_IP-Daten: SHA-1 über SPI, Ziel-IP und -Port des Pakets.

• Der Empfänger KANN mit SHA-1 über SPI, Quell- bzw. Ziel-IP und Port vergleichen; bei Abweichung SOLLTE er NAT-T aktivieren. Stimmt SOURCE mit keiner empfangenen SOURCE überein, KANN er ohne NAT-T ablehnen. DESTINATION-Abweichung: empfangendes System ist hinter NAT und SOLLTE Keepalives [UDPENCAPS] senden; oder ohne NAT-T ablehnen.

• Stimmt keine empfangene NAT_DETECTION_SOURCE_IP mit erwarteter Quell-IP/-Port aus dem IP-Header überein, ist der Absender hinter NAT (Quelle wurde unterwegs ersetzt). Der Empfänger sollte dynamische Aktualisierung der anderen Adresse erlauben (siehe unten).

• Der IKE-Initiator MUSS NAT_DETECTION_SOURCE_IP oder DESTINATION_IP prüfen; stimmen sie nicht mit den äußeren Paketadressen überein, MÜSSEN alle künftigen IKE- und ESP-Pakete dieser IKE SA über UDP 4500 getunnelt werden.

• IKE über 4500: vier Null-Oktetts vor IKE-Header, dann UDP. ESP: ESP-Header direkt nach UDP. Die ersten vier ESP-Oktette sind der SPI (nie gültig null), daher Unterscheidung IKE/ESP.

• Implementierungen MÜSSEN empfangenes UDP-gekapseltes ESP auch ohne erkanntes NAT verarbeiten.

• Ursprüngliche Quell- und Ziel-IP für Transportmodus-TCP/UDP-Prüfsummenkorrektur ([UDPENCAPS]) stammen aus den Traffic Selectors des Austauschs. Bei Transportmodus-NAT-T MÜSSEN die TS genau eine IP-Adresse enthalten (als ursprüngliche IP). Siehe 2.23.1.

• Ein NAT kann noch lebende Mappings entfernen (Keepalive zu lang, Neustart). Ein Host sieht das an einem Paket mit gültiger Integrität, aber anderem Port und/oder anderer Adresse als der SA. Ein Host ohne andere Wiederherstellung (MOBIKE [MOBIKE]) und nicht hinter NAT SOLLTE alle Pakete (inkl. Retransmission) an IP/Port des validierten Pakets senden und die neue Kombination für die SA speichern. Ein Host hinter NAT SOLLTE bei abweichendem Port/Adresse keine solche dynamische Aktualisierung vornehmen (DoS-Risiko). Nur auf neues Paket reagieren (sonst Replay). Nur mit Replay-Schutz sicher. Mit MOBIKE stört dies die MOBIKE-Wiederherstellung; siehe [MOBIKE] 3.8.

2.23.1. Transport Mode NAT Traversal (Transportmodus und NAT-T)

Transportmodus mit NAT-T erfordert spezielle Behandlung der Traffic Selectors in IKEv2. Vollständiges Szenario:

+------+        +------+            +------+         +------+
|Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
|node  |<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

(Andere Szenarien vereinfachen diesen Fall.)

Zwei NAT: A dynamisch (IP1→IPN1), B statisch (Verbindungen zu IPN2→IP2 des Servers). Client erreicht Server über IPN2. B muss nicht statisch sein; der Client muss die externe Adresse von B (IPN2) kennen (Konfiguration, DNS), außerhalb IKEv2.

Client und Server nutzen Transportmodus für Client→Server-Verkehr.

Beim Aufbau von IKEv2 SA und Child SA kann ein Auslöserpaket Quelle IP1 und Ziel IPN2 haben. PAD und SPD müssen passen. Im Transportmodus sind TS und äußere IKE-IP dieselben Adressen. TSi und TSr MÜSSEN je genau eine IP haben; mehrere TS für Portbereiche sind möglich, alle TSi IP1-IP1, alle TSr IPN2-IPN2. Erste TSi/TSr SOLLTEN spezifisch sein (Protokoll, Ports des Auslösers).

NAT A ersetzt IKE-Quelle IP1→IPN1, NAT B Ziel IPN2→IP2; am Server bleiben TS wie vom Client gesendet, IKE-IP ist IPN1 und IP2.

Der Server prüft üblicherweise PAD [IPSECARCH] RFC 4301 nach ID, dann SPD nach TS. IP1 ist im Transportmodus für den Server bei Suche bedeutungslos; ob Transport erlaubt ist, weiß er erst nach passendem SPD-Eintrag.

Der Server prüft zuerst Transportmodus-Anforderung, substituiert dann Adressen in TS. Alte TS-IPs werden für inkrementelle Prüfsummenkorrektur gespeichert (TSi = ursprüngliche Quelle, TSr = ursprüngliches Ziel). Ist die Gegenseite hinter NAT, ersetzt er TSi-IP durch IKE-Quelladresse des empfangenen Pakets (IP1→IPN1). Ist der Server hinter NAT, ersetzt er TSr-IP durch IKE-Zieladresse (IPN2→IP2).

Nach Substitution stimmen TS und IKE-UDP-Adressen überein; SPD-Suche mit neuen TS. Gefundener Eintrag mit Transport: nutzen. Gefunden ohne Transport: Server KANN Substitution rückgängig machen und SPD mit Original-TS erneut suchen; gelingt das, Tunnel-SA mit echten TS der Gegenseite.

Substitution ist nötig, weil SPD mit lokal sichtbaren Adressen gesucht wird. SAD-Einträge für Tunnelende und Rückweg nutzen OS-sichtbare Adressen.

Häufig wildcard-SPD; auch differenziert nach bekannter NAT-Außenadresse möglich.

Nach SPD-Verengung mit substituierten TS; Antwort mit IPN1 und IP2; Protokoll/Ports können weiter verengt werden. Child-SA-SAD: IPN1 und IP2 aus Serversicht.

Client bei Child-SA-Antwort: zurückgegebene TS als ursprüngliche Quell-/Zieladressen speichern, IPs durch IKE-Header ersetzen (IPN1→IP1, IP2→IPN2), SA prüfen und SAD installieren.

Zusammenfassung Transportmodus:

Client (Transport angeboten):

• TSi: genau eine IP, MUSS IKE-SA-Quelle entsprechen.

• TSr: genau eine IP, MUSS IKE-SA-Ziel entsprechen.

• Erste TSi/TSr SOLLTEN Protokoll und Ports präzise enthalten.

• Mehrere TSi/TSr sind erlaubt.

• Bei gewähltem Transport (USE_TRANSPORT_MODE in Antwort):

  • Original-TS als empfangene Quell-/Zieladressen speichern.

  • Server hinter NAT: TSr-IP durch IKE-SA-Remoteadresse ersetzen.

  • Client hinter NAT: TSi-IP durch IKE-SA-Lokaladresse ersetzen.

  • Substitution vor jeder Nutzung außer Originalspeicherung (Verengungsprüfung, SAD, …).

Responder (Client schlägt Transport vor):

• Original-TS-IPs für Rücknahme, „echte“ Adressen [UDPENCAPS], TCP/UDP-Checksummen speichern.

• Client hinter NAT: TSi → IKE-SA-Remote.

• Server hinter NAT: TSr → IKE-SA-Lokal.

• PAD/SPD mit ID und substituierten TS.

• Kein SPD oder kein Transport: Substitution rückgängig, Suche mit Original-TS inkl. Tunnel-SPD (Fallback Tunnel).

• Transport-SPD gefunden: normale Verengung mit substituierten TS; Ergebnis-TS für SAD und Antwort an Client.