Cet article présente le fonctionnement du protocole IPsec, qui permet de créer des réseaux privés virtuels de manière conforme aux spécifications de l’IETF. Les services offerts par IPsec et leurs limitations y sont détaillés, de même que les problèmes d’interopérabilité, tant avec d’autres protocoles qu’entre applications différentes. Enfin, quelques implémentations sont présentées, et un rapide aperçu de leur conformité aux standards est donné.

1 – Introduction au protocole IPSec

Le protocole IPsec est l’une des méthodes permettant de créer des VPN (réseaux privés virtuels), c’est-à-dire de relier entre eux des systèmes informatiques de manière sûre en s’appuyant sur un réseau existant, lui-même considéré comme non sécurisé. Le terme sûr a ici une signification assez vague, mais peut en particulier couvrir les notions d’intégrité et de confidentialité. L’intérêt majeur de cette solution par rapport à d’autres techniques (par exemple les tunnels SSH) est qu’il s’agit d’une méthode standard (facultative en IPv4, mais obligatoire en IPv6), mise au point dans ce but précis, décrite par différentes RFCs, et donc interopérable. Quelques avantages supplémentaires sont l’économie de bande passante, d’une part parce que la compression des entêtes des données transmises est prévue par ce standard, et d’autre part parce que celui-ci ne fait pas appel à de trop lourdes techniques d’encapsulation, comme par exemple les tunnels PPP sur lien SSH. Il permet également de protéger des protocoles de bas niveau comme ICMP et IGMP, RIP, etc… 

IPSec présente en outre l‘intérêt d‘être une solution évolutive, puisque les algorithmes de chiffrement et d‘authentification à proprement parler sont spécifiés séparément du protocole lui-même. Celle-ci a cependant l‘inconvénient inhérent de sa flexibilité et sa grande complexité rend son implémentation délicate. Les différents services offerts par le protocole IPSec sont détaillés dans ce document. Les formes pour combiner entre eux ces divers protocoles, ce que leur mise en œuvre est tenue de supporter et sont ensuite présentées. Les moyens de la gestion des clefs de chiffrement et signature sont étudiés ainsi que la problèmatique sur l‘interopérabilité associée est évoquée. Enfin, un aperçu rapide est donné sur quelques implémentations IPSec, en s‘intéressant essentiellement sur leur conformité aux spécifications.

2 – Les services offerts par IPsec

2.1 – Les deux modes d’échange IPsec

Une communication entre deux hôtes, protégée par IPsec, est susceptible de fonctionner suivant deux modes différents : le mode transport et le mode tunnel. Le premier offre essentiellement une protection aux protocoles de niveau supérieur, le second permet quant à lui d’encapsuler des datagrammes IP dans d’autres datagrammes IP, dont le contenu est protégé. L’intérêt majeur de ce second mode est qu’il rend la mise en place de passerelles de sécurité qui traitent toute la partie IPsec d’une communication et transmettent les datagrammes épurés de leur partie IPsec à leur destinataire réel réalisable. Il est également possible d’encapsuler une communication IPsec en mode tunnel ou transport dans une autre communication IPsec en mode tunnel, elle-même traitée par une passerelle de sécurité, qui transmet les datagrammes après suppression de leur première enveloppe à un hôte traitant à son tour les protections restantes ou à une seconde passerelle de sécurité.

2.2 – Les protocoles à la base d’IPsec

2.2.1 – AH (authentication header)

AH est le premier et le plus simple des protocoles de protection des données qui font partie de la spécification IPsec. Il est détaillé dans la RFC 2402. Il a pour vocation de garantir :

• L’authentification : les datagrammes IP reçus ont effectivement été émis par l’hôte dont l’adresse IP est indiquée comme adresse source dans les entêtes.
• L’unicité (optionnelle, à la discrétion du récepteur) : un datagramme ayant été émis légitimement et enregistré par un attaquant ne peut être réutilisé par ce dernier, les attaques par rejeu sont ainsi évitées.
• L’intégrité : les champs suivants du datagramme IP n’ont pas été modifiés depuis leur émission : les données (en mode tunnel, ceci comprend la totalité des champs, y compris les entêtes, du datagramme IP encapsulé dans le datagramme protégé par AH), version (4 en IPv4, 6 en IPv6), longueur de l’entête (en IPv4), longueur totale du datagramme (en IPv4), longueur des données (en IPv6), identification, protocole ou entête suivant (ce champ vaut 51 pour indiquer qu’il s’agit du protocole AH), adresse IP de l’émetteur, adresse IP du destinataire (sans source routing).

En outre, au cas où du source routing serait présent, le champ adresse IP du destinataire a la valeur que l’émetteur a prévu qu’il aurait lors de sa réception par le destinataire. Cependant, la valeur que prendront les champs type de service (IPv4), indicateurs (IPv4), index de fragment (IPv4), TTL (IPv4), somme de contrôle d’entête (IPv4), classe (IPv6), flow label (IPv6), et hop limit (IPv6) lors de leur réception n’étant pas prédictible au moment de l’émission, leur intégrité n’est pas garantie par AH.

L’intégrité de celles des options IP qui ne sont pas modifiables pendant le transport est assurée, celle des autres options ne l’est pas. 
Attention, AH n’assure pas la confidentialité : les données sont signées mais pas chiffrées. 

Enfin, AH ne spécifie pas d’algorithme de signature particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la RFC 2402 est tenue de supporter les algorithmes MD5 et SHA-1.

2.2.2 – ESP (encapsulating security payload)

ESP est le second protocole de protection des données qui fait partie de la spécification IPsec. Il est détaillé dans la RFC 2406. Contrairement à AH, ESP ne protège pas les entêtes des datagrammes IP utilisés pour transmettre la communication. Seules les données sont protégées. En mode transport, il assure :

• La confidentialité des données (optionnelle) : la partie données des datagrammes IP transmis est chiffrée.
• L’authentification (optionnelle, mais obligatoire en l’absence de confidentialité) : la partie données des datagrammes IP reçus ne peut avoir été émise que par l’hôte avec lequel a lieu l’échange IPsec, qui ne peut s’authentifier avec succès que s’il connaît la clef associée à la communication ESP. Il est également important de savoir que l’absence d’authentification nuit à la confidentialité, en la rendant plus vulnérable à certaines attaques actives.
• L’unicité (optionnelle, à la discrétion du récepteur).
• L’integrité : les données n’ont pas été modifiées depuis leur émission.

En mode tunnel, ces garanties s’appliquent aux données du datagramme dans lequel est encapsulé le trafic utile, donc à la totalité (entêtes et options inclus) du datagramme encapsulé. Dans ce mode, deux avantages supplémentaires apparaissent:

• Une confidentialité, limitée, des flux de données (en mode tunnel uniquement, lorsque la confidentialité est assurée) : un attaquant capable d’observer les données transitant par un lien n’est pas à même de déterminer quel volume de données est transféré entre deux hôtes particuliers. Par exemple, si la communication entre deux sous-réseaux est chiffrée à l’aide d’un tunnel ESP, le volume total de données échangées entre ces deux sous-réseaux est calculable par cet attaquant, mais pas la répartition de ce volume entre les différents systèmes de ces sous-réseaux.
• La confidentialité des données, si elle est demandée, s’étend à l’ensemble des champs, y compris les entêtes, du datagramme IP encapsulé dans le datagramme protégé par ESP).

Enfin, ESP ne spécifie pas d’algorithme de signature ou de chiffrement particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme à la RFC 2406 est tenue de supporter l’algorithme de chiffrement DES en mode CBC, et les signatures à l’aide des fonctions de hachage MD5 et SHA-1.

2.2.3 – Implantation d’IPSec dans le datagramme IP

La figure 1 montre comment les données nécessaires au bon fonctionnement des formats AH et ESP sont placées dans le datagramme IPv4. Il s’agit bien d’un ajout dans le datagramme IP, et non de nouveaux datagrammes, ce qui permet un nombre théoriquement illimité ou presque d’encapsulations IPsec : un datagramme donné peut par exemple être protégé à l’aide de trois applications successives de AH et de deux encapsulations de ESP.

3 – Architectures de sécurité

3.1 – Associations de sécurité

La RFC 2401 (Security Architecture for the Internet Protocol) décrit le protocole IPsec au niveau le plus élevé. En particulier, elle indique ce qu’une implémentation est censée permettre de configurer en termes de politique de sécurité (c’est-à-dire quels échanges IP doivent être protégés par IPsec et, le cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable d’utiliser IPsec doit être présente une SPD (security policy database), dont la forme précise est laissée au choix de l’implémentation, et qui permet de préciser la politique de sécurité à appliquer au système. Chaque entrée de cette base de données est identifiée par un SPI (security parameters index) unique (32 bits) choisi arbitrairement. 

Une communication protégée à l’aide d’IPsec est appelée une SA (security association). Une SA repose sur une unique application de AH ou sur une unique application de ESP. Ceci n’exclut pas l’usage simultané de AH et ESP entre deux systèmes, ou par exemple l’encapsulation des datagrammes AH dans d’autres datagrammes AH, mais plusieurs SA devront alors être activées entre les deux systèmes. En outre, une SA est unidirectionnelle. La protection d’une communication ayant lieu dans les deux sens nécessitera donc l’activation de deux SA. Chaque SA est identifiée de manière unique par un SPI, une adresse IP de destination (éventuellement adresse de broadcast ou de multicast), et un protocole (AH ou ESP). Les SA actives sont regroupées dans une SAD (security association database). 

La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non-IPsec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter, l’accepter sans traitement IPsec, ou appliquer IPsec. Dans le troisième cas, la SPD précise en outre quels traitements IPsec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou chiffrement utiliser). 

Les plus importants de ces termes sont récapitulés dans le tableau suivant :

• SPD base de données définissant la politique de sécurité
• SA une entrée de la SPD
• SAD liste des SA en cours d’utilisation

Les règles de la SPD doivent pouvoir, si l’adminsitrateur du système le souhaite, dépendre des paramètres suivants :

• adresse ou groupe d’adresses IP de destination
• adresse ou groupe d’adresses IP source
• nom du système (DNS complète, nom X.500 distingué ou général)
• protocole de transport utilisé (typiquement, TCP ou UDP)
• nom d’utilisateur complet, comme foo@bar.net (ce paramètre n’est toutefois pas obligatoire sur certains types d’implémentations)
• importance des données (ce paramètre n’est toutefois pas obligatoire sur certains types d’implémentations)
• ports source et destination (UDP et TCP seulement, le support de ce paramètre est facultatif)

Certains paramètres peuvent être illisibles à cause d’un éventuel chiffrement ESP au moment où ils sont traités, auquel cas la valeur de la SPD les concernant peut le préciser, il s’agit de :

• l’identité de l’utilisateur
• le protocole de transport
• les ports source et destination

Il est donc possible de spécifier une politique de sécurité relativement fine et détaillée. Cependant, une politique commune pour le trafic vers un ensemble de systèmes permet une meilleure protection contre l’analyse de trafic qu’une politique extrêmement détaillée, comprenant de nombreux paramètres propres à chaque système particulier. Enfin, si l’implémentation permet aux applications de préciser elles-mêmes à quelle partie du trafic appliquer IPsec et comment, l’administrateur doit pouvoir les empêcher de contourner la politique par défaut.

3.2 – Architectures supportées

Le protocole IPsec permet théoriquement n’importe quelle combinaison, en un nombre quasiment illimité de niveaux d’encapsulation, c’est-à-dire d’accumulations de SA. Néanmoins, les implémentations ne sont pas tenues d’offrir une telle flexibilité. Les architectures qu’une application conforme à la RFC 2401 doivent supporter, au nombre de quatre, sont décrites ci-dessous.

3.2.1 – Dialogue entre deux hôtes protégeant le trafic eux-mêmes

Deux hôtes engagent une communication IPsec, en encapsulant le protocole de haut niveau dans :
en mode transport :

• des datagrammes AH
• des datagrammes ESP
• ou des datagrammes ESP encapsulés dans des datagrammes AH

en mode tunnel :

• des datagrammes AH
• ou des datagrammes ESP

3.2.2 – Dialogue entre deux LANs à l’aide de passerelles de sécurité

Ici, deux passerelles de sécurité gèrent les conversations entre les hôtes de deux LANs différents, IPsec s’appliquant de manière transparente pour les hôtes. Les deux passerelles de sécurité échangent des datagrammes en mode tunnel, à l’aide de AH ou ESP (après routage, ceci correspond simplement à la deuxième partie du cas précédent), puis transmettent les datagrammes obtenus après traitement IPsec aux hôtes destinataires. Ainsi, les datagrammes IP émis par un système de l’un des deux LANs sont encapsulés dans d’autres datagrammes IP+IPsec par la passerelle du « LAN émetteur », encapsulation supprimée par la passerelle du « LAN récepteur » pour obtenir de nouveau les datagrammes IP originaux.

3.2.3 – Dialogue entre deux hôtes traversant deux passerelles de sécurité

Le troisième cas n’ajoute pas vraiment de prérequis sur les implémentations IPsec. Ainsi, une passerelle de sécurité doit avoir la capacité de transmettre dans un tunnel IPsec du trafic déjà sécurisé par IPsec. Celà autorise les dialogues IPsec entre deux hôtes situés eux-mêmes dans des LANs reliés par des passerelles de sécurité.

3.2.4 – Dialogue entre un hôte et une passerelle de sécurité

Le dernier cas est celui d’un hôte externe se connectant à un LAN protégé par une passerelle de sécurité. Les documentations techniques désignent souvent un tel hôte sous le nom de road warrior. Il engage une conversation IPsec avec un système du LAN en mode transport, le tout encapsulé dans un tunnel IPsec établi entre le road warrior lui-même et la passerelle de sécurité. Dans ce cas, les datagrammes du tunnel sont de type AH ou ESP et les datagrammes utilisés en mode transport doivent pouvoir être de type AH, ESP, ou ESP encapsulé dans AH.

4 – Gestion des clefs

Les services de protection offerts par IPsec s’appuient sur des algorithmes cryptographiques, et reposent donc sur des clefs. Si celles-ci sont gérables manuellement dans le cas où peu d’hôtes seront amenés à engager des conversations IPsec, ceci devient un véritable cauchemar quand le système commence à prendre un peu d’extension (le nombre de couples de clefs augmentant de manière quadratique avec le nombre de systèmes). C’est pourquoi la spécification IPsec propose également des procédés d’échange automatique de clefs, dont les aspects les plus importants sont ici évoqués. Une présentation complète de cette procédure dépasse toutefois le cadre de cet article. La RFC 2401 précise qu’une implémentation IPsec est tenue de supporter la gestion manuelle de clefs et la méthode d’échange automatique de clefs IKE, bien que d’autres algorithmes existent. Un point important est que la gestion de clefs automatique est considérée comme plus sûre que la gestion manuelle. 

Le protocole IKE (internet key exchange) est décrit par la RFC 2409. Il permet l’échange de clefs entre deux hôtes d’adresses IP connues préalablement ou inconnues selon le mode d’échange de clefs sélectionné. Parmi ses avantages figure le mode agressif (cette caractéristique n’est pas obligatoire), qui permet d’accélérer la négociation, au prix de la protection d’identité. L’identité est toutefois protégée dans le cas d’une négociation IKE authentifiée à l’aide de signatures à clef publique.

Deux manières d’échanger des clefs sont abondamment utilisées : les clefs pré-partagées, et les certificats X.509 (dans ce dernier cas, deux systèmes d’adresses initialement inconnues pourront protéger leurs échanges). 

La seconde manière de procéder a l’avantage de permettre à des clients d’adresses IP dynamiques et changeant éventuellement de créer des SAs, mais n’est pas obligatoirement supportée par les implémentations conformes à la RFC 2409. 

Enfin, une définition qui peut s’avérer utile lors de la lecture de documentations techniques sur IPsec : la PFS (perfect forward secrecy) est définie par la RFC 2409 comme la notion selon laquelle la compromission d’une clef ne permettra l’accès qu’aux données protégées par cette clef, mais ne sera pas suffisante pour déchiffrer tout l’échange IPsec, seule la partie de la communication protégée par la clef corrompue sera déchiffrable.

5 – La compression des entêtes

La RFC 3095 décrit un protocole de compression d’entêtes pouvant s’appliquer à RTP, UDP, et ESP sur IP. La compression des données elles-mêmes n’est malheureusement pas couverte par cette spécification, il n’est donc pas prévu, à l’heure actuelle, de les compresser. En revanche, il est conçu pour s’accommoder des taux d’erreurs de transmission importants des communications par voie hertzienne. Enfin, la compression décrite s’appuie sur une couche de liens garantissant la transmission des données dans leur ordre d’émission et sans duplication, ce qui peut rendre dangereuse son utilisation sur certains réseaux. Enfin, la couche de liens doit permettre la négociation des paramètres ROHC (robust header compression), cette négociation peut cependant se faire à priori ou en s’appuyant sur d’autres protocoles.

6 – Problèmes divers

L’utilisation simultanée d’IPsec et d’autres protocoles ou de certains équipements réseau pose, dans certains cas, quelques problèmes. En outre, la gestion manuelle de clefs introduit quelques restrictions sur les usages possibles du protocole.

6.1 – Limitations dues à la gestion manuelle des clefs

Les services d’unicité offerts par AH et ESP s’appuient sur des numéros de séquence initialisés à 0 lors de la création d’une SA et incrémentés lors de l’envoi de chaque datagramme. Ces numéros de séquence sont stockés dans un entier de 32 bits, qui ne doit jamais être diminué. Le nombre maximal de datagrammes qu’une SA peut permettre d’échanger est donc de l’ordre de quatre milliards. Passé cette limite, il est nécessaire de créer une nouvelle SA et donc une nouvelle clef. Ceci rend pénible la mise en oeuvre simultanée de la gestion manuelle de clefs et de la protection contre la duplication de datagrammes. Cette dernière étant optionnelle, il est possible de la désactiver, auquel cas le numéro de séquence peut être annulé lorsqu’il a atteint sa valeur maximale.

6.2 – Broadcast et multicast

L’utilisation d’IPsec pour l’envoi et la réception de datagrammes multicast et broadcast pose quelques problèmes dont certains ne sont pas encore résolus. Des problèmes de performances d’une part, et des difficultés qu’une simple augmentation 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 à l’heure actuelle.

6.3 – Firewalls

Le filtrage de datagrammes IPsec est délicat pour deux raisons :

• les RFCs ne précisent pas si, sur un système remplissant simultanément les fonctions de passerelle de sécurité et de Firewall, le décodage de l’IPsec doit avoir lieu avant ou après l’application des règles de firewalling
• il n’est pas possible au code de firewalling de lire certaines données, par exemple des numéros de port, dans des données chiffrées, ou transmises dans un format qu’il ne connaît pas

Il est donc important de lire la documentation de l’implémentation IPsec utilisée sur les systèmes destinés à gérer simultanément IPsec et firewalling. Il est également utile de noter que les systèmes qui appliquent les règles de firewalling avant le décodage IPsec sont néanmoins souvent capables de filtrer les datagrammes décodés en utilisant des outils de tunneling comme ipip et gif, ou en filtrant au niveau de l’interface de sortie des données. Enfin, AH utilise le numéro de protocole 51 et ESP le numéro de protocole 50. Quant à IKE, il utilise le numéro de port UDP 500. Ces informations sont indispensables lors de la configuration d’un firewall qui doit laisser passer ou bloquer les échanges IPsec.

6.4 – NATs

Théoriquement, toute translation d’adresse sur un datagramme IPsec devrait être évitée, 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. Il existe une solution à ce problème, proposée par SSH Communications Security : l’IPsec NAT-Traversal. Il s’agit d’un draft, donc encore incomplet, mais suffisant pour envisager ce que l’avenir réserve. Certains équipement permettent d’ailleurs déjà de traverser des NAT, en utilisant des protocoles plus ou moins normalisés et avec plus ou moins de bonheur. Comme il ne s’agit que d’un draft, il est décrit dans des documents dont le nom et l’adresse changent souvent, mais un moyen simple de le retrouver est d’entrer la chaîne draft-stenberg-ipsec-nat-traversal dans votre moteur de recherche favori. Enfin, ce protocole ne peut être mis en oeuvre que si le protocole IKE est utilisé simultanément.

6.5 – Protocoles autres qu’IP

Un inconvénient d’IPsec est que ce protocole ne prévoit que le convoyage sécurisé de datagrammes IP. Ceci n’est pas suffisant, car d’autres standards comme IPX et NetBIOS sont utilisés sur un grand nombre de réseaux. Il existe cependant une solution à ce problème : encapsuler les données à protéger dans du PPP, lui-même transporté par IPsec. Le rôle de PPP est en effet de permettre la transmission de différents protocoles au-dessus d’un lien existant. Ceci implique de pouvoir encapsuler PPP dans les datagrammes IPsec, cette opération est décrite dans les paragraphes suivants.

6.5.1 – PPTP

La première solution permettant cette encapsulation est le protocole PPTP, décrit par la RFC 2637. PPTP offre ainsi à un client, dit PAC (PPTP access concentrator), la possibilité d’établir un lien PPP avec un serveur dit PNS (PPTP network server), encapsulé dans des datagrammes IP. Si le client a préalablement établi une SA avec une passerelle de sécurité (éventuellement distincte du PNS), qui lui permet de protéger ces datagrammes IP, les données PPP seront donc également sécurisées, de même que les protocoles de niveau supérieur s’appuyant sur le lien PPP. Deux points s’avèrent importants lors de la configuration d’un firewall placé entre un PAC et un PNS :

• PPTP s’appuie sur le protocole d’encaspulation général GRE, auquel l’IANA a attribué le numéro 47
• un lien PPTP est contrôlé par une connexion TCP vers le port 1723 du PNS

Enfin, PPTP seul, c’est-à-dire sans IPsec, peut être et a été utilisé pour crééer des VPNs, assurant des échanges authentifiés, en protégeant les mots de passes utilisés d’un éventuel attaquant, mais sans chiffrer le reste de la communication. Cependant, ce système offre une authentification nettement moins fiable que ce qu’il est possible d’obtenir avec IPsec. En outre, de nombreuses implémentations de ce protocole, notamment celles de Microsoft, ont fait l’objet de découvertes de vulnérabilités et d’incapacité à protéger efficacement les mots de passe des utilisateurs. Aussi l’usage de ce système est-il risqué.

6.5.2 – L2TP

Une deuxième solution d’encapsulation de PPP dans IP est le protocole L2TP, décrit par la RFC 2661. Il permet la transmission de PPP à l’aide des protocoles de niveau 2 comme ethernet. Il offre également un mécanisme d’encapsulation de PPP dans UDP. Ainsi, il est possible de protéger PPP à l’aide d’UDP encapsulé dans IPsec. L2TP offre en outre une architecture plus modulaire que PPTP : on suppose le client capable d’échanger des trames par l’intermédiaire d’un protocole de niveau 2 ou des datagrammes UDP avec un LAC (L2TP access concentrator), qui transmet les données à un LNS (L2TP network server). Si le LAC et le LNS sont situés physiquement sur le même système, celui-ci joue alors exactement le même rôle que le PNS de PPTP.

Un détail important lors du paramétrage d’un firewall : le L2TP encapsulé dans UDP utilise le port 1701.

6.5.3 – PPTP ou L2TP ?

L’utilisation de PPTP ou L2TP ne change pas grand-chose du point de vue de la sécurité, celle-ci étant assurée par la couche inférieure IPsec. La question qui se pose est donc celle de la consommation de bande passante, parce que toutes ces encapsulations commencent à représenter un volume de données non négligeable. Dans le cas d’un client se connectant à un ISP et établissant ensuite le tunnel vers un réseau destination, PPTP devrait permettre d’économiser les entêtes UDP. En revanche, dans le cas d’un client se connectant, par exemple à l’aide d’un modem ou d’une ligne ISDN, directement sur le réseau privé, et disposant donc d’un lien de niveau 2 vers ce réseau, L2TP semble plus économe. Un dernier point à prendre compte est que l’OS tournant sur le serveur imposera parfois des limitations :

• pour Windows 2000 et ultérieures, Microsoft semble privilégier très fortement L2TP
• les versions précédentes de Windows ne supportent pas L2TP
• les Unix-like libres semblent accuser un léger retard en matière de support L2TP

7 – Quelques implémentations actuelles

Cette partie donne un aperçu des capacités de quelques OS populaires en matière de support IPsec. Les informations fournies constituent une synthèse des sites des OS, des éditeurs et des FAQs des logiciels concernés : de plus amples détails sont donc disponibles sur ces sites.

7.1 – Windows

Windows XP et 2000 incluent un support du mode transport d’IPsec et de l’échange de clefs à l’aide de certificats en natif. Il existe de très nombreux logiciels permettant de créer des VPN sous Windows, y compris un serveur VPN en option sous Windows 2000 et XP, capable de mettre en place des tunnels IPsec/L2TP. D’autre part, Windows 95, 98 et NT 4 disposent d’une grande quantité d’implémentations IPsec commerciales et à peu près toutes les versions de Windows depuis 95 sont capables de créer des tunnels PPTP. Une solution intéressante est également proposée par SSH Communications Security. Leur implémentation est à l’heure actuelle l’une des rares à supporter IPsec NAT-Traversal. Le client est disponible pour les versions 95, 98, Me, NT 4, 2000 et XP de Windows.

7.2 – Linux

L’implémentation IPsec la plus utilisée sous Linux est sous licence GPL, il s’agit de FreeS/WAN. La partie kernel de cette implémentation s’appelle KLIPS. Sont notamment supportés :

• l’échange dynamique de clefs IKE à l’aide du logiciel pluto, qui permet l’utilisation de clefs pré-partagées aussi bien que de certificats
• la protection des connexions d’un road warrior à un LAN, même si son adresse IP est attribuée dynamiquement et est susceptible de changer
• la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
• la création de tunnels PPTP (côté client), grâce au logiciel PPTP-linux
• la création de tunnels L2TP, grâce au logiciel l2tpd
• le chiffrement opportuniste, qui permet la protection des données échangées entre deux systèmes totalement étrangers jusqu’alors (les clefs publiques sont alors échangées à l’aide de la DNS)

Les principaux problèmes connus lors de l’écriture de ce document étaient :

• KLIPS présente une très légère fuite de mémoire
• si plusieurs connexions sont établies entre deux passerelles de sécurité, la compression d’entêtes doit être activée pour toutes ou aucune de ces connexions
• KLIPS ne gère pas les datagrammes dans lesquels des options IP sont présentes

Enfin, FreeS/WAN décode les paquets IPsec avant de les transmettre au code de firewalling. Les règles de firewalling peuvent néanmoins tester si les datagrammes ont été envoyés en clair ou non.

7.3 – NetBSD

NetBSD utilise KAME, une implémentation IPsec (et plus généralement IPv6) sous licence BSD. La foire aux questions concernant IPsec pour NetBSD. Sont notamment supportés :

• l’utilisation simultanée d’IPsec en mode tunnel ou transport avec IPv6, au moins pour la version courante de NetBSD
• la configuration socket par socket (à l’aide de l’appel système setsockopt(2))
• la création de tunnels IPsec grâce aux ports pptp et pptp-server
• un nombre quasiment illimité de SA imbriquées
• l’échange dynamique de clefs IKE, en utilisant soit racoon, qui peut fonctionner à l’aide de clefs pré-partagées ou de certificats, soit isakmpd, qui en est encore à son stade alpha, et supporte également ces deux méthodes

Les principaux problèmes connus lors de l’écriture de ce document étaient :

• les clefs associées à une SA mise en place à l’aide de l’appel setsockopt(2) ne peuvent être négociées par racoon
• le protocole AH en mode tunnel ne fonctionne pas correctement

Enfin, lors d’une utilisation conjointe de KAME et IPfilter sous NetBSD, les datagrammes sont traités par le firewall avant d’être décodés par KAME.

7.4 – FreeBSD

FreeBSD s’appuie également KAME. L’utilisation d’IPsec sous FreeBSD est documentée. Sont notamment supportés :

• l’utilisation simultanée d’IPsec en mode tunnel ou transport avec IPv6, au moins pour la version courante de FreeBSD
• la création de tunnels PPTP (côté client)
• la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
• la création de tunnels L2TP, grâce au logiciel (dont le portage sous FreeBSD en est encore au stade alpha) l2tpd
• l’échange dynamique de clefs IKE, en utilisant racoon

7.5 – OpenBSD

A l’instar de FreeBSD et NetBSD, OpenBSD utilise KAME. La documentation relative à l’utilisation d’IPsec sous OpenBSD. Sont notamment supportés :

• l’échange dynamique de clefs ISAKMP grâce au logiciel isakmpd, qui supporte le mode agressif et l’utilisation de certificats comme de clefs pré partagées, et la création de SAs avec des clients d’adresse IP variables et attribuées dynamiquement, photuris peut également être employé, mais il est encore en stade alpha et peu documenté
• la création de tunnels PPTP (côté client), grâce au port pptp
• la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
• l’échange dynamique de clefs selon le standard Photuris, en s’appuyant sur le logiciel photurisd

7.6 – Solutions hardware

Si de nombreuses SA doivent être maintenues, compte tenu de la forte charge CPU liée au chiffrement, il sera peut-être nécessaire d’avoir recours à l’une des multiples solutions hard disponibles dans le commerce (Redcreek, Timestep).

8 – Les écueils

Nous conclurons cet article sur une mise en garde : il est fondamental, lors de la mise en place de VPNs à l’aide d’IPsec de parfaitement comprendre à quoi la protection va s’appliquer. Il est en effet très facile de commettre des erreurs aux conséquences extrêmement graves. Par exemple, placer une passerelle de sécurité derrière un Firewall et configurer ce dernier pour laisser passer tout trafic IPsec implique un paramétrage soigneux de la passerelle de sécurité, pour éviter qu’un attaquant l’utilise pour contourner le firewall. Notamment, si cette passerelle met en oeuvre le chiffrement opportuniste de l’implémentation FreeS/WAN, le firewall peut ne plus être d’aucune utilité. Il est de manière générale recommandé d’appliquer des règles de firewalling après au même titre qu’avant les traitements IPsec (pour fixer les idées, une manière simple bien qu’exorbitante d’appliquer ce conseil est de placer un premier firewall avant la passerelle de sécurité et un second après cette passerelle). 

En outre, le chiffrement des données ne doit pas créer l’illusion de la sécurité, comme SSL l’a trop souvent fait : chiffrer n’est pas authentifier (un attaquant peut très bien engager une conversation chiffrée avec une passerelle de sécurité), et authentifier le système émetteur d’un datagramme à l’aide du protocole AH ne suffit pas nécessairement à assurer la sécurité : si un administrateur utilise un protocole permettant une authentification en clair comme telnet, en encapsulant les données dans des datagrammes protégés par AH, un attaquant pourra lire son mot de passe, et s’il est ensuite possible d’établir des connexions non authentifiées à l’aide d’IPsec vers le système, ce dernier peut alors être considéré comme compromis. 

Ces deux exemples illustrent la complexité de la mise en place d’IPsec. Cette complexité ne saurait que difficilement s’accommoder de solutions soi-disant magiques et clefs en mains, paramétrées en quelques clics de souris. IPsec est excessivement complexe, et masquer cette complexité derrière des interfaces graphiques n’appelant pas les choses par leurs noms est aussi dangereux qu’irresponsable (serait-il grand temps de mettre un terme à l’anarchie dans le vocabulaire ?-D).

9 – Les vidéos

• 9.1 - Création et configuration d'un tunnel IPSec

  Cette vidéo vous présente comment créer et configurer un tunnel IPSec.

  

• 9.2 - What is IPSec?

  Cette vidéo en Anglais présente de manière complète qu'est-ce que IPSec. This video describes the workings of the IKE and IPSec Phases that occur during the establishment of a VPN tunnel.

  

• 9.3 - Understanding Cisco SSL VPN vs IPSec VPN

  Cette vidéo en Anglais présente un bon comparatif entre les VPNs IPSec et SSL. This video is from the Cisco SIMOS class at Stormwind Live, in this section we explore the differences between the newer SSL VPN and legacy IPsec VPN.

  

• 9.4 - Understanding AH vs ESP and ISKAKMP vs IPSec

  Cette vidéo en Anglais explique comment fonctionne les tunnels VPN en comparant AH,ESP, ISAKMP et IPSec. This is a sniplet from the Cisco SIMOS course, where we discuss the logical constructs behind a site-to-site IPSec VPN. I hope that this content helps you understand what's happening behind the scenes of your VPN's.

  

• 9.5 - IPSec vs SSL security protocols comparison

  Cette vidéo en Anglais présente un comparatif pragmatique en les protocoles IPSec et SSL.

  

• 9.6 - IPSec overview

  Cette vidéo en Anglais présente basiquement et de manière ludique, le protocole IPSec (Internet Protocol Security).

  

10 – Suivi du document

Création et suivi de la documentation par Brieuc Jeunhomme et _SebF

11 – Discussion autour du protocole IPSec

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos du protocole IPSec. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :