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

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.