Vous êtes sur la page 1sur 8

Négociation de l'encapsulation UDP de IPSec

Ce document décrit comment encapsuler et .décapsuler les paquets IPSec ESP


(Encapsulating Security Payload) dans des paquets UDP pour permettre leurs passage
à travers des NAT (Network Address Tipvranslators). L'encapsulation ESP définie
dans ce document est utilisable dans le cas de IPv4 et IPv6. L'encapsulation est utilisé
si négocié auparavant avec le protocole IKE (Internet Key Exchange).
Ce document s’inspire du draft de l’IETF : draft-ietf-ipsec-udp-encaps-06.txt.

Table des matières


Négociation de l'encapsulation UDP de IPSec ........................................................... 2
Table des matières ................................................................................................. 2
Introduction........................................................................................................... 2
Format des paquets................................................................................................ 3
UDP-encapsulated ESP Header ......................................................................... 3
Floated IKE Header ........................................................................................... 3
NAT-keepalive Packet....................................................................................... 4
Procédures d'encapsulation et décapsulation .......................................................... 4
Procédures auxiliaires........................................................................................ 4
Encapsulation ESP du mode Transport .............................................................. 5
Décapsulation ESP du mode Transport .............................................................. 6
Encapsulation ESP du mode Tunnel .................................................................. 6
Décapsulation ESP du mode Tunel .................................................................... 6
Procédure pour le keepalive NAT.......................................................................... 6
Considérations sur la sécurité ................................................................................ 7
Déni de service DoS .......................................................................................... 7
Conflits du mode Tunnel ................................................................................... 7
Conflits du mode Transport ............................................................................... 7
Mots clés ............................................................................................................... 8

Introduction
Ce document défini les méthodes d'encapsulation et décapsulation de paquets ESP
dans des paquets UDP pour le passage de NAT. Les ports UDP utilisés sont les
mêmes que ceux utilisés pour le trafic IKE, comme définit dans le document draft-
ietf-ipsec-nat-t-ike-05.txt.
Les clients IPSec doivent supporter au moins le mode transport. Pour distinguer les
paquets ESP des paquets IKE, l'implémentation IKE qui supporte l'encapsulation
UDP ne doit pas utiliser le champ zéro des SPI ESP pour les paquets ESP.

Encapsulation UDP de l'ESP d' IPsec Page 2


Format des paquets
UDP-encapsulated ESP Header

!"# $
%%%

L'entête UDP est standard selon le protocole UDP, comme le décrit le document
[RFC 768]. Les ports source et destination doivent être les mêmes utilisés pour le
trafic IKE. Le checksum devrait être transmis avec la valeur zéro; les récepteurs ne
doivent donc pas contrôler se checksum.

Le champ SIP dans l'entête ESP ne doit pas être à zéro.

Floated IKE Header

& ' (

)* !"# $
%%%

L'entête UDP est standard selon le protocole UDP, comme le décrit le document
[RFC 768]. Les ports source et destination doivent être les mêmes utilisés pour le
trafic IKE. Le checksum devrait être transmis avec la valeur zéro; les récepteurs ne
doivent donc pas contrôler se checksum.

Le champ Non-ESP Marker est au même endroit que le champ SPI d'un paquet ESP.

Encapsulation UDP de l'ESP d' IPsec Page 3


NAT-keepalive Packet

+##

L'entête UDP est standard selon le protocole UDP, comme le décrit le document
[RFC 768]. Les ports source et destination doivent être les mêmes utilisés pour le
trafic IKE. Le checksum devrait être transmis avec la valeur zéro; les récepteurs ne
doivent donc pas contrôler se checksum.

L'émetteur devrait utiliser un payload avec un octet long de valeur 0xFF.


Le récepteur devrait ignorer un paquet NAT-keepalive.

Procédures d'encapsulation et décapsulation


Procédures auxiliaires

Procédure de décapsulation NAT du mode tunnel


Quand le mode tunnel est utilisé pour la transmission des paquets, l'entête IP
contenue peut avoir des adresses qui ne sont pas utilisables pour le réseau courant.
Cette procédure définit comment convertir ces adresses pour être utilisable dans le
réseau courant.

Selon la politique de sécurité locale, au moins une des conditions suivantes doit être
effectuée:

1. Si une espace d'adressage IP valide a été défini dans les règles de cette
connexion, il faut contrôler que l'espace d'adressage des paquets correspond
bien à ces règles.

2. Si une adresse IP a été assignée au pair distant, il faut contrôler que l'IP source
contenu dans ses paquets correspond bien à celle assignée.

3. Une translation d'adresse NAT est effectuée sur les paquets afin qu'il puissent
être transportés vers le réseaux local.

Procédure de décapsulation NAT du mode transport


Quand le mode transport est utilise pour la transmission des paquets, les entêtes TCP
ou UDP des paquets contenus, auront des checksum pas corrects à cause de la
modification des paquets IP pendant la transition.
Cette procédure définit comment corriger ces checksums.

Encapsulation UDP de l'ESP d' IPsec Page 4


Selon la politique de sécurité locale, au moins une des conditions suivantes doit être
effectuée:

1. Si l'entête après celle d'ESP est TCP/UDP et on a reçu, selon le document


draft-ietf-ipsec-nat-t-ike-05.txt, les adresses IP source et destination réelles du
pair distant avec le protocole IKE, il faut recalculer les checksum TCP/UDP
comme de suite:
a. Soustraire au checksum l'adresse IP source du paquet.
b. Ajouter au checksum la vraie adresse IP source reçue (obtenue avec un
payload NAT-OA)
c. Soustraire au checksum l'adresse IP destination du paquet.
d. Ajouter au checksum la vraie adresse IP destination reçue (obtenue
avec un payload NAT-OA)
À noter: si les adresses reçues sont les mêmes que les adresses réelles, les
opérations d'effacements ne doivent pas être effectuées.

2. Si l'entête après celle d'ESP est TCP/UDP, il faut recalculer simplement les
checksum TCP/UDP.

3. Si l'entête après celle d'ESP est UDP, mettre à zéro le checksum de l'entête
UDP.
Si l'entête après celle d'ESP est TCP, et l'option de ne pas tester le checksum
est activée, le checksum n'est pas calculé; ce flag pourrait être utilisé.
Tout ceci doit être effectué uniquement pour le mode transport et si on
protège l'intégrité du paquet. Les checksums du mode tunnel doivent être
vérifiés.

De plus, chaque implémentation pourrait fixer aussi d'autres protocoles modifies par
le NAT.

Encapsulation ESP du mode Transport

Avant l'encapsulation ESP/UDP:

) , ) 1 212
- . / 0

Après l'encapsulation ESP/UDP:

) , ) 3 1 212
- . / 0 4 4 1 5 2
./ 6

2 7 6

La normale procédure d'encapsulation ESP est utilise.


Une entête préfabriqué a été insérée comme indiqué dans la figure précédente.
Les champs de la longueur totale, du type de protocole et du checksum de
l'entête IP sont corrigés.

Encapsulation UDP de l'ESP d' IPsec Page 5


Décapsulation ESP du mode Transport
L'entête UDP est enlevée du paquet.
Les champs de la longueur totale, du type de protocole et du checksum de
l'entête IP sont corrigés.
La normale procédure de décapsulation ESP est utilise.
La procédure du mode transport de le décapsulation NAT est utilisée.

Encapsulation ESP du mode Tunnel

Avant l'encapsulation ESP/UDP:

) , ) 1 212
- . / 0

Après l'encapsulation ESP/UDP:

& 8 3 )
) , - / 0 4 4 - . / 0 1 212 1 5 2
./ 6

2 7 6

La normale procédure d'encapsulation ESP est utilise.


Une entête préfabriqué a été insérée comme indiqué dans la figure précédente.
Les champs de la longueur totale, du type de protocole et du checksum de la
nouvelle entête IP sont corrigés.

Décapsulation ESP du mode Tunel


L'entête UDP est enlevée du paquet.
Les champs de la longueur totale, du type de protocole et du checksum de la
nouvelle entête IP sont corrigés.
La normale procédure de décapsulation ESP est utilise.
La procédure du mode tunnel de le décapsulation NAT est utilisée.

Procédure pour le keepalive NAT


Le seul objectif de l'envoi de paquets NAT-keepalive, est de garantir les mappages
NAT actifs pour toute la durée d'une connexion entre pairs. La réception de paquets
NAT-keepalive ne doit pas être utilisé pour détecter si la connexion existe encore.

Un pair peut envoyer un NAT-keepalive s'il existe une ou plusieurs SA de phase 1 ou


2 de IKE, ou si une SA à existé au moins N minutes auparavant. N est un paramètre
configurable localement avec une valeur par défaut de 5 minutes.

Un pair devrait envoyer un NAT-keepalive si nécessaire, selon le document draft-


ietf-ipsec-nat-t-ike-05.txt et aucun message n' a pas été envoyé pendant M seconds. M
est un paramètre configurable localement avec une valeur par défaut de 20 seconds.

Encapsulation UDP de l'ESP d' IPsec Page 6


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é.

Déni de service DoS


Dans certaines configurations, l'encapsulation ESP-UDP, put engendrer des
conséquences d'attaque de déni de service, spécialement si des ports UDP utilisés par
le système d'exploitation sont utilisés. Il est recommandé de ne pas ouvrire un port
UDP ordinaire pour cette fonction.

Conflits du mode Tunnel


Dans le cas suivant il y a possibilité de conflits:

4
% % % &21

4 &21 9 8 . B
% % % ,

Le gateway VPN verra maintenant deux SA possibles pour 10.1.2.3. C'est aux
implémentateurs de trouver des solutions pour prévenir ce cas.

Il est recommandé l'usage de protocoles d'assignation d'adresses IP comme DHCP-


over-IPSec (traité dans le document draft-ietf-ipsec-dhcp-13.txt) ou simplement
configurer les IP pour que le conflit n'intervienne pas.

Conflits du mode Transport


Un cas similaire peut arriver dans le mode transport avec deux clients, Gege et Bob,
se trouvant derrière un NAT et qui causent de façon sûre avec un serveur. Un
troisième utilisateur, Gigi, veut communiquer avec le même serveur mais en clair.

9
% % %

? @ &21 B
% % % ,

9
% % %

Maintenant, les SA de transport sur le serveur ressemblent à ceci:

9 : &21; < 77 =; 3 / < ; >=


? @: &21; < 77 =; 3 / < ; A=

Le traffic de Gigi est en clair, don il n'y a pas de SA

Encapsulation UDP de l'ESP d' IPsec Page 7


< 77 = est l'information sur le protocole et le port.

>;A sont les port sources dynamiques associés par le NAT pendant la négociation
IKE. Donc Gege émet ses paquets avec UDP(4500,4500) et ils arrivent au serveur
avec UDP(Y,4500)

Si le trafic < 77 = superpose le trafic < 77 =, alors des simples


filtres ne sont pas suffisant pour détecter quelle SA utiliser pour l'envoi de trafic. C'est
aux implémentateurs de trouver des solutions pour prévenir ce cas.

Maintenant on assume que Gigi veut se connecter aussi au serveur mais en clair. Ceci
est très difficile car le serveur a déjà une règles jusqu'à l'adresse publique du NAT
pour sécuriser le trafic < 77 =. Il est possible de faire cette connexion mais
pour des trafics différents.

Par exemple, maintenant, les SA de transport sur le serveur ressemblent à ceci:

9 : &21; < 77 =; 3 / < ; >=


? @: &21; < 77 =; 3 / < ; A=
9 : &21; 2 ) ( ; 5 +

Il est à noter que ces règles permettent aussi à Gege et à Bob d'envoyer du traffic icmp
vers le serveur.

Le serveur verra tous ses clients derrière le NAT et la même IP, donc il est possible de
configurer plusieurs règles pour le même descripteur de trafic.

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

Encapsulation UDP de l'ESP d' IPsec Page 8

Vous aimerez peut-être aussi