Negociation de La Fonction NAT T de IPSec

N/I-Ircver:c|
Lc :c|uIicn lFSec cu
prcL|me N/I

Eco|e d'|rgr|eurs du Carlor de vaud
lrsl|lul de T|corrur|cal|ors

Auleur: 6hr|st|an Tettamant|
lnsr|rur oe re|ecommun|car|ons 0nr|sr|an Terramanr|

NAT-Traversal et IPsec Page 2

Ngociation de la fonction NAT-T de IPSec
Ce document dcrit comment il est possible de dtecter une ou plusieurs translations
dadresses IP (NATs) entre des pairs IPSec. La ngociation de lencapsulation des
paquets IPSec dans de lUDP travers des quipements NAT sera de mme traite.
Ce document sinspire du draft de lIETF : draft-ietf-ipsec-nat-t-ike-05.txt.

Table des matires
Ngociation de la fonction NAT-T de IPSec.............................................................. 2
Table des matires................................................................................................. 2
Introduction........................................................................................................... 2
Phase 1.................................................................................................................. 3
Dtection du support NAT-Traversal ................................................................. 3
Dtection de la prsence de NAT....................................................................... 3
Modification du port IKE ...................................................................................... 5
Quick Mode .......................................................................................................... 7
Ngociation de l'encapsulation NAT-Traversal .................................................. 8
Envoi des adresses IP source et destination originelles....................................... 8
Notification Initial Contact .................................................................................. 10
Rstauration des correspondances NAT expirs................................................... 10
Considrations sur la scurit .............................................................................. 10
Mots cls............................................................................................................. 11

Introduction
Ce document est divis en deux parties. La premire partie dcrit les besoins de la
phase 1 IKE pour le support du NAT-Traversal (NAT-T). Un des besoins consiste
dtecter si lautre pair IPSec supporte le NAT-T, et sil y a des quipements NAT
entre les deux pairs.
La deuxime partie dcrit la ngociation de lencapsulation des paquets IPSec dans
des paquets UDP dans la phase Quick Mode du protocole IKE. Elle dcrit de mme
comment transmettre les adresses IP source et destination dorigine, si lautre pair en
a besoin. Les adresses IP source et destination peuvent tre utilises dans le mode
transport pour la mise jour incrmentale du checksum TCP/IP, afin de le faire
correspondre aprs la transformation NAT. Le NAT ne peut pas le faire, car le
checksum TCP/IP se trouve lintrieur des paquets UDP contenant les paquets
IPSec.
Le document draft-ietf-ipsec-udp-encaps-06.txt dcrit les dtails de lencapsulation
UDP ; le document draft-ietf-ipsec-nat-reqts-04.txt donne des informations et les
motifs gnraux sur le NAT-Traversal.



Phase 1
La dtection du support pour le NAT-T et la dtection du NAT au long du
cheminement des paquets lieu dans la phase 1 IKE.
Le NAT est suppos dplacer le port UDP de IKE. Les pairs de la communication
doivent tre capables de traiter des paquets IKE, dont le port source est diffrent de
500. Des fois le NAT na pas besoin de dplacer le port source. Ceci se vrifie
lorsquil y a un seul client IPSec derrire le NAT, soit pour le premier client IPSec
utilisant le port 500 (les autres clients utilisant des ports flottants).
Les pairs doivent rpondre ladresse IP source du paquet. Ceci signifie de mme
que quand le serveur fait un rekeying ou un envoi de notification vers le client, il doit
utiliser la mme IP et port qui taient utiliss lors de la dernire SA IKE (mmes 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. Lautre pair doit tre capable de traiter ce
type de paquets (avec ports source diffrent de 500), et il doit rpondre avec un
paquets avec 500 comme ports source et 12312 comme port de destination. Cest le
NAT qui va ensuite translater le message pour avoir un paquets avec 500 comme port
source et destination.

Dtection du support NAT-Traversal
Cette fonctionnalit est dtermin avec lchange de Vendor Strings. Si supporte les
pairs doivent schanger dans les deux premier messages de la phase 1 IKE, le
Vendor ID pour le NAT-T, cest a dire le hash MD5 du texte suivant:

"kIC XXXX" - |"XXXXXXXX XXXXXXXX XXXXXXXXX XXXXXXXX"]

Quand les deux pairs reoivent le Vendor ID, la dtection du NAT peut continuer.

Dtection de la prsence de NAT
L'objectif du NAT-D (NAT discovery) est double. Il ne dtecte pas seulement la
prsence du NAT entre deux pairs, mais il dtecte aussi ou le NAT se trouve. Cette
location est importante car le keepalive doit tre initi par le pair derrire le NAT.

Pour dtecter la prsence de NAT, on doit dtecter 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 mme rsultat 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 connat pas son IP (dans le cas, par exemple, de
plusieurs interfaces rseaux et d'une implmentation ne connaissant pas laquelle est


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

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

Ces messages sont inclus dans le troisime et quatrime message du main mode et
dans le deuxime et troisime message de l'aggressive mode.

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

1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7

Nexf Pay1oad

kL5LkvLD

Pay1oad 1engfh

hA5h of fhe addess and pof

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

L'hachage est calcul comme de suite avec l'algorithme ngoci:

hA5h = hA5h{CkY-l | CkY-k | lP | Pof}

L'adresse IP est code avec 4 octets pour l'IPv4 et avec 16 octets pour l'IPv6. Les
ports sont cods 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 envoys. Cette rgle 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 dcrit 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 utiliss pour
viter les attaques d'usurpation d'adresses IP.



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

ln1f1afo kesponde

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

ln1f1afo kesponde

Le signe '#' identifie les paquets envoys vers le port modifi si le NAT est dtect.

Modification du port IKE
IPSec et NAT ensemble, peuvent causer des problmes. Certains NAT ne changent
pas le port source IKE 500, mme s'il y a plusieurs clients derrire le NAT. Il peuvent
aussi mapper les cookies IKE pour dmultiplexer le trafic au lieu d'utiliser le port
source.
Ces deux cas sont problmatiques pour la transparence gnrique du NAT, car il est
difficile pour IKE de dcouvrir les capacits du NAT.
La meilleure approche est de dplacer 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 derrire le NAT. Il doit changer son
port source 4500, aussitt le NAT dtect, pour viter les problmes lis aux NAT
intelligents.

hDk, 5A, kL, N1, lD11,
vlD
hDk, 5A, kL, N, lD1, |CLk1, ],
vlD, NA1-D, NA1-D, 5lGk
hDk"#, |CLk1, ], NA1-D,
NA1-D, 5lGl

hDk, 5A, vlD

hDk, 5A, vlD

hDk, kL, N1, NA1-D, NA1-D

hDk, kL, N, NA1-D, NA1-D

hDk"#, lD11, |CLk1, ] 5lGl

hDk"#, lD1, | CLk1, ], 5lGk


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

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

lP uDP{4500,4500} <non-L5P make> hDk", lD11, |CLk1, ] 5lGl

Quand le pair correspondant reoit ce paquet, il le dcrypte et processe les diffrents
payloads. Si tout est correct, il doit mettre jour son tat de sorte que tous les paquets
de rponse soient envoies avec le nouveau port, et si possible l'IP source du paquet
valide reu.
Le port est gnralement diffrent 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
prcdents. Le rpondeur doit rpondre UDP(4500,Y).

De faon similaire, si le serveur/rpondeur exige un rekey de la phase 1 de la SA,
alors il doit commencer la ngociation avec UDP(4500,Y). Toute implmentation
supportant le NAT-T doit supporter les ngociations qui dbutent 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
considr 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 dtruit.

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 schma suivant (authentification par
signatures):

ln1f1afo kesponde

uDP{500,500} hDk, 5A, vlD

uDP{500,X} hDk, 5A, vlD
uDP{500,500} hDk, kL, N1,
NA1-D, NA1-D
uDP{500,X} hDk, kL, N,
NA1-D, NA1-D
uDP{4500,4500} hDk"#,
lD11, |CLk1, ]5lGl
uDP{4500,Y} hDk"#, lD1,
| CLk1, ], 5lGk


L'algorithme pour l'aggressive mode est trs similaire. Aprs que le NAT a t
dtect, l'instigateur envoie:

lP uDP{4500,4500} <non-L5P make> hDk", |CLk1, ], NA1-D, NA1-D, 5lGl

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

ln1f1afo kesponde

Pendant le changement de port dans l'ID payload des modes main et aggressive, le
port doit tre 0.

Un cas trs rpandu est celui d'un serveur derrire 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 mme algorithme vu prcdemment, mme si dans ce
cas, Y est gale 4500, vu qu'aucune translation d'adresse intervienne.

Un cas diffrent de changement de port implique une dcouverte out-of-band du port
utiliser. Par exemple, si le serveur est derrire un NAT, l'initiateur a besoin de se
connecter en premier. Pour connatre le port utiliser, il devra contacter d'autres
serveurs. Une fois qu'il connatra les ports utiliser pour passer le NAT, gnralement
UDP(Z,4500), il initiera une connexion avec ces paramtres. Ceci est similaire au cas
du rekey de la part du serveur par le fait que les ports utiliser sont dj connus et il
n'y a plus le besoin de les changer.
Aussi le premier paquet keepalive est envoy aprs le changement de port. Aucun
keepalive est envoy sur le port 500.

Quick Mode
Une fois la phase 1 termine, 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 ngoci 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 aprs la translation NAT.

uDP{500,500} hDk, 5A, kL,
N1, lD11, vlD
uDP{500,X} hDk, 5A, kL, N, lD1,
|CLk1, ], vlD, NA1-D, NA1-D, 5lGk
uDP{4500,4500} hDk"#, |CLk1,
], NA1-D, NA1-D, 5lGl

uDP{4500, Y} hDk"#, ...


Ngociation de l'encapsulation NAT-Traversal
La ngociation de NAT-T peut tre effectue avec l'ajout de deux nouveau modes
d'encapsulation. Ces modes sont:

uDP-Lncapsu1afed-1unne1 3
uDP-Lncapsu1afed-1anspof 4

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

Envoi des adresses IP source et destination originelles
Pour calculer et fixer le checksum incrmentale de TCP, les deux pairs pourraient
avoir besoin des adresses IP originelles utilises par leur homologues.
Dans l'initiateur, l'adresse original Initiator address, est dfinie comme tant l'IP de
l'initiateur. L'adresse original Responder address, est dfinie comme tant l'adresse
IP perue.
Sur son homologue, le rpondeur, l'adresse original Initiator address est dfinie
comme tant l'adresse IP perue. L'adresse original Responder address, est dfinie
comme tant l'IP du rpondeur.

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

L'Initiator NAT-OA payload est le premier payload et le Responder NAT-OA
payload est le deeuxime.

Exemple 1:

ladd NafPub kadd

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

Instigateur:

NA1-OA1 = ladd
NA1-OA = kadd

Rpondeur:

NA1-OA1 = NA1Pub
NA1-OA = kadd

ln1f1afo

kesponde NA1


Exemple 2:

ladd Naf1Pub Naf2Pub kadd

Ii, NAT2 publique Nat2Pub pour le rpondeur et renvoie tout trafic de cette adresse
au rpondeur.

Instigateur:

NA1-OA1 = ladd
NA1-OA = Naf2Pub

Rpondeur:

NA1-OA1 = Naf1Pub
NA1-OA = kadd

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 envoys 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) encapsuls (UDP). Le rpondeur 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 rpondeur choisit le mode
UDP-Encapsulated-Tunnel, et il n'envoie pas de payload NAT-OA en rponse.

Le format du paquet NAT-OA est le suivant:

1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7

Nexf Pay1oad

kL5LkvLD

Pay1oad 1engfh

lD 1ype

kL5LkvLD

kL5LkvLD

lPv4 {4 ocfefs} o lPv6 addess {16 ocfefs}

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

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

ln1f1afo

kesponde NA11

NA12


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

ln1f1afo kesponde

Notification Initial Contact

Les adresses IP et les ports source des messages de notifications Initial-Contact pour
une machine derrire un NAT ne peuvent pas tre utiliss pour dterminer quelle SA
devrait tre efface. Il faut utiliser l'ID payload envoy. Par exemple quand la
notification Initial-Contact est reue, le pair doit effacer toutes les SA associes qui
ont le mme ID payload.

Rstauration des correspondances NAT expirs
Des fois les routeurs NAT dcident d'enlever les correspondances qui sont encore
utilises (par exemple l'intervalle keepalive est trop long, ou le routeur NAT est
redmarr), et les pairs deviennent invisibles. Pour continuer communiquer avec ces
pairs depuis un poste qui n'est pas lui-mme derrire du NAT, on doit utiliser le
dernier paquet authentifi valide et dterminer les adresses et ports utiliser.
Uun pair qui se trouve derrire un NAT dynamique ne doit pas faire a, car il risque
d'ouvrir une possibilit d'attaque de dni de service (DoS); de plus il n'est pas
ncessaire car l'IP et port du pair ne vont pas changer (il n'est pas derrire du NAT).

Les keepalives ne peuvent pas tre utiliss pour cet objectif car il ne sont pas
authentifis, mais n'importe quel paquet IKE ou ESP authentifi fera l'affaire et on
pourra dtecter si le port ou l'IP ont changs.

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

Voici certaines observations:

Les propositions IKE rvlent quiconque le support du NAT-T. Ceci ne
devrait pas tre un issue.

hDk", hA5h{1}, 5A, N1, |,
kL]|, lDc1, lDc ]|, NA1-
OA1, NA1-OA]
hDk", hA5h{2}, 5A, N, |,
kL]|, lDc1, lDc ]|, NA1-
OA1, NA1-OA]

hDk", hA5h{3}


Avec le NAT on ne peut plus se baser sur des mcanismes d'authentification
utilisant les adresse IP. Ceci n'est pas forcement mauvais, car pour une vrai
scurit uniquement les mcanismes qui n'utilisent pas les IP devrait tre
utiliss. En pratique on ne peut plus utiliser l'authentification utilisant des
secrets partags avec le main mode car le mme secret sera partag par tous
les utilisateurs derrire le NAT. L'usage de secrets partags 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 derrire le NAT. Les ports utiliss sont gnralement 500 et les
cookies peuvent tre extraites des paquets. Ceci limite le calculs 2
32
. Si de
plus on utilise des classes prives (ce qui devrait tre le cas), alors le nombre
de calculs pour trouver la bonne adresse IP descendent 2
24
+2*(2
16
).

Ni le payload NAT-D, ni le Vendor ID sont authentifis dans le mode main
ou agressive. On attaquant peut donc effacer, modifier ou rajouter ces
payloads causant des attaque de dni 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, rvle l'IP cach
par le NAT l'autre pair. Dans ce cas on est dj 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 dni de
service si un attaquant peut couter et changer l'ordre des paquets. Par
exemple un hacker sniffe un paquet authentifi d'une machine derrire 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 derrire
un NAT mettra jour ses IP et ports et envoiera ses paquets une fausse
destination. Cette situation est fix immdiatement aprs que l'attaquant
stoppe la modifications des paquets. Les implmentations devraient auditer
cet vnement chaque fois qu'il survienne, car dans des cas normaux il ne
devrai pas apparatre trs souvent.

Mots cls
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 Deuxime phase du protocole IKE
SA Security Association

Negociation de La Fonction NAT T de IPSec

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Negociation de La Fonction NAT T de IPSec

Transféré par

Droits d'auteur :

Formats disponibles

N/I-Ircver:c|

Vous aimerez peut-être aussi