4. Solutions existantes

4.1. Mode tunnel IPsec

Dans un ensemble limité de circonstances, il est possible pour une implémentation en mode tunnel IPsec, telle que celle décrite dans [DHCP], de traverser NA(P)T avec succès. Cependant, les exigences pour une traversée réussie sont suffisamment limitées pour qu'une solution plus générale soit nécessaire:

IPsec ESP. Les tunnels IPsec ESP ne couvrent pas l'en-tête IP externe dans la vérification d'intégrité du message, et ne souffriront donc pas d'invalidation des données d'authentification en raison de la traduction d'adresse. Les tunnels IPsec n'ont pas non plus besoin de se préoccuper de l'invalidation de la somme de contrôle.
Pas de validation d'adresse. La plupart des implémentations actuelles en mode tunnel IPsec n'effectuent pas de validation d'adresse source, de sorte que les incompatibilités entre les identifiants IKE et les adresses source ne seront pas détectées. Cela introduit des vulnérabilités de sécurité comme décrit dans la section 5.
Entrées SPD "Any to Any". Les clients en mode tunnel IPsec peuvent négocier des SPD "any to any", qui ne sont pas invalidés par la traduction d'adresse. Cela empêche effectivement l'utilisation des SPD pour le filtrage du trafic de tunnel autorisé.
Fonctionnement à client unique. Avec un seul client derrière un NAT, il n'y a aucun risque de chevauchement des SPD. Étant donné que le NAT n'aura pas besoin d'arbitrer entre des clients concurrents, il n'y a pas non plus de risque de mauvaise traduction de re-clé, ou de démultiplexage incorrect de SPI ou de cookie entrant.
Pas de fragmentation. Lorsque l'authentification par certificat est utilisée, la fragmentation IKE peut être rencontrée. Cela peut se produire lorsque des chaînes de certificats sont utilisées, ou même lors de l'échange d'un seul certificat si la taille de clé, ou la taille d'autres champs de certificat (tels que le nom distinctif et d'autres extensions), est suffisamment grande. Cependant, lorsque des clés pré-partagées sont utilisées pour l'authentification, la fragmentation est moins probable.
Sessions actives. La plupart des sessions VPN maintiennent généralement un flux de trafic continu pendant leur durée de vie, de sorte que les mappages de ports UDP sont moins susceptibles d'être supprimés en raison d'inactivité.

4.2. RSIP

RSIP, décrit dans [RSIP] et [RSIPFrame], inclut des mécanismes pour la traversée IPsec, comme décrit dans [RSIPsec]. En permettant la communication hôte-NA(P)T, RSIP résout les problèmes de démultiplexage SPI IPsec, ainsi que le chevauchement SPD. Il convient donc à une utilisation dans les entreprises, ainsi que dans les scénarios de réseau domestique. En permettant aux hôtes derrière un NAT de partager l'adresse IP externe du NA(P)T (la passerelle RSIP), cette approche est compatible avec les protocoles incluant des adresses IP intégrées.

En tunnelisant les paquets IKE et IPsec, RSIP évite les modifications des protocoles IKE et IPsec, bien que des modifications majeures soient nécessaires pour les implémentations IKE et IPsec de l'hôte afin de les adapter à la compatibilité RSIP. Il est donc compatible avec tous les protocoles existants (AH/ESP) et modes (transport et tunnel).

Afin de gérer le démultiplexage des re-clés IKE, RSIP nécessite le flottement du port source IKE, ainsi que le re-keying vers le port flotté. En conséquence, l'interopérabilité avec les implémentations IPsec existantes n'est pas assurée.

RSIP ne satisfait pas les exigences de déploiement pour une solution de compatibilité IPsec-NAT car un hôte compatible RSIP nécessite une passerelle compatible RSIP correspondante afin d'établir un SA IPsec avec un autre hôte. Étant donné que RSIP nécessite des modifications uniquement des clients et des routeurs et non des serveurs, il est moins difficile à déployer qu'IPv6. Cependant, pour les fournisseurs, l'implémentation de RSIP nécessite une fraction substantielle des ressources requises pour la prise en charge d'IPv6. Ainsi, RSIP résout un problème "transitoire" sur une échelle de temps à long terme, ce qui n'est pas utile.

4.3. 6to4

6to4, comme décrit dans [RFC3056] peut former la base d'une solution de traversée IPsec-NAT. Dans cette approche, le NAT fournit aux hôtes IPv6 un préfixe IPv6 dérivé de l'adresse IPv4 externe du NAT, et encapsule les paquets IPv6 dans IPv4 pour la transmission vers d'autres hôtes 6to4 ou relais 6to4. Cela permet à un hôte IPv6 utilisant IPsec de communiquer librement avec d'autres hôtes dans les nuages IPv6 ou 6to4.

Bien que 6to4 soit une solution élégante et robuste lorsqu'un seul NA(P)T sépare un client et une passerelle VPN, elle n'est pas universellement applicable. Étant donné que 6to4 nécessite l'attribution d'une adresse IPv4 routable au NA(P)T afin de permettre la formation d'un préfixe IPv6, elle n'est pas utilisable lorsque plusieurs NA(P)T existent entre le client et la passerelle VPN. Par exemple, un NA(P)T avec une adresse privée sur son interface externe ne peut pas être utilisé par les clients derrière lui pour obtenir un préfixe IPv6 via 6to4.

Bien que 6to4 nécessite peu de support supplémentaire des hôtes qui prennent déjà en charge IPv6, elle nécessite des modifications des NAT, qui doivent être mis à niveau pour prendre en charge 6to4. En conséquence, 6to4 peut ne pas convenir au déploiement à court terme.