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

RAPPORT DE STAGE

DE FIN D'ETUDES

/

Etude d'IPsec

Projet d'une API_IPsec

pour la Mobilité et le Multihoming



France Télécom Recherche et Développement 38-40, rue du Général Leclerc

92794 Issy-les-Moulineaux Cedex 9

Présentation en Septembre, 2008

Étudiant :

Xavier FERRER CABALLERO

Responsable de stage de France Télécom : M. Daniel MIGAULT

Enseignants de Supélec Rennes :

M. Christophe MOY, M. Gilles TOURNEUR

	Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming
	Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Sommaire

SOMMAIRE 3

RESUME 5

1. FRANCE TELECOM RESARCH & DEVELOPMENT 6

2. DESCRIPTION DU STAGE 7

2.1 CONTEXTE ET PROBLEMATIQUES 7

2.2 OBJECTIFS 8

2.3 TRAVAIL REALISE 9

2.4 PLANNING 9

3. ÉTUDE THEORIQUE 10

3.1 IPSEC 10

3.1.1 Introduction : besoins de sécurité sur IP 10

3.1.2 Présentation d'IPsec 11

3.1.3 La gestion de clés : IKEv2 14

3.1.4 Architecture IPsec 16

3.2 IPSEC ET LA MOBILITE 17

3.2.1 Définition de la mobilité et du multihoming 17

3.2.2 MIPv6 et IPsec 17

3.2.3 MOBIKE 19

3.2.4 PF_KEY et MIP: solution dans le "bootstrapping" 20

3.2.5 PF_KEY et MIP: solution "database" 21

3.2.6 HIP 22

4. LA SOLUTION API_IPSEC 24

4.1 DEFINITION DE L'API_IPSEC 24

4.1.1 Interfaces 25

4.1.2 Fonctionnement global 25

4.1.3 La base de donées DB 26

4.1.4 Le protocole AIM: API_IPsec Messages 28

4.1.5 Intégration d'OpenIKEv2 29

4.1.6 Limitations de cette première version 29

4.2 L'API_IPSEC ET LA MOBILITE 30

4.2.1 La Mobility_Application 30

4.2.2 API_IPsec versus MOBIKE 30

4.2.3 Description du scénario de Mobilité et de Multihoming 31

4.3 LE PROTOTYPE 32

4.3.1 Description générale 32

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4.3.2 Serveurs Multithread 33

4.3.3 Création de messages. Liste de fonctions 36

4.3.4 Messages pour les applications. Liste de fonctions 39

4.3.5 Traitement des messages pour l'API_IPsec distante 41

4.3.6 La compilation et le debug 42

4.3.7 Prototype de la Mobility_Application 42

4.3.8 Démonstrateur de l'API_IPsec 43

4.4 TESTS ET RESULTATS 43

4.4.1 Test1 : Scénario permanente 44

4.4.2 Test2 : scénario de Mobilité 46

4.4.3 Test 3 : scénario de Multihoming 47

4.4.4 Test d'IKEv2 (strongSwan) 48

4.4.5 Test de MOBIKE (strongSwan) 50

4.4.6 Comparative API_IPsec versus IKEv2 / MOBIKE 51

5. CONCLUSION 53

6. ANNEXES 55

6.1 FONCTIONS ET STRUCTURES DE L'API_IPSEC 55

6.2 COMPILATION : FICHIERS DE CONFIGURATION 55

6.2.1 Liste de commandes pour faire un projet avec « automake » 55

6.2.2 Configure.ac 55

6.2.3 Makefile.am 55

6.3 CONFIGURATION D'IPSEC AVEC « SETKEY » 56

6.4 CONFIGURATION DE « STRONGSWAN » 56

6.4.1 Fichiers et répertoires importants 56

6.4.2 Création de certificats au format X509 56

6.4.3 ipsec.conf 57

7. BIBLIOGRAPHIE 58

8. REFERENCES D'INTERNET 58

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Résumé

L'objectif du stage est de mener une étude du protocole IPsec et de développer une API_IPsec pour établir une connexion facile et transparente entre des applications qui s'appuient sur la sécurité de la couche IPsec. Cette API doit également comprendre une gestion de connections IPsec dans un cadre de mobilité et de multihoming. Il est donc nécessaire de développer à priori trois interfaces différentes: Application/API, API/couche-IPsec, API/API-Remote. Pour l'interaction entre couches on utilise un protocole de messages basiques. Enfin, cette étude est dans le cadre du groupe BTNS, un WG de l'IETF qui cherche à établir une sécurité en même temps légère et optimale.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

1. France Télécom Resarch & Development

France Télécom - Orange Group est le principal opérateur de télécommunications en France et un des plus importants dans le monde. Actuellement il a environ 191,000 employeurs et il sert presque 174 millions de clients dans le monde, avec une chiffre d'affaires d'entour 52 billion d'euros.

France Télécom R&D - Orange Labs constitue le réseau mondial d'innovation du Groupe. Elle regroupe 5000 collaborateurs, dont 3800 chercheurs répartis dans 15 laboratoires sur trois continents (8 en France et 7 répartis en Europe, Amérique et Asie). Chaque Orange Labs est ainsi intégré à son propre écosystème géographique, lui permettant de favoriser les partenariats et de contribuer et d'anticiper les avancées technologiques et l'évolution des usages partout dans le monde.

Les activités de recherche et de développement de chaque Orange Labs sont structurées en sept centres fonctionnels, lesquels répondent aux domaines qui constituent l'essentiel de la profession d'un opérateur. Ils sont les suivants :

- Residential and Personal Integrated Services (SIRP)

- Business Services (BIZZ)

- Middleware and Advanced Platforms (MAPS)

- Technologies (TECH)

- Core Network (CORE)

- Access Network (RESA)

- International Laboratories (ILAB)

Tous ces Centres de Recherche et de Développement (CRD) sont divisés en laboratoires, oil chacun a plusieurs Unités de Recherche et de Développement (URD).

Le CRD d'Issy-les-Moulineaux (près de Paris) oil je suis en train de faire mon stage est le MAPS, plus concrètement dans le laboratoire de Network and Service Security (NSS). Le laboratoire se concentre sur techniques, applications et protocoles pour protéger la infrastructure, les services, les données critiques et les clients du opérateur contre tout type d'actions hostiles. À cette fin, cryptologues et ingénieurs de réseau travaillent ensemble et partagent ses connaissances.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

2. Description du stage

Le stage établi une étude d'IPsec, dans un premier temps de manière général et après focalisé sur des situations de mobilité et de multihoming. Puis cela sert à définir une API_IPsec qu'ensuite est développé, testé et enfin évalué dans ce cadre. Cette partie explique en détail les problématiques qui motivent à la réalisation de ce stage, ainsi que les objectifs et le travail à réaliser pour obtenir un premier prototype et démonstrateur d'une API_IPsec.

2.1 Contexte et problématiques

Le laboratoire MAPS/NSS de France Télécom, liée au groupe de travail BTNS de l'IETF, étudie comment les applications et les communications entre terminaux peuvent tirer partie au maximum des mécanismes de sécurité implémentés au sien de la couche IPsec. Cette motivation vient des nombreux avantages qu'offre IPsec et qu'on justifiera plus tard, par rapport à d'autres protocoles de sécurité aussi très étendus (SSH, TLS, SSL...). Mais pour ce but il faut résoudre des enjeux et des limitations actuelles dans des situations d'aujourd'hui.

D'une part, les deux plus importantes spécifications d'IPsec (RF401-IPsecV1 et RFC4301-IPsecV2) sont normes qui décrivent son fonctionnement mais, mis à part certaines applications bien spécifiques (IKE...) et bien configurées ou quelques utilisateurs avertis, elles ne fournissent pas d'interfaces permettant aux applications d'interagir et de bénéficier de la couche IPsec.

Cette limitation permet alors de configurer seulement une sécurité IPsec ne tenant compte que de paramètres réseaux et non applicatifs. L'absence d'interactions entre les couche réseau et applicative débouchent alors sur des situations où, par exemple, une protection ou une authentification peut être effectuée à la fois ou niveau de la couche applicative (TLS, ...) et au niveau de la couche réseau (IKE, ...). Cette double protection est bien entendue inutile.

Pour répondre à ce problème de multiple authentification, le laboratoire MAPS/NSS prend de BTNS des solutions en recherche que peuvent habiliter une communication IPsec sans authentification, parmi d'autres techniques, pour la faire plus légère et optimisé .

D'autre part, la sécurité dans un cadre de mobilité et multihoming est en pleine recherche. Les protocoles actuels, soit SSH - TLS/SSL ou soit IKE/IKEv2 qui gère automatiquement IPsec, ils ne sont pas conçus pour ces situations : lors d'un changement des connexions de sécurité (mobilité) ou un héritage de sécurité à partir d'une connexion établie (multihoming) ils ont besoin de renégocier la sécurité. Mais au niveau de la couche IPsec on peut bien faire la mise à jour des associations de sécurité de manière moins

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

lourde et plus performante : c'est le concept d'une réutilisation ou d'une dérivation de données/clés, évitant autre fois les multiples négociations ou authentifications.

Des premières solutions dans ce domaine sont sorties. Il existe par exemple MIPv6 qui utilise IPsec uniquement pour authentifier le host en mobilité, ou MOBIKE (extension d'IKEv2) qui permet maintenir des connexions de sécurité (authentification et chiffrement) mais seulement en mode tunnel et sans considérer le multihoming. Par ailleurs des très récents protocoles comme HIP/SHIM6 utilisent déjà le principe d'une association de sécurité unique qui ne dépend pas des adresses IP utilisées sinon de l'identité des machines qui ne change pas.

Dans ce conglomérat de réalisations, le laboratoire MAPS/NSS souhaite faire la solution parfaite qui utilise et gère la couche IPsec et les fonctionnalités d'IKEv2, qui soit capable d'adapter et de créer des connexions de sécurité entre noeuds dans toutes les situations possibles de mobilité et multihoming, qui sert de base pour des protocoles supérieurs comme MIPv6, HIP et enfin qui soit l'interface facile et légère mais aussi puissante et performante de sécurité IPsec pour toutes les applications. Cette solution est l' « API_IPsec ».

2.2 Objectifs

En vue du contexte, des motivations et problématiques antérieures, les objectifs principaux sont :

- Définition de l'API_IPsec, et de ses interfaces et de sa base de données

o Fournir de primitives qui permettent de gérer facilement la couche IPsec par des applications à la fois sur le noeud et à distance.

o Optimiser les négociations IPsec dans le cadre de multihoming et de la mobilité en évitant les multiples authentifications et négociations

- Réaliser un premier démonstrateur d'API_IPsec :

o Développer une API_IPsec qui doit permettre de gérer l'ensemble des données IPsec.

IPsec comprend différentes bases de données qui doivent être cohérentes entre elles d'une part, ainsi qu'un protocole de négociation qui détient le contexte de négociation. Cette API devrait fournit une interface à ces différentes bases.

o Développer une Mobility_Application qui s'appuiera sur l'API_IPsec et lui permettra de gérer les associations de sécurité entre différents noeuds dans un contexte de Mobilité et de Multihoming.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

2.3 Travail realise

Étude théorique (2 mois):

- Étudier l'ensemble de protocoles d'IPsec, son architecture et ses implémentations.

- Étudier l'utilisation d'IPsec dans un cadre de Mobilité et de Multihoming (MM)

o Les protocoles associés (MIPv6, MOBIKE...) et les changements de données.

o L'état de l'art des dernières recherches ou nouvelles techniques proposées.

- Définir l'API_IPsec : sa fonctionnement, ses interfaces, sa base de données.

- Définir un scénario simple de mobilité et autre de multihoming que l'API_IPsec devra bien gérer. Prototype et Résultats (2,5 mois)

- Développer l'API_IPsec

- Développer deux applications qui s'appuient sur l'API_IPsec pour gérer le cas définis de MM.

- Tester le prototype

- Évaluer les performances de l'API_IPsec par rapport à IKEv2 / MOBIKE

Conclusions (0,5 mois)

- Rapport de stage

- Réalisation d'un brevet pour France Télécom R&D

2.4 Planning



Figure 1. Planning du stage

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

3. Etude Théorique

Cette étude théorique permet, dans un premier temps, d'établir une base de connaissances sur IPsec et ses protocoles associés afin de mieux mesurer les divers composants d'une Architecture de Sécurité basée sur IPsec. Le but n'est pas décrire ici en détail les protocoles avec tous ses "headers", ses "payloads" ou ses messages ; on se réfère au RFCs dans le cas échéant. Par contre, on se concentre sur les différences entre la seconde génération d'IPsec et la première, ainsi que sur les différentes implémentations existantes. Cela permettra de faciliter dans la partie technique l'encadrement de l'API_IPsec dans une architecture IPsec actuelle.

Dans un deuxième temps, on étudie les relations entre IPsec, la mobilité et le multihoming. On commence d'abord par définir ce qu'on entend par mobilité et multihoming, puis un État de l'Art des protocoles actuels ou des dernières ébauches de l'IETF qui traitent des aspects IPsec dans un cadre de mobilité. De manière analogue à l'étude précédente, on ne veut pas décrire de manière détaillée les divers protocoles. On se contente d'en exposer les principes sur le cas qui nous intéresse. Cela permettra de faciliter la définition de l'API_IPsec dans un cadre de mobilité ainsi que de donner des idées ou des méthodes pour manager la mobilité et le multihoming. Cette étude théorique servira également de base pour les développements futurs de l'API_IPsec.

3.1 IPsec

3.1.1 Introduction : besoins de sécurité sur IP

Avec IP sans IPsec, les données IP sont transportées sont contenues en clair dans les paquets. Il est donc possible, en écoutant le trafic réseau, de lire et de modifier les paquets soit le contenu (données) soit l'entête (adresse source, adresse destination ...). IP étant utilisé aussi bien pour les communications d'Internet qu'au sein des réseaux privées, ces faiblesses peuvent avoir de larges répercussions.

Les besoins classiques de sécurité auxquels doit répondre la couche IP sont :

- Confidentialité : les données ne peuvent être compréhensibles que par le destinataire final.

- Authentification : vérification de l'identité de l'émetteur supposé lors des données reçues.

- Intégrité : la modification des données par des intermédiaires ne peut pas être possible.

Les deux grandes classes de solutions cryptographiques d'aujourd'hui sont les systèmes de chiffrement à :

- Clés symétriques : une même clé sert à chiffrer et à déchiffrer. Elle est partagée uniquement par l'émetteur et le récepteur. Les algorithmes utilisés sont DES ou AES, et permettent d'assurer la confidentialité et l'intégrité des paquets.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

- Clés asymétriques : qui fait intervenir deux clés, une publique et une autre privée. Entre communicants, chacun garde sa clé privée et distribue aux autres sa clé publique. Deux cas sont à considérer : l'authentification et la confidentialité. Pour authentifier une donnée on chiffrera avec la clé privé, détenue par un noeud unique, et on déchiffrera avec la clé publique associée. On suppose que si l'on déchiffre avec la clé publique, le chiffrement a été effectué avec la clé privée. Pour assurer la confidentialité d'une donnée, c'est-à-dire pour qu'une donnée ne soit lu que par le propriétaire d'une clé privée, on chiffrera avec la clé publique associée. Seul le propriétaire de la clé privée associée pourra déchiffrer la donnée. Les algorithmes, comme RSA ou l'algorithme de Diffie-Hellman, sont basés sur des problèmes mathématiques de factorisation de grands nombres. Les opérations surtout de déchiffrement sont plus coûteuses que dans le cas du chiffrement / déchiffrement symétrique.

En général, pour la communication entre deux entités, on commence par utiliser un système à clés asymétriques pour s'authentifier et s'échanger un secret partagé qui est utilisé comme clé symétrique pour chiffrer les messages.

Pour plus de précision sur les systèmes cryptographiques, leurs types de faiblesses et d'attaques, les possibles scénarios... on se reportera à [1].

3.1.2 Présentation d'IPsec

IPsec (Internet Protocol Security) est un ensemble de protocoles permettant le transport de données IP sécurisées. Il comprend des mécanismes de chiffrement et d'authentification. L'IETF standardise ce protocole et son architecture depuis 1995, et publie des RFCs dont la plus important aujourd'hui est IPsecv2 [2]. Il a été décidé que IPsec serait obligatoire dans IPv6 et facultatif dans IPv4, mais avec un mécanisme identique.



Figure 2. Le protocole IPSec dans le modèle OSI

Les protocoles d'IPsec agissent au niveau de la couche de réseau (niveau 3 du modèle OSI). Il existe
d'autres protocoles de sécurité aussi très étendus. On peut citer SSH (Secure SHell) qui permet à un
utilisateur distant d'avoir un interpréteur de commande à distance sécurisé (chiffrement et

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

authentification). Il y a aussi TLS (Transport Layer Security), descendant de SSL (Secure Socket Layer), qui offre la possibilité d'ouvrir des sockets TCP sécurisées, mais les applications doivent alors explicitement faire appel à cette bibliothèque. Ces protocoles opèrent à partir de la couche de transport vers la couche applicative (niveau 4 à 7). L'utilisation d'IPsec permet de protéger d'avantage les données dès la couche 3. Son grand succès est qu'il sécurise toutes les applications et leurs communications audessus d'IP de façon transparente, évitant ainsi les vulnérabilités des couches supérieures.

Les protocoles de transformation d'IPsec

IPsec regroupe les trois mécanismes ou services de sécurité au niveau réseau :

- AH (Authentication Header) qui sert à valider l'intégrité des messages.

- ESP (Encapsulation Security Payload) qui sert à assurer la confidentialité des messages.

- IPcomp (IP compression) qui compresse les données qui transitent.

Les modes Transport et Tunnel

Il existe deux modes dans IPsec qui diffèrent par la méthode de construction des paquets IP des messages. Dans le mode transport seul les données sont protégées; par contre, dans le mode tunnel l'en-tête est aussi protégé.



Figure 3. Transformation AH, mode transport vs tunnel Figure 4. Transformation ESP, mode transport vs tunnel

Les bases de données : SPD, SADB, PAD

La SAD (Security Association Database) donne un contexte à chaque connexion unidirectionnelle IPsec, qu'on appelle SA ou « association de sécurité », regroupant l'ensemble de ces informations parmi les plus importants:

- L'index qu'identifie une SA : SPI (Security Parameter Index)

- les adresses @source et @destination

- le mode de la connexion IPsec (tunnel ou transport)

- le type de service de sécurité IPsec utilisé : ESP ou AH

- l'algorithme utilisé pour le service, et la clé utilisée

- Le temps de vie

Comme une SA est unidirectionnelle, protéger une communication classique requiert deux associations, une dans chaque sens.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

La SPD (Security Policy Database) spécifie les SP ou « politiques de sécurité », c'est-à-dire, les opérations IPsec que doit adopter le noeud sur les paquets sortant ou entrant. Chaque entrée SP est une règle qui fait correspondre à un paquet une opération IPsec. On définit le paquet grâce à des "selector" (le protocole de transport, le range d'adresses/ports source et destination). La "politique" ou comportement à appliquer comprend des informations de l'utilisation IPsec (none / require), du type mode (transport / tunnel), du type IPsec (AH, ESP), etc.

La PAD (Policy Authorization Database) est une base de données indiquant la manière dont un noeud doit être identifié, ou quels sont les identifiants qui doivent être pris en compte lors de la phase d'authentification.

Le trafic entrant et sortant

Trafic sortant : lorsque la couche IPsec reçoit des paquets sortants (la machine veut envoyer un paquet vers l'extérieur), le système vérifie dans la SPD quelle politique IPsec (SP) doit être associée à ce paquet. S'il existe une politique IPsec, le système va rechercher s'il existe une SA qui correspond à cette SP. Si le système trouve la SA correspondant, le paquet se voit appliquer les règles définies dans la SA, sinon le système va appeler le démon IKE pour négocier une SA avec le noeud destinataire du paquet. Cette SA doit satisfaire les SP des deux noeuds.

Trafic entrant : lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine l'en-tête pour savoir si ce paquet s'est vu appliquer un ou plusieurs services IPsec et si oui, quelle SA. Elle consulte alors la SAD pour connaître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Dans IPsecv1, une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si la SA appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Dans le cas oil le paquet reçu est un paquet IP classique, la SPD permet de savoir s'il a néanmoins le droit de passer.

IPsecV2 : nouvelles fonctionnalités

IPsecV2 [2] est la nouvelle révision d'IPsec qui suit le même protocole et architecture présentés, mais qui incorpore de fonctionnalités ou éléments plus performants [2.1]. Les plus importants qu'on considère dans ce projet sont :

- Pour indexer une SA il n'y a pas besoin de connaître le triplet complet <spi, @source et
@destination, type>. On peut faire de recherches ou de comparassions avec un seul paramètre.

- SPD plus flexible. On a plus de "selectors" ce qui permet plus de granularité pour définir des règles. On justifiera dans la partie de mobilité l'avantage de cela.

- On définie l'indicateur Packet Flag Population (PFP) qui fait la relation entre les valeurs des "selectors" dans la SPD et dans la SAD.

- La SPD n'est pas consultée systématiquement lors de la réception de paquets.

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Interfaces d'IPsecV2 : PF_KEYv2 (implémentation "setkey") et XFRM

PF_KEYv2 Key Management API [3] fournit une interface de communication entre les applications (user-land) et le noyau (kernel) pour manager la SAD. La communication se fait avec l'envoi de paquets à travers d'un socket PF_KEY. Les réponses du noyau sont souvent envoyées à tous les sockets. PF_KEY permet les suivants messages et opérations (avec paramètres différentes) aux applications :

- SADB_ADD, SADB_UPDATE, SADB_DELE TE : opérations pour ajouter, actualiser et effacer une SA.

- SADB_GETSPI : demander le SPI d'une SA à partir des adresses, le mode et le type.

- SADB_GET : obtenir une SA dans des registres spéciaux oil les applications peuvent accéder.

- SADB_FLUSH : effacer toutes les entrées de la SAD.

- SADB_REGIS TER : ouvrir un socket pour être notifiés quand le kernel reçoit paquets qui requirent

une type de SA (AH, ESP...) que n'existe pas encore.

- SADB_DUMP : imprimer toutes les entrées de la SAD. Utile pour debugger.

PF_KEY permet au kernel envoyer les suivants messages :

- SADB_ACQUIRE : pour notifier aux applications registrées avec REGISTER.

- SADB_EXPIRE : pour notifier aux applications que le temps de vie d'une SA est expiré.

PF_KEY a été utilisé aussi pour gérer la SPD à partir de ses messages et quelque petite extension. Il existe l'implémentation « setkey » en Linux qui est basé en PF_KEY et qui permet de faire une configuration manuelle d'IPsec. On l'utilise beaucoup dans la partie technique pour configurer les noeuds avant les tests. Dans la section 6.3 de l'Annexe on présente quelques exemples d'utilisation.

XFRM est autre interface qui permet aussi gérer la SAD/SPD du noyau mais avec un langage complètement différent à PF_KEY. On n'a pas trouvé de références, de manuels/tutoriales ou même d'information, seulement le header «xfrm.h » dans le répertoire du noyau. Par contre, il y a quelques implémentations que l'utilisent, comme les qu'on veut utiliser pour IKEv2 et qu'on présente plus tard.

En conséquence, on n'a pas considéré pour l'API_IPsec l'utilisation de XFRM mais de PF_KEY comme interface directe pour gérer la SAD/SPD.

3.1.3 La gestion de clés : IKEv2

IKE (Internet Key Exchange) est un protocole qui permet, lorsque deux noeuds souhaitent communiquer entre eux via un canal IPsec, l'authentification et la négociation du matériel cryptographique en accord avec les SP respectives, pour enfin la mise en place des SA. Il est implémenté sous la forme d'un démon. La spécification de IKEv2 [4] synthétise les différentes fonctionnalités de IKEv1 (documenté dans plusieurs RFCs) ainsi que des fonctionnalités introduites par les diverses implémentations de IKEv1 (comme par exemple les extensions permettant l'utilisation d'IPsec à travers les réseau NAT, l'héritage d'authentification...). Ainsi, IKEv2 est une récriture de IKEv1 [4.1] qui préserve la plus part des

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

fonctions d'IKEv1 (cacher l'identité, deux phases, négociation cryptographique...), qui fixe plusieurs problèmes d'IKEv1 trouvés pendant sont déploiement ou analyse, et qui améliore le protocole afin de la rendre plus efficace, plus robuste et plus interoperable.

Le principe du protocole IKE

Le principe devient justement le même qu'on applique pour le trafic sortant (expliqué dans le point antérieur). Il existe une exception à ce principe : les paquets IKE ne sont jamais soumis à IPsec par un ajout d'une règle précisant de ne pas utiliser IPsec dans ce cas. Cela permet de casser le problème de l'oeuf ou de la poule (pour mettre en place IPsec, on ne peut pas utiliser IPsec). A noter qu'IKE effectue ses échanges au-dessus du niveau transport (UDP, port 500, en général). Cela permet bien de découpler la négociation IPsec des fonctionnalités d'IPsec.

Les phases d'IKE

IKEv2 se décompose en deux phases pour négocier les SA:

- La première phase permet de vérifier l'identité des entités en présence. On choisit les algorithmes de cryptographie utilisés pour les futures négociations. Á la fin de cette phase, chaque entité doit disposer d'une clé de chiffrement, d'une clé d'authentification et d'un secret partagé qui servira de "graine" dans la phase suivante (on produit une clé en fonction de valeurs déjà calculées).

- La deuxième phase permet de négocier les attributs plus spécifiques à IPsec (utilisation d'AH ou d'ESP par exemple), ces échanges sont chiffrés et authentifiés grâce aux éléments décidés lors de le première phase.

Il y a un intérêt à ce découpage. La première phase fait appel à de la cryptographie asymétrique lente, elle est de plus utilisée qu'une seule fois pour définir les paramètres qui vont permettre de sécuriser les échanges de phase 2. La phase 2 est en revanche appelée plusieurs fois. En effet, les clés qui servent à chiffrer deviennent vulnérables avec le temps ou quand on s'en sert beaucoup. Cette phase est donc régulièrement re-effectuée pour changer certaines clés de sessions.

Implémentations d'IKEv2 : on choisit strongSwan et OpenIKEv2

Il existe plusieurs implémentations d'Open Source d'IKEv2, qui utilisent une interface IPsec basée soit en XFRM soit en PFKEY2. Voici une comparative actualisée qui détaille ses fonctionnalités:

Features	openikev2	racoon2	ikev2		strongSwan	Version
0.94	20/07/2007	2.0alpha	4.1.2		Cookies; Negotiation: DH group, Proposal, Traffic selector
Yes	Yes	Yes	Yes		Narrowing
Yes	No	Yes	Yes		Preshared-Key & Certificate Authentication
Yes	Yes	Yes	Yes		Child_SA/IKE_SA Rekeying, Deletion
Yes	Yes	Yes	Yes		Configuration Payload (Dynamic Addressing)
Yes	?	No	Yes

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Features	openikev2	racoon2	ikev2		strongSwan	NAT Traversal
No	Yes	Yes	Yes		EAP Support
Yes	No	Yes	Yes		Tunnel / Transport Mode IPSec
Yes	Yes	Yes	Yes		IPSec Interface
XFRM	PFKEYv2	PFKEYv2	XFRM		Perfect Forward Secrecy for CHILD_SAs
Yes	Yes	No	Yes		IPv6 support
Yes	Yes	Yes	Yes		Different configuration per peer
Yes	Yes	Yes	Yes		Repeated Authentication (RFC4478)
Yes	No	No	Yes		External API
Yes	No	No	No

Table 1. Comparative des implémentations IKEv2

Pour ce projet on a besoin de choisir des implémentations pour accomplir deux buts différents :

- Le premier consiste à étudier la viabilité d'intégrer IKEv2, totalement ou partiellement, dans l'API_IPsec. Dans ce cas on a la motivation de choisir « OpenIKEv2 » parce qu'il est programmé en C++ (on peut arriver à compiler l'API_IPsec développé en C avec OpenIKEv2) et c'est l'unique implémentation qui fournit une API externe d'IKE avec une bonne sorte de fonctions, d'objets et d'interfaces relativement facile à utiliser.

- Le deuxième consiste à réaliser des tests afin de comparer IKE et l'API_IPsec. Dans ce cas on choisit une ancienne implémentation «strongSwan» qui présente l'avantage d'être largement documenté au niveau des configurations des noeuds.

En conséquence, ces deux implémentations, OpenIKEv2 et strongSwan, sont installées, analysés et utilisés plus tard, chacune à sa tourne.

3.1.4 Architecture IPsec

L'architecture IPsec, d'accord avec l'information présentée, peut se résumer dans le schéma suivant :



Figure 5. Architecture IPsecv2

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

3.2 IPsec et la mobilité

3.2.1 Définition de la mobilité et du multihoming

On parle de la « mobilité » quand l'adresse IP d'une machine (ou un hôte ou un noeud) est changée. Plusieurs cas de figure peuvent se présenter lors du changement, et il faut spécifier les différents cas par rapport aux interfaces de connectivité de la machine. Considérant une machine qui dispose de plusieurs interfaces de connexion, on définie alors:

- Mobilité : quand une machine change son point de connexion et il reçoit une nouvelle adresse IP, sur la même interface.

- Multihomming : quand une machine change à une interface différente elle obtient logiquement autre adresse IP. Mais, par contre, elle maintient aussi l'adresse antérieure dans l'autre interface et peut utiliser les deux en même temps ou switcher de l'une à l'autre.

La littérature [5] définit un cas de multihoming qui considère un noeud qui bien que disposant de deux
interfaces n'en utilise qu'une à la fois. Ce cas permet en cas de chute d'un lien de passer sur l'autre lien.
Nous considérons, dans ce document, clairement ce cas comme un cas de mobilité et non de multihoming.

Terminologie dans un cadre de mobilité IP

Pour gérer la mobilité, l'IETF définit le protocole Mobile IP. MIP s'appuie sur une architecture spécifique et fait intervenir les concepts suivants:

- MN : Mobile Node. Noeud qui change son point d'accès alors qu'il est toujours accessible via HoA. - CoA : Care of Address. Une adresse IP physique du MN quand il visite un réseau distant.

- HoA : Home Address. Une adresse IP permanente du MN dans le réseau local. Le MN est toujours joignable via cette adresse IP, soit directement soit par le biais d'un HA.

- HA : Home Agent. C'est un router dans la réseau local qui représente le MN quand il a fait la mobilité donc il n'est pas attaché au réseau local.

- CN : Communicant Node. C'est un noeud avec qui le MN est en train de communiquer. Le CN peut être soit statique soit aussi mobile.

- Binding : c'est une association entre le HoA et le CoA du MN qui possède le HA pour renvoyer le trafic qui concerne le MN. Deux messages liés: le Binding Update (BU) et le Binding Acknowledge (BA).

3.2.2 MIPv6 et IPsec

Le protocole Mobile IP6 (MIPv6) et son architecture sont définis en [6]. L'objet de cette section est de décrire concrètement les scénarios de mobilité basés sur MIPv6 les plus usuels. Ces scénarios comprennent le cas oil le MN et le CN communiquent via le HA, et le cas oil les communications entre MN et CN se font directement, sans passer par le HA. On parle alors de "Route Optimization".

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

1. MN se connecte à un réseau distant.

2. MN envoie un BU au HA (il est sécurisé avec IPsec ESP en transport mode).

3. HA crée le "Binding" et il utilise un Proxy Neighbor Discovery (IPv6 équivalent au proxy ARP) pour représenter le MN dans le réseau local.

4. CN envoie au HoA tous les paquets destinés au MN. Directement ils seront encapsulés par le HA dans un tunnel et envoyés à l'adresse physique CoA du MN.

5. MN envoie des paquets vers CN par le tunnel, et le HA les renvoie depuis HoA au CN (dans les paquets l'adresse source CoA du MN est changé par HoA).

Le MN est relié par un tunnel au HA qui joue un rôle de "forwarder" soit en direction du MN, soit en direction du CN. Par contre, MIPv6 est complètement transparent pour le CN (uniquement le MN et le HA traitent des paquets spéciaux). Cette transparence à un prix au niveau du routage, et la communication n'est généralement pas optimale: le MN et le CN s'échangent des paquets en passant toujours par le HA.

Figure 6. Tunnel Mode en MIPv6

Pour palier à cet inconvénient le "Route Optimization" permet de construire un routage direct entre le MN et le CN. Cette optimisation ne se fait pas de manière transparente, et le CN doit implémenter MIPv6.

1. MN envoie un BU au CN. Ensuite il envoie du trafic au CN avec la CoA comme adresse source. Les paquets contiennent comme option de destination la HoA (option IPv6).

2. CN change l'adresse source par HoA avant passer le paquet aux couches supérieures.

3. CN envoie du trafic au MN avec CoA marqué comme adresse de destination. Les paquets ont un Routing Header spécial qu'indique la HoA comme deuxième noeud de destination possible. Cela signifie que du point de vue de l'application, ou des couches supérieures à la couche IP, le paquet devra présenter le HoA comme adresse de destination.

4. MN prend la HoA du Routing Header et efface cet en-tête. Il modifie l'adresse destination des paquets avec HoA et, enfin, il passe les paquets aux couches supérieurs qui espèrent trouver justement la HoA. Cette translation d'adresse permet de ne pas casser les connexions MIPv6 lors du changement d'adresse.

La problématique soulevée dans le cas antérieur est de bien s'assurer que la CoA appartient bien au MN. En l'occurrence, le CN doit s'assurer que le BU initialement envoyé du MN vers le CN provient bien du MN. Cette authentification est fournie par le mécanisme appelé Return Routeability.

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

1. MN envoie deux messages avec un cookie au CN :

2. Home Test init (HTi) envoyé via HA (ce chemin est encrypté).

3. Care of Test init (CTi) envoyé directement au CN.

4.



Figure 7. Return Routability

Il les reçoit, il construit 2 keygen-tokens qu'il renvoie au CN, lequel lui envoie enfin un BU signé avec une clé spéciale. Après cela, le CN est sûre que MN est accessible par les deux routes.

Dans MIPv6, IPsec est requis uniquement pour
l'échange des messages de signalisation entre le HA et
le MN, et entre le MN et le CN pour le test de Return

Routability.

3.2.3 MOBIKE

MOBIKE est une extension d'IKEv2 définie par [7][8]. MOBIKE considère seulement IPsec tunnels et pour l'utiliser IKEv2 a été modifié pour recevoir information du noeud en mobilité lors d'un changement d'adresse IP. Le principal but de MOBIKE est de prévenir la négociation entre toutes les différentes interfaces et de gagner du temps dans la négociation initiale d'IPsec.

Les scénarios de MOBIKE sont basés sur la Mobilité. Les cas de multihoming considèrent le switch d'une interface vers une autre, ce qu'on ramène à un scénario de Mobilité dans cette étude.

Le principal avantage d'utiliser tunnels est que seulement l'adresse IP "extérieure" est impacté par la mobilité. Quand un noeud se déplace d'un point d'accès à un autre, l'adresse IP "interne" (par laquelle est vue le MN du point de vue du CN) reste la même, et la mobilité peut s'effectuer de manière transparente du point de vue des applications. Avec un design sans tunnel, à chaque fois les adresses IP changent et toutes les applications du réseau ont besoin de réinitialiser les sessions réseaux et donc de redémarrer, sinon elles sont perdues. On remarquera qu'aujourd'hui il existe nouveaux protocoles comme HIP ou SHIM6 qui pallient à ces limitations.

MOBIKE est une option d'IKEv2 qu'il faut activer dans les deux noeuds en question pour l'utiliser. Le noeud qui commence la communication s'appelle « initator » et l'autre « responder ». MOBIKE échange des messages, qui contiennent un Notify Payload, entre les deux noeuds. Les opérations de MOBIKE et les Notify Payloads envoyés sont :

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

- MOBIKE_SUPPORTED : pendant la deuxième phase d'IKEv2 chaque noeud informe à l'autre avec ce Notify Payload qu'il a l'option MOBIKE activé.

- ADDITIONAL_IP4_ADDRESS (ou IP6) : pour ajouter les différentes adresses IP du noeud.

- NO_ADDITIONAL_ADDRESSES : il indique que le noeud n'a plus d'adresses IP.

- UPDATE_SA_ADDRESS : il est envoyé par le noeud qui change depuis la nouvelle adresse IP pour actualiser les SA.

- COOKIE2 : il confirme que l'actualisation de l'adresse IP a été effectuée.

Limitations de MOBIKE :

- Il n'essaie pas d'être un protocole de sécurité complet.

- Il traite la Mobilité seulement entre deux noeuds, un MN attaché à une "Security Gateway".

- Il supporte seulement le mode tunnel.

- Le MN ne possède qu'une adresse IP à la fois.

3.2.4 PF_KEY et MIP: solution dans le "bootstrapping"

[9] propose deux extensions de PF_KEY, l'API qui fait possible la manipulation des SA, qui permettent un fonctionnement correct et optimal entre MIPv6 et IPsec/IKE.

En effet, au moment du BOOTTRAPPING le MN effectue une négociation entre sa CoA et l'adresse IP du HA. La problématique de IKEv2 et MIPv6 est que IKE gère des associations de sécurité entre des adresses IP qui servent à acheminer des paquets IP et que MIPv6 identifie les communications entre le MN et le HA grâce à la HoA qui n'est pas systématiquement utilisée pour l'acheminement des paquets IP. Pour cette raison MIPv6 est contraint de gérer certains aspects IPsec. Ainsi par exemple, lorsqu'un MN envoie un BU à son HA, le paquet a comme adresse source la CoA et comme adresse destination l'adresse IP du HA. La HA reçoit ce paquet mais ne possède pas de SA associée à la CoA car il identifie le MN à son HoA. Pour rendre cohérent les tables IPsec et celles de la mobilité, MIPv6 doit, à la réception du paquet, remplacer l'adresse CoA par celle du HoA. A ce moment là, le HA pourra procéder à un lookup dans sa table.

- PF_KEY_MIGRATE : permet de faire la migration de l'adresse d'un noeud vers un autre connecté par un tunnel IPsec (établit par des SA). Aussi, il peut actualiser la session IKE et ainsi permet à IKE de survivre aux déplacements.

- SADB_X_EXT_PACKET : permet à IKE de faire le bon choix de l'adresse dans le bootsrapping.

PF_KEY_MIGRATE

MIPv6 définit un indicateur nommé Key Management Mobility Capability bit, le K-bit, dans les
messages de BU et de BA. Il indique la capacité que les sessions d'IKE puissent survivre à la mobilité. En
effet, si MN et HA peuvent manager cet indicateur, le démon IKE actualise dynamiquement la session

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

d'IKE quand le MN se déplace. Pour réaliser cela, le démon IKE doit être notifié par MIPv6 avec l'information nécessaire pour migrer sa session IKE.

La structure du message PF_KEY_MIGRATE doit contenir :

-



Information sur une SP : - L'adresse/port source/destination ; le protocole de la couche supérieure.
- La direction du trafic: entrant ou sortant.

- Information sur l'ancienne SA : - L'adresse source/destination ;

- Information sur la nouvelle SA : - Le protocole : ESP/AH ; le mode (seulement tunnel).



Figure 8. Schéma d'échanges dans le MN (à gauche), et entre lui et le HA (à droite)

SADB_X_EXT_PACKET

Dans l'étape de bootstrapping de MIPv6, le MN et HA ont besoin d'établir une IPsec SA pour protéger les messages de signalisation de MIPv6 comme BU et BA. La négociation IKE est la première transaction qui se fait entre le MN et le HA, il est donc nécessaire de guider IKE pour lui communiquer l'adresse sur laquelle il fera les négociations.

La solution consiste à analyser tous les paquets reçus (« triggering packet ») et ajouter l'information nécessaire dans une extension du message SADB_ACQUIRE. Cette extension est le SADB_X_EXT_PACKET.

3.2.5 PF_KEY et MIP: solution "database"

Dans l'ébauche [10] il y a l'objectif de créer une Mobility Security Reference Database (MSRD) qui doit centraliser tous les liens entre les adresses IP et leurs fonctionnalités MIP (CoA, HoA, HA, lifetime ...). Le design proposé est une table indexée par un Mobile Parameter Index (MPI) avec les données MIP, mais aucune structure n'est définitive. D'autre part, l'interaction avec IPsec et IKE est considérée en utilisant une extension du message PF_KEY_ACQUIRE avec le paramètre MPI parmi d'autres.

L'interaction entre IPsec, IKE, les applications MIP et la MSRD est étudiée pour les trois scénarios de mobilité suivants :

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

- Pendant le bootstrapping : traitement du transport de SA pour le BU/BA.



Figure 9. Architecture et interaction d'IPsec / IKE / MIPv6 avec la base de données MSRD proposé

- Pendant le handover : Actualisation du tunnel de SAs. Cela nécessite seulement une intervention de l'application MIPv6 pour actualiser la MSRD. PF_KEY est en train d'envoyer à IKE un message SADB_ACQUIRE, avec lequel le correspondant MPI, alors que IKE peut actualiser sa base de données local.

- La rénegotiation de clés des SAs : la couche IPsec envoie un PF_KEY SADB_EXPIRE avec le message d'extension MPI au démon IKE. IKE demande les paramètres de mobilité à la MSRD et commence le restart.

3.2.6 HIP

Le Host Identity Protocole (HIP) [11] crée une nouvelle couche entre les protocoles de transport et de réseau. Il introduit le concept qui permet avoir la séparation entre la localisation et l'identification d'un host :

			- Le Host Identifier (HI) est assigné à chaque machine comme une clé. Le Host Identity Tag (HIT) est le hash à 128bits de HI. Il s'utilise au début des communications pour avoir plus de sécurité. Ceci correspond à la taille d'une adresse IPv6, et un paquet HIP a le même format que celui d'un paquet IPv6 traditionnel. Pour IPv4, le Local Scope Identifier (SPI) représente aussi le HI en 32bits. - Le Locator, ou la localisation, devient l'adresse IP de la machine.
-
Figure 10. HIP dans le modèle OSI

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

HIP fournit la capacité de manager plusieurs adresses sous une même identité (HIT) qui n'est pas impacté par les changements d'adresses, et offre ainsi un lien constant avec les applications. Cela fait possible une grande utilisation de HIP pour la mobilité et le multihoming.

La mobilité d'un noeud qui change son adresse IP est possible avec l'échange des suivants messages :

- La notification à l'autre noeud du change d'adresse avec un paquet UPDATE.

- L'association de la nouvelle adresse IP avec le HIT dans la couche HIP.

- La réponse avec ECHO_REQUEST pour valider la nouvelle localisation.



Figure 11. Exemple de gestion de la mobilité par HIP

Dans un cas de multihoming, un peut utiliser le même mécanisme mais en ajoutant dans le message UPDATE le nouveau Locator avec qui le noeud peut se connecter aussi.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4. La solution API_IPsec

Cela est la partie technique du stage. A partir de l'étude théorique et l'état de l'art précédents j'ai défini, développé et évalué une solution d'API_IPsec qu'on présente ensuite.

4.1 Définition de l'API_IPsec

L'API_IPsec est une application qui fonctionne comme un serveur qui permet aux applications d'utiliser IPsec à partir d'une communication de messages basiques. La couche IPsec permet d'offrir aux applications un moyen d' sécuriser les communications, ainsi qu'un moyen d'authentifier un noeud. Pour permettre aux applications de bénéficier de ces deux fonctionnalités, l'API_IPsec doit répondre aux critères suivants:

- L'API_IPsec doit fournir une interface entre la couche IPsec et les applications. En effet IPsec est utilisé pour sécuriser des transactions réseau. Certaines applications ont besoin de mécanismes d'authentification, et nécessitent de sécuriser leur lien avec un client. L'API_IPsec permettra à une application de bénéficier des fonctionnalités implémentées au sein de la couche IPsec, et d'éviter de multiplier des procédures comme l'authentification ou le chiffrement sur plusieurs couches.

- L'API_IPsec doit permettre le déploiement facile d'un IPsec par défaut entre les différents noeuds.

Une des principales causes de non déploiement d'IPsec est la difficulté de configurer la couche IPsec, et notamment les données d'identification. L'interaction entre les applications et la couche IPsec permettra alors d'établir facilement un IPsec sans authentification et de procéder à l'authentification uniquement lorsque cette dernière est demandée, au cours d'une communication. IPsec serait alors utilisé principalement pour se prémunir contre les attaques de l'homme au milieu.

- L'API_IPsec doit maintenir les connexions sécurisées et éviter les renégociations lors de la mobilité et le multihoming.

En effet, IPsec est une couche qui permet de sécuriser les communications entre deux noeuds, cela veut dire entre deux adresses IP. Dans les scénarios de mobilité ces adresses sont amenées à changer au cours du temps. Il s'agit alors de maintenir une connexion sécurisée avec un même degré de sécurité tout en évitant de casser la connexion et de renégocier une nouvelle association de sécurité tenant en compte la nouvelle adresse. En effet les négociations d'associations IPsec sont relativement coûteuses en termes de nombre d'échanges et de ressources impliquées notamment pour l'authentification. Dans le cas du multihoming, deux noeuds sont connectés via plusieurs interfaces. Il s'agit alors d'éviter d'avoir à négocier une association de sécurité par paire d'adresse et de permettre une unique négociation dont bénéficieront toutes les adresses mises en jeu.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4.1.1 Interfaces

La figure ci dessous permet de visualiser les trois interfaces de l'API_IPsec qui ont interaction avec:

- La couche applicative : elle permet à l'API de communiquer avec les applications de plus haut niveau. Un exemple de dialogue est une application qui utilise les fonctionnalités de l'API_IPsec pour gérer la mobilité/multihoming.

- Les API_IPsec distantes : elle permet à un noeud de communiquer à une API_IPsec distante les opérations à effectuer, ou d'informer l'API_IPsec distante d'un événement pour que puissent être prises les actions de part et d'autre. Pour cela, le transfert de Contexte sera utilisé.

- La couche IPsec : elle permet a l'API_IPsec de traduire au niveau des SPD, SAD et IKE les requêtes provenant des précédentes interface.



Figure 12. Interfaces de l'API_IPSEC

4.1.2 Fonctionnement global

Le fonctionnement global de l'API_IPsec est présenté dans la figure suivante qui met en évidence les différentes bases de données (SPD, SAD, PAD) et le démon IKEv2 qui interagissent avec l'API_IPsec. L'API_IPsec maintient à jour une base de donnée qui contient des informations sur les SA's, les SP's et les contextes d'IKE, de Mobilité, de Multihoming... liés à chaque canal IPsec. En fonction de ces différentes informations, l'API_IPsec va pouvoir gérer les différents cas de mise à jour ou d'héritage des SA.



Figure 13. Fonctionnement global de l'API_IPSEC

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4.1.3 La base de donées DB

La base de données DB de l'API _IPsec est constituée par l'ensemble des tables suivantes:

- DBC: table Centrale de liaison entre toutes les autres tables. Elle a comme index les SA _ID.

- DB_SA: table dynamique ou liste enchdinée d'objets SA. Elle est une "image" de la SAD.

- DB_SP : table dynamique ou liste enchaînée d'objets SP. Elle est une "image" de la SPD.

- DB_MH : table de MultiHoming. Chaque entrée ajoutée est constitué par une SA de référence, une liste de ses SA héritées et une indication du type de flux et des données héritées. Pour l'instant, on considère une méthode fixe de dérivation de la clé pour les SA hérités.

DB_SA

INDEX SA

IPSEC

CRYPTO MATERIAL

LIFETIME

ID

*NEXT

SPI

@SRC

@DST

MODE

TYPE

SEQ

O THERS

ALGO

LEN

KEY

1



ID 2

ID N

NULL

&SA

&SA

N < DB_SA_MAXREGS


·
·
·

Liste enchainee
de N objets SA

"NEXT

INDEX SA

IPSEC

CRYPTO MATERIAL LIFETIME

INDEX SA

IPSEC

CRYPTO MATERIAL LIFETIME



DB_SP

INDEX SP

SELECTOR

POLICY

LIFETIME

ID

*NEXT

SPID

SEQ

Range @SRC

Range @DST

Port SRC

Port DS T

UPPER PROTOCOL

MODE / TYPE / ...

&SP

INDEX SP SELECTOR / POLICY LIFETIME

ID 2

"NEXT

M < DB_SP_MAXREGS

Liste enchainee
de M objets SP


·
·
·

&SP

INDEX SP SELECTOR / POLICY LIFETIME

ID M

NULL

DB_MH

SA REFERENCE	INHERITED SA LIST				FLOW ID	FLAG OF INHERITANCE	ID
SPI	@SRC	@DST	*DB_SA	(POIN TERS; MAX 3)



@src

@dst

ype

Mode

Lifetime

Algorithm


·
·
·

DBC	INDEX SA			STATUS	SFD_REMOTE		LINKS WITH OTHER TABLES (POINTERS)				ID
SPI	@SRC	@DST			"DB_SA		"DB_SP	"DB_MH	"DB_MIP

Figure 14. Tables de la base de données DB de l'API_IPsec

On défini aussi les suivants tables, lesquelles ne sont pas développées dans le premier prototype d'API_IPsec mais elles sont envisagées lors d'un prochain stage ou thèse :

- DB_IKE (Internet Key Exchange) :

Table de données avec le contexte relatif à une négociation IKE entre deux adresses IP. En effet,
on se place dans le cas oil la négociation d'une première SA dite SA originelle se fait grâce à

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

IKEv2. C'est ce protocole qui va permettre avec le temps de lancer des renégociations, de changements de clés, etc. Lorsque l'on crée une SA à partir de la SA originelle, il est nécessaire qu'un contexte IKEv2 lui soit associé. La nouvelle SA sera alors associée à une SA "normale", i.e. indépendante et pouvant bénéficier des fonctionnalités de IKEv2 pour une connexion établie. L'avantage est que on ne procédera pas à la création de la nouvelle SA sans procéder à une négociation par IKEv2, et ainsi économiser du temps réseau. Cette table est très liée à l'implémentation de IKEv2, car les paramètres du contexte IKEv2 comprennent des paramètres réseau mais aussi des paramètres liés à l'implémentation. La table devra tenir compte de cette distinction. On envisagera par exemple un contexte générique, puis un contexte lié à chaque implémentation. Dans un premier temps cette table sera liée à OpenIKEv2, et les opérations sur les contextes de IKEv2 se contenteront d'utiliser la librairie d'OpenIKEv2.

- DB_MIP (Mobilité IP)

Cette table prend un format similaire à la base de données MSRD qu'on a vu dans l'état de l'art de l'Étude Théorique (section 3.2.5), et elle doit maintenir des interactions semblables avec PF_KEY, IKEv2 et MIPv6. Chaque entrée ajoutée est constitué par un identificateur Mobile Parameter Index (MPI), et les informations de mobilité du noeud Local et Distante :

o Type de noeud : communicant (CN) et/ou en mobilité (MN)

o Status de la mobilité : REQUESTED / PROCEEDED / ESTABLISHED;

o Éléments de MIP: Home Agent (HA), Home of Address (HoA), Care of Address (CoA).

o Associations de sécurité : trois couples de SA qu'on explique après de présenter la table.

DB_MIP

LOCAL

REMOTE

MPI

TYPE

STATUS

C

*SAs local

H

H

*SAs

H

H

*SAs

C

STATUS

TYPE

o

A

o

middle

o

A

remote

o

A

A

A

A

1

MN

ESTABLISHED

2.1

SAs21

1.0

1.1

SAs14

X

X

X

4.1

ESTABLISHED

CN

2

MN

ESTABLISHED

2.1

SAs21

1.0

1.1

SAs13

3.1

3.0

SAs34

4.1

ESTABLISHED

MN

Figure 15. Proposition de la table MIP de la base de données DB de l'API_IPsec

En effet, il y a une couple de SAs entre la CoA et le HA si un noeud est en mobilité, deux pour le noeud Local « SAs local » et deux pour le noeud distante « SAs remote ». Dans le cas qu'un seul noeud est en mobilité (type MN), les deux « SA middle » sont entre la HoA du MN et l'adresse physique CoA de l'autre noeud CN. Dans ce cas, le noeud CN n'a pas de HA, HoA et « SAs remote ». Dans le cas que les deux noeuds sont en mobilité, les deux sont de type CN, et les deux disposent de CoA, HA, « SAs local / remote » et HoA, et ils partagent des « SAs middle » entre les HoA de chacun. On montre dans la table précédente ces deux possibles cas.

- DB_HIP (Host Identity) : Les deux noeuds sont identifiés par un identifiant et non plus une adresse IP ou "locator". Des

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

exemples d'identifiant pourront être les Host Identity (HI) qui correspond à un clé publique ou au hash de cette dernière, le Host Identity Tag (HIT). Cette table s'inspire de HIP (Host Identity Protocol), et on envisage pour un prochain stage ou thèse de regarder OpenHIP (une implémentation "open-source" en développement) et étudier la relation avec l'API_IPsec.

4.1.4 Le protocole AIM: API_IPsec Messages

Pour communiquer l'API_IPsec avec les applications ou avec les API_IPsec distantes on a défini le protocole API_IPsec Messages (AIM). Il permet d'encapsuler différents structures qui ont l'information nécessaire pour communiquer soit messages de signalisation (confirmations, ouvrir/fermer sockets, etc.) soit messages de fonctions pour gérer la couche IPsec (opérations de créer/consulter/modifier/effacer associations ou politiques de sécurité dans la base de données, synchronisation avec la SAD/SPD, etc.). Pour le protocole AIM on a défini les quatre structures : un Header commun dans tous le message, et trois structures « dm_XX » spécifiques. Un message est composé d'un Header et d'une structure « dm_XX » selon le Type de message. Uniquement la structure dm_FUNCTION peut contenir forcement des paramètres, cela veut dire, plusieurs structures dm_PARAM ; aussi, on peut avoir sans problèmes plusieurs dm_FUNCTION dans le même message, l'une après l'autre. Voici un schéma pour clarifier :

Toes de Message Structure



HEADER

API_MSG_ERR
API_MSG_ACK
API_MSG_NCK



API_MSG_FUNCTION







ID
TYPE
LENGTH

API_MSG_PARAMETERS

- Numéro de paquet (unique)

- Type de Message. Il indique la structure « dm_XX » qui suivra le Header.

-

dm_RESPONSE		- Code de ACK / ERROR. Il contient un numéro lié au Type de Message ou de Fonction qu'on a traité. - Code = RETURN_FUNCTION, RETURN_PARAM	CODE
		TABLE TYPE LENGTH
- Table de la DB : TB_SA, TB_SP, TB_MH ... - Type de Fonction : ADD, UPDATE, DELETE ... - Taille totale de la fonction : cet en-tête + paramètres
dm_PARAM

TAG
LENGTH

- Type de Paramètre : ID, SA_MODE, SA_TYPE ...
Taille variable du paramètre : il permet connaître combien de bytes il faut lire pour obtenir la valeur du paramètre.

Taille totale du message en bytes (header inclusive)

DATA



APX_SCK_CLOSE API_MSG_EXIT APX_SCK_RESTART REM_SCK_OPEN API_SYN_IPSEC

Messages de signalisation ou d'opération directe. Pas besoin d'une structure « dm_XX »

Figure 16. Type de messages et structures du protocole AIM

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Ensuite, on présente les exemples plus représentatifs des messages qu'on peut créer, et on fait évident l'encapsulation :

HEADER



PARAM N value

PARAM 1

PARAM 2

dm_FUNCTION 1

value

value

dm_FUNCTION 2

dm_FUNCTION N

HEADER

dm_RESPONSE
CODE = valueuchar

HEADER

dm_RESPONSE
CODE = RE TPARAM

dm_PARAM



value

HEADER
YPE = Message

HEADER
YPE = REM_MSG_FUNC

dm_PARAM (tag=@)

Address API_REMOTE

dm_FUNCTION 1

value

PARAM 1





Figure 17. Exemples de messages encapsulés dans le protocole AIM

Ce protocole contraint les applications qui veulent utiliser l'API_IPsec de compiler et exécuter une libraire pour envoyer/recevoir les messages. Dans la section du Prototype développé on détaillera cette librairie et la table de messages, de fonctions et de paramètres associées.

4.1.5 Intégration d'OpenIKEv2

L'API_IPsec doit gérer les bases IPsec ainsi que les contextes liés à IKEv2. On a envisagé d'avoir accès aux fonctionnalités d'IKEv2 en utilisant OpenIKEv2, une implémentation ouverte développé en C++. OpenIKEv2 permet :

- Un canal ou un moyen de communication API_IPsec - IKEv2 pour faire une gestion de clés et de l'authentification seulement quand on aura besoin. Dans ce cas, l'idée n'est pas d'intégrer les fonctions sinon d'exécuter le démon IKE.

- Intégrer dans l'interface de la couche IPsec les fonctions d'openIKEv2, basés en XFRM, pour gérer la SAD/SPD n'utilisant plus les fonctions PF_KEY2.

4.1.6 Limitations de cette première version

L'implémentation de l'API_IPsec au cours de ce stage est essentiellement une preuve de concept, bien que nous ayons constamment cherché au cours de nos développements à lui donner les aspects d'un projet finalisé, nous avons choisie quelques restrictions afin de pouvoir respecter le calendrier de développement. En conséquence, il est hors du stage réalisé les suivants éléments ou aspects:

- La PAD (Privilege Application Database) est relativement récente dans l'architecture d'IPsec. Elle est définie dans la spécification d'IPsecv2, mais aucune implémentation n'est disponible actuellement. Alors, on a décidé de ne pas la considérer dans le projet bien qu'elle est une pièce très importante.

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

- La création d'une version totalement multithread. Toutes les applications et les API_IPsec distantes connectés à l'API_IPsec seront servies par des threads dédiés. Ils partageront la même mémoire et les mêmes données, et il faudra donc mettre l'accent par exemple sur l'introduction de sémaphores, de variables de condition, dans toute le code du projet afin d'éviter la collision ou la perte de données lors d'accès concurrentiels. Cette problématique nécessite pour être traitée une grande charge en terme de temps d'analyse du code. On priorisera donc de réaliser une première version monothread de l'API_IPsec qui fonctionnera avec soit une application soit une API_IPsec distante. Le problème de mémoire partagée est alors temporellement résolu et on peut se concentrer sur l'architecture de l'API_IPsec.

4.2 L'API_IPsec et la mobilité 4.2.1 La Mobility_Application

On a défini l'application MA (Mobility_Application), un démon détecteur de changements ou de besoins de mobilité/multihoming dans la machine, qui s'appuiera sur l'API_IPsec et lui permettra de gérer les associations de sécurité entre différents noeuds dans ces cas.

Dans ce stage on ne s'occupera pas de la partie de changement d'interface et on développera la part de la MA qui fait l'interaction avec l'API_IPsec. Dans notre cas, et dans le cadre du Prototype, la MA émulera les changements d'interfaces pour effectuer les tests qui valideront l'API_IPsec dans un scénario de mobilité et de multihoming.

4.2.2 API_IPsec versus MOBIKE

Aujourd'hui l'unique solution qui pourrait faire la concurrence à l'API_IPsec est MOBIKE qui permet également de gérer les associations de sécurité d'une connexion lors de la mobilité d'un des deux noeuds. Toutefois, MOBIKE a les limitations suivantes par rapport à l'API_IPsec :

- MOBIKE ne fonctionne que dans le mode tunnel. L'API_IPsec permet aussi le mode transport.

- MOBIKE peut gérer qu'une interface en changement : celle entre le mobile MN et la Security Gateway. L'API_IPsec effectue les changements indépendamment du scénario et elle n'a pas besoin d'être connecté à une Security Gateway. L'API_IPsec prend en compte également les scénarios de mobilité avec MIPv6 et SANS MIPv6.

- MOBIKE est spécifique pour la Mobilité et ne gère qu'une interface à la fois. L'API_IPsec permet aussi gérer le Multihoming et avoir plusieurs interfaces de manière simultanée.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

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.

4.3.2 Serveurs Multithread

Pour la création des deux serveurs principaux multithread de l'API_IPsec, on utilise les fonctions de création de threads du standard POSIX, les Pthreads, qu'offre Linux de manière gratuite¹. Le serveur server_main_apps fait la connexion avec les applications utilisant par défaut le PORT_APPAPI 5010 et l'adresse IP de l'interface 0 de la machine où il s'exécute. De même manière, le serveur server_main_rems fait la connexion avec les API_IPsec distantes utilisant par défaut le PORT_APIAPI 5011 et la même adresse IP. L'API_IPsec doit bien créer et exécuter les deux serveurs principaux pour

¹ La librairie de pthreads a été développée l'année 1995 par l'IEEE, donc pour les utiliser il fallait payer une taxe. Puis, l'année 1998 le MIT a développé les pmpthreads avec presque les mêmes fonctions. Enfin, pour Linux il existe depuis 2003 une version GNU qui est la qu'on utilise dans ce projet.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

avoir un fonctionnement correct. Pour cette raison, on a développé un protocole synchronisé qui annule le lancement de l'API_IPsec lorsque l'un ou l'autre des serveurs ne se lance pas. On reviendra plus tard sur ce point.

Un fois les serveurs initialisés, chacun entre dans une boucle oil écoutent et acceptent les connexions. Ils créent un serveur dédié, soit un server_app soit un server_rem, pour servir chaque connexion acceptée et ainsi traiter les messages et réaliser les opérations que lui demandent. Ces serveurs dédiés sont aussi threads qui sont registrés et contrôlés par le thread principal père. Il peut avoir un maximum de MAX_APPLICATIONS threads server_app et de MAX_REMOTES threads server_rem.

Dans la définition de l'API_IPsec on a cité comme une des principales limitations pour cette première version la gestion de données partagées entre les différents threads. La solution drastique prise a été de limiter le nombre maximum d'applications et d'API_IPsec distantes à un.



Figure 21. Exemple du serveur thread principal "app_main_server" et de ses serveurs threads dédiés "server_appi"

Ensuite on détaille dans le schéma suivant le protocole de création de serveurs principaux. En effet, l'API_IPsec doit bien créer les deux serveurs et de manière synchronisé. Pour cela, on s'appuie sur la création d'une variable global « contmain », d'une variable de condition «contmain_cv» et d'une variable mutex « contmain_mutex » (un sémaphore). La première permet d'envoyer signaux entre les différents threads ou de les attendre. La deuxième sert à pouvoir accéder à la variable global ou à la variable de condition de manière unique et sans problèmes de collisions avec les autres threads qui peuvent aussi les utiliser. Alors, le protocole suit l'ordre suivant : une phase d'initialisation, avec l'établissement des sockets d'écoute des deux serveurs ("socket & bind" du server_main_apps, puis du server_main_rems). À chaque étape de l'initialisation, des messages sont remontés grâce aux signaux. Si les connexions s'établissent correctement ils s'autorisent l'un à l'autre d'accéder à la boucle d'acceptations d'applications ou d'API_IPsec distantes. Par contre, au moindre problème de connexion, les deux serveurs principaux sont annulés.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Après la création des serveurs principaux, le processus d'API_IPsec reste dans une boucle oil il attend les signaux soit des serveurs principaux soit des serveurs dédiés. Si un signal reçu est dû à la bonne initialisation des serveurs principaux on l'ignore. Si un signal reçu de part des serveurs dédiés indique RESTART (par exemple à cause d'une synchronisation important due à un changement d'adresse) il faut annuler tous les threads (dans cette première version, maximum on annulera 4 threads : deux serveurs principaux et deux dédiés), obtenir la nouvelle adresse IP et démarrer la création des serveurs principaux. Puis, n'importe quel autre message fait quitter l'API_IPsec, soit un EXIT pour attendre la bonne finalisation des threads, soit un signal inconnu ou de mal initialisation des serveurs principaux qui forcera l'annulation des threads.

Voici le schéma :



Figure 22. Protocole de création et maintenance des serveurs principaux

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilité et le Multihoming

4.3.3 Création de messages. Liste de fonctions

Le fichier « apx_msg_gen.c » permet de générer les messages qui sont utilisés pour toutes les communications en s'appuyant sur le protocole API_IPsec Messages (AIM). Dans la section 4.1.4 on présente ce protocole en expliquant les structures basiques pour construire un message (HEADER, dm_FUNC TIONS, dm_PARAM, dm_RESPONSE), le concept de l'encapsulation des messages ainsi que quelques types de messages (API_MSG_ACK, API_MSG_FUNC TION...). Ensuite on définit la table complète de type de messages, de fonctions et de paramètres que l'API_IPsec connaît. Puis on présente la liste de fonctions développés pour construire / encapsuler / envoyer / recevoir les messages. Enfin on montre un exemple pour créer un message.

HEADER (type)	ACTION		SIGNAL	Types de Messages
Non	Serveur principal d'applications bien initialisé		APX_SCK_CLOSE
Fermer la connexion avec l'API_IPsec	Serveur principal d'applications mal initialisé		APX_SCK_RES TART
Redémarrer l'API_IPsec	Redémarrer l'API_IPsec		API_MSG_EXI T
Sortir de l'API_IPsec (fermer tous les serveurs)	Sortir de l'API_IPsec		REM_SCK_OPEN
Ouvrir 1 connexion avec une API_IPsec distante	Serveur principal de 'remotes' bien initialisé		REM_SCK_CLOSE
Fermer la connexion avec une API_IPsec distante	Serveur principal de 'remotes' mal initialisé		APX_MSG_ERR
Réponse d'erreur	APX_MSG_ACK
Réponse de confirmation	API_MSG_FUNC TION
Fonction que doit réaliser l'API_IPsec	REM_MSG_FUNCTION
Fonction que doit réaliser une API_IPsec distante
(voir ci-dessous la liste de fonctions)	API_SYN_IPSEC
Synchronisation de la SAD/SPD avec la DB_SA / DB_SP	API_MOBILI TY
Message pour la mobilité	API_MSG_PARAM
Message pour encapsuler X parametres. Il ne s'envoie pas (il ne définit pas aucune action).

Table 2. Types de messages de l'API_IPsec

dm_FUNCTION (table, type)		dm_PARAM (tag)			Type de Fonctions
Tags de parametres SA		Tags de parametres SP	Tags Remote	DB_ADD DB_UPDATE DB_READ DB_DELETE DB_DUMP DB_GE TID DB_COPY
DB_SA_ID, DB_SA_SPI, DB_SA_ADR_SRC, DB_SA_ADR_DS T, DB_SA_TYPE, DB_SA_MODE, DB_SA_REQ, DB_SA_SEQ, DB_SA_STATE, DB_SA_WSIZE, DB_SA_FLAGS, DB_SA_KEYMAT, DB_SA_KE_TYPE, DB_SA_KE_LEN, DB_SA_KA_TYPE, DB_SA_KA_LEN, DB_SA_ALLOC, DB_SA_BYTE, DB_SA_ADDTIME, DB_SA_USE TIME		DB_SP_ID, DB SP SPID _ _ , DB_SP_RANGE_ADR_SRC, DB_SP_RANGE_ADR_DS T, DB_SP_UPPER_PRO TO, DB_SP_SEQ, DB_SP_LIFE TIME, DB_SP_VALID TIME, DB_SP_POLICY_LEN, DB_SP_POLICY, DB_SP_ALL_PARAM	REM_PARAM_SFD REM_PARAM_ADR	Tables
DB_SA_IDEXT				TB_IKE

Table 3. Types de fonctions et de paramètres des messages de l'API_IPsec

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Ensuite on utilise les abréviations suivantes :

H = HEADER F = dm_FUNCTION R = dm_RESPONSE P = dm_PARAM

Fonctions pour crder messages

Ces fonctions créent le HEADER du message et ajoutent une structure spécifique « dm_XX » avec les paramètres obligatoires. Elles retournent le pointer *msg qui contient l'adresse de mémoire du message. msg = create_m sg_respon se (u_char type, u_char code);

Structure du message : H (type) + R (code)
type = API_MSG_ACK ou API_MSG_ERR

code = value (u_char), Le message de reponse est complete.

RE TURN_PARAM, La reponse ajoutera un parametre (structures dm_PARAM).

RE TURN_FUNC TION La reponse ajoutera une fonction (structure dm_FUNC TION).

C'est utile ajouter un parametre a la reponse quand, par exemple, apres de réaliser une fonction l'API_IPsec veut retourner une valeur de résultat. On ajoute une fonction quand l'API_IPsec doit retourner beaucoup de résultats, par exemple, la lecture de plusieurs parametres d'une SA/SP.

msg = create_m sg_function (u_char table, u_char typefun, u_int id);

Structure du message : H( type=API_MSG_FUNC TION) + F(table, typefun) + P(tag) + [ value=id ]

table = TB_SA, TB_SP, TB_MH, TB_MIP, TB_IKE

typefun = DB_ADD, DB_GETID, DB_UPDATE, DB_READ, DB_DELE TE, DB_COPY, DB_DUMP tag_id = DB_SA_ID, DB_SP_ID

Il existe de messages, comme DB_ADD ou DB_GE TID, qui specifient seulement le g tag_id D mais n'ajoutent pas aucune valeur de g id D car c'est un resultat qu'on attend a la reponse.

msg = create_m sg_remote (u_char type, int sfd_~rem, char *adr_~rem, void *msgrem);

Structure du message : H1(type) + P(tag) + value + [ H2(type) + ... ]

type = REM_SCK_OPEN, REM_SCK_CLOSE, REM_MSG_FUNC TION tag = REM_PARAM_SFD ou REM_PARAM_ADR

value = g sfd_rem D ou g adr_rem D

On utilise g msg_rem D avec REM_MSG_FUNC TION pour encapsuler un message independant qu'on veut envoyer a une API_IPsec distante. Dans ce cas, la structure du message continue avec le H2.

msg = create_m sg_any (u_char type);

Structure du message : H(type)

type = APX_SCK_XX, API_MSG_EXI T, API_SYN_IPSEC, API_MSG_PARAM Ces messages n'ont pas besoin de parametres.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Fonctions pour ajouter données aux messages

Ces fonctions ajoutent à la fin d'un message quelconque une structure F, une structure P ou plusieurs P. Ainsi, à partir d'un message crée avec les fonctions antérieures, on peut ajouter plus de paramètres ou des nouvelles fonctions API_MSG_FUNCTION qui seront exécutés l'une après l'autre par l'API_IPsec.

msg = add_m sg_function (void *msg, u_char table, u_char typefun, u_int id);

msg = add_m sg_param (void *msg, u_char tag, u_int16_t length, void *value);

Ce fonction additionne a la part finale du message une structure P(tag) + value.

Grace a length, on indique toujours la taille de la valeur : une structure de plusieurs octets, un entier de quatre octets ou un caractère d'un octet. Si length est zero et la valeur n'est pas nulle, la fonction calculera de manière automatique la taille si le type de paramètre (le tag) est connu. Par contre, si la valeur est nulle, on passe seulement le tag et non sa valeur, laquelle est prevue normalement dans la reponse du message.

msg = add_msg_xparam (void *msg, void *xp);

On peut créer un "message de X paramètres" avec g xp = create_msg_any(API_MSG_PARAM) D. Puis on ajoute tous les paramètres qu'on veut avec g add_msg_param D. Alors, grace a g add_msg_xparam D on élimine le H de g xp D et on ajoute tous ses paramètres a la part finale de la structure du message choisit.

Fonction pour obtenir données des messages

value = get_m sg_param (void *msg, u_char typefun, u_char tag );

xp = get_m sg_param (void *msg, u_char typefun, 0 );

La suivante fonction permet d'obtenir un paramètre quelconque contenu dans un message, indiquant le type de fonction (typefun) et le type de paramètre (tag). La fonction analyse toujours le message pour savoir quel type de header et quelle structure il contient. Si le message n'a pas une structure F, la fonction cherche directement le tag. Si le tag est nul, alors elle retourne tous les paramètres dans un message g xp D.

Fonctions pour envoyer/recevoir messages

Ces fonctions sont la base de la communication pour l'API_IPsec. ret = send_m sg (int sfd, void *msg, int length);

Un g send_msg D envoie par le socket identifie par le descripteur sfd le message de taille length. Si length est zero, on prend la taille qu'indique le header du message. On remarque qu'après la transmission, le message est efface et pointer *msg n'est plus valide.

ret = wait_m sg (int sfd, void **ppmsg, int length);

Un g wait_msg D bloque le programme jusqu'à recevoir a travers du socket de descripteur sfd un message de taille length. Si length est zero, on regoit un header toujours de taille connu, et grace a qu'il contient la taille totale on lira le message complètement. Ce message est sauvegardé en mémoire et on retourne son adresse a travers du pointer ppmsg.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Exemple d'implémentation des messages

La fonction « value = db_read (sfd, table, id, *idext, tag); » est développée à partir des fonctions antérieurs. Elle permet de lire une SA/SP référenciée soit par « id » soit par la structure « IDEXT = (spi, @src, @dst) ». Si cette dernière structure est utilisée, l'API_IPsec doit exécuter la fonction DB_GETID pour chercher l'identificateur de la SA/SP avant de réaliser le DB_READ. On remarque que à la fonction DB_READ on ajoute uniquement un indicateur de paramètre (le tag) parce qu'on veut l'obtenir dans le message de réponse. Si « sfd » indique une API_IPsec distante, on encapsule le message. Puis on envoi le message, on reçoit la réponse et si elle est de type ACK on peut lire la valeur du tag demandé.

msg=create_msg_any(API_MSG_FUNC TION);

if(id==0 && idext!=NULL) {

msg = create_msg_function (msg, table, DB_GE TID, id);

msg = add_msg_param(msg, DB_SA_IDEXT, sizeof(t_idext), idext);

}

msg = add_msg_function(msg, table, DB_READ, id);

msg = add_msg_param(msg, tag, 0, NULL); // length=0, value=NULL 4 only tag !

//header_remote

if(sfd>0 && sfd!=sfd_local)

msg = create_msg_remote(REM_MSG_FUNC TION, sfd, NULL, msg);

//sending...

send_msg(sfd_local,msg, 0);

wait_msg(sfd_local, &msg, 0);

//process response...

if(process_rsp(msg) != API_MSG_ACK) return NULL;

value = get_msg_param(msg, tag, 0); // length = 0 4 length automatique !

4.3.4 Messages pour les applications. Liste de fonctions

Le fichier « app_msgs.c » est le fichier principal que doit incorporer une application qui veut se connecter et utiliser l'API_IPsec et ses fonctionnalités directement. Il incorpore le fichier pour la génération de messages. Ensuite on présente la liste de fonctions qu'on a développés liées au message envoyé et la valeur que retourne. On n'explique pas au détail les fonctions comme dans la section antérieure oil on a déjà traité très bien le but des messages, les fonctions et les paramètres de l'API_IPsec. Fonctions pour se connecter

Type de Message Valeurs de retour

sfd = api_connect (char *addr); APX_SCK_OPEN sfd_local / VKO

ret = api_close (int sfd_~local) ; APX_SCK_CLOSE VOK / VKO

sfd = rem_connect (char *adr_~rem); REM_SCK_OPEN sfd_rem / VKO

ret = rem_close (int sfd_~rem); REM_SCK_CLOSE VOK VKO

ret = api_exit (int sfd_~local) ; API_MSG_EXI T VOK / VKO

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Fonctions simples pour gérer l'API_IPsec DB, et fonctions de synchronisation

API MSG FUNCTION Valeurs de retour

db_add (sfd, table); > DB_ADD id / VKO

db_add_sa (sfd, spi, *src, *dst, mode, type); > DB_ADD + DB_UPDATE id / VKO

db_getid (sfd, table, spi, *src, *dst); > DB_GE TID id / VKO

db_copy (sfd, table, id, *idext, *mh); > DB_COPY id2 / VKO

db_read (sfd, table, id, *idext, tag); > DB_READ 1_PARAM / NULL

db_update (sfd, table, id, *idext, tag, *value); > DB_UPDATE VOK / VKO

db_delete (sfd, table, id, ^*idext); > DB_DELE TE VOK / VKO

db_dump (sfd, table, id, *idext); > DB_DUMP VOK / VKO

db_read_xparam (table, id, *xparams); > DB_READ X_PARAM / NULL

db_update_xparam (table, id, *xparams); > DB_UPDATE VOK / VKO

synchro_ipsec (int sfd) API_SYN_IPSEC VOK / VKO

api_re start (int sfd) API_SCK_RES TART VOK / VKO

OPTIONS :

sfd>0 On encapsule le message avec REM_MSG_FUNCTION pour

l'envoyer à une API_IPsec distante avec laquelle on a déjà une connexion établie.

idext = (spi, @src, @dst) Structure pour chercher l'identificateur d'une DB_SA/DB_SP à

partir d'autres paramètres que l'indexent aussi. Si on l'utilise, on introduit dans le message la fonction DB_GETID avant de la fonction spécifique à demander à l'API_IPsec.

> DB_GETID + DB_XX...

mh = (flow, flags) Structure de multihoming que le message/fonction DB_COPY

peut utiliser. On explique cette structure dans la section de fonctions pour la mobilité.

Fonctions pour la mobilité

Ces fonctions spéciales modifient ou dérivent un canal sécurisé (2 SA) dans la machine local et la machine distante. Puis synchronisent pour faire effectif les changes dans la SAD. Seulement trois messages sont échangés entre les deux machines ou noeuds. L'analyse des messages échangés pour chaque fonction est faite dans la prochaine section des tests avec le Démonstrateur de l'API_IPsec.

Pour faire l'opération de mobilité ou de multihoming, à la base les messages font appel aux fonctions de type API_MSG_FUNCTION. Pour la mobilité la fonction est DB_UPDATE de l'adresse source et pour le multihoming est DB_COPY d'une SA utilisant la structure MH (flow, flags) pour remplir la TB_MH.

Les deux opérations utilisent aussi la fonctionnalité DB_GETID parce que la Mobility_Application n'est pas obligée à connaître l'identificateur des DB_SA qu'il veut changer ou utiliser. Une structure « idext » qui contient au moins un des valeurs <spi, @src, @dst> sert alors à trouver les associations de sécurité.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

La modification des SAs dans la machine distante ce fait grâce à l'encapsulation du message dans un Header de type REM_MSG_FUNCTION auquel doit suivre le descripteur du socket « sfd » avec l'API_IPsec distante.

mobility	(sfd, (idext, @src_new )		+
	> (2SA) DB_GE TID + DB_UPDATE				multihoming
(sfd, (idext, flow, flags)		+
	> (2SA) DB_GE TID + DB_COPY

Ensuite, autre fonction de mobilité est considéré. En effet, dans le cas antérieur les fonctions considèrent opérer sur une connexion sécurisée uniquement. Dans le cas de Multihoming cela reste plutôt correct parce qu'on considère qu'il faut choisir la connexion de référence pour l'héritage et le type de dérivation. Par contre, dans le cas de Mobilité on réussit la mobilité d'un seul canal quand il faut notamment changer tous les canaux de sécurité. Ainsi, on pourrait appeler la fonction « mobility » pour chaque canal, mais cela reste trop lourd à gérer pour la Mobility_Application. La solution est la suivant fonction qui change les adresses @adr par @adr_new dans toutes les SAassociations de sécurité de la base de données.

REM_MSG_FUNC TION > API_MOBILI TY	+		REM_SYN_IPSEC

mobility_all (sfd, @adr, @adr_new )

4.3.5 Traitement des messages pour l'API_IPsec distante

Le fichier « process.c » fait un traitement initial des messages pour les renvoyer au module spécifique qui peut réaliser les actions demandées. Ensuite on détaille le traitement des messages qui sont dirigés vers l'API_IPsec distante. En effet, quand une application veut manager une API_IPsec distante elle doit s'y connecter et obtenir son descripteur de socket « sfd_remote ». Puis, elle doit encapsuler tous les messages en utilisant un Header de type REM_MSG_FUNC TION suivi par le paramètre sfd_remote. La figure suivante montre le traitement du message : on prend le sfd_remote, on efface le Header1 et on renvoie le message original à l'API_IPsec distante. Normalement le message original est aussi traité dans l'API_IPsec locale.

H1: REM_MSG_FUNC TION
P1: sfd_remote

H2: Message Original
F2 / P2 / R2



Application



H2: Message Original
F2 / P2 / R2

API_IPsec
Local

process

H2: Message Original
F2 / P2 / R2

API_IPSEC
Remote

module

Figure 23. Traitement des messages REM_MSG_FUNCTION pour l'API_IPsec distante

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4.3.6 La compilation et le debug

Le projet est compilé avec l'utilitaire «makefile» de Linux. Il est configuré pour utiliser le GCC (GNU C Compiler) et compiler et linker tous les fichiers du répertoire du projet, avec les dépendances nécessaires et les headers du système ou des librairies (comme « libipsec» ou « libpthread ») spécifiques.

Une étude de manuels et de tutoriales a été nécessaire pour écrire les fichiers de configuration « configure.am » et « makefile.am». Aussi, la connaissance pour linker ou créer librairies dynamiques (*.so) et statiques (*.a), ou l'emplacement des headers et librairies du système a été indispensable pour réussir a bien compiler le projet d'API_IPsec qui a toujours vu grandir la taille et le nombre de ses fichiers source. Dans l'Annexe on détaille le contenu des fichiers de configuration.

Le debuggage s'est fait de manière manuelle, avec la méthode de « essai / error ».

4.3.7 Prototype de la Mobility_Application

La Mobility_Application, comme toute autre application qui veut utiliser l'API_IPsec, doit compiler les fichiers qui contiennent les fonctions et messages de communication. Pour cette raison, on a développé cette première version aussi en langage C.

La suivante figure présente le schéma des fichiers source qui constituent la Mobility_Application et leur interrelation:



Figure 24. Schéma des fichiers source de la Mobility_Application

«MA.c» est le fichier principal de la Mobility_Application. Principalement elle utilise le fichier « app_msgs », qu'on a déjà expliqué, pour envoyer les messages à l'API_IPsec et savoir comme atteindre ses réponses de confirmation, d'erreur ou de valeurs.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

On veut faire noter que dans cette première version le fichier « app_detect » n'est pas réalisé mais émulé directement dans la MA. Le fichier « api_utils » ou les structures de « api_structs » sont également réutilisés de manière à faciliter le développement. La Mobility_Application ne devrait pas les connaître, seule l'API_IPsec peut connaître ce type de structures ou de fonctions d'utilité.

4.3.8 Démonstrateur de l'API_IPsec

Le démonstrateur de l'API_IPsec, présenté dans la figure suivante, a été construit pour valider et tester les performances de l'API_IPsec. L'ordinateur portable (à gauche) on le voit comme le client, le Mobile Noeud ou le noeud qui change. Il utilise la Mobility_Application qui s'appuie sur l' « API_IPsec Local » pour gérer les scénarios qu'on a planifié. Il a une connexion de sécurité avec un autre ordinateur (à droite), qu'on le voit comme le serveur ou le Noeud fixe qui ne change pas. Il a une API_IPsec qui va interagir comme l' « API_IPsec Remote ». Dans la figure on montre les messages de connexion que la Mobility_Application envoie aux deux API_IPsec pour initialiser et arrêter le Démonstrateur.



Figure 25. Démonstrateur de l'API_IPsec et messages pour l'inisialiter et l'ârreter

4.4 Tests et Résultats

Cette partie décrit les tests réalisés avec le Démonstrateur de l'API_IPsec. D'une part, on montre les principales fonctionnalités qu'à la fin du stage est capable de faire l'API_IPsec. D'une autre part, on mesure les performances de l'API_IPsec par rapport à IKEv2 et MOBIKE, son extension pour la mobilité. Il est intéressant de déterminer si l'API_IPsec, qui a d'objectifs plus généralistes pour manager la sécurité IPsec, permet s'approcher aux exploits de ces deux solutions standardisés d'aujourd'hui. Comme on a déjà justifié dans la partie théorique, l'implémentation utilisée pour IKEv2 et MOBIKE dans les tests est strongSwan.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

On a fait trois test avec l'API_IPsec: la création d'une connexion de sécurité dans un scénario statique, le changement d'une connexion de sécurité dans le scénario de Mobilité et l'héritage d'une connexion à partir d'une déjà étable dans le scénario de Multihoming. Ensuite, on a répété le premier test mais avec IKEv2. Puis le deuxième, logiquement avec MOBIKE. Enfin on présente une comparative. Le test de multihoming est hors de comparative parce que dévient une innovation que peut faire l'API_IPsec.

Dans chaque test on présente un schéma du scénario traité, la configuration établie dans chaque machine avant le test, et les résultats oil on considère comme mesure de performance : le nombre de paquets et le nombre de bytes transmis entre les deux machines nécessaire pour gérer le scénario et le temps utilisé. Le logicielle utilisé pour mesurer est « Wireshark » (successeur d' «Ethereal») et on l'a situé du côté de la Mobility_Application.

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

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.

4.4.4 Test d'IKEv2 (strongSwan)

Même schéma que dans le Test 1.

Configuration

On prend la configuration du Test 1 mais on ajoute une ligne d'exception pour IKE : il a besoin du port 500 libre pour échanger des messages. Pour la configuration d'IKE, lire la part de l'Annexe : utilisation de strongSwan.

Client (@1.5):

> sudo ifconfig eth0 192.168.1.5

> sudo ip sec restart

> sudo setkey -f ISACLI_4

flush; spdflush;

# IPSEC

spdadd 192.168.1.1[any] 192.168.1.5[any] any -P in ipsec esp/transport//require; spdadd 192.168.1.5[any] 192.168.1.1[any] any -P out ipsec esp/transport//require; # IKEv2 (hole)

spdadd 192.168.1.1[500] 192.168.1.5[500] any -P in none;

spdadd 192.168.1.5[500] 192.168.1.1[500] any -P out none;

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Detail des connexions IKEv2 du client : # ipsec.conf - strongSwan IPsec configuration file

conn host-host-CERT conn ho st-host-PSK

mobike=no mobike=no

left=192.168.1.5 authby=secret

leftid=@ moony.strongswan.org left=192.168.1.5

leftcert=moonyCert.pem leftid=@ moony.strongswan.org

right=192.168.1.1 right=192.168.1.1

rightid="C=FR, L=Issy, CN= suny.strongswan.org" rightid=@ suny.strongswan.org

type=transport type=transport

auto=add auto=add

Serveur (@1.1):

> sudo ifconfig eth0 192.168.1.1

> sudo ip sec restart

> sudo setkey -f i sa ser_4

flush; spdflush;

#IPSEC

spdadd 192.168.1.5[any] 192.168.1.1[any] any -P in ipsec espitransportilrequire; spdadd 192.168.1.1[any] 192.168.1.5[any] any -P out ipsec espitransportilrequire; #IKEv2 (hole)

spdadd 192.168.1.5[500] 192.168.1.1[500] any -P in none;

spdadd 192.168.1.1[500] 192.168.1.5[500] any -P out none;

IPsec configuration file

Detail des connexions IKEv2 du serveur : # ipsec.conf - strongSwan

conn ho st-host-PSK

mobike=no authby=secret

left=192.168.1.1 leftid=@ suny.strongswan.org right=192.168.1.5 rightid=@ moony.strongswan.org type=transport

auto=add

conn host-host-CERT

mobike=no

left=192.168.1.1 leftid=@ suny.strongswan.org leftcert=sunyCert.pem right=192.168.1.5

rightid="C=FR, L=Issy, CN= moony.strongswan.org" type=transport

auto=add

Client (@1.5):

> sudo ipsec up host-host-CERT [Répéter la configuration antérieure]

> sudo ipsec up ho st-host-PSK

Résultats

IKEv2 réalise quatre messages pour créer deux SA dans chaque noeud et établir un canal sécurisé d'accord avec la politique de sécurité. On a fait les deux types de tests suivants avec IKEv2 :



Figure 34.1 IKEv2. Authentification avec Certificats

Figure 34.2 IKEv2. Authentification avec Pre-Shared-Key

On observe que l'authentification avec Certificats est plus lente qu'avec PSK.

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

4.4.5 Test de MOBIKE (strongSwan)

Même schéma que dans le Test 2.

Configuration

Même configuration de la SPD/SAD que dans le Test 4 sauf deux changements pour spécifier le mode unique que MOBIKE utilise : mode tunnel. Lire l'Annex : utilisation de strongSwan.

Client (@1.5) :

> sudo ifconfig eth0 192.168.1.5

> sudo ip sec restart

> sudo setkey -f ISACLI_5

ipsec esp/tunnel/192.168.1.5-192.168.1.1/require;
ipsec esp/tunnel/192.168.1.1-192.168.1.5/require;

Detail des connexions IKEv2 du client : # ipsec.conf - strongSwan IPsec configuration file

conn mobike-PSK

mobike=yes

authby= secret left=192.168.1.4 leftid=@ moony.strongswan.org right=192.168.1.1 rightid=@ suny.strongswan.org type=tunnel

auto=add

conn mobike-CERT

mobike=ye s

left=192.168.1.4

leftid=@ moony.strongswan.org leftcert=moonyCert.pem

right=192.168.1.1

rightid="C=FR, L=I ssy, CN= suny. strong swan.org" type=tunnel

auto=add

Serveur (@1.1) :

> sudo ifconfig eth0 192.168.1.1

> sudo ip sec restart

> sudo setkey --f ISASER_5

ipsec esp/tunnel/192.168.1.1-192.168.1.5/require;
ipsec esp/tunnel/192.168.1.5-192.168.1.1/require;

Detail des connexions IKEv2 du serveur : # ipsec.conf - strongSwan IPsec configuration file

conn mobike-PSK

mobike=yes authby= secret left=192.168.1.1

leftid=@ suny.strongswan.org right=192.168.1.5 rightid=@ moony.strongswan.org type=tunnel

auto=add

conn mobike-CERT

mobike=ye s

left=192.168.1.1

leftid=@ suny.strongswan.org

leftcert= sunyCert.pem

right=192.168.1.5

rightid="C=FR, L=I ssy, CN=moony. strong swan.org" type=tunnel

auto=add

Client (@1.4) :

> sudo ifconfig eth0 192.168.1.4

> sudo ipsec up host-host-CERT // cela etablie les SA dans les deux noeuds > sudo ipsec up mobike-CERT // cela fait la mobilite avec certificats
[repeter tout l'anterieur]

> sudo ipsec up ho st-host-PSK // cela etablie les SA dans les deux noeuds

> sudo ipsec up mobike-PSK // cela fait la mobilite avec Pre-Shared-Keys

Étude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Résultats

MOBIKE réalise aussi 4 messages pour actualiser dans les SA l'adresse du noeud en mobilité. Ces paquets comprennent deux MOBIKE_SUPPORT, le UPDATE_SA_ADDRESS et le COOKI2. Par contre, on montre que «Wireshark» détecte qu'on traite encore avec IKEv2 donc il affiche incorrectement les types de paquet.

On a fait les deux tests suivants avec MOBIKE :



Figure 35.1 MOBIKE. Authentification avec Certificats

Figure 35.2 MOBIKE. Authentification avec Pre-Shared-Key

- On montre que pour MOBIKE l'authentification avec certificats est plus lente qu'avec PSK.

- On observe que MOBIKE est plus lent que IKEv2.

- On remarque un erreur avec MOBIKE : on a perdu complètement l'adresse @1.5 lors de la mobilité. Alors MOBIKE n'a pas pu effacer les associations de sécurité de la connexion antérieure à la mobilité dans le noeud qui ne change pas.

4.4.6 Comparative API_IPsec versus IKEv2 / MOBIKE

La table comparative suivante résume les résultats :



Mesure de performance	1. Scénario Statique			2. Mobilité			3. Multihoming
	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

Table 4. Comparative des différents tests

** Le temps moyen est calculé sur 5 échantillons.

(*) 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

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

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.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

5. Conclusion

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.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

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.

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilité et le Multihoming

6. Annexes

6.1 Fonctions et structures de l'API_IPsec

On fournit joint à ce rapport de stage le code du projet de l'API_IPsec avec ses fonctions et ses structures bien expliquées.

6.2 Compilation : fichiers de configuration

6.2.1 Liste de commandes pour faire un projet avec « automake »

.>autoscan - logiciel de linux que analyse tout le repertoire du projet et il crée le fichier "configure.scan"

.>autolocal 4

.>autoheader --f - création des fichiers comme "config.h" qu'il faut ajouter dans tous les headers du projet.

>autoconf --f - analyse le fichier "configure.ac"

>automake --acf - -foreign

>./configure - il vérifie

>./src/make

6.2.2 Configure.ac

# package + version

AC_PREREQ(2.59) AC_INI T( [apic], [1.2])

# gives an existing source file AC_CONFIG_SRCDIR([src/api_fdb.c])

AC_CONFIG_HEADER([src/config.h])

AM_INI T_AU TOMAKE

# copy&paste "configure.scan" generated by "autoscan"

# Checks for programs:

AC_PROG_CXX

AC_PROG_CC

# Checks for libraries

....

# Checks for header files.

....

# Checks for typedefs, structures, and compiler characteristics.

....

# Checks for library functions.

....

AC_CONFIG_FILES([src/Makefile src/ipsecvlch/Makefile]) AC_OU TPU T

6.2.3 Makefile.am

sbin_PROGRAMS = apic AM_CFLAGS = -L/usr/lib -lpthread

apic_SOURCES = apic.c1

api_fdb.c api_fdb.h1

api_fdb_sa.c api_fdb_sa.h1

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilité et le Multihoming

api_fdb_sp.c api_fdb_sp.h1

api_process.c api_process.h1

api_utils.c api_utils.h1

api_structs.h api_include_basic.h 1

apx_msg_process.c apx_msg_process.h 1

apx_msg_gen.c apx_msg_gen.h apx_msg_structs.h 1 apx_errors.c apx_errors.h

SUBDIRS = ipsecv1ch

apic_LDADD = ipsecv1ch/libipsecv1ch.a /usr/lib/libipsec.a

6.3 Configuration d'IPsec avec 0 setkey »

> setkey --D Dump (lister toutes les entrées) de la SAD.

> setkey --DP Dump de la SPD.

> setkey --F Flush (effacer toutes les entrées) de la SAD.

> setkey --FP Flush de la SPD.

> setkey --f <fichier>

spdf~ush ; spddump ; f~ush ; dump ;

#ADD SP

#spdadd @src/range @dst/range protocol -Policy in-out none-ipsec g IPsec/mode // require-used; spdadd 192.168.1.1/24 192.168.1.5/24 tcp -P out ipsec espitransportll require;

#ADD SA

#add @src @dst transf SPI -E-A algorithm key ;

add 192.168.1.1 192.168.1.5 esp 1001 -E des-cbc 0x3ffe05014819ffff ;

6.4 Configuration de 0 strongswan »

Pour utiliser strongSwan et tester IKEv2 et MOBIKE sur le Démonstrateur de l'API_IPsec on doit configurer les fichiers « ipsec.conf » « ipsec.secrets » et créer de certificats pour chaque machine.

6.4.1 Fichiers et répertoires importants

(strongswan v4.1.9)

/etc/ipsec.conf >> Configuration manuelle des connexions des noeuds

/etc/ipsec.secrets >> Les clés privés soit PSK (Pre-Shared-Key) soit RSA

/etc/ipsec.d/ >> Il y a les certificats des utilisateurs, la CA, les clés (*.pem), les politiques... /var/lib/strongswan/ >> fichiers de redirection vers "ipsec.conf.inc" et "ipsec.secrets.inc" /var/log/ >> fichier "daemon.log" qui est la sortie de strongSwan

6.4.2 Création de certificats au format X509

Pour utiliser les certificats avec strongSwan, on crée une CA et un certificat signé pour chaque machine.

Creation d'une Autorite de Certification (CA)

>> openssl req -x509 -days 1460 -newkey rsa:2048 -keyout strongswanKey.pem -out strongswanCert.pem

Etude d'IPsec Projet d'une API_IPSEC pour la Mobilite et le Multihoming

Cela genere une base de cles de type RSA dans e strongswanKey.pem ». Puis des questions sont posses a l'utilisateur pour personnaliser la CA. Introduir ". " pour ignorer une donnee. Enfin la CA est cr~e et associe au fichier e strongswanCert.pem ».

Generation d'un Certificat Request :

» sudo openssl req -newkey rsa:1024 -keyout moonyKey.pem -out moonyReq.pem

Un certificat Request doit etre signe par la CA pour etre valide.

Verification du contenu d'un certificat signe

» openssl x509 -in cert.pem -noout -text

Cette verification montre le contenu d'un certificat signe mais ne considere pas valide un certificat Request. Signer un certificat par la CA :

»sudo openssl x509 -req -days 365 -in moonyReq.pem --CA strongswanCert.pem -CAkey strongswanKey.pem -CA createserial -out moonyCert.pem

Le certificat "moonyCert.pem" est signe par la CA et on peut l'utiliser pour authentifier avec IKEv2.

6.4.3 ipsec.conf

Ce fichier contient la configuration initiale suivant. Puis, chaque connexion utilisée dans les tests est expliquée dans la section opportune.

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup

# plutodebug=all

# crlcheckinterval=600 # strictcrlpolicy=yes

# cachecrls=yes

# nat_traversal=yes crlcheckinterval=180 strictcrlpolicy=no

charonstart=yes

plutostart=no

# Add connections here.

conn %default

ikelifetime=60m keylife=20m rekeymargin=3m

keyingtries=1 keyexchange=ikev2

conn host-host-cert

conn host-host-p sk - definit dans la section 4.4.4 Test IKEv2

conn mobike-cert

conn mobike-p sk - definit dans la section 4.4.5 Test MOBIKE

Etude d'IPsec Projet d'une API_IPSEC pour la Mobility et le Multihoming

7. Bibliographie

[1] Stallings, W. Network security essentials. 2nd ed. Prentice Hall, 2000.

[2] Kent, S. and Seo, K. Security Architecture for the /nternet Protocol (/Psecv2). RFC 4301. IE TF, 2005. [2.1] Chapitre 13. Page 71. Differences avec RFC 240 1 (/Psecv 1, 1998. Obsolete).

[3] McDonald, D. and Metz C. and Phan B. PF_KEY Key Management API, Version 2.RFC 2367. IE TF, 1998.

[4] Kaufman, C. /nternet Key Exchange (/KEv2) Protocol. RFC 4306. IE TF, 2005 [4.1] Appendix A : Summary of changes from /KEv 1.

[5] Montavont, N., Wakikawa, R., Ernst, T., Ng, C. and Kuladinithi, K. Motivations and Scenarios for Using Multiple /nterfaces and Global Addresses. Draft-monami6-multihoming-motivation-scenario-03. IE TF, 2008.

[6] Johnson, D. and Perkins C. and Arkko, J. Mobility Support in /Pv6. RFC 3775. IE TF, 2004 Devarapalli, V. and Dupont, F. Using /Psec to Protect MIPv6 Signaling between Mobile Nodes and Home

Agents. RFC 3776. IETF, 2004

Devarapalli, V. and Dupont, F. M/Pv6 with /KEv2 and /Psec. RFC 4877. IE TF, 2007

[7] Eronen, P. IKEv2 Mobility and Multihoming Protocol (MOBIKE). RFC 4555. IE TF, 2006.

[8] Kivinen, T. and Tschofenig, H. Design of the MOB/KE Protocol. RFC 4621. IE TF, 2006.

[9] S. Sugimoto, F. Dupont, M. Nakamura. PF_?KEY Extension as an /nterface between Mobile /Pv6 and /Psec//KE. Draft-sugimoto-mip6-pfkey-migrate-04. IE TF, 2007.

[10] M. Qi, H. Li et al. /nterfacing between /KEv2//Psec & M/Pv6 by simple PF_?KEY extensions. Draft-qi-mip6-ikev2-interfacing-01. IE TF, 2007.

[11] Moskowitz, Robert, et al. Host /dentity Protocol (H/P). Draft-ietf-hip-base-10.txt. IE TF, 2007.

8. Références d'Internet

Références indispensables pour la partie technique :

- Tutorial de Pthreads. https://computing.llnl.gov/tutorials/pthreads/

- Documentation Strongswan. www.strongswan.org/

- Automake et Autoconf. http://www.openismus.com/documents/linux/automake/automake.shtml