Logo English Web Page
Accueil Association BSD Linux Dev Reseau Infologisme Mac OSX
tl tr
Sujet Sécurité Date 24-03-2011
Titre Le protocole IPSec - Internet Protocol Security Section Dev Reseau
Article

Avant-propos

Définition

Interopérabilité syntaxique

Si deux ou plus systèmes sont capables de communication avec un échange de données, ils exposent une interopérabilité syntactique. Les formats spécifiés de données, protocoles de communication et autres sont fondamentales. La normes XML ou SQL sont parmi les outils d‘interopérabilité syntaxique. Cela est également vrai pour les formats de données de niveau inférieur, tels que la garantie des caractères alphabétiques qui sont stockés au format ASCII dans tous les systèmes de communication et autres.

Une interopérabilité syntaxique est une condition nécessaire pour une plus grande interopérabilité.

Interopérabilité sémantique

Au-delà de la capacité pour échanger de l‘informations pour deux ou plusieurs systèmes informatiques, l‘interopérabilité sémantique est la capacité à interpréter automatiquement les informations échangées de façon significative et précisément afin de produire des résultats conformes et utiles tels que définis par les utilisateurs finaux de ces systèmes. Pour atteindre une interopérabilité sémantique, les systèmes informatiques doivent se référer à un modèle commun de référence d‘échange d‘informations. Le contenu de l‘information et la demande d‘échange sont déterminées sans ambivalence ou amphibologie possible par des critères drastiques : Ce qui est envoyé doit être conforme à ce qui est compris.


Remerciement pour Brieuc Jeunhomme, auteur de ce document en 2002 sur le protocole IPSec.Mise à jour Mars 2011


Sommaire

1 – Introduction
2 – Les services procurés par IPSec
2.1 – Les deux modes d‘échange IPSec
2.2 – La base du protocole IPSec
2.2.1 – AH Authentication Header
2.2.2 – ESP Encapsulating Security Payload
2.2.3 – Implantation d‘IPSec dans le datagramme IP
3 – Architectures de sécurité
3.1 – Associations de sécurité
3.2 – Architectures supportées
3.2.1 – Dialogue entre deux hôtes protégeant le trafic eux-mêmes
3.2.2 – Dialogue entre deux LANs à l‘aide de passerelles de sécurité
3.2.3 – Dialogue entre deux hôtes traversant deux passerelles de sécurité
3.2.4 – Dialogue entre un hôte et une passerelle de sécurité
4 – Gestion des clefs
5 – La compression des en-têtes
6 – Problèmes divers
6.1 – Limitations dues à la gestion manuelle des clefs
6.2 – Broadcast et multicast
6.3 – Firewalls
6.4 – NATs
6.5 – Protocoles autres que IP
6.5.1 – PPTP Point-to-Point Tunneling Protocol
6.5.2 – L2TP Layer Two Tunneling Protocol
6.5.3 – PPTP ou L2TP
7 – Quelques implémentations actuelles
7.1 – FreeBSD
7.2 – NetBSD
7.3 – OpenBSD
7.4 – Linux
7.5 – Windows
7.6 – Solutions hardware
8 – Les écueils
9 – Discussion autour de la documentation
Index – RFC concernant le sujet

1Introduction

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érents RFCs, et donc interopérable. Quelques avantages supplémentaires sont l‘économie de bande passante, d‘une part parce que la compression des en-tê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.

2Les services procurés 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 en l‘imbriquant dans une autre communication avec 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.2La base du protocole 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 le RFC 4302. 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 en-tê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 en-têtes, du datagramme IP encapsulé dans le datagramme protégé par AH), version (4 en IPV4, 6 en IPV6), longueur de l‘en-tête (en IPV4), longueur totale du datagramme (en IPV4), longueur des données (en IPV6), identification, protocole ou en-tê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‘en-tê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 précis de signature en particulier, ceux-ci sont décrits séparément, cependant une implémentation conforme au RFC 4302 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 le RFC 4303. Contrairement à AH, ESP ne protège pas les en-tê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é des en-têtes et options incluses du datagramme encapsulé. Ce mode possède deux avantages supplémentaires :

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, comprend l‘ensemble des champs en incluant les en-têtes du datagramme IP encapsulé dans le datagramme protégé par ESP.

Enfin, ESP ne spécifie pas un algorithme de signature ou de chiffrement en particulier, ceux-ci sont décrits séparément, cependant, une implémentation conforme au RFC 4303 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 pas 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 un AH et deux encapsulations de ESP.
Header IP classique
Protocole = 51
Header AH Données AH en mode transport
Header IP classique
Destination IP = Fin du tunnel
Protocole = 50
Header EPS Header IP
d‘origine
Données Trailer EPS
et données d‘authentification
EPS en mode tunnel

3Architectures de sécurité

3.1 – Associations de sécurité

Le RFC 4301 (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
Le nom du système
(DNS complète, nom X.500 distingué ou général)
Le protocole de transport utilisé (typiquement, TCP ou UDP)
Le ports source et destination (UDP et TCP seulement, le support de ce paramètre est facultatif)
Importance des données (ce paramètre n‘est pas toutefois obligatoire sur certains types d‘implémentations)
Un nom d‘utilisateur complet, comme par exemple foo@bar.net (ce paramètre n‘est pas toutefois obligatoire sur certains types d‘implémentations)

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 au RFC 4301 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 :

Le mode transport :

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


Le 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. Cela 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é

Avec le dernier cas, le principe 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. Le RFC 4301 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 le RFC 5996. 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 pour avantage de permettre à des clients DHCP ayant des adresses IP dynamiques et changeantes de créer éventuellement des SAs, mais ce n‘est pas obligatoirement supportée par les implémentations conformes au RFC 5996.

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 le RFC 5996 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 en-têtes

Le RFC 4815 décrit un protocole de compression d‘en-tê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 concilier des taux importants d‘erreurs de transmission par voie hertzienne des communications. 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 son utilisation dangereuse 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 du protocole 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 fastidieux la mise en œuvre simultanée de la gestion manuelle de clefs et 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 du protocole 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 les numéros de port, dans les données chiffrées ou celles transmises dans un format qu‘il ne connaît pas.

Il est donc important de lire la documentation de l‘implémentation du protocole IPSec utilisée sur les systèmes destinés à gérer simultanément IPSec et le 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 : 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 œuvre que si le protocole IKE est utilisé simultanément.

6.5 – Protocoles autres que IP

Un inconvénient du protocole 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 Point-to-Point Tunneling Protocol

La première solution permettant cette encapsulation est le protocole PPTP, décrit par le 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 relativement risqué.

6.5.2 – L2TP Layer Two Tunneling Protocol

La deuxième solution est une encapsulation de PPP dans IP qui est le protocole L2TP, décrit par le 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 de 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 représentent 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 en-tê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.

Certains Unix-like libres semblent parfois accuser un léger retard en matière de support L2TP.

7 – Quelques implémentations actuelles

Cette partie donne un aperçu sur les capacités de quelques Systèmes d‘exploitation les plus populaires qui supportent le protocole IPSec. Les informations fournies constituent une synthèse des sites sur ces différents OS, des éditeurs et des FAQs logiciels concernés, plus amples détails sont disponibles sur ces sites Web.

7.1 – FreeBSD

La mise en œuvre du protocole IPSec sous FreeBSD est basé sur KAME qui supporte les protocoles IPV4 et IPV6. FreeBSD est documenté sur le sujet et il est notamment supporté :

– Utilisation simultanée de IPSec en mode tunnel ou transport avec IPV6 pour la version Release de FreeBSD

– Création de tunnels PPTP (côté client) pptpclient

– Création de tunnels PPTP grâce au logiciel poptop (côté serveur)

– Création de tunnels L2TP avec le logiciel l2tpd

– Un échange dynamique de clefs IKE en utilisant soit ipsec-tools et racoon2

Documentation


Remarque : OpenVPN n‘est pas compatible avec IPsec ou d‘autres logiciels VPN. FreeBSD OpenVPN

7.2 – NetBSD

NetBSD utilise KAME, une implémentation IPSec (et plus généralement IPV6) sous licence BSD. NetBSD est documenté sur le sujet et il est notamment supporté :

L‘utilisation simultanée d‘IPSec en mode tunnel ou transport avec IPV6, au moins pour la version courante de NetBSD.

– Configuration socket par socket à l‘aide de l‘appel système setsockopt(2)

– Création de tunnels IPSec grâce au port ipsec(4)

– Un nombre quasiment illimité de SA imbriquées

– Échange dynamique de clefs IKE, en utilisant racoon(8) et setkey(8), qui peut fonctionner à l‘aide de clefs pré-partagées ou de certificats.

Les clefs associées à une SA sont mises en place à l‘aide de l‘appel setsockopt(2) ne peuvent être négociées par racoon(8).

Pour le protocole AH en mode tunnel voir la documentation.

Enfin, lors d‘une utilisation conjointe de KAME et IPfilter sous NetBSD, les datagrammes sont traités par le firewall examine les paquets avant le traitement IPsec à l‘arrivée, et après le traitement IPsec au départ.

Documentation


Remarque : OpenVPN n‘est pas compatible avec IPsec ou d‘autres logiciels VPN. NetBSD OpenVPN

7.3 – OpenBSD

A l‘instar de FreeBSD et NetBSD, OpenBSD utilise KAME. L‘utilisation d‘IPSec sous OpenBSD est relativement documentée sur le sujet et il est notamment supporté :

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

– Protocole IPSec ESP Encapsulating Security Payload et AH Authentication Header ipsec(4)

– Échange dynamique de clefs selon le standard IKE, en s‘appuyant sur le logiciel iked

– Un client PPTP est disponible avec l‘interface de pppd(8) capable de se connecter et qui est basé sur PPTP Virtual Private Networks (VPN).

Le démon sasyncd(8) synchronise IPsec SA et l‘information SPD du basculement entre certains adressages de la passerelle IPSec. Un scénario typique sur les hôtes partageant la même adresse IP avec carp(4).

Documentation


Remarque : OpenVPN n‘est pas compatible avec IPsec ou d‘autres logiciels VPN. OpenBSD OpenVPN

7.4 – Linux

L‘implémentation IPSec la plus utilisée sous Linux est sous licence GPL. La partie kernel de cette implémentation KLIPS (KerneL IP Security) sous RedHat et Fedora Core RPMs Linux avec FreeS/WAN qui 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.

La protection des connexions d‘un road warrior sur un LAN, même si son adresse IP est attribuée dynamiquement et susceptible de changer.


Avec Arch Linux :

L‘échange dynamique de clefs IKE à l‘aide du logiciel IPsec-Tools, qui permet l‘utilisation de clefs pré-partagées aussi bien que de certificats.

– Création de tunnels PPTP (côté serveur), grâce au logiciel pptpd

– Création de tunnels PPTP (côté client), grâce au logiciel pptpclient

– Création de tunnels L2TP, grâce au logiciel xl2tpd

Documentation


Remarque : OpenVPN n‘est pas compatible avec IPsec ou d‘autres logiciels VPN. Arch Linux OpenVPN

7.5 – Windows

Windows Seven 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 Seven, capable de mettre en place des tunnels L2TP/IPSec VPN.

Un point potentiel de confusion dans L2TP/IPsec est l‘utilisation des termes tunnel et canal sécurisé. Le terme tunnel se réfère à un canal qui permet le transport de paquets intacts d‘un réseau d‘être transportés sur un autre réseau. Dans le cas de L2TP/PPP, cela permet seulement aux paquets L2TP/PPP d‘être transporté sur IP. Un canal sécurisée se réfère à une connexion dans lequel on garantit la confidentialité de toutes les données. Avec L2TP/IPsec, en premier lieu IPsec fournit un canal sécurisé et ensuite L2TP fournit un tunnel.

Documentation


Remarque : OpenVPN n‘est pas compatible avec IPsec ou d‘autres logiciels VPN. Windows Seven OpenVPN

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, ZyXEL).

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 œuvre le chiffrement opportuniste de l‘implémentation FreeS/WAN, le firewall peut dès lors 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, il est grand temps de mettre un terme à l‘anarchie dans le vocabulaire.

9 – Discussion autour de la documentation

Vous pouvez poser toutes vos questions, exprimez vos remarques et faire part de vos expériences à propos du protocole IPSec. Pour cela, rendez-vous sur le Forum de Frameip.com : Les réseaux privées virtuels

Index – RFC concernant le sujet

Numéro Titre Date Actualisation Status
RFC2401 Security Architecture for the Internet Protocol 11-1998 Obsolete – Update by RFC4301 Standard proposé
RFC4301 Security Architecture for the Internet Protocol 12-2005 Update by RFC3168 Standard proposé
RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP 09-2001 Update by RFC4301 RFC6040 Standard proposé
RFC2402 IP Authentication Header 11-1998 Obsolete – Update by RFC4302 Standard proposé
RFC4302 IP Authentication Header 12-2005 Errata Standard proposé
RFC2406 IP Encapsulating Security Payload (ESP) 11-1998 Obsolete – Update by RFC4303 Standard proposé
RFC4303 IP Encapsulating Security Payload (ESP) 12-2005 Errata Standard proposé
RFC2637 Point-to-Point Tunneling Protocol (PPTP) 07-1999 Informationnel
RFC2661 Layer Two Tunneling Protocol "L2TP" 08-1999 Errata Standard proposé
RFC4815 RObust Header Compression (ROHC):
Corrections and Clarifications to RFC 3095
02-2007 Standard proposé
RFC4835 Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
04-2007 Standard proposé
RFC4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels 05-2007 Informationnel
RFC5225 RObust Header Compression Version 2 (ROHCv2):
Profiles for RTP, UDP, IP, ESP and UDP-Lite
04-2008 Errata Standard proposé
RFC5856 Integration of Robust Header Compression over IPsec Security Associations 05-2010 Informationnel
RFC5857 IKEv2 Extensions to Support Robust Header Compression over IPsec 05-2010 Errata Standard proposé
RFC5858 IPsec Extensions to Support Robust Header Compression over IPsec 05-2010 Errata Standard proposé
RFC5996 Internet Key Exchange Protocol Version 2 (IKEv2) 09-2010 Update by RFC5998 Standard proposé
RFC5998 An Extension for EAP-Only Authentication in IKEv2 09-2010 Standard proposé
RFC6040 Tunnelling of Explicit Congestion Notification 11-2010 Standard proposé
RFC6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap 02-2011 Informationnel
* Liste de documents non exhaustive
Epilogue
Le Protocole IPSec est un assemblage de plusieurs protocoles et dispositifs de sécurité, ce qui le rend techniquement très complexe. Le problème est qu‘il n‘existe aucune norme pour ce qui constitue un VPN. Il peut être mis en œuvre en utilisant un certain nombre de technologies différentes, qui ont chacune leurs forces et leurs faiblesses. Parmi les documents en Français du Web, trouvant celui-ci de qualité, ce document permet par la description du mécanisme du protocole IPSec d‘étayer l‘article suivant :

VPN Réseau Privé Virtuel - Tunneling

Mise en forme du document, ajout, relecture et correction – Eric Douzet


Article connexe du sujet

Datagramme IP
Présentation de Système BSD - FreeBSD
Principe fondamental de sécurité Réseau
VPN Réseau Privé Virtuel - Tunneling

Auteur
Brieuc Jeunhomme - www.frameip.com
Début de page
bl br
C-extra.com v. 1.2.2 © 2000-2014, tous droits réservés  –  Mise à jour le 12 Avril 2014 Infologisme.com