4.4.1 Test1 : Scénario permanente
![](Projet-dune-API-IPSEC-pour-la-mobilite-et-le-multihoming125.png)
Figure 26. Scénario permanente et messages
échangés pour la création d'un canal
sécurisé
Initialement dans ce test on installe deux politiques
de sécurité à partir lesquelles l'API_IPsec doit
créer les associations de sécurité pour former une
connexion sécurisée. Cela permettra de faire une comparative avec
IKEv2, qui a besoin de partir d'une configuration déjà
établie de la SPD que, par contre, l'API_IPsec peut manager. On
considère deux possibles configurations avant le test :
- On configure les SP seulement pour sécuriser le
protocole ICMP. Cela permet de ne pas bloquer l'API_IPsec qui utilise le
protocole TCP et de voir ses échanges de messages en claire.
- On configure les SP sur tous les protocoles, et on
ajoute une règle qui fait l'exception au PORT_APIAPI de l'API_IPsec.
Cela est un mécanisme pareil auquel utilise IKEv2 pour transmettre ses
messages.
Pour simplicité de configuration on a choisi la
première. Au début l'application « ping », qui marche
sur le protocole ICMP, est bloquée : il existe des SP mais pas des
SA. Puis la Mobility_Application se connecte à l'API_IPsec locale et
aussi à l'API_IPsec distante. Ensuite elle utilise la fonction
développé
|
Etude d'IPsec Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
« db_add_sa (sfd, spi, @src, @dst,
mode, type); » pour créer deux SA et sécuriser la
connexion pour le ping. Cette fonction envoie un
message REM_MSG_FUNCTION 1 qui encapsule les actions à réaliser
à l'API_IPsec distante et locale. Voici le contenu de ce message
:
![](Projet-dune-API-IPSEC-pour-la-mobilite-et-le-multihoming128.png)
Figure 27. Messages utilisés par la
Mobility_Application : ADD et SYNCHRO
Après recevoir la confirmation (APX_MSG_ACK)
de l'API_IPsec distante du serveur, la Mobility_Application envoie un message
de synchronisation pour les deux machines. Quand les associations de
sécurité de la SAD des deux noeuds sont correctement
synchronisées et opérationnelles, le « ping » est
automatiquement débloqué. Ainsi, on peut mesurer avec Wireshark
le temps nécessaire pour créer cette connexion
sécurisée.
Configuration
Client (@1.5):
> sudo ifconfig eth0 192.168.1.5
> sudo setkey - f ISACLI_1
flush; spdflush;
#SPD(inversed isaser)
spdadd 192.168.1.1 192.168.1.5 icmp -P in ipsec
esp/transport//require; spdadd 192.168.1.5 192.168.1.1 icmp -P out ipsec
esp/transport//require; Serveur (@1.1) :
> sudo ifconfig eth0 192.168.1.1
> sudo setkey - f ISASER_1
flush; spdflush;
#SPD (inversed isacli)
spdadd 192.168.1.5 192.168.1.1 icmp -P in ipsec
esp/transport//require; spdadd 192.168.1.1 192.168.1.5 icmp -P out ipsec
esp/transport//require;
Résultats
On présente et analyse tous les résultats
dans la section 4.4.6.
![](Projet-dune-API-IPSEC-pour-la-mobilite-et-le-multihoming129.png)
Figure 28. Une capture avec Wireshark des messages
échanges dans le Test du scénario permanent
|
Etude d'IPsec Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
|