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 ».
| 
