3. Anforderungen für IPsec-NAT-Kompatibilität

3. Anforderungen für IPsec-NAT-Kompatibilität

Das Ziel einer IPsec-NAT-Kompatibilitätslösung besteht darin, den Bereich der verwendbaren IPsec-Funktionalität über die in der in Abschnitt 2.3 beschriebenen NAT-kompatiblen IPsec-Tunnelmodus-Lösung hinaus zu erweitern.

Bei der Bewertung einer Lösung für IPsec-NAT-Inkompatibilität sollten die folgenden Kriterien berücksichtigt werden:

Bereitstellung

Da IPv6 die Adressknappheitsprobleme lösen wird, die häufig zur Verwendung von NA(P)Ts mit IPv4 führen, ist das IPsec-NAT-Kompatibilitätsproblem ein Übergangsproblem, das im Zeitraum vor der weit verbreiteten Bereitstellung von IPv6 gelöst werden muss. Daher MUSS eine IPsec-NAT-Kompatibilitätslösung in einem kürzeren Zeitrahmen als IPv6 bereitstellbar sein, um nützlich zu sein.

Da die IPv6-Bereitstellung Änderungen sowohl an Routern als auch an Hosts erfordert, wird eine potenzielle IPsec-NAT-Kompatibilitätslösung, die Änderungen sowohl an Routern als auch an Hosts erfordert, in etwa dem gleichen Zeitrahmen wie IPv6 bereitstellbar sein. Daher SOLLTE eine IPsec-NAT-Kompatibilitätslösung nur Änderungen an Hosts und nicht an Routern erfordern.

Dies impliziert unter anderem, dass die Kommunikation zwischen dem Host und dem NA(P)T NICHT von einer IPsec-NAT-Kompatibilitätslösung gefordert werden SOLLTE, da dies Änderungen an den NA(P)Ts und Interoperabilitätstests zwischen Host- und NA(P)T-Implementierungen erfordern würde. Um eine kurzfristige Bereitstellung zu ermöglichen, ist es notwendig, dass die Lösung mit vorhandenen Router- und NA(P)T-Produkten innerhalb der bereitgestellten Infrastruktur funktioniert.

Protokollkompatibilität

Von einer IPsec-NAT-Traversierungslösung wird nicht erwartet, dass sie Probleme mit Protokollen löst, die NA(P)T nicht durchqueren können, wenn sie nicht mit IPsec gesichert sind. Daher können ALGs für einige Protokolle noch erforderlich sein, selbst wenn eine IPsec-NAT-Traversierungslösung verfügbar ist.

Sicherheit

Da die NA(P)T-Direktionalität eine Sicherheitsfunktion erfüllt, sollten IPsec NA(P)T-Traversierungslösungen nicht zulassen, dass beliebiger eingehender IPsec- oder IKE-Verkehr von jeder IP-Adresse von einem Host hinter dem NA(P)T empfangen wird, obwohl der Mapping-Zustand aufrechterhalten werden sollte, sobald bidirektionale IKE- und IPsec-Kommunikation hergestellt ist.

Telearbeiter-Szenario

Da eine der Hauptanwendungen von IPsec der Fernzugriff auf Unternehmens-Intranets ist, MUSS eine NA(P)T-Traversierungslösung NA(P)T-Traversierung unterstützen, entweder über IPsec-Tunnelmodus oder L2TP über IPsec-Transportmodus [RFC3193]. Dies umfasst die Unterstützung für die Traversierung von mehr als einem NA(P)T zwischen dem Remote-Client und dem VPN-Gateway.

Der Client kann eine routbare Adresse haben und das VPN-Gateway kann hinter mindestens einem NA(P)T sein, oder alternativ können sowohl der Client als auch das VPN-Gateway hinter einem oder mehreren NA(P)Ts sein. Telearbeiter können dieselbe private IP-Adresse verwenden, jeder hinter seinem eigenen NA(P)T, oder viele Telearbeiter können in einem privaten Netzwerk hinter demselben NA(P)T wohnen, jeder mit seiner eigenen eindeutigen privaten Adresse, die sich mit demselben VPN-Gateway verbindet. Da IKE UDP-Port 500 als Ziel verwendet, ist es nicht notwendig, mehrere VPN-Gateways zu aktivieren, die hinter derselben externen IP-Adresse betrieben werden.

Gateway-to-Gateway-Szenario

In einem Gateway-to-Gateway-Szenario kann ein privat adressiertes Netzwerk (DMZ) zwischen das Unternehmensnetzwerk und das Internet eingefügt werden. In diesem Design können IPsec-Sicherheitsgateways, die Teile des Unternehmensnetzwerks verbinden, in der DMZ ansässig sein und private Adressen auf ihren externen (DMZ) Schnittstellen haben. Ein NA(P)T verbindet das DMZ-Netzwerk mit dem Internet.

End-to-End-Szenario

Eine NAT-IPsec-Lösung MUSS sichere Host-zu-Host-TCP/IP-Kommunikation über IPsec sowie Host-zu-Gateway-Kommunikation ermöglichen. Ein Host in einem privaten Netzwerk MUSS in der Lage sein, eine oder mehrere IPsec-geschützte TCP-Verbindungen oder UDP-Sitzungen zu einem anderen Host mit einem oder mehreren NA(P)Ts zwischen ihnen aufzubauen. Beispielsweise können NA(P)Ts in Zweigstellen bereitgestellt werden, die sich mit dem Unternehmensnetzwerk verbinden, mit einem zusätzlichen NA(P)T, der das Unternehmensnetzwerk mit dem Internet verbindet. Ebenso können NA(P)Ts innerhalb eines Unternehmens-LAN oder -WAN bereitgestellt werden, um drahtlose oder entfernte Standortclients mit dem Unternehmensnetzwerk zu verbinden. Dies kann eine spezielle Verarbeitung von TCP- und UDP-Verkehr auf dem Host erfordern.

Das Aufbauen von SCTP-Verbindungen zu einem anderen Host mit einem oder mehreren NA(P)Ts zwischen ihnen kann besondere Herausforderungen darstellen. SCTP unterstützt Multi-Homing. Wenn mehr als eine IP-Adresse verwendet wird, werden diese Adressen als Teil des SCTP-Pakets während des Assoziations-Setups transportiert (in den INIT- und INIT-ACK-Chunks). Wenn nur Single-Homed-SCTP-Endpunkte verwendet werden, heißt es in [RFC2960] Abschnitt 3.3.2.1:

  Beachten Sie, dass die Nichtverwendung von IP-Adress-Parametern im INIT und
  INIT-ACK eine Alternative ist, um eine Assoziation wahrscheinlicher über
  eine NAT-Box funktionieren zu lassen.

Dies impliziert, dass IP-Adressen nicht in das SCTP-Paket eingefügt werden sollten, es sei denn, es ist notwendig. Wenn NATs vorhanden sind und IP-Adressen enthalten sind, wird das Assoziations-Setup fehlschlagen. Kürzlich wurde [AddIP] vorgeschlagen, das die Änderung der IP-Adresse ermöglicht, sobald eine Assoziation hergestellt ist. Die Änderungsnachrichten haben auch IP-Adressen im SCTP-Paket und werden daher durch NATs negativ beeinflusst.

Firewall-Kompatibilität

Da Firewalls weit verbreitet sind, MUSS eine NAT-IPsec-Kompatibilitätslösung es einem Firewall-Administrator ermöglichen, einfache, statische Zugriffsregeln zu erstellen, um IKE- und IPsec-NA(P)T-Traversierungsverkehr zu erlauben oder zu verweigern. Dies impliziert beispielsweise, dass eine dynamische Zuweisung von IKE- oder IPsec-Zielports vermieden werden sollte.

Skalierung

Eine IPsec-NAT-Kompatibilitätslösung sollte in der Lage sein, in einer Installation mit Tausenden von Telearbeitern bereitgestellt zu werden. In dieser Situation ist es nicht möglich anzunehmen, dass nur ein einzelner Host gleichzeitig mit einem bestimmten Ziel kommuniziert. Daher MUSS eine IPsec-NAT-Kompatibilitätslösung das Problem überlappender SPD-Einträge und der Demultiplexierung eingehender Pakete angehen.

Modusunterstützung

Mindestens MUSS eine IPsec-NAT-Kompatibilitätslösung die Traversierung der IKE- und IPsec-Modi unterstützen, die für die Unterstützung in [RFC2409] und [RFC2401] erforderlich sind. Zum Beispiel MUSS ein IPsec-Gateway ESP-Tunnelmodus-NA(P)T-Traversierung unterstützen, und ein IPsec-Host MUSS IPsec-Transportmodus-NA(P)T-Traversierung unterstützen. Der Zweck von AH besteht darin, unveränderliche Felder im IP-Header (einschließlich Adressen) zu schützen, und NA(P)T übersetzt Adressen, wodurch die AH-Integritätsprüfung ungültig wird. Infolgedessen sind NA(P)T und AH grundsätzlich inkompatibel, und es besteht keine Anforderung, dass eine IPsec-NAT-Kompatibilitätslösung AH-Transport- oder Tunnelmodus unterstützt.

Rückwärtskompatibilität und Interoperabilität

Eine IPsec-NAT-Kompatibilitätslösung MUSS mit vorhandenen IKE/IPsec-Implementierungen interoperabel sein, damit sie kommunizieren können, wenn kein NA(P)T vorhanden ist. Dies impliziert, dass eine IPsec-NAT-Kompatibilitätslösung rückwärtskompatibel mit IPsec, wie in [RFC2401] definiert, und IKE, wie in [RFC2409] definiert, sein MUSS. Darüber hinaus SOLLTE sie in der Lage sein, das Vorhandensein eines NA(P)T zu erkennen, so dass NA(P)T-Traversierungsunterstützung nur bei Bedarf verwendet wird. Dies impliziert, dass es MÖGLICH sein MUSS zu bestimmen, dass eine vorhandene IKE-Implementierung keine NA(P)T-Traversierung unterstützt, so dass eine Standard-IKE-Konversation stattfinden kann, wie in [RFC2407], [RFC2408] und [RFC2409] beschrieben. Beachten Sie, dass dies zwar die Initiierung von IKE an Port 500 impliziert, aber keine Anforderung für einen spezifischen Quellport besteht, so dass UDP-Quellport 500 verwendet werden kann oder nicht.

Sicherheit

Eine IPsec-NAT-Kompatibilitätslösung DARF NICHT zusätzliche IKE- oder IPsec-Sicherheitsschwachstellen einführen. Zum Beispiel muss eine akzeptable Lösung nachweisen, dass sie keine neuen Denial-of-Service- oder Spoofing-Schwachstellen einführt. IKE MUSS auf bidirektionale Weise re-keyen dürfen, wie in [RFC2408] beschrieben.