Projet d'une API IPSEC pour la mobilité et le multihoming

3.1.4 Architecture IPsec

L'architecture IPsec, d'accord avec l'information présentée, peut se résumer dans le schéma suivant :

Figure 5. Architecture IPsecv2

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

3.2 IPsec et la mobilité

3.2.1 Définition de la mobilité et du multihoming

On parle de la « mobilité » quand l'adresse IP d'une machine (ou un hôte ou un noeud) est changée. Plusieurs cas de figure peuvent se présenter lors du changement, et il faut spécifier les différents cas par rapport aux interfaces de connectivité de la machine. Considérant une machine qui dispose de plusieurs interfaces de connexion, on définie alors:

- Mobilité : quand une machine change son point de connexion et il reçoit une nouvelle adresse IP, sur la même interface.

- Multihomming : quand une machine change à une interface différente elle obtient logiquement autre adresse IP. Mais, par contre, elle maintient aussi l'adresse antérieure dans l'autre interface et peut utiliser les deux en même temps ou switcher de l'une à l'autre.

La littérature [5] définit un cas de multihoming qui considère un noeud qui bien que disposant de deux
interfaces n'en utilise qu'une à la fois. Ce cas permet en cas de chute d'un lien de passer sur l'autre lien.
Nous considérons, dans ce document, clairement ce cas comme un cas de mobilité et non de multihoming.

Terminologie dans un cadre de mobilité IP

Pour gérer la mobilité, l'IETF définit le protocole Mobile IP. MIP s'appuie sur une architecture spécifique et fait intervenir les concepts suivants:

- MN : Mobile Node. Noeud qui change son point d'accès alors qu'il est toujours accessible via HoA. - CoA : Care of Address. Une adresse IP physique du MN quand il visite un réseau distant.

- HoA : Home Address. Une adresse IP permanente du MN dans le réseau local. Le MN est toujours joignable via cette adresse IP, soit directement soit par le biais d'un HA.

- HA : Home Agent. C'est un router dans la réseau local qui représente le MN quand il a fait la mobilité donc il n'est pas attaché au réseau local.

- CN : Communicant Node. C'est un noeud avec qui le MN est en train de communiquer. Le CN peut être soit statique soit aussi mobile.

- Binding : c'est une association entre le HoA et le CoA du MN qui possède le HA pour renvoyer le trafic qui concerne le MN. Deux messages liés: le Binding Update (BU) et le Binding Acknowledge (BA).

3.2.2 MIPv6 et IPsec

Le protocole Mobile IP6 (MIPv6) et son architecture sont définis en [6]. L'objet de cette section est de décrire concrètement les scénarios de mobilité basés sur MIPv6 les plus usuels. Ces scénarios comprennent le cas oil le MN et le CN communiquent via le HA, et le cas oil les communications entre MN et CN se font directement, sans passer par le HA. On parle alors de "Route Optimization".

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

1. MN se connecte à un réseau distant.

2. MN envoie un BU au HA (il est sécurisé avec IPsec ESP en transport mode).

3. HA crée le "Binding" et il utilise un Proxy Neighbor Discovery (IPv6 équivalent au proxy ARP) pour représenter le MN dans le réseau local.

4. CN envoie au HoA tous les paquets destinés au MN. Directement ils seront encapsulés par le HA dans un tunnel et envoyés à l'adresse physique CoA du MN.

5. MN envoie des paquets vers CN par le tunnel, et le HA les renvoie depuis HoA au CN (dans les paquets l'adresse source CoA du MN est changé par HoA).

Le MN est relié par un tunnel au HA qui joue un rôle de "forwarder" soit en direction du MN, soit en direction du CN. Par contre, MIPv6 est complètement transparent pour le CN (uniquement le MN et le HA traitent des paquets spéciaux). Cette transparence à un prix au niveau du routage, et la communication n'est généralement pas optimale: le MN et le CN s'échangent des paquets en passant toujours par le HA.

Figure 6. Tunnel Mode en MIPv6

Pour palier à cet inconvénient le "Route Optimization" permet de construire un routage direct entre le MN et le CN. Cette optimisation ne se fait pas de manière transparente, et le CN doit implémenter MIPv6.

1. MN envoie un BU au CN. Ensuite il envoie du trafic au CN avec la CoA comme adresse source. Les paquets contiennent comme option de destination la HoA (option IPv6).

2. CN change l'adresse source par HoA avant passer le paquet aux couches supérieures.

3. CN envoie du trafic au MN avec CoA marqué comme adresse de destination. Les paquets ont un Routing Header spécial qu'indique la HoA comme deuxième noeud de destination possible. Cela signifie que du point de vue de l'application, ou des couches supérieures à la couche IP, le paquet devra présenter le HoA comme adresse de destination.

4. MN prend la HoA du Routing Header et efface cet en-tête. Il modifie l'adresse destination des paquets avec HoA et, enfin, il passe les paquets aux couches supérieurs qui espèrent trouver justement la HoA. Cette translation d'adresse permet de ne pas casser les connexions MIPv6 lors du changement d'adresse.

La problématique soulevée dans le cas antérieur est de bien s'assurer que la CoA appartient bien au MN. En l'occurrence, le CN doit s'assurer que le BU initialement envoyé du MN vers le CN provient bien du MN. Cette authentification est fournie par le mécanisme appelé Return Routeability.

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

1. MN envoie deux messages avec un cookie au CN :

2. Home Test init (HTi) envoyé via HA (ce chemin est encrypté).

3. Care of Test init (CTi) envoyé directement au CN.

4.

Figure 7. Return Routability

Il les reçoit, il construit 2 keygen-tokens qu'il renvoie au CN, lequel lui envoie enfin un BU signé avec une clé spéciale. Après cela, le CN est sûre que MN est accessible par les deux routes.

Dans MIPv6, IPsec est requis uniquement pour
l'échange des messages de signalisation entre le HA et
le MN, et entre le MN et le CN pour le test de Return

Routability.