4. Bestehende Lösungen

4.1. IPsec-Tunnelmodus

Unter begrenzten Umständen ist es möglich, dass eine IPsec-Tunnelmodus-Implementierung, wie die in [DHCP] beschriebene, NA(P)T erfolgreich durchquert. Die Anforderungen für eine erfolgreiche Traversierung sind jedoch so begrenzt, dass eine allgemeinere Lösung benötigt wird:

IPsec ESP. IPsec-ESP-Tunnel decken den äußeren IP-Header nicht in der Nachrichtenintegritätsprüfung ab und leiden daher nicht unter Authentifizierungsdaten-Invalidierung aufgrund von Adressübersetzung. IPsec-Tunnel müssen sich auch nicht um Prüfsummen-Invalidierung kümmern.
Keine Adressvalidierung. Die meisten aktuellen IPsec-Tunnelmodus-Implementierungen führen keine Quelladressvalidierung durch, so dass Inkompatibilitäten zwischen IKE-Identifikatoren und Quelladressen nicht erkannt werden. Dies führt zu Sicherheitsschwachstellen, wie in Abschnitt 5 beschrieben.
"Any to Any" SPD-Einträge. IPsec-Tunnelmodus-Clients können "any to any" SPDs aushandeln, die durch Adressübersetzung nicht invalidiert werden. Dies schließt effektiv die Verwendung von SPDs für die Filterung von erlaubtem Tunnel-Verkehr aus.
Einzelclient-Betrieb. Mit nur einem Client hinter einem NAT besteht kein Risiko überlappender SPDs. Da das NAT nicht zwischen konkurrierenden Clients vermitteln muss, besteht auch kein Risiko einer Re-Key-Fehlübersetzung oder einer unsachgemäßen eingehenden SPI- oder Cookie-Demultiplexierung.
Keine Fragmentierung. Bei Verwendung der Zertifikatauthentifizierung kann IKE-Fragmentierung auftreten. Dies kann auftreten, wenn Zertifikatsketten verwendet werden, oder sogar beim Austausch eines einzelnen Zertifikats, wenn die Schlüsselgröße oder die Größe anderer Zertifikatsfelder (wie der Distinguished Name und andere Erweiterungen) groß genug ist. Bei Verwendung von Pre-Shared-Keys zur Authentifizierung ist Fragmentierung jedoch weniger wahrscheinlich.
Aktive Sitzungen. Die meisten VPN-Sitzungen halten typischerweise während ihrer Lebensdauer einen kontinuierlichen Verkehrsfluss aufrecht, so dass UDP-Port-Mappings weniger wahrscheinlich aufgrund von Inaktivität entfernt werden.

4.2. RSIP

RSIP, beschrieben in [RSIP] und [RSIPFrame], enthält Mechanismen für IPsec-Traversierung, wie in [RSIPsec] beschrieben. Durch Ermöglichung der Host-NA(P)T-Kommunikation behandelt RSIP Probleme der IPsec-SPI-Demultiplexierung sowie SPD-Überlappung. Es ist daher sowohl für den Einsatz in Unternehmen als auch in Heimnetzwerk-Szenarien geeignet. Indem Hosts hinter einem NAT ermöglicht wird, die externe IP-Adresse des NA(P)T (das RSIP-Gateway) zu teilen, ist dieser Ansatz mit Protokollen kompatibel, die eingebettete IP-Adressen enthalten.

Durch Tunneling von IKE- und IPsec-Paketen vermeidet RSIP Änderungen an den IKE- und IPsec-Protokollen, obwohl größere Änderungen an Host-IKE- und IPsec-Implementierungen erforderlich sind, um sie RSIP-kompatibel zu machen. Es ist daher mit allen vorhandenen Protokollen (AH/ESP) und Modi (Transport und Tunnel) kompatibel.

Um die Demultiplexierung von IKE-Re-Keys zu handhaben, erfordert RSIP das Floating des IKE-Quellports sowie das Re-Keying zum schwebenden Port. Infolgedessen ist die Interoperabilität mit vorhandenen IPsec-Implementierungen nicht gewährleistet.

RSIP erfüllt nicht die Bereitstellungsanforderungen für eine IPsec-NAT-Kompatibilitätslösung, da ein RSIP-fähiger Host ein entsprechendes RSIP-fähiges Gateway benötigt, um eine IPsec-SA mit einem anderen Host herzustellen. Da RSIP nur Änderungen an Clients und Routern und nicht an Servern erfordert, ist es weniger schwierig bereitzustellen als IPv6. Für Anbieter erfordert die Implementierung von RSIP jedoch einen erheblichen Anteil der für IPv6-Unterstützung erforderlichen Ressourcen. RSIP löst somit ein "Übergangs"-Problem in einem langfristigen Zeitrahmen, was nicht nützlich ist.

4.3. 6to4

6to4, wie in [RFC3056] beschrieben, kann die Grundlage für eine IPsec-NAT-Traversierungslösung bilden. Bei diesem Ansatz stellt das NAT IPv6-Hosts ein IPv6-Präfix bereit, das von der externen IPv4-Adresse des NAT abgeleitet ist, und kapselt IPv6-Pakete in IPv4 für die Übertragung an andere 6to4-Hosts oder 6to4-Relays. Dies ermöglicht es einem IPv6-Host, der IPsec verwendet, frei mit anderen Hosts innerhalb der IPv6- oder 6to4-Clouds zu kommunizieren.

Obwohl 6to4 eine elegante und robuste Lösung ist, wenn ein einzelnes NA(P)T einen Client und ein VPN-Gateway trennt, ist es nicht universell anwendbar. Da 6to4 die Zuweisung einer routbaren IPv4-Adresse an das NA(P)T erfordert, um die Bildung eines IPv6-Präfixes zu ermöglichen, ist es nicht verwendbar, wenn mehrere NA(P)Ts zwischen dem Client und dem VPN-Gateway existieren. Zum Beispiel kann ein NA(P)T mit einer privaten Adresse auf seiner externen Schnittstelle von Clients dahinter nicht verwendet werden, um ein IPv6-Präfix über 6to4 zu erhalten.

Obwohl 6to4 wenig zusätzliche Unterstützung von Hosts erfordert, die bereits IPv6 unterstützen, erfordert es Änderungen an NATs, die aktualisiert werden müssen, um 6to4 zu unterstützen. Infolgedessen ist 6to4 möglicherweise nicht für die kurzfristige Bereitstellung geeignet.