2.23. NAT-Traversal

Dieser Abschnitt beschreibt die Mechanismen, die IKEv2-Implementierungen unterstützen MÜSSEN, um die Interoperabilität über NATs (Network Address Translators) hinweg sicherzustellen. Die in diesem Abschnitt definierten Namen von Nachrichten, Transformationen und Benachrichtigungen finden sich im IANA-"IKEv2 Parameters"-Registry (siehe Abschnitt 2.23.4).

2.23.1. Erkennung von NAT-Fähigkeiten

Wenn beide Peers NAT-Traversal unterstützen, SOLLTEN sie den Notification-Payload NAT_DETECTION_SOURCE_IP oder NAT_DETECTION_DESTINATION_IP in die IKE_SA_INIT-Nachrichten aufnehmen. Der Initiator und der Responder SOLLTEN den NAT_DETECTION_SOURCE_IP-Payload senden. Der Initiator SOLLTE den NAT_DETECTION_DESTINATION_IP-Payload senden, und der Responder SOLLTE ihn senden, wenn sich seine Adresse seit dem Senden der IKE_SA_INIT-Nachricht geändert hat.

Der Inhalt dieser Notification-Payloads ist der folgende Hash der Adressen und Ports von Quelle oder Ziel des Pakets:

NAT_DETECTION_SOURCE_IP = HASH(Address of Initiator | Port of Initiator) NAT_DETECTION_DESTINATION_IP = HASH(Address of Responder | Port of Responder)

wobei Adresse und Port diejenigen sind, die zum Senden des Pakets mit der IKE_SA_INIT-Nachricht verwendet wurden, und der Hash-Algorithmus das durch die Pseudo-Random-Function-Transformationsgruppe der Proposal 2.1.1 definierte prf ist. Die Verwendung von prf als Hash-Funktion stellt sicher, dass nur Parteien mit dem Schlüssel SK_e diese Werte überprüfen können.

Wenn die vom Initiator und vom Responder berechneten Hashes unterschiedlich sind, wird angenommen, dass ein NAT vorhanden ist. Wenn die Hashes übereinstimmen, wird angenommen, dass kein NAT vorhanden ist.

2.23.2. NAT-Traversal-Parameter

Wenn ein NAT erkannt wird oder die Peers damit rechnen, eines zu treffen, gelten die folgenden Parameter:

o IKE-Nachrichten MÜSSEN über UDP-Port 4500 gesendet werden.

o IKE-Nachrichten MÜSSEN in UDP gekapselt werden, mit einem Header, der vier Null-Oktette als Präfix enthält.

o ESP- und AH-Payloads MÜSSEN in UDP gekapselt werden (d.h. UDP-ESP-NAT-Traversal, [UDPENCAP]).

o Implementierungen MÜSSEN bereit sein, IKE-Nachrichten über UDP-Port 4500 mit oder ohne das Präfix der vier Null-Oktette zu empfangen, SOLLTEN jedoch Nachrichten über Port 500 oder 4500 ohne Präfix akzeptieren.

2.23.3. Behandlung von Adressänderungen

Wenn eine Implementierung ein Paket über eine andere als die erwartete Adresse oder Port empfängt, MUSS sie dies als Hinweis auf eine Adressänderung behandeln. Sie SOLLTE dann NAT_DETECTION_SOURCE_IP- und NAT_DETECTION_DESTINATION_IP-Benachrichtigungen senden, um Änderungen zu erkennen und gegebenenfalls ihre Adressierungsinformationen zu aktualisieren.

Wenn eine Implementierung feststellt, dass sich die Adresse des Peers geändert hat, SOLLTE sie eine INFORMATIONAL-Nachricht mit einem Notify-Payload des Typs NAT_DETECTION_DESTINATION_IP senden, um den Peer über den neuen Zieladress-Hash zu informieren.

2.23.4. IANA-Einträge

IANA hat Registries für NAT-Traversal-Nachrichten und zugehörige Benachrichtigungen erstellt, wie in [IKEV2IANA] beschrieben. Implementierungen MÜSSEN die in diesen Registries definierten Benachrichtigungstypen und Nachrichtennummern verwenden.