Critique des IPsec

Un article de IPv6.

Mise en place d'une paire de SA IPsec

Table des matières

Comparaison entre VPN IPsec et VPN SSL

Dès lors que l'on introduit de la sécurité dans un réseau, que ce soit pour filtrer les communications, ou pour protéger le trafic en confidentialité ou en authentification, les performances d'un réseau en termes de débit et temps de transit sont affectées. Cette diminution de performances est en partie due aux opérations de chiffrement/déchiffrement et de génération/vérification de l'authentificateur qui sont très gourmandes en temps de calcul.

Il faut également savoir que l'introduction de l'IPsec dans un réseau a un impact sur le fonctionnement même du réseau et sur l'usage que l'on souhaite en faire [Pui02-A] [Pui02-B] [Pui04-B]. En effet, IPsec actuel souffre des lacunes suivantes :

• Protéger une communication multicast avec IPsec n'est pas possible actuellement. Plus exactement, les protocoles AH et ESP autorisent le multicast. Cependant, le protocole de gestion des associations de sécurité IKE ne prévoit pas de négocier des associations de sécurité entre plus de deux équipements de sécurité.
• Le renouvellement de l'association de sécurité n'est pas transparent en ce sens que généralement pendant toute la durée du renouvellement, aucun trafic ne peut être échangé. A noter qu'un renouvellement d'association de sécurité est prévisible, car il est déclenché à chaque fois que l'association de sécurité arrive à expiration ou dès que le numéro de séquence a effectué un cycle (ceci pour éviter tout rejeu de paquet). Des méthodes de renouvellement "anticipées" existent donc, mais elles s'avèrent encore bien souvent problématiques.
• La fragmentation de paquets IP qui peut survenir dans un réseau IP a un impact sérieux sur les performances d'un réseau en termes de débit et de temps de transit. En effet, si un paquet se trouve fragmenté, il est nécessaire de le réassembler avant de procéder à son déchiffrement et/ou de vérifier la validité de son authentificateur. Or, ce réassemblage est très coûteux car il fait entre autres appel à des opérations de bufferisation. De plus, du fait de cette opération de bufferisation, il est possible qu'en période de forte charge, des paquets soient perdus.
• Le protocole DHCP permet entre autre d'allouer dynamiquement une adresse à un terminal. La difficulté est de savoir, au niveau d'une passerelle, quelle politique de sécurité appliquée au trafic en provenance de ces terminaux.
• Les IPsec et le DNS peuvent s'affecter de plusieurs façons. En particulier, l'exploitation d'une faille du DNS empêchant par exemple la résolution de nom peut bloquer le fonctionnement des IPsec du fait qu'IPsec peut identifier un correspondant en fonction de son nom de domaine. D'autre part, les réponses DNS de trop grande taille peuvent être bloquées par une passerelle IPsec si la fragmentation est interdite sur ces paquets ; en effet, la passerelle IPsec mettant en oeuvre un tunnel IPsec voudra fragmenter les paquets avant de les encapsuler.
• La majorité des logiciels IPsec existants ne vérifient pas qu'un paquet reçu est correctement protégé [Pui03]. Ainsi, si un tunnel AH ou ESP est établi entre deux équipements IPsec et n'assure que les services d'intégrité et d'authentification, il est tout à fait possible d'usurper l'un de ces équipements et d'injecter du trafic dans les échanges. Bien entendu, cette attaque suppose que le terminal espion se trouve sur le même réseau local que l'équipement usurpé. Grâce à une attaque ARP (Address Resolution Protocol), il peut empoisonner le cache ARP des machines environnantes et ainsi se voir rediriger tout le trafic destiné à l'équipement IPsec. Le tunnel n'étant pas chiffré, le terminal espion peut alors modifier ou forger des paquets en supprimant l'extension IPsec (AH ou ESP) et envoyer ces paquets non protégés vers l'équipement IPsec destinataire. Ce dernier ne vérifiant pas le niveau de protection attendue, il accepte les paquets et les traite.
• Les extensions ESP et AH ne sont pas compatibles avec la traduction d'adresses/ports. Cependant, une solution palliative [RFC 3947] [RFC 3948] est en cours de définition pour ESP à l'IETF, ce qui permet d'offrir aux utilisateurs un accès VPN depuis un plus grand nombre de points d'accès au réseau. Noter que pour cette raison, mais également pour son service de confidentialité, l'extension ESP a la faveur des utilisateurs pour protéger les échanges IP.
• Actuellement, il n'existe pas d'infrastructure PKI mondiale. Les certificats de clés publiques n'ont le plus souvent qu'une portée nationale faute d'accord entre autorités de certification. Il est vrai que cette notion de confiance entre autorités de certification n'est pas anodine puisqu'elle est à la base de toute la sécurité. L'enjeu ici n'est pas technique, mais bien politique et juridique.
• Le manque de dynamicité dans la mise en oeuvre des IPsec. Pour que les IPsec soient d'un usage plus courant, non limité à un domaine administratif défini, il faudrait que n'importe quel couple d'équipements IPsec puissent entrer en communication de façon improvisée, sans aucun arrangement initial sur des secrets cryptographiques, des certificats, sans faire appel à des services spécifiques... Aujourd'hui, cela n'est pas faisable car dans le meilleur des cas, si des certificats sont utilisés, il est nécessaire qu'ils soient reconnus de part et d'autre comme de confiance. Cela suppose dans les faits, que les équipements IPsec soient enregistrés auprès de la même autorité de certification, voire pour les équipements IPsec les plus tolérants, que le certificat du partenaire soit préchargé dans l'équipement.

Mise en place d'une paire de SA IPsec

Table des matières

Comparaison entre VPN IPsec et VPN SSL