WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Xavier FERRER CABALLERO
Supélec - Ingénieur réseau 2008
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

4.4.1 Test1 : Scénario permanente

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 :

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.

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

 
 

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Ceux qui vivent sont ceux qui luttent"   Victor Hugo