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

Mesure de performance	1. Scénario Statique			2. Mobilité			3. Multihoming
Mesure de performance	API_IPsec	IKEv2		API_IPsec	MOBIKE		API_IPsec
(authentification)	btns	PSK	certificat	btns	PSK	certificat	btns
Num. Paquets	3	4	4	3	4	4	3
*()**				11			11
Num. Bytes	728	1845	3524	640	1885	3565	828
*()**	1194			1106			1294
Temps Moyen**	0,0025	0,245	0,268	0,0015	0,25	0,32	0,0022
*()**	0,0045			0,0032			0,0042

(*) On peut considérer le nombre de paquets utilisés par l'API_IPsec à 3 parce que c'est le protocole de
messages qu'on a développé. L'utilisation de TCP ajoute des paquets supplémentaires liés au protocole

TCP. L'ouverture de la socket génère trois paquets TCP, la fermeture 2, et chaque paquet de l'API génère un paquet TCP. Au total cela fait un total de 11 paquets.

On observe clairement que l'API_IPsec obtient des temps très performants par rapport à IKE ou MOBIKE, d'un facteur cent, dans les scénarios de permanente et de mobilité. En effet, le protocole de messages de l'API_IPsec est optimisé à trois messages, un de moins que les autres. Par contre, on est conscients que ces avantages sont à nuancer :

- La charge d'IKEv2 est plus lourde parce qu'il fait de l'authentification, soit avec une Pre-SharedKey soit avec des certificats. Il gère plus de données et il a donc besoin de plus de temps pour établir les connexions de sécurité. â vue des mesures et des paquets analysés dans Wireshark, MOBIKE semble avoir un comportement similaire à une négociation de SA via IKEv2. Il ne devrait pas procéder à de l'authentification lors d'un scénario de la mobilité. MOBIKE devrait se contenter d'envoyer un ADDRESS_SA_UPDATE à travers d'un message INFORMATIONAL.

- L'implémentation des messages avec le protocole de transport TCP fait que le nombre de messages est le double en réalité. À la vue des performances obtenues, on ne considère pas cela comme problématique. Le transport utilisé pour la communication des messages de l'API_IPsec est au stade de prototype. La communication se fait directement sans aucune précaution de sécurité. Les travaux futurs de l'API_IPsec devront prendre en compte une communication sécurisée. Pour cela différentes pistes sont à considérer comme l'utilisation d'une communication HIP, l'intégration à IKE, un canal SSL... Ces mécanismes auront nécessairement un impact sur les performances futures de l'API.

Dans ce projet de stage on a spécifié et implémenté la première version de l'API_IPsec.

Dans ce rapport, l'Étude Théorique présente IPsec de manière résumée en essayant de transmettre les concepts les plus importants pour comprendre son Architecture (IKEv2, les bases de données, la liaison des différents éléments, etc.). Il ne s'agit en aucun cas d'une documentation explicite d'IPsec, la partie la plus centrale de notre étude étant les interactions entre IPsec et la Mobilité ou le Multihoming. La section "IPsec et la Mobilité" présente un état de l'art de la Mobilité et du Multihoming. Cela inclut une présentation des protocoles MIPv6, HIP, les travaux récents de l'IETF avec leurs interactions avec IPsec.

Ce cadre d'étude a permit de créer une bonne base de connaissances pour spécifier une première ébauche ou définition de l'API_IPsec. Cela comprend la définition des interfaces à introduire (l'interface applicative, l'interface distante et l'interface avec la couche IPsec) ainsi que le format des messages (API_IPsec Messages : AIM), le fonctionnement globale dans l'architecture d'IPsec, et la base de donnée centrale : les tables pour gérer tous les éléments autour d'IPsec comme la SAD/SPD, la mobilité, le multihoming, l'intégration d'IKEv2, etc. En effet, il a fallut bien spécifier l'architecture globale afin de définir clairement les parties ou fonctionnalités que l'on a développées et les limitations de ce premier projet, sans pour autant compromettre les interactions avec fonctionnalités qui feront l'objet d'un développement ultérieur. En ce sens, la définition de la base de donnée centrale représente un choix crucial qui a impacté toute l'architecture de l'API.

Puis le développement d'un premier Prototype a été tout un événement. On a d'abord considéré le code d'un programme existant et développé dans les laboratoires de France Télécom R&D pour se familiariser avec la couche IPsec et ses bases de données associées. Ensuite, les fonctions de bases ont été programmées. Elles permettent de gérer la couche IPsec directement depuis la couche applicative. Après, on a procédé à la mise en place des dialogues, utilisant le protocole de messages AIM, entre les applications et l'API, et les APIs "remote". Enfin on a traité l'autre but du stage qui était de gérer les associations de sécurité dans un cadre de Mobilité et de Multihoming. Cela a nécessité de la spécification des messages encapsulés permettant l'optimisation du protocole, ainsi que la mise en place d'un Démonstrateur qui a permit aussi la validation de l'API_IPsec. C'est sur ce Démonstrateur que l'on a procédé à une série de tests permettant la comparaison et évaluation de quelques performances par rapport aux protocoles standardisés comme IKE, pour la négociation et établissement d'associations de sécurité, et son extension MOBIKE, pour gérer un scénario concrète de mobilté. Le résultat a été très satisfaisant car l'API_IPsec procède beaucoup plus rapidement que ces homologues. Par contre, beaucoup d'améliorations doivent encore être à réaliser afin de considérer l'API comme finalisée.

Enfin, on a présenté le fonctionnement de l'API IPsec et de ses avantages à plusieurs Laboratoires de France Télécom et des équipes de France Télécom devraient prendre en charge le développement complet de l'API_IPsec.

Ce stage, ce projet et les résultats obtenus ont été très satisfaisants. En effet, le stage a su allier à la fois des aspects de recherche et opérationnels. J'ai pu me sensibiliser aux problématiques liées à la sécurité, et notamment IPsec ainsi qu'à celles liées à la mobilité et à la gestion de plusieurs connexions simultanées. Durant l'étude théorique j'ai du interagir avec de nombreuses personnes au sein de l'équipe afin de bien cerner les problématiques. Ensuite je suis passé à une phase de spécification, puis à une phase de développement. Il a fallu faire des choix de développement afin de pouvoir présenter un premier résultat et effectuer certaines mesures. Les choix à effectuer ont été déterminants par rapport aux résultats du stage, car une mauvaise gestion n'aurait pas permis la réalisation du démonstrateur final. J'ai également apprécié les activités de communication sur mes travaux et leur avancement auprès de différents laboratoires, et au sein de France Télécom R&D par l'intermédiaire d'un article dans la revue interne.

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

4.4.6 Comparative API_IPsec versus IKEv2 / MOBIKE