3. Exigences pour la compatibilité IPsec-NAT
3. Exigences pour la compatibilité IPsec-NAT
L'objectif d'une solution de compatibilité IPsec-NAT est d'élargir la gamme de fonctionnalités IPsec utilisables au-delà de celle disponible dans la solution de mode tunnel IPsec compatible NAT décrite dans la section 2.3.
Lors de l'évaluation d'une solution à l'incompatibilité IPsec-NAT, les critères suivants doivent être gardés à l'esprit:
Déploiement
Étant donné qu'IPv6 résoudra les problèmes de pénurie d'adresses qui conduisent fréquemment à l'utilisation de NA(P)T avec IPv4, le problème de compatibilité IPsec-NAT est un problème transitoire qui doit être résolu dans le délai précédant le déploiement généralisé d'IPv6. Par conséquent, pour être utile, une solution de compatibilité IPsec-NAT DOIT être déployable sur une échelle de temps plus courte qu'IPv6.
Étant donné que le déploiement d'IPv6 nécessite des modifications des routeurs ainsi que des hôtes, une solution potentielle de compatibilité IPsec-NAT, qui nécessite des modifications à la fois des routeurs et des hôtes, sera déployable sur approximativement la même échelle de temps qu'IPv6. Ainsi, une solution de compatibilité IPsec-NAT DEVRAIT nécessiter des modifications uniquement des hôtes, et non des routeurs.
Entre autres choses, cela implique que la communication entre l'hôte et le NA(P)T NE DEVRAIT PAS être requise par une solution de compatibilité IPsec-NAT, car cela nécessiterait des modifications des NA(P)T, et des tests d'interopérabilité entre les implémentations d'hôte et de NA(P)T. Afin de permettre un déploiement à court terme, il est nécessaire que la solution fonctionne avec les produits de routeur et NA(P)T existants dans l'infrastructure déployée.
Compatibilité des protocoles
Une solution de traversée NAT IPsec n'est pas censée résoudre les problèmes avec les protocoles qui ne peuvent pas traverser NA(P)T lorsqu'ils ne sont pas sécurisés avec IPsec. Par conséquent, des ALG peuvent encore être nécessaires pour certains protocoles, même lorsqu'une solution de traversée NAT IPsec est disponible.
Sécurité
Étant donné que la directionnalité NA(P)T remplit une fonction de sécurité, les solutions de traversée IPsec NA(P)T ne doivent pas permettre au trafic IPsec ou IKE entrant arbitraire de n'importe quelle adresse IP d'être reçu par un hôte derrière le NA(P)T, bien que l'état de mappage doive être maintenu une fois que la communication IKE et IPsec bidirectionnelle est établie.
Scénario de télétravailleur
Étant donné que l'une des principales utilisations d'IPsec est l'accès à distance aux intranets d'entreprise, une solution de traversée NA(P)T DOIT prendre en charge la traversée NA(P)T, soit via le mode tunnel IPsec, soit L2TP sur le mode transport IPsec [RFC3193]. Cela inclut la prise en charge de la traversée de plus d'un NA(P)T entre le client distant et la passerelle VPN.
Le client peut avoir une adresse routable et la passerelle VPN peut être derrière au moins un NA(P)T, ou alternativement, le client et la passerelle VPN peuvent tous deux être derrière un ou plusieurs NA(P)T. Les télétravailleurs peuvent utiliser la même adresse IP privée, chacun derrière son propre NA(P)T, ou de nombreux télétravailleurs peuvent résider sur un réseau privé derrière le même NA(P)T, chacun avec sa propre adresse privée unique, se connectant à la même passerelle VPN. Étant donné qu'IKE utilise le port UDP 500 comme destination, il n'est pas nécessaire d'activer plusieurs passerelles VPN fonctionnant derrière la même adresse IP externe.
Scénario passerelle à passerelle
Dans un scénario passerelle-passerelle, un réseau adressé en privé (DMZ) peut être inséré entre le réseau d'entreprise et Internet. Dans cette conception, les passerelles de sécurité IPsec connectant des portions du réseau d'entreprise peuvent résider dans la DMZ et avoir des adresses privées sur leurs interfaces externes (DMZ). Un NA(P)T connecte le réseau DMZ à Internet.
Scénario de bout en bout
Une solution NAT-IPsec DOIT permettre une communication TCP/IP hôte-hôte sécurisée via IPsec, ainsi que des communications hôte-passerelle. Un hôte sur un réseau privé DOIT être capable d'établir une ou plusieurs connexions TCP protégées par IPsec ou sessions UDP vers un autre hôte avec un ou plusieurs NA(P)T entre eux. Par exemple, des NA(P)T peuvent être déployés dans des succursales se connectant au réseau d'entreprise, avec un NA(P)T supplémentaire connectant le réseau d'entreprise à Internet. De même, des NA(P)T peuvent être déployés dans un LAN ou WAN de réseau d'entreprise pour connecter des clients sans fil ou distants au réseau d'entreprise. Cela peut nécessiter un traitement spécial du trafic TCP et UDP sur l'hôte.
L'établissement de connexions SCTP vers un autre hôte avec un ou plusieurs NA(P)T entre eux peut présenter des défis particuliers. SCTP prend en charge le multi-homing. Si plus d'une adresse IP est utilisée, ces adresses sont transportées dans le cadre du paquet SCTP lors de la configuration de l'association (dans les morceaux INIT et INIT-ACK). Si seuls des points de terminaison SCTP à domicile unique sont utilisés, [RFC2960] section 3.3.2.1 déclare:
Notez que ne pas utiliser de paramètres d'adresse IP dans l'INIT et
l'INIT-ACK est une alternative pour rendre une association plus susceptible
de fonctionner à travers un boîtier NAT.
Cela implique que les adresses IP ne doivent pas être mises dans le paquet SCTP sauf si nécessaire. Si des NAT sont présents et que des adresses IP sont incluses, la configuration de l'association échouera. Récemment, [AddIP] a été proposé, ce qui permet la modification de l'adresse IP une fois qu'une association est établie. Les messages de modification ont également des adresses IP dans le paquet SCTP, et seront donc affectés négativement par les NAT.
Compatibilité avec les pare-feu
Étant donné que les pare-feu sont largement déployés, une solution de compatibilité NAT-IPsec DOIT permettre à un administrateur de pare-feu de créer une ou des règles d'accès simples et statiques pour permettre ou refuser le trafic de traversée IKE et IPsec NA(P)T. Cela implique, par exemple, que l'allocation dynamique des ports de destination IKE ou IPsec doit être évitée.
Passage à l'échelle
Une solution de compatibilité IPsec-NAT devrait être capable d'être déployée dans une installation composée de milliers de télétravailleurs. Dans cette situation, il n'est pas possible de supposer qu'un seul hôte communique avec une destination donnée à la fois. Ainsi, une solution de compatibilité IPsec-NAT DOIT résoudre le problème des entrées SPD qui se chevauchent et du démultiplexage des paquets entrants.
Support de mode
Au minimum, une solution de compatibilité IPsec-NAT DOIT prendre en charge la traversée des modes IKE et IPsec requis pour la prise en charge dans [RFC2409] et [RFC2401]. Par exemple, une passerelle IPsec DOIT prendre en charge la traversée du mode tunnel ESP NA(P)T, et un hôte IPsec DOIT prendre en charge la traversée du mode transport IPsec NA(P)T. Le but d'AH est de protéger les champs immuables dans l'en-tête IP (y compris les adresses), et NA(P)T traduit les adresses, invalidant la vérification d'intégrité AH. En conséquence, NA(P)T et AH sont fondamentalement incompatibles et il n'y a aucune exigence qu'une solution de compatibilité IPsec-NAT prenne en charge le mode transport ou tunnel AH.
Compatibilité descendante et interopérabilité
Une solution de compatibilité IPsec-NAT DOIT être interopérable avec les implémentations IKE/IPsec existantes, afin qu'elles puissent communiquer lorsqu'aucun NA(P)T n'est présent. Cela implique qu'une solution de compatibilité IPsec-NAT DOIT être rétrocompatible avec IPsec tel que défini dans [RFC2401] et IKE tel que défini dans [RFC2409]. De plus, elle DEVRAIT être capable de détecter la présence d'un NA(P)T, de sorte que la prise en charge de la traversée NA(P)T ne soit utilisée que lorsque cela est nécessaire. Cela implique qu'il DOIT être possible de déterminer qu'une implémentation IKE existante ne prend pas en charge la traversée NA(P)T, de sorte qu'une conversation IKE standard puisse se produire, comme décrit dans [RFC2407], [RFC2408] et [RFC2409]. Notez que bien que cela implique l'initiation d'IKE vers le port 500, il n'y a pas d'exigence pour un port source spécifique, de sorte que le port source UDP 500 peut ou non être utilisé.
Sécurité
Une solution de compatibilité IPsec-NAT NE DOIT PAS introduire de vulnérabilités de sécurité IKE ou IPsec supplémentaires. Par exemple, une solution acceptable doit démontrer qu'elle n'introduit pas de nouvelles vulnérabilités de déni de service ou d'usurpation. IKE DOIT être autorisé à re-clé de manière bidirectionnelle comme décrit dans [RFC2408].