Négociation de la fonction NAT-T de IPSec

Ce document décrit comment il est possible de détecter une ou plusieurs translations

d’adresses IP (NATs) entre des pairs IPSec. La négociation de l’encapsulation des
paquets IPSec dans de l’UDP à travers des équipements NAT sera de même traitée.
Ce document s’inspire du draft de l’IETF : draft-ietf-ipsec-nat-t-ike-05.txt.

Table des matières

Négociation de la fonction NAT-T de IPSec.............................................................. 2
Table des matières ................................................................................................. 2
Introduction........................................................................................................... 2
Phase 1 .................................................................................................................. 3
Détection du support NAT-Traversal ................................................................. 3
Détection de la présence de NAT....................................................................... 3
Modification du port IKE ...................................................................................... 5
Quick Mode .......................................................................................................... 7
Négociation de l' encapsulation NAT-Traversal .................................................. 8
Envoi des adresses IP source et destination originelles....................................... 8
Notification Initial Contact .................................................................................. 10
Réstauration des correspondances NAT expirés................................................... 10
Considérations sur la sécurité .............................................................................. 10
Mots clés ............................................................................................................. 11

Introduction
Ce document est divisé en deux parties. La première partie décrit les besoins de la
phase 1 IKE pour le support du NAT-Traversal (NAT-T). Un des besoins consiste à
détecter si l’autre pair IPSec supporte le NAT-T, et s’il y a des équipements NAT
entre les deux pairs.
La deuxième partie décrit la négociation de l’encapsulation des paquets IPSec dans
des paquets UDP dans la phase Quick Mode du protocole IKE. Elle décrit de même
comment transmettre les adresses IP source et destination d’origine, si l’autre pair en
a besoin. Les adresses IP source et destination peuvent être utilisées dans le mode
transport pour la mise à jour incrémentale du checksum TCP/IP, afin de le faire
correspondre après la transformation NAT. Le NAT ne peut pas le faire, car le
checksum TCP/IP se trouve à l’intérieur des paquets UDP contenant les paquets
IPSec.
Le document draft-ietf-ipsec-udp-encaps-06.txt décrit les détails de l’encapsulation
UDP ; le document draft-ietf-ipsec-nat-reqts-04.txt donne des informations et les
motifs généraux sur le NAT-Traversal.

NAT-Traversal et IPsec Page 2

Phase 1
La détection du support pour le NAT-T et la détection du NAT au long du
cheminement des paquets à lieu dans la phase 1 IKE.
Le NAT est supposé déplacer le port UDP de IKE. Les pairs de la communication
doivent être capables de traiter des paquets IKE, dont le port source est différent de
500. Des fois le NAT n’a pas besoin de déplacer le port source. Ceci se vérifie
lorsqu’il y a un seul client IPSec derrière le NAT, soit pour le premier client IPSec
utilisant le port 500 (les autres clients utilisant des ports flottants).
Les pairs doivent répondre à l’adresse IP source du paquet. Ceci signifie de même
que quand le serveur fait un rekeying ou un envoi de notification vers le client, il doit
utiliser la même IP et port qui étaient utilisés lors de la dernière SA IKE (mêmes IP et
ports sources et destination).

Par exemple, quand le serveur envoie un paquet ayant 500 comme port source et
destination, le NAT le modifie pour obtenir un paquets avec 12312 comme port
source et 500 comme port de destination. L’autre pair doit être capable de traiter ce
type de paquets (avec ports source différent de 500), et il doit répondre avec un
paquets avec 500 comme ports source et 12312 comme port de destination. C’est le
NAT qui va ensuite translater le message pour avoir un paquets avec 500 comme port
source et destination.

Détection du support NAT-Traversal

Cette fonctionnalité est déterminé avec l’échange de Vendor Strings. Si supportée les
pairs doivent s’échanger dans les deux premier messages de la phase 1 IKE, le
Vendor ID pour le NAT-T, c’est a dire le hash MD5 du texte suivant:

Quand les deux pairs reçoivent le Vendor ID, la détection du NAT peut continuer.

Détection de la présence de NAT

L'objectif du NAT-D (NAT discovery) est double. Il ne détecte pas seulement la
présence du NAT entre deux pairs, mais il détecte aussi ou le NAT se trouve. Cette
location est importante car le keepalive doit être initié par le pair derrière le NAT.

Pour détecter la présence de NAT, on doit détecter les changements d' adresses IP
pendant le cheminement des paquets. Ceci est fait avec l' envoi du hash des IP et des
ports source et destination entre les pairs. Il n' y pas de NAT quand les deux
correspondants obtiennent le même résultat que l' hachage. Si ce n' est pas le cas,
quelqu'un a modifié l'IP ou les ports et on doit utiliser le NAT-T pour faire passer
IPSec.

Si l'
instigateur de la connexion ne connaît pas son IP (dans le cas, par exemple, de
plusieurs interfaces réseaux et d'
une implémentation ne connaissant pas laquelle est

NAT-Traversal et IPsec Page 3

utilisée pour l'
envoi des paquets), il peut envoyer plusieurs payloads NAT-D. Dans ce
cas le NAT est détecté si, et seulement si, un hachage correspond.

Les hachages sont envoyés comme une série de payloads NAT-D. Chaque payload
contient seulement un hachage, donc dans le cas d'hachages multiples, plusieurs
payloads sont envoyés.

Ces messages sont inclus dans le troisième et quatrième message du main mode et
aggressive mode.
dans le deuxième et troisième message de l'

Le format d'
un paquet NAT-D est le suivant:

! "

#$ # % " & '' ( &

Le type de payload pour le NAT discovery est le 15.

L'
hachage est calculé comme de suite avec l'
algorithme négocié:

#$ # ) #$ #* +, - . +, . - . & /

L'adresse IP est codée avec 4 octets pour l' IPv4 et avec 16 octets pour l' IPv6. Les
ports sont codés avec 2 octets.
Le premier payload NAT-D contient l' IP et le port distants (IP et port de destination
pour les paquets UDP). Lest autres payloads NAT-D contiennent toutes les IP et ports
locales possibles (IP et ports de sources pour les paquets UDP).

S'il n'
existe aucun NAT entre les pairs, le premier payload NAT-D doit correspondre
à au moins un des paquets NAT-D locaux envoyés. Cette règle est valable pour les
deux correspondants. Si le premier check n' aboutisse pas, alors il existe du NAT
dynamique et il faut envoyer un keepalive en premier, comme décrit dans le document
draft-ietf-ipsec-udp-encaps-06.txt.

CKY-I et CKY-R sont les cookies de l' instigateur et de son pair. Il sont utilisés pour
éviter les attaques d'
usurpation d'
adresses IP.

NAT-Traversal et IPsec Page 4

Un exemple de la phase 1 de IKE utilisant le NAT-T avec le main mode est donné
dans le schéma suivant (authentification par signatures):

- 0 0 & '( &

# 1 $1 -

# 1 $1 -

# 1 + 1 01 $2 1 $2

# 1 + 1 &1 $2 1 $2

# 561 - 001 21 -34-

# 561 - 0&1 21 1 -34

Un exemple de la phase 1 de IKE utilisant le NAT-T avec l' aggressive mode est
donné dans le schéma suivant (authentification par signatures):

- 0 0 & '( &

# 1 $1 + 1 01 - 001
-
# 1 $1 + 1 &1 - 0&1 21 1
- 1 $2 1 $2 1 -34
# 561 21 1 $2 1
$2 1 -34-

Le signe '
#'identifie les paquets envoyés vers le port modifié si le NAT est détecté.

Modification du port IKE

IPSec et NAT ensemble, peuvent causer des problèmes. Certains NAT ne changent
pas le port source IKE 500, même s' il y a plusieurs clients derrière le NAT. Il peuvent
aussi mapper les cookies IKE pour démultiplexer le trafic au lieu d' utiliser le port
source.
Ces deux cas sont problématiques pour la transparence générique du NAT, car il est
difficile pour IKE de découvrir les capacités du NAT.
La meilleure approche est de déplacer simplement le trafic IKE du port 500 pour
tromper toutes les NAT intelligents (qui comprennent IPSec) à 4500.

Le cas le plus commun est celui de l'initiateur derrière le NAT. Il doit changer son
port source à 4500, aussitôt le NAT détecté, pour éviter les problèmes liés aux NAT
intelligents.

NAT-Traversal et IPsec Page 5

Dans le main mode, s' initiateur doit changer le port pour l'
il y a du NAT, l' envoi de
ID payload. Il doit mettre les ports UDP source et destination à 4500. Tous les
l'
paquets envoyés à ce pair (notifications d'information comprises) doivent utiliser les
ports 4500. De plus les données IKE doivent maintenant contenir un marqueur non
ESP pour permettre le démultiplexage du trafic comme définit dans le document
draft-ietf-ipsec-udp-encaps-06.txt.

Le format du paquet IKE est maintenant le suivant (authentification par signatures):

- 7 * 881 88/ 9 : &; &< # 51 - 001 21 -34-

Quand le pair correspondant reçoit ce paquet, il le décrypte et processe les différents

payloads. Si tout est correct, il doit mettre à jour son état de sorte que tous les paquets
de réponse soient envoies avec le nouveau port, et si possible à l' IP source du paquet
valide reçu.
Le port est généralement différent de 500 car le NAT va mapper UDP(500,500) à
UDP(X,500) et UDP (4500,4500) à UDP(Y,4500). L' IP est pris des paquets
précédents. Le répondeur doit répondre à UDP(4500,Y).

De façon similaire, si le serveur/répondeur exige un rekey de la phase 1 de la SA,

alors il doit commencer la négociation avec UDP(4500,Y). Toute implémentation
supportant le NAT-T doit supporter les négociations qui débutent sur le port 4500;
ensuite aucun changement devrait être fait dans l'
échange.

Une fois le changement de port effectué, un paquet arrivant sur le port 500 est
considéré comme vieux. Si c' est un paquet d' information et la politique locale le
permette, il peut être utilisé. Si le paquet appartient au mode aggressive ou main il
doit être détruit.

Un exemple de la phase 1 de IKE utilisant le NAT-T avec le main mode et le

changement de ports est donné dans le schéma suivant (authentification par
signatures):

- 0 0 & '( &

7 * 881 88/ # 1 $1 -

7 * 881 / # 1 $1 -

7 * 881 88/ # 1 + 1 01
$2 1 $2
7 * 881 / # 1 + 1 &1
$2 1 $2
7 * 881 88/ # 561
- 001 21 -34-
7 * 881,/ # 561 - 0&1
21 1 -34

NAT-Traversal et IPsec Page 6

 L'algorithme pour l' aggressive mode est très similaire. Après que le NAT a été
détecté, l'
instigateur envoie:

- 7 * 881 88/ 9 : &; &< # 51 21 1 $2 1 $2 1 -34-

Son pair effectue le même processus et si tout se passé bien, il doit mettre à jour ces
ports IKE internes. Il doit aussi répondre à tous les paquets IKE par des paquets
UDP(4500,Y).
Voici un exemple:

- 0 0 & '( &

7 * 881 88/ # 1 $1 + 1
01 - 001 -
7 * 881 / # 1 $1 + 1 &1 - 0&1
21 1 - 1 $2 1 $2 1 -34
7 * 881 88/ # 561 21
1 $2 1 $2 1 -34-

7 * 881 ,/ # 561 ===

ID payload des modes main et aggressive, le

Pendant le changement de port dans l'
port doit être à 0.

Un cas très répandu est celui d' un serveur derrière du NAT effectuant un translation
statique 1-1. Dans ce cas, l'
instigateur doit continuer à changer les deux port à 4500.
Le serveur utilise exactement le même algorithme vu précédemment, même si dans ce
cas, Y est égale à 4500, vu qu'aucune translation d'adresse intervienne.

Un cas différent de changement de port implique une découverte out-of-band du port

à utiliser. Par exemple, si le serveur est derrière un NAT, l' initiateur a besoin de se
connecter en premier. Pour connaître le port à utiliser, il devra contacter d' autres
serveurs. Une fois qu' il connaîtra les ports à utiliser pour passer le NAT, généralement
UDP(Z,4500), il initiera une connexion avec ces paramètres. Ceci est similaire au cas
du rekey de la part du serveur par le fait que les ports à utiliser sont déjà connus et il
n'y a plus le besoin de les changer.
Aussi le premier paquet keepalive est envoyé après le changement de port. Aucun
keepalive est envoyé sur le port 500.

Quick Mode
Une fois la phase 1 terminée, les deux pairs connaissent s' il y a de la translation
d'
adresse. Le choix d' utiliser ou pas le NAT-T est laissé au quick mode. L' usage du
NAT-T est négocié dans les payloads des SA du quick mode. Dans ce mode les deux
parties peuvent s'échanger leurs adresses IP originelles (dans le mode transport) afin
de corriger le checksum TCP/IP après la translation NAT.

NAT-Traversal et IPsec Page 7

Négociation de l'encapsulation NAT-Traversal
La négociation de NAT-T peut être effectuée avec l'
ajout de deux nouveau modes
d'
encapsulation. Ces modes sont:

7 > ('? 2?
7 > ('? 2& '( &

Ce n' est pas normal de proposer les modes tunnel ou transport standards et les
modes tunnel ou transport encapsulés (UDP). Si un NAT existe, les modes
standards ne pourront pas être utilisés. Si le NAT n' existe pas, il serait dommage
d'utiliser de la bande passante en rajoutant une encapsulation UDP. A cause de ça,
initiateur ne doit pas inclure les modes tunnel ou transport standards et les modes
l'
tunnel ou transport encapsulés dans ses proposition.

Envoi des adresses IP source et destination originelles

Pour calculer et fixer le checksum incrémentale de TCP, les deux pairs pourraient
avoir besoin des adresses IP originelles utilisées par leur homologues.
Dans l' adresse original Initiator address, est définie comme étant l'
initiateur, l' IP de
l'
initiateur. L' adresse original Responder address, est définie comme étant l' adresse
IP perçue.
Sur son homologue, le répondeur, l' adresse original Initiator address est définie
comme étant l' adresse IP perçue. L' adresse original Responder address, est définie
comme étant l' IP du répondeur.

Les addresses originelles sont transmises avec les payloads NAT-OA (NAT Original
Address).

Initiator NAT-OA payload est le premier payload et le Responder NAT-OA

L'
payload est le deeuxième.

Exemple 1:

- 0 0 & $2 '( &

- & ?@ &

L'instigateur de la connexion est derrière un NAT et cause avec son pair qui est
disponible publiquement sans NAT. L' instigateur a l'
adresse IP Iaddr tandis que le
répondeur a l'adresse IP Raddr. Le NAT a une adresse IP publique NatPub.

Instigateur:
$2 A$0 ) - &
$2 A$& ) &

Répondeur:
$2 A$0 ) $2 ?@
$2 A$& ) &

NAT-Traversal et IPsec Page 8

Exemple 2:

- 0 0 & $2 $2 '( &

- & ?@ ?@ &

Içi, NAT2 publique Nat2Pub pour le répondeur et renvoie tout trafic de cette adresse
au répondeur.

Instigateur:
$2 A$0 ) - &
$2 A$& ) ?@

Répondeur:
$2 A$0 ) ?@
$2 A$& ) &

Dans le cas du mode transport, les deux pairs doivent s'envoyer l'original Initiator
address et l'
original Responder address.
Pour le mode tunnel, les deux pairs ne doivent pas s'
envoyer leurs adresses d'
origine.

Les payloads NAT-OA sont envoyés dans le premier et le second paquet du quick
mode. L' initiateur doit envoyer le payload si il propose un mode de transport
(transport ou tunnel) encapsulés (UDP). Le répondeur doit envoyer le payload
uniquement si il choisit le mode UDP-Encapsulated-Transport. Par exemple, si
l'
initiateur envoie on payload NAT-OA, mais il propose le mode UDP-Encapsulated-
Transport et le mode UDP-Encapsulated-Tunnel, alors le répondeur choisit le mode
UDP-Encapsulated-Tunnel, et il n' envoie pas de payload NAT-OA en réponse.

Le format du paquet NAT-OA est le suivant:

! "

- 2 (

- B * > '/ & - B & '' * > '/

Le type de payload pour le NAT original address est le 16.

L'ID Type est définit dans la [RFC-2407]. Sont premises seulement des addresses
ID Type doivent être à 0.
IPv4 et IPv6. Les deux champs reserves aprs l'

NAT-Traversal et IPsec Page 9

Voici un exemple de quick mode utilisant un payload NAT-OA:

- 0 0 & '( &

# 51 #$ #* /1 $1 01 1
+ 1 - >01 - >& 1 $2
A$01 $2 A$&

# 51 #$ #* /1 $1 &1 1
+ 1 - >01 - >& 1 $2
A$01 $2 A$&

# 51 #$ #* /

Notification Initial Contact

Les adresses IP et les ports source des messages de notifications Initial-Contact pour
une machine derrière un NAT ne peuvent pas être utilisés pour déterminer quelle SA
devrait être effacée. Il faut utiliser l' ID payload envoyé. Par exemple quand la
notification Initial-Contact est reçue, le pair doit effacer toutes les SA associées qui
ont le même ID payload.

Réstauration des correspondances NAT expirés

Des fois les routeurs NAT décident d' enlever les correspondances qui sont encore
utilisées (par exemple l' intervalle keepalive est trop long, ou le routeur NAT est
redémarré), et les pairs deviennent invisibles. Pour continuer à communiquer avec ces
pairs depuis un poste qui n' est pas lui-même derrière du NAT, on doit utiliser le
dernier paquet authentifié valide et déterminer les adresses et ports à utiliser.
Uun pair qui se trouve derrière un NAT dynamique ne doit pas faire ça, car il risque
d'ouvrir une possibilité d' attaque de déni de service (DoS); de plus il n' est pas
nécessaire car l'
IP et port du pair ne vont pas changer (il n'
est pas derrière du NAT).

Les keepalives ne peuvent pas être utilisés pour cet objectif car il ne sont pas
authentifiés, mais n' importe quel paquet IKE ou ESP authentifié fera l'
affaire et on
pourra détecter si le port ou l'
IP ont changés.

Considérations sur la sécurité

Lorsqu'on effectue des changements fondamentaux d' un protocole de sécurité, on ne
peut pas s'
échapper à un étude des implications sur la sécurité.

Voici certaines observations:

Les propositions IKE révèlent à quiconque le support du NAT-T. Ceci ne

devrait pas être un issue.

NAT-Traversal et IPsec Page 10

 Avec le NAT on ne peut plus se baser sur des mécanismes d' authentification
utilisant les adresse IP. Ceci n'
est pas forcement mauvais, car pour une vrai
sécurité uniquement les mécanismes qui n' utilisent pas les IP devrait être
utilisés. En pratique on ne peut plus utiliser l'authentification utilisant des
secrets partagés avec le main mode car le même secret sera partagé par tous
les utilisateurs derrière le NAT. L' usage de secrets partagés n' est donc pas
recommandé.

Comme les adresses IP sont codes sur 32 octets, il est possible qu' un attaquant,
avec de la force brute pour trouver le bon hash, trouve la classe d' adresses
utilisé derrière le NAT. Les ports utilisés sont généralement à 500 et les
cookies peuvent être extraites des paquets. Ceci limite le calculs à 232. Si de
plus on utilise des classes privées (ce qui devrait être le cas), alors le nombre
de calculs pour trouver la bonne adresse IP descendent à 224+2*(216).

Ni le payload NAT-D, ni le Vendor ID sont authentifiés dans le mode main

ou agressive. On attaquant peut donc effacer, modifier ou rajouter ces
payloads causant des attaque de déni de service. Il est aussi possible de forcer
le mode d' encapsulation UDP au lieu d' utiliser les modes directes afin de
consommer plu de bande passante.

L'envoi de l' adresse IP source original dans le quick mode, révèle l' IP caché
par le NAT à l' autre pair. Dans ce cas on est déjà authentifié et l'
envoi de l'
IP
originale est requis uniquement avec le mode transport.

La mise à jour d' une SA IKE, ou des port pour l' encapsulation ESP dans de
l'
UDP, pour chaque paquet authentifié, peut causer un attaque de déni de
service si un attaquant peut écouter et changer l' ordre des paquets. Par
exemple un hacker sniffe un paquet authentifié d' une machine derrière un
NAT, modifie l' IP, le port UDP source ou destination de ce paquet, et il
l'
envoie vers le pair avant le vrai paquet arrive. Le pair qui n'
est pas derrière
un NAT mettra à jour ses IP et ports et envoiera ses paquets à une fausse
destination. Cette situation est fixé immédiatement après que l' attaquant
stoppe la modifications des paquets. Les implémentations devraient auditer
cet évènement à chaque fois qu' il survienne, car dans des cas normaux il ne
devrai pas apparaître très souvent.

Mots clés
IKE Internet Key Exchange Protocol
NAT-T Traversal Network Address Translation
NAT-D Discovery Network Address Translation
NAT-OA Original Address Network Address Translation
Quick Mode Deuxième phase du protocole IKE
SA Security Association

NAT-Traversal et IPsec Page 11