Négociation de la fonction NAT-T de IPSec

�

�

�

�

��

��

��

� �

� � � ��

��

NAT-Traversal et IPsec Page 2

�

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.

��


�

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

��


�

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 dans le deuxième et troisième message de l'aggressive mode. 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.

��


�

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��&� � � � � � � ��'(� ��&��

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��&� � � � � � � ��'(� ��&��

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.

#��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-

�

#��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�

��


�

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 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�

��


�

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��&� � � � � � � ��'(� ��&��

Pendant le changement de port dans l'ID payload des modes main et aggressive, le 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.

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�===

��


�

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, l'initiateur ne doit pas inclure les modes tunnel ou transport standards et les modes 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'initiateur, l'adresse original Initiator address, est définie comme étant 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). L'Initiator NAT-OA payload est le premier payload et le Responder NAT-OA payload est le deeuxième. Exemple 1: ��

��-��&� � ��?@��&�

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$&�)��&

�

- 0�0��& �

��'(� ��& �

�$2

��


�

Exemple 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 IPv4 et IPv6. Les deux champs reserves aprs l'ID Type doivent être à 0.

�

- 0�0��& �

��'(� ��& �

�$2 �

�$2�

��


�

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

- 0�0��&� � � � � � � ��'(� ��&��

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.

#��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�#$�#*�/

��


�

��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

Documents

Négociation de la fonction NAT-T de IPSec