V.3.3.6. Inconvénients
Les problèmes rencontrés avec le protocole IPSec
sont relatifs à l'ambiguïté documentaire,
l'implémentation et a la redondance des fonctionnalités.
V.3.3.6.1. Interopérabilité entre les
implémentations
A cause de l'ambiguïté et la complexité
dans la documentation des différentes parties de ce protocole, nous
sommes arrivés actuellement à des implémentations
incompatibles. De plus, puisque IPSec est intégré dans le noyau
des systèmes, l'interopérabilité d'IPSec dépendra
de la volonté qu'auront les constructeurs à faire coopérer
des équipements hétérogènes entre eux (cela pose
notamment le problème des algorithmes cryptographiques communs).
V.3.3.6.2. Redondances des
fonctionnalités
d'authentification. Cette situation peut entraîner des
faiblesses dans les différentes versions du produit IPSec.
Compte tenu de la souplesse des protocoles, certaines
combinaisons peuvent s'avérer inacceptables au plan de la
sécurité. Par exemple, le protocole ESP offre des services
d'authentification et de chiffrement mais n'empêche pas l'utilisateur de
transmettre un message chiffré sans authentification.
V.3.3.6.3. Broadcast et multicast
L'utilisation d'IPSec pour l'envoi et la réception de
datagrammes multicast et broadcast pose quelques problèmes liés a
des difficultés qu'une simple implémentation de la puissance de
calcul ne saurait résoudre, comme la vérification des
numéros de séquence. Le service de protection contre la
duplication des données n'est donc pas utilisable en environnement
multicast et broadcast a l'heure actuelle.
V.3.3.6.4. NATs
Théoriquement, aucune translation d'adresse ne devrait
affecter un datagramme IPSec, car ce type d'opération modifie le contenu
des datagrammes, ce qui est incompatible avec les mécanismes de
protection de l'intégrité des données d'IPSec. Par
exemple, en mode AH (Authentication Header), l'encapsulation IPSec ajoute une
somme de contrôle (checksum), calculée notamment sur les
adresses source et destination. Le protocole IKE, lui aussi se base sur les
adresses IP sources et destinations pour la génération des
clés et des cookies.
V.3.4. Protocoles ISAKMP et IKEv1 V.3.4.1.
Généralités
Le protocole ISAKMP (Internet Security Association and Key
Management Protocole), défini dans le RFC 2408 de novembre 1998, est
proposé pour la gestion des associations de sécurité.
ISAKMP fournit un cadre générique pour la négociation, la
modification et la destruction des SA ainsi que pour le format de leurs
attributs.
Dans le cadre de la standardisation d'IPSec, ISAKMP est
associé a une partie des protocoles SKEME et Oakley pour donner un
protocole final du nom d'Internet Key Exchange IKE. ISAKMP n'impose pas un
algorithme spécifique d'échanges de clés. Il se compose
plutôt d'un ensemble de types de messages qui permettent l'utilisation de
divers algorithmes d'échanges de clés. Cependant, Oakley est
l'algorithme spécifique d'échange de clés exigé
pour la version initiale d'ISAKMP.
Pour IPSec, IKE est complété par un «
domaine d'interprétation '> ou (Domain of Interpretation, DOI). C'est
dans ce document qu'on défini les algorithmes d'échanges des
clés et les différents blocs ISAKMP.
La figure V.6 illustre l'architecture d'ISAKMP.
Fig. V.6. Architecture d'ISAKMP
| 
