Revision as of 19:36, 4 December 2005

La mobilité doit satisfaire les deux contraintes de sécurité suivantes :

• L'introduction de la mobilité dans IP ne doit pas introduire de nouvelles vulnérabilités dans le réseau,
• Une communication dans un contexte mobile ne doit pas être plus risquée que dans un contexte fixe.

La sécurisation de MIPv6 est prévue dans le cadre standard de l'Internet où l'infrastructure de routage est réputée correcte, c'est-à-dire où un paquet destiné à un noeud A est effectivement acheminé vers ce noeud A. Cette sécurisation vise à obtenir un niveau de confiance des communications mobiles, égal à ou proche de celui offert aux communications fixes.

Les risques pour le noeud mobile

Un noeud dans son réseau mère (home network dans les figures) considère généralement son environnement comme amical, surtout lorsqu'il communique avec des correspondants également situés dans son réseau mère. En visite dans un autre réseau il doit se montrer plus circonspect. En particulier, il devra assurer la confidentialité des données transmises, par exemple en utilisant IPsec, afin d'éviter qu'elles ne soient épiées, au niveau du réseau visité, mais également sur le chemin entre le réseau visité et son réseau mère (cf. figure Chiffrement nécessaire des données).

Un noeud mobile peut également souffrir de déni de service si les mises à jour d'association avec son agent mère sont falsifiées. Un n?ud hostile dans le réseau visité, ou partout ailleurs dans le réseau, pourrait envoyer une fausse demande de mise à jour d'association afin de détourner le trafic de son véritable destinataire. Il est donc important pour le noeud mobile de sécuriser ces mises à jour (cf. figure Détournement de trafic).

L'IETF a décidé d'utiliser IPsec pour la signalisation entre le mobile et son agent mère, spécifiée dans le RFC 3776.

Les risques pour les autres noeuds

Un noeud malveillant peut utiliser des messages de mise à jour d'association frauduleux pour détourner de ses clients légitimes les flux d'un serveur mettant en oeuvre la mobilité. Ce cas est similaire au cas du détournement du trafic destiné à un noeud mobile. Un noeud malveillant peut également utiliser des noeuds mettant en oeuvre la mobilité pour inonder un autre noeud, de trafic non sollicité, de façon à engorger ses liens de communication, ceci sans même que la victime ne mette en oeuvre la mobilité (cf. figure Déni de service envers un noeud tiers).

On notera que ces risques sont exclusivement liés à la mise en oeuvre de l'optimisation du routage. Afin de les diminuer jusqu'à un niveau acceptable, sans pénaliser les performances du protocole, MIPv6 prévoit la procédure de test de "routage retour" entre le noeud mobile et son correspondant. Cette procédure est décrite au paragraphe suivant et spécifiée dans le RFC 3775.

Sécurisation de la signalisation avec les noeuds correspondants

La procédure de test de routage retour

Les mises à jour d'association étant fréquentes, il est important que cette procédure soit la plus légère possible. Un noeud mobile et un noeud correspondant ne se connaissent pas à priori. Ils ne partagent donc pas de secret susceptible de chiffrer leurs échanges lors des différentes mises à jour d'association nécessaires pendant toute la durée de la communication. L'utilisation d'IPsec et d'une procédure d'échange sécurisé des clefs aurait été trop lourde. La procédure choisie a pour premier but de générer ce secret partagé.

Afin d'éviter l'attaque en déni de service à l'encontre d'un noeud tiers, elle garantit au noeud correspondant que, pour une certaine adresse temporaire et pour une certaine adresse mère, il y a effectivement un noeud mobile prêt à recevoir un paquet.

La procédure est conçue de façon à ce que le noeud correspondant ne puisse pas subir lui-même une attaque en déni de service par la simple exécution répétée de la procédure. A cette fin, elle consomme peu de ressources de calcul, et les ressources mémoires nécessaires ne dépendent pas du nombre de demande d'association. Enfin, pour ne pas surcharger le réseau, le noeud correspondant n'émet pas plus de paquets qu'il n'en reçoit.

La procédure est constituée de deux phases préliminaires, dont l'une teste la home address et l'autre teste la care-of address. Ensuite toute demande de mise à jour, ou de destruction d'association sera assujettie à l'exécution correcte des ces deux phases préliminaires.

Les deux phases sont menées parallèlement l'une de l'autre, à l'initiative du noeud mobile. Le noeud correspondant répond à leurs requêtes indépendamment l'une de l'autre. Il demeure sans état jusqu'à ce qu'une association soit établie. Les messages doivent donc être autosuffisants pour que la procédure puisse se dérouler.

La procédure (cf. figure Routage retour) nécessite que le noeud mobile dispose d'un ensemble de nombres aléatoires secrets (nonces), tels que l'index d'un de ces nombres suffise à le retrouver dans cet ensemble. Elle nécessite également que le noeud correspondant dispose d'une clef secrète notée Kcn.

Un message HoTI, émis depuis la home address du noeud mobile vers le noeud correspondant (donc via l'agent mère), contient une valeur aléatoire sur 64 bits, le home init cookie identifiant cette home address.

Un message HoT, émis par le noeud correspondant en réponse au message HoTI à destination de la home address du mobile, donc toujours via l'agent mère contient trois valeurs :

• le home init cookie obtenu dans le message HoTI,
• l'index sur 16 bits d'un nonce, choisi par le noeud correspondant,
• le home keygen token, calculé par le noeud correspondant :
  

premiers (64, HMAC_SHA1 (Kcn, (home address | nonce | 0 )))

Un message CoTI, émis depuis la care-of address du n?ud mobile, directement vers le noeud correspondant, contient une seconde valeur aléatoire sur 64 bits, le care-of init cookie identifiant cette care-of address.

Un message CoT, émis par le noeud correspondant en réponse au message CoTI du noeud mobile, directement vers le noeud mobile contient trois valeurs :

• le care-of init cookie obtenu dans le message CoTI,
• l'index sur 16 bits d'un second nonce, choisi par le noeud correspondant,
• le care-of keygen token, calculé par le noeud correspondant :

premiers (64, HMAC_SHA1 (Kcn, (care-of address| nonce | 1 )))

Lorsque le noeud mobile a reçu les messages HoT et CoT, la procédure de test du routage retour est terminée. Arrivé à ce point, le noeud mobile calcule Kbm, la clef de gestion des associations (key binding management) telle que :

Kbm = SHA1 ( "home keygen token" | "care-of keygen token") 

pour la mise à jour d'une association, ou

Kbm = SHA1 ( "home keygen token") 

pour sa destruction.

Pour demander une nouvelle association, le noeud mobile envoie, depuis sa care-of address courante, à destination du noeud correspondant, une demande d'association contenant cinq informations :

• Sa home address
• Un numéro de séquence d'association
• Les deux index des home et care-of nonces
• Une valeur chiffrée
• Premier( 96, HMAC_SHA1(Kbm , ("home address" | adresse du noeud correspondant | donnée de la mise jour d'association)))

On notera que puisque les indexes des nombres aléatoires secrets sont fournis par le noeud mobile, le noeud correspondant peut recalculer Kbm. Kbm est donc bien une clef partagée utilisable dans une procédure HMAC_SHA1 pour vérifier la légalité d'une demande de mise à jour d'association.

La correction de la procédure repose sur l'hypothèse qu'aucun intrus ne peut écouter à la fois les messages home test et care-of test ni connaître Kbm. Ces messages utilisant deux chemins différents pour joindre le noeud correspondant (cf. figure Attaque contre le routage retour), il faudrait donc que l'intrus se trouve dans le réseau du noeud correspondant. Dans ce cas, la mobilité n'introduit pas plus de risque que IP fixe lui-même.

Par contre, si un noeud malveillant obtient les deux home et care-of keygen tokens, il pourra par la suite envoyer de fausses demandes de mise à jour d'association. Pour cela, ce noeud doit écouter des données circulant en clair sur les 2 chemins conduisant du noeud mobile au noeud correspondant, directement et via l'agent mère. La probabilité que cette écoute soit possible augmente si le noeud malveillant est proche du noeud correspondant. L'écoute est définitivement possible lorsque l'on est connecté au réseau du noeud correspondant.

Les message HoTI, CoTI, HoT et CoT sont transportés dans des en-têtes d'extension de mobilité (numéro de protocole 135). Chacun possède un numéro de type d'en-tête de message particulier (respectivement 1,2,3,4).

La procédure conduit au partage d'un secret entre les n?uds mobile et correspondant. Il est nécessaire de rafraîchir régulièrement ce secret. Le rafraîchissement est laissé à l'initiative du noeud correspondant. Il est mise en oeuvre en expirant la validité du nonce utilisé dans la clef Kbm. Une demande de modification d'association arrivant avec un nonce expiré sera refusée via le message d'acquittement. Le noeud mobile relancera alors la procédure pour obtenir une nouvelle Kbm basée sur un nonce valide.

La clef Kcn doit elle même être régulièrement régénérée. Elle le sera en particulier à chaque redémarrage du n?ud correspondant et préférablement lors de chaque régénération de nonce. Il est en effet nécessaire que chaque nonce soit associé à la bonne Kcn dans la vérification de la clef Kbm d'une demande de mise à jour d'association.

La vérification par le noeud correspondant d'une clef Kbm s'effectue en vérifiant que :

• Les nonces HoA et CoA ne sont pas expirés,
• Le re-calcul de Kbm, sur la base des indices des nonces et de la Kcn associée, est cohérent avec la valeur Kbm contenue dans la demande d'association.

Un message d'erreur est envoyé en cas d'expiration d'une au moins des nonces. Aucun message d'erreur n'est émis dans le cas ou le re-calcul de la Kbm échoue. Dans le cas de nonce expiré, il est nécessaire de procéder au re-calcul sur la base d'une éventuelle ancienne valeur de Kcn pour n'envoyer de message d'expiration que si la Kbm est valide par rapport à l'ancienne Kcn.

Seul le noeud mobile maintient l'état des données de sécurité de chaque association. Les informations home init cookie et care-of init cookie peuvent être supprimées dès réceptions des nonces et keygen tokens. Les demandes de création d'association sont à l'initiative du noeud mobile. Il n'est donc pas sujet à une attaque en déni de service par consommation excessive de ressources mémoire.

Le noeud correspondant maintient un état de sécurité indépendant du nombre d'associations en cours. Il n'est donc pas sujet non plus à une attaque en déni de service par consommation excessive de ressources mémoire.

Protection de la signalisation par le protocole IPsec

Utilisation du protocole IPsec dans MIPv6

Le protocole IPsec nécessite la connaissance réciproque des clefs entre les correspondants. Le noeud mobile et son agent mère appartenant à la même organisation, il est raisonnable d'admettre qu'ils auront pu échanger leurs clefs en toute sécurité sans la mise en place d'une lourde infrastructure de gestion de clefs. L'utilisation d'IPsec entre le n?ud mobile et son agent mère est donc tout à fait adaptée. Elle n'utilise que ESP en mode tunnel ou transport. La position des en-tête ESP sera choisie de façon à protéger également les informations de routage sans avoir recours à IPsec en mode AH, d'où une simplification de l'implémentation de la mobilité.

Le protocole IPsec est utilisé dans trois types de communications entre le noeud mobile et son agent mère :

• Les messages de la procédure de routage retour,
• La mise à jour des association de mobilité et leur acquittement,
• L'encapsulation du flux des données entre le mobile et son noeud correspondant sur le tronçon noeud mobile-agent mère. (Ce qui n'est somme toute qu'un cas d'utilisation "standard" d'IPsec dans IPv6 entre un noeud (le noeud mobile) et une passerelle de sécurité (l'agent mère).)

L'efficacité d'une procédure de sécurité repose largement sur la qualité des politiques mises en oeuvre. Cet ouvrage n'étant pas un ouvrage sur la sécurité il n'est pas possible de détailler les politiques recommandées pour la gestion de la mobilité (voir RFC 3776).

IPsec dans les mises à jour d'association entre le n?ud mobile et son agent mère

L'essentiel du problème consiste à garantir l'origine de la demande de mise à jour ainsi que sa valeur. ESP sera utilisé en mode transport. C'est-à-dire que le packet ESP ne contient qu'une signature des données qu'il encapsule (cf. figure IPsec en mode tranport pour les mises à jour d'association de mobilité).

Lors d'une demande de mise à jour, la care-of address est répétée dans l'option alternate care-of address de la demande de mise à jour. Comme sa valeur est certifiée par ESP, l'agent mère considèrera cette adresse plutôt que l'adresse source de l'en-tête IPv6. L'adresse de l'agent mère de l'en-tête n'est pas protégée par ESP, elle est garantie par les règles d'utilisation de l'adresse de l'agent mère lors de l'établissement de l'association de sécurité entre le noeud mobile et l'agent mère.

Enfin, lorsqu'un n?ud mobile est dans son réseau mère, l'en-tête option destination ainsi que l'en-tête de routage peuvent être omises puisque le n?ud mobile peut utiliser son adresse mère. Ce sera le cas notamment quand le n?ud mobile de retour dans son réseau mère, demande la destruction de son association. IPsec en mode tranport pour les mises à jour d'association de mobilité

En-tête IPv6

En-tête suivant: 60

En-tête IPv6

En-tête suivant: 60

SRC: care-of address du n?ud mobile

DST: adresse de l'agent mère

SRC: adresse de l'agent mère

DST: "care-of address" du n?ud mobile

En-tête option destination

En-tête suivant: 50

En-tête de routage type 2

En-tête suivant: 50

"home address" du n?ud mobile

"home address" du n?ud mobile

En-tête ESP (en mode transport)

En-tête ESP (en mode transport)

En-tête de mobilité

Mise à jour d'association,

Option: care-of address du n?ud mobile

En-tête de mobilité

Acquittement de l'association de mobilité

En-tête suivant: 135

En-tête suivant: 135

IPsec dans la procédure de "retour de routage" via l'agent mère

L'essentiel du problème est d'éviter qu'un n?ud malveillant puisse écouter les échanges conduisant au n?ud mobile à calculer la clef Kbm avec le n?ud correspondant. Les informations home init cookie et home keygen token doivent donc être chiffrées. ESP est ici utilisé en mode tunnel. L'algorithme de chiffrement utilisé dans l'association ne doit donc pas être nul (cf. See IPsec en mode tunnel pour la procédure de retour de routage).

On notera également que lorsque le n?ud mobile change d'adresse temporaire, l'agent mère devra mettre à jour l'association de sécurité pour prendre en compte cette nouvelle adresse destination du n?ud mobile. IPsec en mode tunnel pour la procédure de retour de routage

En-tête IPv6

En-tête suivant: 60

Entête IPV6

Entête suivant: 43

SRC: care-of address du n?ud mobile

DST: adresse de l'agent mère

SRC: adresse de l'agent mère

DST: care-of address du n?ud mobile

En-tête ESP (en mode tunnel)

Entête ESP (en mode tunnel)

En-tête IPV6

En-tête suivant: 135

Entête IPV6

Ent-ête suivant: 135

SRC: home address du n?ud mobile

DST: adresse du n?ud correspondant

SRC: home address du n?ud mobile

DST: adresse du home agent

En-tête de mobilité

Initialisation du test de la home address

home address cookie

En-tête de mobilité

Test de la home adress

home address cookie

home keygen token

En-tête suivant: 41

En-tête suivant: 41