4.1.5 Intégration d'OpenIKEv2
L'API_IPsec doit gérer les bases IPsec ainsi
que les contextes liés à IKEv2. On a envisagé d'avoir
accès aux fonctionnalités d'IKEv2 en utilisant OpenIKEv2, une
implémentation ouverte développé en C++. OpenIKEv2 permet
:
- Un canal ou un moyen de communication API_IPsec -
IKEv2 pour faire une gestion de clés et de l'authentification seulement
quand on aura besoin. Dans ce cas, l'idée n'est pas d'intégrer
les fonctions sinon d'exécuter le démon IKE.
- Intégrer dans l'interface de la couche IPsec
les fonctions d'openIKEv2, basés en XFRM, pour gérer la SAD/SPD
n'utilisant plus les fonctions PF_KEY2.
4.1.6 Limitations de cette première version
L'implémentation de l'API_IPsec au cours de ce
stage est essentiellement une preuve de concept, bien que nous ayons
constamment cherché au cours de nos développements à lui
donner les aspects d'un projet finalisé, nous avons choisie quelques
restrictions afin de pouvoir respecter le calendrier de développement.
En conséquence, il est hors du stage réalisé les suivants
éléments ou aspects:
- La PAD (Privilege Application Database) est
relativement récente dans l'architecture d'IPsec. Elle est
définie dans la spécification d'IPsecv2, mais aucune
implémentation n'est disponible actuellement. Alors, on a
décidé de ne pas la considérer dans le projet bien qu'elle
est une pièce très importante.
|
Étude d'IPsec
Projet d'une
API_IPSEC pour la Mobilite et le Multihoming
|
|
|
- La création d'une version totalement
multithread. Toutes les applications et les API_IPsec distantes
connectés à l'API_IPsec seront servies par des threads
dédiés. Ils partageront la même mémoire et les
mêmes données, et il faudra donc mettre l'accent par exemple sur
l'introduction de sémaphores, de variables de condition, dans toute le
code du projet afin d'éviter la collision ou la perte de données
lors d'accès concurrentiels. Cette problématique nécessite
pour être traitée une grande charge en terme de temps d'analyse du
code. On priorisera donc de réaliser une première version
monothread de l'API_IPsec qui fonctionnera avec soit une application soit une
API_IPsec distante. Le problème de mémoire partagée est
alors temporellement résolu et on peut se concentrer sur l'architecture
de l'API_IPsec.
4.2 L'API_IPsec et la mobilité 4.2.1 La
Mobility_Application
On a défini l'application MA
(Mobility_Application), un démon détecteur de changements ou de
besoins de mobilité/multihoming dans la machine, qui s'appuiera sur
l'API_IPsec et lui permettra de gérer les associations de
sécurité entre différents noeuds dans ces cas.
Dans ce stage on ne s'occupera pas de la partie de
changement d'interface et on développera la part de la MA qui fait
l'interaction avec l'API_IPsec. Dans notre cas, et dans le cadre du Prototype,
la MA émulera les changements d'interfaces pour effectuer les tests qui
valideront l'API_IPsec dans un scénario de mobilité et de
multihoming.
4.2.2 API_IPsec versus MOBIKE
Aujourd'hui l'unique solution qui pourrait faire la
concurrence à l'API_IPsec est MOBIKE qui permet également de
gérer les associations de sécurité d'une connexion lors de
la mobilité d'un des deux noeuds. Toutefois, MOBIKE a les limitations
suivantes par rapport à l'API_IPsec :
- MOBIKE ne fonctionne que dans le mode tunnel.
L'API_IPsec permet aussi le mode transport.
- MOBIKE peut gérer qu'une interface en
changement : celle entre le mobile MN et la Security Gateway. L'API_IPsec
effectue les changements indépendamment du scénario et elle n'a
pas besoin d'être connecté à une Security Gateway.
L'API_IPsec prend en compte également les scénarios de
mobilité avec MIPv6 et SANS MIPv6.
- MOBIKE est spécifique pour la Mobilité
et ne gère qu'une interface à la fois. L'API_IPsec permet aussi
gérer le Multihoming et avoir plusieurs interfaces de manière
simultanée.
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
| 
