2. Bekannte Inkompatibilitäten zwischen NA(P)T und IPsec

Die Inkompatibilitäten zwischen NA(P)T und IPsec können in drei Kategorien unterteilt werden:

Inhärente NA(P)T-Probleme. Diese Inkompatibilitäten leiten sich direkt von der in [RFC3022] beschriebenen NA(P)T-Funktionalität ab. Diese Inkompatibilitäten werden daher in jedem NA(P)T-Gerät vorhanden sein.
NA(P)T-Implementierungsschwächen. Diese Inkompatibilitäten sind nicht inhärent für NA(P)T, sind aber in vielen NA(P)T-Implementierungen vorhanden. In diese Kategorie fallen Probleme bei der Handhabung eingehender oder ausgehender Fragmente. Da diese Probleme nicht inhärent für NA(P)T sind, können sie prinzipiell in zukünftigen NA(P)T-Implementierungen behoben werden. Da die Implementierungsprobleme jedoch weit verbreitet zu sein scheinen, müssen sie in einer NA(P)T-Traversierungslösung berücksichtigt werden.
Hilfsfunktionsprobleme. Diese Inkompatibilitäten sind in NA(P)T-Geräten vorhanden, die versuchen, IPsec NA(P)T-Traversierung bereitzustellen. Ironischerweise schafft diese "Hilfs"-Funktionalität weitere Inkompatibilitäten und macht ein bereits schwieriges Problem noch schwieriger zu lösen. Obwohl die IPsec-Traversierungs-"Hilfs"-Funktionalität nicht in allen NA(P)Ts vorhanden ist, werden diese Funktionen ausreichend populär, so dass sie auch in einer NA(P)T-Traversierungslösung berücksichtigt werden müssen.

2.1. Inhärente NA(P)T-Probleme

Inkompatibilitäten, die inhärent für NA(P)T sind, umfassen:

a) Inkompatibilität zwischen IPsec AH [RFC2402] und NAT. Da der AH-Header die IP-Quell- und Zieladressen in die schlüsselbasierte Nachrichtenintegritätsprüfung einbezieht, werden NAT- oder Reverse-NAT-Geräte, die Änderungen an Adressfeldern vornehmen, die Nachrichtenintegritätsprüfung ungültig machen. Da IPsec ESP [RFC2406] die IP-Quell- und Zieladressen nicht in seine schlüsselbasierte Nachrichtenintegritätsprüfung einbezieht, tritt dieses Problem bei ESP nicht auf.

b) Inkompatibilität zwischen Prüfsummen und NAT. TCP- und UDP-Prüfsummen haben eine Abhängigkeit von den IP-Quell- und Zieladressen durch die Einbeziehung des "Pseudo-Headers" in die Berechnung. Infolgedessen werden Prüfsummen, die berechnet und beim Empfang überprüft werden, durch die Passage durch ein NAT- oder Reverse-NAT-Gerät ungültig gemacht.

Infolgedessen wird IPsec Encapsulating Security Payload (ESP) nur dann ungehindert durch ein NAT passieren, wenn TCP/UDP-Protokolle nicht beteiligt sind (wie im IPsec-Tunnelmodus oder IPsec-geschütztem GRE) oder Prüfsummen nicht berechnet werden (wie es mit IPv4 UDP möglich ist). Wie in [RFC793] beschrieben, ist die TCP-Prüfsummenberechnung und -verifizierung in IPv4 erforderlich. Die UDP/TCP-Prüfsummenberechnung und -verifizierung ist in IPv6 erforderlich.

Das Stream Control Transmission Protocol (SCTP), wie in [RFC2960] und [RFC3309] definiert, verwendet einen CRC32C-Algorithmus, der nur auf dem SCTP-Paket (gemeinsamer Header + Chunks) berechnet wird, so dass der IP-Header nicht abgedeckt ist. Infolgedessen machen NATs die SCTP-CRC nicht ungültig, und das Problem tritt nicht auf.

Beachten Sie, dass da Transportmodus-IPsec-Verkehr integritätsgeschützt und mit starker Kryptographie authentifiziert ist, Änderungen am Paket vor der Überprüfung der UDP/TCP-Prüfsummen erkannt werden können. Daher bietet die Prüfsummenverifizierung nur Sicherheit gegen Fehler bei der internen Verarbeitung.

c) Inkompatibilität zwischen IKE-Adressidentifikatoren und NAT. Wenn IP-Adressen als Identifikatoren im Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] oder Phase 2 verwendet werden, führt die Änderung der IP-Quell- oder Zieladressen durch NATs oder Reverse-NATs zu einer Nichtübereinstimmung zwischen den Identifikatoren und den Adressen im IP-Header. Wie in [RFC2409] beschrieben, müssen IKE-Implementierungen solche Pakete verwerfen.

Um die Verwendung von IP-Adressen als IKE Phase 1 und Phase 2 Identifikatoren zu vermeiden, können stattdessen UserIDs und FQDNs verwendet werden. Wenn Benutzerauthentifizierung gewünscht ist, kann ein ID-Typ von ID_USER_FQDN verwendet werden, wie in [RFC2407] beschrieben. Wenn Maschinen-authentifizierung gewünscht ist, kann ein ID-Typ von ID_FQDN verwendet werden. In jedem Fall ist es notwendig zu überprüfen, dass der vorgeschlagene Identifikator als Ergebnis der Verarbeitung eines Endentitätszertifikats authentifiziert wird, wenn Zertifikate in Phase 1 ausgetauscht werden. Während die Verwendung von USER_FQDN oder FQDN-Identitätstypen innerhalb von IKE möglich ist, gibt es Verwendungsszenarien (z.B. Security Policy Database (SPD) Einträge, die Subnetze beschreiben), die auf diese Weise nicht berücksichtigt werden können.

Da die Quelladresse im Phase 2 Identifikator häufig verwendet wird, um einen vollständigen 5-Tupel-Eingangs-SA-Selektor zu bilden, können die Zieladresse, das Protokoll, der Quellport und der Zielport im Selektor verwendet werden, um die Eingangs-SA-Verarbeitung nicht zu schwächen.

d) Inkompatibilität zwischen festen IKE-Quellports und NAPT. Wenn mehrere Hosts hinter dem NAPT IKE-SAs zum selben Responder initiieren, wird ein Mechanismus benötigt, um dem NAPT zu ermöglichen, die eingehenden IKE-Pakete vom Responder zu demultiplexen. Dies wird typischerweise erreicht, indem der IKE-UDP-Quellport bei ausgehenden Paketen vom Initiator übersetzt wird. Daher müssen Responder in der Lage sein, IKE-Verkehr von einem anderen UDP-Quellport als 500 zu akzeptieren und auf diesen Port zu antworten. Es muss darauf geachtet werden, unvorhersehbares Verhalten während Re-Keys zu vermeiden. Wenn der schwebende Quellport nicht als Zielport für den Re-Key verwendet wird, kann das NAT möglicherweise die Re-Key-Pakete nicht an das richtige Ziel senden.

e) Inkompatibilitäten zwischen überlappenden SPD-Einträgen und NAT. Wenn initiierende Hosts hinter einem NAT ihre Quell-IP-Adressen in Phase 2 Identifikatoren verwenden, können sie überlappende SPD-Einträge mit derselben Responder-IP-Adresse aushandeln. Der Responder könnte dann Pakete über den falschen IPsec-SA senden. Dies tritt auf, weil für den Responder die IPsec-SAs äquivalent erscheinen, da sie zwischen denselben Endpunkten existieren und zum Durchlassen desselben Verkehrs verwendet werden können.

f) Inkompatibilitäten zwischen IPsec SPI-Auswahl und NAT. Da IPsec ESP-Verkehr verschlüsselt und somit für das NAT undurchsichtig ist, muss das NAT Elemente des IP- und IPsec-Headers verwenden, um eingehenden IPsec-Verkehr zu demultiplexen. Die Kombination aus Ziel-IP-Adresse, Sicherheitsprotokoll (AH/ESP) und IPsec SPI wird typischerweise für diesen Zweck verwendet.

Da jedoch die ausgehenden und eingehenden SPIs unabhängig ausgewählt werden, gibt es für das NAT keine Möglichkeit zu bestimmen, welcher eingehende SPI welchem Zielhost entspricht, indem nur ausgehender Verkehr inspiziert wird. Wenn also zwei Hosts hinter dem NAT gleichzeitig versuchen würden, IPsec-SAs am selben Ziel zu erstellen, ist es möglich, dass das NAT die eingehenden IPsec-Pakete an das falsche Ziel liefert.

Beachten Sie, dass dies keine Inkompatibilität mit IPsec an sich ist, sondern vielmehr mit der Art und Weise, wie es typischerweise implementiert wird. Bei sowohl AH als auch ESP gibt der empfangende Host den für eine gegebene SA zu verwendenden SPI an, eine Wahl, die nur für den Empfänger bedeutsam ist. Derzeit identifiziert die Kombination aus Ziel-IP, SPI und Sicherheitsprotokoll (AH, ESP) eindeutig eine Sicherheitsassoziation. Außerdem sind SPI-Werte im Bereich 1-255 für die IANA reserviert und können in Zukunft verwendet werden. Dies bedeutet, dass bei Verhandlungen mit demselben externen Host oder Gateway die internen Hosts hinter demselben NAPT denselben SPI-Wert auswählen können, so dass eine Host-Eingangs-SA (SPI=470, Internal Dest IP=192.168.0.4) und eine andere Host-Eingangs-SA (SPI=470, Internal Dest IP=192.168.0.5) ist. Das empfangende NAPT wird nicht in der Lage sein zu bestimmen, an welchen internen Host ein eingehendes IPsec-Paket mit SPI=470 weitergeleitet werden soll.

Es ist auch möglich, dass der empfangende Host jeder Unicast-Sicherheitsassoziation einen eindeutigen SPI zuweist. In diesem Fall muss die Ziel-IP-Adresse nur überprüft werden, ob sie "eine gültige Unicast-IP für diesen Host" ist, nicht ob sie die spezifische vom sendenden Host verwendete Ziel-IP-Adresse ist. Mit dieser Technik kann dem NA(P)T eine geringe, aber nicht null Wahrscheinlichkeit versichert werden, Pakete an den falschen internen Host weiterzuleiten, selbst wenn zwei oder mehr Hosts SAs mit demselben externen Host einrichten.

Dieser Ansatz ist vollständig rückwärtskompatibel und erfordert nur, dass der spezifische empfangende Host eine Änderung an seiner SPI-Zuweisung und dem IPsec_esp_input()-Code vornimmt. NA(P)T-Geräte können dieses Verhalten jedoch möglicherweise nicht ohne Probleme beim Parsen von IKE-Payloads erkennen. Und ein Host kann immer noch verpflichtet sein, einen SPI im IANA-reservierten Bereich für den zugewiesenen Zweck zu verwenden.

g) Inkompatibilitäten zwischen eingebetteten IP-Adressen und NAT. Da die Payload integritätsgeschützt ist, können alle in IPsec-Paketen enthaltenen IP-Adressen nicht von einem NAT übersetzt werden. Dies macht Application Layer Gateways (ALGs), die in NATs implementiert sind, unwirksam. Protokolle, die eingebettete IP-Adressen verwenden, umfassen FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optional) und viele Spiele. Um dieses Problem zu lösen, ist es notwendig, ALGs auf dem Host oder Sicherheitsgateway zu installieren, die auf Anwendungsverkehr vor der IPsec-Kapselung und nach der IPsec-Entkapselung arbeiten können.

h) Implizite Direktionalität von NA(P)T. NA(P)Ts erfordern oft, dass ein anfängliches ausgehendes Paket durch sie fließt, um einen eingehenden Mapping-Zustand zu erstellen. Direktionalität verbietet die unaufgeforderte Einrichtung von IPsec-SAs zu Hosts hinter dem NA(P)T.

i) Eingangs-SA-Selektor-Verifizierung. Unter der Annahme, dass IKE Phase-2-Selektoren aushandelt, wird die Eingangs-SA-Verarbeitung das entkapselten Paket verwerfen, da [RFC2401] erfordert, dass die Quelladresse eines Pakets mit dem SA-Selektor-Wert übereinstimmt, was die NA(P)T-Verarbeitung eines ESP-Pakets ändern würde.

2.2. NA(P)T-Implementierungsschwächen

In vielen NA(P)Ts vorhandene Implementierungsprobleme umfassen:

j) Unfähigkeit, Nicht-UDP/TCP-Verkehr zu handhaben. Einige NA(P)Ts verwerfen Nicht-UDP/TCP-Verkehr oder führen nur Adress-Übersetzung durch, wenn nur ein Host hinter dem NAT ist. Solche NAPTs können SCTP-, ESP- (Protokoll 50) oder AH- (Protokoll 51) Verkehr nicht aktivieren.

k) NAT-Mapping-Timeouts. NA(P)Ts variieren in der Zeit, für die ein UDP-Mapping in Abwesenheit von Verkehr aufrechterhalten wird. Daher kann selbst wenn IKE-Pakete korrekt übersetzt werden können, der Übersetzungszustand vorzeitig entfernt werden.

l) Unfähigkeit, ausgehende Fragmente zu handhaben. Die meisten NA(P)Ts können ausgehende IP-Pakete ordnungsgemäß fragmentieren, wenn die IP-Paketgröße die MTU auf der ausgehenden Schnittstelle überschreitet. Die ordnungsgemäße Übersetzung ausgehender Pakete, die bereits fragmentiert sind, ist jedoch schwierig, und die meisten NAPTs handhaben dies nicht korrekt. Wie in Abschnitt 6.3 von [RFC3022] erwähnt, können sich die Fragment-Identifikatoren überlappen, wenn zwei Hosts fragmentierte Pakete an dasselbe Ziel senden. Da der Zielhost sich auf den Fragmentierungs-Identifikator und das Fragment-Offset für die Wiederzusammensetzung verlässt, wird das Ergebnis eine Datenbeschädigung sein. Nur wenige NA(P)Ts schützen gegen Identifikator-Kollisionen durch Unterstützung der Identifikator-Übersetzung. Identifikator-Kollisionen sind kein Problem, wenn NATs die Fragmentierung durchführen, da der Fragment-Identifikator nur innerhalb eines Quell-/Ziel-IP-Adresspaares eindeutig sein muss.

Da ein Fragment so klein wie 68 Oktette [RFC791] sein kann, gibt es keine Garantie, dass das erste Fragment einen vollständigen TCP-Header enthält. Daher muss ein NA(P)T, das die TCP-Prüfsumme neu berechnen möchte, möglicherweise ein nachfolgendes Fragment ändern. Da Fragmente neu geordnet werden können und IP-Adressen eingebettet und möglicherweise sogar zwischen Fragmenten aufgeteilt werden können, muss das NA(P)T eine Wiederzusammensetzung durchführen, bevor die Übersetzung abgeschlossen wird. Nur wenige NA(P)Ts unterstützen dies.

m) Unfähigkeit, eingehende Fragmente zu handhaben. Da normalerweise nur das erste Fragment einen vollständigen IP/UDP/SCTP/TCP-Header enthält, müssen NAPTs in der Lage sein, die Übersetzung nur basierend auf der Quell-/Ziel-IP-Adresse und dem Fragment-Identifikator durchzuführen. Da Fragmente neu geordnet werden können, sind die Header zu einem gegebenen Fragment-Identifikator möglicherweise nicht bekannt, wenn ein nachfolgendes Fragment vor dem ersten ankommt, und die Header können zwischen Fragmenten aufgeteilt sein. Infolgedessen muss das NAPT möglicherweise eine Wiederzusammensetzung durchführen, bevor die Übersetzung abgeschlossen wird. Nur wenige NAPTs unterstützen dies. Beachten Sie, dass bei NAT die Quell-/Ziel-IP-Adresse ausreicht, um die Übersetzung zu bestimmen, so dass dies nicht auftritt. Es ist jedoch möglich, dass die IPsec- oder IKE-Header zwischen Fragmenten aufgeteilt werden, so dass eine Wiederzusammensetzung noch erforderlich sein kann.

2.3. Hilfsfunktions-Inkompatibilitäten

Inkompatibilitäten zwischen IPsec und NAT-"Hilfs"-Funktionalität umfassen:

n) Internet Security Association and Key Management Protocol (ISAKMP) Header-Inspektion. Heute versuchen einige NAT-Implementierungen, IKE-Cookies zu verwenden, um eingehenden IKE-Verkehr zu demultiplexen. Wie beim Quellport-Demultiplexing führt IKE-Cookie-Demultiplexing zu Problemen beim Re-Keying, da Phase 1 Re-Keys typischerweise nicht dieselben Cookies wie der frühere Verkehr verwenden.

o) Spezialbehandlung von Port 500. Da einige IKE-Implementierungen nicht in der Lage sind, Nicht-500-UDP-Quellports zu handhaben, übersetzen einige NATs keine Pakete mit einem UDP-Quellport von 500. Dies bedeutet, dass diese NATs auf einen IPsec-Client pro Zielgateway beschränkt sind, es sei denn, sie inspizieren Details des ISAKMP-Headers, um Cookies zu untersuchen, was das oben genannte Problem schafft.

p) ISAKMP-Payload-Inspektion. NA(P)T-Implementierungen, die versuchen, ISAKMP-Payloads zu parsen, können möglicherweise nicht alle Payload-Anordnungskombinationen handhaben oder vendor_id-Payloads für IKE-Optionsverhandlung unterstützen.