3.2.3 MOBIKE
MOBIKE est une extension d'IKEv2 définie par
[7][8]. MOBIKE considère seulement IPsec tunnels et pour l'utiliser
IKEv2 a été modifié pour recevoir information du noeud en
mobilité lors d'un changement d'adresse IP. Le principal but de MOBIKE
est de prévenir la négociation entre toutes les
différentes interfaces et de gagner du temps dans la négociation
initiale d'IPsec.
Les scénarios de MOBIKE sont basés sur la
Mobilité. Les cas de multihoming considèrent le switch d'une
interface vers une autre, ce qu'on ramène à un scénario de
Mobilité dans cette étude.
Le principal avantage d'utiliser tunnels est que
seulement l'adresse IP "extérieure" est impacté par la
mobilité. Quand un noeud se déplace d'un point d'accès
à un autre, l'adresse IP "interne" (par laquelle est vue le MN du point
de vue du CN) reste la même, et la mobilité peut s'effectuer de
manière transparente du point de vue des applications. Avec un design
sans tunnel, à chaque fois les adresses IP changent et toutes les
applications du réseau ont besoin de réinitialiser les sessions
réseaux et donc de redémarrer, sinon elles sont perdues. On
remarquera qu'aujourd'hui il existe nouveaux protocoles comme HIP ou SHIM6 qui
pallient à ces limitations.
MOBIKE est une option d'IKEv2 qu'il faut activer dans
les deux noeuds en question pour l'utiliser. Le noeud qui commence la
communication s'appelle « initator » et l'autre « responder
». MOBIKE échange des messages, qui contiennent un Notify Payload,
entre les deux noeuds. Les opérations de MOBIKE et les Notify Payloads
envoyés sont :
|
Étude d'IPsec
Projet d'une API_IPSEC
pour la Mobilite et le Multihoming
|
|
- MOBIKE_SUPPORTED : pendant la deuxième phase
d'IKEv2 chaque noeud informe à l'autre avec ce Notify Payload qu'il a
l'option MOBIKE activé.
- ADDITIONAL_IP4_ADDRESS (ou IP6) : pour ajouter les
différentes adresses IP du noeud.
- NO_ADDITIONAL_ADDRESSES : il indique que le noeud n'a
plus d'adresses IP.
- UPDATE_SA_ADDRESS : il est envoyé par le noeud
qui change depuis la nouvelle adresse IP pour actualiser les SA.
- COOKIE2 : il confirme que l'actualisation de l'adresse
IP a été effectuée.
Limitations de MOBIKE :
- Il n'essaie pas d'être un protocole de
sécurité complet.
- Il traite la Mobilité seulement entre deux
noeuds, un MN attaché à une "Security Gateway".
- Il supporte seulement le mode tunnel.
- Le MN ne possède qu'une adresse IP à la
fois.
3.2.4 PF_KEY et MIP: solution dans le
"bootstrapping"
[9] propose deux extensions de PF_KEY, l'API qui fait
possible la manipulation des SA, qui permettent un fonctionnement correct et
optimal entre MIPv6 et IPsec/IKE.
En effet, au moment du BOOTTRAPPING le MN effectue
une négociation entre sa CoA et l'adresse IP du HA. La
problématique de IKEv2 et MIPv6 est que IKE gère des associations
de sécurité entre des adresses IP qui servent à acheminer
des paquets IP et que MIPv6 identifie les communications entre le MN et le HA
grâce à la HoA qui n'est pas systématiquement
utilisée pour l'acheminement des paquets IP. Pour cette raison MIPv6 est
contraint de gérer certains aspects IPsec. Ainsi par exemple, lorsqu'un
MN envoie un BU à son HA, le paquet a comme adresse source la CoA et
comme adresse destination l'adresse IP du HA. La HA reçoit ce paquet
mais ne possède pas de SA associée à la CoA car il
identifie le MN à son HoA. Pour rendre cohérent les tables IPsec
et celles de la mobilité, MIPv6 doit, à la réception du
paquet, remplacer l'adresse CoA par celle du HoA. A ce moment là, le HA
pourra procéder à un lookup dans sa table.
- PF_KEY_MIGRATE : permet de faire la migration de
l'adresse d'un noeud vers un autre connecté par un tunnel IPsec
(établit par des SA). Aussi, il peut actualiser la session IKE et ainsi
permet à IKE de survivre aux déplacements.
- SADB_X_EXT_PACKET : permet à IKE de faire le
bon choix de l'adresse dans le bootsrapping.
PF_KEY_MIGRATE
MIPv6 définit un indicateur nommé Key
Management Mobility Capability bit, le K-bit, dans les
messages de BU et de
BA. Il indique la capacité que les sessions d'IKE puissent survivre
à la mobilité. En
effet, si MN et HA peuvent manager cet
indicateur, le démon IKE actualise dynamiquement la session
|
Étude d'IPsec
Projet d'une
API_IPSEC pour la Mobilite et le Multihoming
|
|
|
d'IKE quand le MN se déplace. Pour
réaliser cela, le démon IKE doit être notifié par
MIPv6 avec l'information nécessaire pour migrer sa session
IKE.
La structure du message PF_KEY_MIGRATE doit contenir
:
-
Information sur une SP : - L'adresse/port
source/destination ; le protocole de la couche supérieure.
- La
direction du trafic: entrant ou sortant.
- Information sur l'ancienne SA : - L'adresse
source/destination ;
- Information sur la nouvelle SA : - Le protocole :
ESP/AH ; le mode (seulement tunnel).
Figure 8. Schéma d'échanges dans le MN
(à gauche), et entre lui et le HA (à droite)
SADB_X_EXT_PACKET
Dans l'étape de bootstrapping de MIPv6, le MN
et HA ont besoin d'établir une IPsec SA pour protéger les
messages de signalisation de MIPv6 comme BU et BA. La négociation IKE
est la première transaction qui se fait entre le MN et le HA, il est
donc nécessaire de guider IKE pour lui communiquer l'adresse sur
laquelle il fera les négociations.
La solution consiste à analyser tous les
paquets reçus (« triggering packet ») et ajouter l'information
nécessaire dans une extension du message SADB_ACQUIRE. Cette extension
est le SADB_X_EXT_PACKET.
| 
