4.4.2 Test2 : scénario de Mobilité
Figure 29. Scénario de Mobilité et
messages échangés
La configuration initiale de ce test est
constituée par une politique de sécurité et deux SA qui
créent une connexion sécurisée entre les deux noeuds. La
Mobility_Application émule la détection de la mobilité et
avant changer l'adresse @1.5 par la @1.4 elle dirige l'API_IPsec local et
distante pour maintenir la connexion sécurisée après la
mobilité.
À la base, l'échange de messages est le
même qu'on a expliqué dans le première test. Par contre,
dans ce cas on a développé deux possibles messages pour la
mobilité (présentés dans la part final de la section
4.3.4). Ci-dessous on montre ses structures. Pour ce test on à choisit
le paquet plus petit et performante, implémenté par la fonction
« mobility_all (sfd, @adr, @adr_new ) », car il peut changer toutes
les adresses de la SAD.
Figure 30. Détail des messages de
MOBILITÉ développés. On choisit le message plus petit et
performant
Configuration
Client (@1.5) :
> sudo ifconfig eth0 192.168.1.5 > sudo setkey -f
ISACLI_2
flush; spdflush;
#SPD(inversed isaser)
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
spdadd 192.168.1.1 192.168.1.5 tcp -P in ipsec
esp/transport//require; spdadd 192.168.1.5 192.168.1.1 tcp -P out ipsec
esp/transport//require; #SAD(same isaser, only change in/out idea)
add 192.168.1.1 192.168.1.5 esp 1001 -E des-cbc
0x3ffe05014819ffff ; #spd in add 192.168.1.5 192.168.1.1 esp 1002 -E des-cbc
0x3ffe05014819ffff ; #spd out
Serveur (@1.1) :
> sudo ifconfig eth0 192.168.1.1
> sudo setkey -f ISASER_2
flush; spdflush;
#SPD (inversed isacli)
spdadd 192.168.1.5 192.168.1.1 tcp -P in ipsec
esp/transport//require; spdadd 192.168.1.1 192.168.1.5 tcp -P out ipsec
esp/transport//require; #SAD (same isacli), only change in/out idea
add 192.168.1.1 192.168.1.5 esp 1001 -E des-cbc
0x3ffe05014819ffff ; # spd out add 192.168.1.5 192.168.1.1 esp 1002 -E des-cbc
0x3ffe05014819ffff ; # spd in
Résultats
On présente et analyse tous les résultats
dans la section 4.4.6.
Figure 31. Exemple d'une capture avec Wireshark des
messages échanges dans le Test de la Mobilité
4.4.3 Test 3 : scénario de Multihoming
Figure 32. Scénario de multihoming et messages
échangés
Ce Test part de la même configuration initiale
que le deuxième test, et l'échange de messages résulte
aussi identique. Par contre, pour effectuer le multihoming on utilise le
suivant message implémenté par la fonction « multihoming
(sfd, *idext, flow, flags) ».
|
Étude d'IPsec
Projet d'une
API_IPSEC pour la Mobilite et le Multihoming
|
|
|
Figure 33. Détail du message de multihoming
encapsulé
Configuration
Même configuration que dans le Test 2.
Client (@1.5)
> sudo ifconfig eth0 192.168.1.5 > sudo setkey -f
ISACLI_2
Serveur (@1.1)
> sudo ifconfig eth0 192.168.1.1 > sudo setkey -f
ISASER_2
Résultats
On obtient les mêmes captures qu'avec le Test 1
avec des temps très proches mais utilisant une taille des paquets plus
élevée (regarder la table comparative de la section 4.4.6). Cela
est lié à l'implémentation parce que le traitement des
opérations de multihoming, un COPY à la base, est moins lourde de
traiter que additionner une nouvelle SA oil il faut créer la SA par
défaut et puis faire un UPDATE de chacun des paramètres qu'on
veut différentes.
| 
