Aller au contenu principal

2.23. NAT Traversal (Traversée NAT)

2.23. NAT Traversal (Traversée NAT)​

Les passerelles de traduction d'adresse réseau (NAT) sont controversées. Cette section décrit brièvement ce qu'elles sont et comment elles affectent probablement le trafic IKE. Beaucoup pensent que les NAT sont nuisibles et qu'il ne faut pas adapter les protocoles pour mieux les accommoder. IKEv2 définit en effet des règles de traitement peu intuitives pour que les NAT fonctionnent plus souvent.

Les NAT existent surtout à cause du manque d'adresses IPv4. Les nœuds « derrière » un NAT n'ont pas d'adresses globalement uniques; elles sont uniques dans le réseau derrière le NAT mais souvent réutilisées derrière d'autres NAT. Généralement, les nœuds derrière un NAT communiquent avec d'autres derrière le même NAT et avec des nœuds à adresses globalement uniques, mais pas avec des nœuds derrière d'autres NAT (exceptions possibles). Lorsqu'ils se connectent à Internet, la passerelle NAT « traduit » l'adresse source IP vers une adresse routable vers la passerelle. Les messages Internet vers la passerelle voient leur destination « traduite » vers l'adresse interne qui route vers le bon nœud terminal.

Les NAT visent la « transparence » pour les extrémités. Ni le logiciel derrière le NAT ni le nœud Internet n'a besoin d'être modifié. Cette transparence est plus difficile pour certains protocoles. Les protocoles incluant des adresses IP des extrémités dans la charge échouent si la passerelle NAT ne comprend pas le protocole et ne modifie pas les références internes et les en-têtes. Une telle connaissance est intrinsèquement peu fiable, viole la couche réseau et cause souvent des problèmes subtils.

Ouvrir une connexion IPsec à travers un NAT pose des problèmes particuliers. En mode transport, modifier les adresses IP casse les sommes de contrôle et le NAT ne peut pas les corriger car elles sont protégées cryptographiquement. Même en mode tunnel, la traduction transparente des adresses des paquets AH et ESP exige une logique spéciale au NAT, heuristique et peu fiable. IKEv2 utilise donc l'encapsulation UDP d'IKE et d'ESP. C'est un peu moins efficace mais plus facile pour les NAT. Les pare-feu peuvent aussi n'autoriser que le trafic IPsec encapsulé UDP.

Les NAT traduisent souvent aussi les ports TCP et UDP et utilisent les ports des paquets entrants pour choisir le nœud interne. Ainsi, même si IKE DOIT utiliser les ports UDP 500 ou 4500, IKE DOIT être accepté depuis n'importe quel port et les réponses DOIVENT être renvoyées au port d'origine, car les ports peuvent changer en traversant les NAT. De même, les adresses des extrémités IKE ne sont généralement pas dans les charges IKE car elles sont protégées et ne pourraient pas être modifiées par les NAT.

Le port 4500 est réservé à ESP et IKE encapsulés UDP. Un extrémité IPsec découvrant un NAT (voir ci-dessous) DOIT envoyer tout le trafic ultérieur depuis le port 4500, que les NAT ne devraient pas traiter spécialement comme le port 500.

L'initiateur PEUT utiliser le 4500 pour IKE et ESP dès le début, NAT ou non. Si une extrémité utilise 4500, l'envoi d'ESP encapsulé UDP n'est pas requis mais la réception d'ESP encapsulé UDP l'est. L'encapsulation UDP NE DOIT PAS se faire sur le port 500. Si le NAT-T est supporté (échange NAT_DETECTION_*_IP pendant IKE_SA_INIT), tous les équipements DOIVENT pouvoir recevoir et traiter à tout moment ESP encapsulé UDP et non encapsulé. Chaque extrémité choisit indépendamment l'encapsulation ESP. Si un NAT est détecté, les deux DOIVENT utiliser l'encapsulation UDP pour ESP.

Les exigences [NATREQ] pour le support de traversée NAT sont listées ci-dessous. Le support est optionnel. Dans cette section seulement, MUST ne s'applique qu'aux implémentations qui supportent la traversée NAT.

  • L'initiateur et le répondant IKE DOIVENT inclure dans IKE_SA_INIT des Notify NAT_DETECTION_SOURCE_IP et NAT_DETECTION_DESTINATION_IP. Elles détectent la présence de NAT et quel extrémité est derrière le NAT. Elles se placent juste après Ni et Nr (avant CERTREQ optionnel).

  • Les données NAT_DETECTION_SOURCE_IP sont un digest SHA-1 des SPI (ordre d'apparition dans l'en-tête), de l'adresse IP et du port d'envoi.

    Il PEUT y avoir plusieurs NAT_DETECTION_SOURCE_IP si l'expéditeur ignore quelle interface enverra le paquet.

  • Les données NAT_DETECTION_DESTINATION_IP sont un digest SHA-1 des SPI, de l'adresse IP et du port de destination du paquet.

  • Le destinataire PEUT comparer à un hachage SHA-1 des SPI, adresse IP source ou destination et port; en cas de divergence, il DEVRAIT activer la traversée NAT. Si le hachage SOURCE ne correspond à aucune charge SOURCE reçue, le destinataire PEUT rejeter si pas de support NAT-T. Si DESTINATION ne correspond pas, le système recevant est derrière un NAT et DEVRAIT envoyer des keepalives [UDPENCAPS]; ou PEUT rejeter sans NAT-T.

  • Si aucune charge NAT_DETECTION_SOURCE_IP reçue ne correspond à l'IP/port source attendus depuis l'en-tête IP du paquet, l'expéditeur des charges est derrière un NAT (la source a été remplacée en route). Le récepteur devrait alors permettre la mise à jour dynamique de l'adresse de l'autre système (voir plus loin).

  • L'initiateur IKE DOIT vérifier NAT_DETECTION_SOURCE_IP ou DESTINATION_IP si présentes; si elles ne correspondent pas aux adresses externes du paquet, il DOIT tunneliser tous les IKE et ESP futurs de cette IKE SA sur UDP 4500.

  • Pour tunneliser IKE sur 4500: préfixer l'en-tête IKE de quatre octets nuls, puis UDP. Pour ESP: l'en-tête ESP suit immédiatement UDP. Les quatre premiers octets d'ESP sont le SPI, jamais zéro valide, donc IKE et ESP sont distinguables.

  • Les implémentations DOIVENT traiter l'ESP UDP encapsulé reçu même sans NAT détecté.

  • Les adresses IP source et destination d'origine pour la correction des sommes TCP/UDP en mode transport ([UDPENCAPS]) proviennent des sélecteurs de trafic de l'échange. En traversée NAT mode transport, les TS DOIVENT contenir exactement une adresse IP, utilisée comme adresse d'origine. Voir 2.23.1.

  • Un NAT peut supprimer des mappings encore actifs (keepalive trop long, reboot). Un hôte le voit s'il reçoit un paquet à intégrité valide mais avec port et/ou adresse différents de ceux associés à la SA. Un hôte sans autre récupération (MOBIKE [MOBIKE]) et pas derrière un NAT DEVRAIT envoyer tous les paquets (retransmissions incluses) vers l'IP/port du paquet validé et DEVRAIT mémoriser cette nouvelle combinaison pour la SA. Un hôte derrière un NAT NE DEVRAIT PAS faire cette mise à jour dynamique si port/adresse diffèrent (risque DoS). La mise à jour dynamique ne doit répondre qu'à un nouveau paquet (sinon rejeu d'anciens paquets). Elle n'est sûre qu'avec protection anti-rejeu. Avec MOBIKE, cette mise à jour interfère avec la récupération MOBIKE; voir [MOBIKE] 3.8.

2.23.1. Transport Mode NAT Traversal (Mode transport et traversée NAT)​

Le mode transport avec traversée NAT exige un traitement spécial des sélecteurs de trafic IKEv2. Schéma complet:

+------+        +------+            +------+         +------+
|Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
|node  |<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

(Les autres scénarios simplifient ce cas.)

Deux NAT: A dynamique (IP1→IPN1), B statique (connexions vers IPN2 mappées vers IP2 du serveur). Le client joint le serveur via IPN2. B n'a pas besoin d'être statique mais le client doit connaître l'adresse externe de B (IPN2), par configuration ou autre protocole (DNS), hors périmètre IKEv2.

Client et serveur utilisent le mode transport pour le trafic client→serveur.

À la création IKEv2 SA et Child SA, un paquet déclencheur peut avoir source IP1 et destination IPN2. PAD et SPD doivent correspondre. En mode transport, les TS et l'IP externe IKE sont les mêmes adresses. TSi et TSr DOIVENT avoir exactement une adresse IP chacun; plusieurs TS sont possibles pour plusieurs plages de ports, mais toutes les TSi utilisent IP1-IP1 et toutes les TSr IPN2-IPN2. Les premiers TSi/TSr DEVRAIENT être très spécifiques (protocole, ports du paquet déclencheur).

NAT A remplace la source IKE IP1→IPN1, NAT B la destination IPN2→IP2; au serveur les TS restent ceux du client mais l'IP du paquet IKE est IPN1 et IP2.

Le serveur consulte d'habitude le PAD [IPSECARCH] RFC 4301 par ID puis le SPD par TS. IP1 n'a pas de sens pour le serveur en mode transport pour la recherche; mais il ignore si le mode transport est permis avant d'avoir une entrée SPD correspondante.

Le serveur vérifie d'abord que l'initiateur a demandé le mode transport, puis substitue les adresses dans les TS. Il stocke les anciennes adresses TS pour la correction incrémentale des sommes (TSi = source d'origine, TSr = destination d'origine). Si l'autre extrémité est derrière un NAT, il remplace l'IP dans TSi par la source du paquet IKE reçu (IP1→IPN1). Si le serveur est derrière un NAT, il remplace l'IP dans TSr par la destination du paquet reçu (IPN2→IP2).

Après substitution, TS et adresses UDP IKE coïncident; recherche SPD sur les nouveaux TS. Si entrée trouvée et mode transport autorisé, on l'utilise. Si entrée trouvée mais pas de transport, le serveur PEUT annuler la substitution et refaire la recherche SPD avec les TS d'origine; si la seconde réussit, création d'une SA tunnel avec les vrais TS de l'autre extrémité.

Cette substitution est nécessaire car le SPD est consulté avec les adresses vues par l'hôte local. Les entrées SAD pour sortie de tunnel et paquets retour utilisent les adresses vues par la pile OS.

Souvent le SPD serveur a des entrées joker; on peut aussi différencier par adresse externe de NAT connue.

Après SPD, rétrécissement des TS selon l'entrée, toujours avec TS substitués; réponse avec IPN1 et IP2; on peut encore rétrécir protocole/ports. La SAD Child SA utilise IPN1 et IP2 vus par le serveur.

Le client, à la réponse Child SA, stocke les TS retournés comme adresses source/destination d'origine, remplace les IP par celles de l'en-tête IKE (IPN1→IP1, IP2→IPN2), puis vérifie la SA et installe la SAD.

Résumé des règles mode transport:

Client proposant le mode transport:

  • TSi: exactement une adresse IP, DOIT égaler la source de l'IKE SA.

  • TSr: exactement une adresse IP, DOIT égaler la destination de l'IKE SA.

  • Premiers TSi/TSr DEVRAIENT inclure protocole et ports précis (paquet déclencheur).

  • Plusieurs TSi/TSr PEUVENT exister.

  • Si mode transport choisi (USE_TRANSPORT_MODE dans la réponse):

    • Conserver les TS d'origine comme adresses reçues.

    • Si serveur derrière NAT: remplacer l'IP des TSr par l'adresse distante de l'IKE SA.

    • Si client derrière NAT: remplacer l'IP des TSi par l'adresse locale de l'IKE SA.

    • Substitutions avant toute autre utilisation que le stockage d'origine (vérification du rétrécissement, création SAD, etc.).

Répondant (proposition transport par le client):

  • Stocker les IP TS d'origine pour annulation éventuelle, adresses « réelles » [UDPENCAPS], correction TCP/UDP.

  • Client derrière NAT: TSi → adresse distante IKE SA.

  • Serveur derrière NAT: TSr → adresse locale IKE SA.

  • Recherche PAD/SPD avec ID et TS substitués.

  • Pas d'entrée SPD ou transport non autorisé: annuler substitutions, recherche avec ID et TS d'origine incluant entrées tunnel (repli tunnel).

  • Si entrée transport trouvée: rétrécissement normal sur TS substitués et entrée SPD; utiliser les TS résultants pour SAD et réponse au client.

Dernière mise à jour le