4.2.3 Description du scénario de
Mobilité et de Multihoming
Dans le cas de la Mobilité on considère
un terminal mobile qui possède initialement une adresse IP
[interface1@src1] et qui communique avec un noeud distant sur l'adresse @dst.
On suppose que les deux noeuds possèdent l'API_IPsec. Une association de
sécurité est négociée entre l'adresse @src1 et
l'adresse @dst. On suppose que le mode choisi est le mode transport (la
communication est de point à point).
Le terminal change d'adresse IP @src2 et n'est plus
joignable par l'intermédiaire de l'adresse @src1. L'idée est donc
de considérer les paramètres de l'association de
sécurité entre @src1 et @dst et de la « transférer
» en changeant @src1 par @src2. Des protocoles comme MOBIKE permettent un
tel transfert mais uniquement avec un mode tunnel.
Le terminal va donc envoyer un message indiquant
qu'il a procédé à un changement d'adresse dans un cadre de
mobilité. L'API_IPsec va procéder de part et d'autre aux
changements sur le serveur et sur le terminal.
Figure 18. IPsec dans un contexte de
Mobilité
Le cas du Multihoming ressemble à celui de la
Mobilité à la différence que dans un cadre de Multihoming
le terminal acquiert une nouvelle adresse et reste néanmoins joignable
sur la précédente. La problématique est donc similaire et
l'on souhaite éviter de renégocier une association de
sécurité entre @src2 et @dst si l'on a déjà
établie une association de sécurité entre @src1 et @dst.
Par ailleurs des options doivent également permettre aux associations de
sécurité d'être dérivées d'une association
sans pour autant en être l'exacte réplication.
Figure 19. IPsec dans un contexte de
Multihoming
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
4.3 Le Prototype
Cette partie décrit le développement
réalisé.
4.3.1 Description générale
L'API_IPsec a été
développé en langage C. Cette première version a environ
10.000 lignes de code. La suivante figure présente le schéma des
fichiers source qui constituent l'API_IPsec et leur interrelation entre ses
trois interfaces et avec la base de données.
Figure 20. Schéma des fichiers source de
l'API_IPsec
Ensuite on détaille la fonction de chaque fichier
source:
- «APIC.c» est le fichier principal de
l'API_IPsec qui est exécuté après la compilation et le
linkage avec tous les autres fichiers et librairies nécessaires du
projet. Il permet deux modes d'exécution: le mode "menu", qui offre une
interface utilisateur en mode console (avec l'activation de la partie «
apiipsec » pour gérer la couche IPsec directement); et le mode
"server", oil les fonctionnalités son exécutées via
l'envoie de messages. Le mode serveur ouvre toutes les fonctionnalités
et crée à la fois deux serveurs principaux multithreadés,
un pour la connexion des applications et l'autre pour des API_IPsec
distantes.
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
- « fdb.c » contient toutes les fonctions pour
accéder et modifier la base de données. Il est divisé en
fichiers spécialisés pour accéder à chaque table :
«fdb_sa» pour DB_SA, «fdb_sp » pour DB_SP, etc.
- « apiipsec.c » permet accéder aux
fonctions IPsec qui interagissent avec l'interface PFKEYv2 pour modifier la
SAD/SPD. On envoie les messages spécifiques de PFKEY
présentés dans la section 3.1.2, partie interfaces d'IPsecv2, de
l'étude théorique.
- « process.c » traite les messages qui
arrivent au serveur dédié. Il s'appuie sur « apx_msg_gen
» pour en faire l'extraction des données ou pour créer les
messages de réponse. C'est lui qui renvoie au module adéquat
(« fdb », « apiipsec », « synchro » ou «
socket Remote » pour l'API_IPsec distante) les actions que les messages
demandent et qui en prend les réponses ou résultats.
- « synchro.c » permet pour l'instant de
synchroniser la DB avec la SPD/SAD. L'idée est que la DB contient la
vraie information qu'on peut changer, et après une synchronisation on
fait la mise à jour de la SPD/SAD. L'exception est au début
d'exécution de l'API_IPsec quand elle fait une image de la SPD/SAD dans
la DB.
Tout le prototype est basé sur les fichiers
headers suivants :
- « api_include_basic.h » spécifie les
headers du système pour compiler.
- « api_structs.h » déclare la
structure des éléments (une SA, une SP ...), des listes ou des
tables de la base de données, ainsi que toutes les constants et
énumérations utilisés liées.
- « api_msg_structs.h » déclare les
différentes structures pour former un message (HEADER, dm_FUNCTION,
dm_RESPONSE ... qu'on a expliqué dans la section 4.1.4) et les constants
et énumérations liées.
| 
