LE PROTOCOLE IPSEC

Cet article prsente le fonctionnement du protocole IPsec, qui permet de crer des
rseaux privs virtuels de manire conforme aux spcifications de lIETF. Les services
offerts par IPsec et leurs limitations y sont dtaills, de mme que les problmes
dinteroprabilit, tant avec dautres protocoles quentre applications diffrentes. Enfin,
quelques implmentations sont prsentes, et un rapide aperu de leur conformit aux
standards est donn.

1 Introduction au protocole IPSec

Le protocole IPsec est lune des mthodes permettant de crer des VPN (rseaux privs
virtuels), cest--dire de relier entre eux des systmes informatiques de manire sre en
sappuyant sur un rseau existant, lui-mme considr comme non scuris. Le terme sr
a ici une signification assez vague, mais peut en particulier couvrir les notions dintgrit et
de confidentialit. Lintrt majeur de cette solution par rapport dautres techniques (par
exemple les tunnels SSH) est quil sagit dune mthode standard (facultative en IPv4,
mais obligatoire en IPv6), mise au point dans ce but prcis, dcrite par diffrentes RFCs,
et donc interoprable. Quelques avantages supplmentaires sont lconomie de bande
passante, dune part parce que la compression des enttes des donnes transmises est
prvue par ce standard, et dautre part parce que celui-ci ne fait pas appel de trop
lourdes techniques dencapsulation, comme par exemple les tunnels PPP sur lien SSH. Il
permet galement de protger des protocoles de bas niveau comme ICMP et IGMP, RIP,
etc
IPsec prsente en outre lintrt dtre une solution volutive, puisque les algorithmes de
chiffrement et dauthentification proprement parler sont spcifis sparment du
protocole lui-mme. Elle a cependant linconvnient inhrent sa flexibilit : sa grande
complexit rend son implmentation dlicate. Les diffrents services offerts par le
protocole IPsec sont ici dtaills. Les manires de les combiner entre eux que les
implmentations sont tenues de supporter sont ensuite prsentes. Les moyens de
gestion des clefs de chiffrement et signature sont tudis et les problmes
dinteroprabilit associs sont voqus. Enfin, un aperu rapide de quelques
implmentations IPsec, en sintressant essentiellement leur conformit aux
spcifications est donn.

2 Les services offerts par IPsec

2.1 Les deux modes dchange IPsec
Une communication entre deux htes, protge par IPsec, est susceptible de fonctionner
suivant deux modes diffrents : le mode transport et le mode tunnel. Le premier offre
essentiellement une protection aux protocoles de niveau suprieur, le second permet
quant lui dencapsuler des datagrammes IP dans dautres datagrammes IP, dont le
contenu est protg. Lintrt majeur de ce second mode est quil rend la mise en place de
passerelles de scurit qui traitent toute la partie IPsec dune communication et
transmettent les datagrammes purs de leur partie IPsec leur destinataire rel

https://astuces-top.blogspot.com
ralisable. Il est galement possible dencapsuler une communication IPsec en mode
tunnel ou transport dans une autre communication IPsec en mode tunnel, elle-mme
traite par une passerelle de scurit, qui transmet les datagrammes aprs suppression
de leur premire enveloppe un hte traitant son tour les protections restantes ou une
seconde passerelle de scurit.

2.2 Les protocoles la base dIPsec

2.2.1 AH (authentication header)

AH est le premier et le plus simple des protocoles de protection des donnes qui font
partie de la spcification IPsec. Il est dtaill dans la RFC 2402. Il a pour vocation de
garantir :
Lauthentification : les datagrammes IP reus ont effectivement t mis par lhte
dont ladresse IP est indique comme adresse source dans les enttes.
Lunicit (optionnelle, la discrtion du rcepteur) : un datagramme ayant t mis
lgitimement et enregistr par un attaquant ne peut tre rutilis par ce dernier, les
attaques par rejeu sont ainsi vites.
Lintgrit : les champs suivants du datagramme IP nont pas t modifis depuis
leur mission : les donnes (en mode tunnel, ceci comprend la totalit des champs,
y compris les enttes, du datagramme IP encapsul dans le datagramme protg
par AH), version (4 en IPv4, 6 en IPv6), longueur de lentte (en IPv4), longueur
totale du datagramme (en IPv4), longueur des donnes (en IPv6), identification,
protocole ou entte suivant (ce champ vaut 51 pour indiquer quil sagit du protocole
AH), adresse IP de lmetteur, adresse IP du destinataire (sans source routing).
En outre, au cas o du source routing serait prsent, le champ adresse IP du destinataire
a la valeur que lmetteur a prvu quil aurait lors de sa rception par le destinataire.
Cependant, la valeur que prendront les champs type de service (IPv4), indicateurs (IPv4),
index de fragment (IPv4), TTL (IPv4), somme de contrle dentte (IPv4), classe (IPv6),
flow label (IPv6), et hop limit (IPv6) lors de leur rception ntant pas prdictible au
moment de lmission, leur intgrit nest pas garantie par AH.
Lintgrit de celles des options IP qui ne sont pas modifiables pendant le transport est
assure, celle des autres options ne lest pas.
Attention, AH nassure pas la confidentialit : les donnes sont signes mais pas
chiffres.
Enfin, AH ne spcifie pas dalgorithme de signature particulier, ceux-ci sont dcrits
sparment, cependant, une implmentation 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 donnes qui fait partie de la spcification
IPsec. Il est dtaill dans la RFC 2406. Contrairement AH, ESP ne protge pas les
enttes des datagrammes IP utiliss pour transmettre la communication. Seules les
donnes sont protges. En mode transport, il assure :
La confidentialit des donnes (optionnelle) : la partie donnes des datagrammes
IP transmis est chiffre.

https://astuces-top.blogspot.com
 Lauthentification (optionnelle, mais obligatoire en labsence de confidentialit) : la
partie donnes des datagrammes IP reus ne peut avoir t mise que par lhte
avec lequel a lieu lchange IPsec, qui ne peut sauthentifier avec succs que sil
connat la clef associe la communication ESP. Il est galement important de
savoir que labsence dauthentification nuit la confidentialit, en la rendant plus
vulnrable certaines attaques actives.
Lunicit (optionnelle, la discrtion du rcepteur).
Lintegrit : les donnes nont pas t modifies depuis leur mission.
En mode tunnel, ces garanties sappliquent aux donnes du datagramme dans lequel est
encapsul le trafic utile, donc la totalit (enttes et options inclus) du datagramme
encapsul. Dans ce mode, deux avantages supplmentaires apparaissent:
Une confidentialit, limite, des flux de donnes (en mode tunnel uniquement,
lorsque la confidentialit est assure) : un attaquant capable dobserver les
donnes transitant par un lien nest pas mme de dterminer quel volume de
donnes est transfr entre deux htes particuliers. Par exemple, si la
communication entre deux sous-rseaux est chiffre laide dun tunnel ESP, le
volume total de donnes changes entre ces deux sous-rseaux est calculable
par cet attaquant, mais pas la rpartition de ce volume entre les diffrents systmes
de ces sous-rseaux.
La confidentialit des donnes, si elle est demande, stend lensemble des
champs, y compris les enttes, du datagramme IP encapsul dans le datagramme
protg par ESP).
Enfin, ESP ne spcifie pas dalgorithme de signature ou de chiffrement particulier, ceux-ci
sont dcrits sparment, cependant, une implmentation conforme la RFC 2406 est
tenue de supporter lalgorithme de chiffrement DES en mode CBC, et les signatures
laide des fonctions de hachage MD5 et SHA-1.

2.2.3 Implantation dIPSec dans le datagramme IP

La figure 1 montre comment les donnes ncessaires au bon fonctionnement des formats
AH et ESP sont places dans le datagramme IPv4. Il sagit bien dun ajout dans le
datagramme IP, et non de nouveaux datagrammes, ce qui permet un nombre
thoriquement illimit ou presque dencapsulations IPsec : un datagramme donn peut par
exemple tre protg laide de trois applications successives de AH et de deux
encapsulations de ESP.

https://astuces-top.blogspot.com
3 Architectures de scurit
3.1 Associations de scurit
La RFC 2401 (Security Architecture for the Internet Protocol) dcrit le protocole IPsec au
niveau le plus lev. En particulier, elle indique ce quune implmentation est cense
permettre de configurer en termes de politique de scurit (cest--dire quels changes IP
doivent tre protgs par IPsec et, le cas chant, quel(s) protocole(s) utiliser). Sur
chaque systme capable dutiliser IPsec doit tre prsente une SPD (security policy
database), dont la forme prcise est laisse au choix de limplmentation, et qui permet de
prciser la politique de scurit appliquer au systme. Chaque entre de cette base de
donnes est identifie par un SPI (security parameters index) unique (32 bits) choisi
arbitrairement.
Une communication protge laide dIPsec est appele une SA (security association).
Une SA repose sur une unique application de AH ou sur une unique application de ESP.
Ceci nexclut pas lusage simultan de AH et ESP entre deux systmes, ou par exemple
lencapsulation des datagrammes AH dans dautres datagrammes AH, mais plusieurs SA
devront alors tre actives entre les deux systmes. En outre, une SA est
unidirectionnelle. La protection dune communication ayant lieu dans les deux sens
ncessitera donc lactivation de deux SA. Chaque SA est identifie de manire 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 regroupes dans une SAD
(security association database).
La SPD est consulte 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, laccepter sans traitement IPsec, ou appliquer IPsec. Dans le
troisime cas, la SPD prcise 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 rcapituls dans le tableau suivant :
SPD base de donnes dfinissant la politique de scurit
SA une entre de la SPD
SAD liste des SA en cours dutilisation
Les rgles de la SPD doivent pouvoir, si ladminsitrateur du systme le souhaite, dpendre
des paramtres suivants :
adresse ou groupe dadresses IP de destination
adresse ou groupe dadresses IP source
nom du systme (DNS complte, nom X.500 distingu ou gnral)
protocole de transport utilis (typiquement, TCP ou UDP)
nom dutilisateur complet, comme foo@bar.net (ce paramtre nest toutefois pas
obligatoire sur certains types dimplmentations)
importance des donnes (ce paramtre nest toutefois pas obligatoire sur certains
types dimplmentations)
ports source et destination (UDP et TCP seulement, le support de ce paramtre est

https://astuces-top.blogspot.com
 facultatif)
Certains paramtres peuvent tre illisibles cause dun ventuel chiffrement ESP au
moment o ils sont traits, auquel cas la valeur de la SPD les concernant peut le prciser,
il sagit de :
lidentit de lutilisateur
le protocole de transport
les ports source et destination
Il est donc possible de spcifier une politique de scurit relativement fine et dtaille.
Cependant, une politique commune pour le trafic vers un ensemble de systmes permet
une meilleure protection contre lanalyse de trafic quune politique extrmement dtaille,
comprenant de nombreux paramtres propres chaque systme particulier. Enfin, si
limplmentation permet aux applications de prciser elles-mmes quelle partie du trafic
appliquer IPsec et comment, ladministrateur doit pouvoir les empcher de contourner la
politique par dfaut.

3.2 Architectures supportes

Le protocole IPsec permet thoriquement nimporte quelle combinaison, en un nombre
quasiment illimit de niveaux dencapsulation, cest--dire daccumulations de SA.
Nanmoins, les implmentations ne sont pas tenues doffrir une telle flexibilit. Les
architectures quune application conforme la RFC 2401 doivent supporter, au nombre de
quatre, sont dcrites ci-dessous.

3.2.1 Dialogue entre deux htes protgeant le trafic eux-mmes

Deux htes 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 encapsuls dans des datagrammes AH
en mode tunnel :
des datagrammes AH
ou des datagrammes ESP

3.2.2 Dialogue entre deux LANs laide de passerelles de scurit

Ici, deux passerelles de scurit grent les conversations entre les htes de deux LANs
diffrents, IPsec sappliquant de manire transparente pour les htes. Les deux
passerelles de scurit changent des datagrammes en mode tunnel, laide de AH ou
ESP (aprs routage, ceci correspond simplement la deuxime partie du cas prcdent),
puis transmettent les datagrammes obtenus aprs traitement IPsec aux htes
destinataires. Ainsi, les datagrammes IP mis par un systme de lun des deux LANs sont
encapsuls dans dautres datagrammes IP+IPsec par la passerelle du LAN metteur ,
encapsulation supprime par la passerelle du LAN rcepteur pour obtenir de nouveau

https://astuces-top.blogspot.com
les datagrammes IP originaux.

3.2.3 Dialogue entre deux htes traversant deux passerelles de scurit

Le troisime cas najoute pas vraiment de prrequis sur les implmentations IPsec. Ainsi,
une passerelle de scurit doit avoir la capacit de transmettre dans un tunnel IPsec du
trafic dj scuris par IPsec. Cel autorise les dialogues IPsec entre deux htes situs
eux-mmes dans des LANs relis par des passerelles de scurit.

3.2.4 Dialogue entre un hte et une passerelle de scurit

Le dernier cas est celui dun hte externe se connectant un LAN protg par une
passerelle de scurit. Les documentations techniques dsignent souvent un tel hte sous
le nom de road warrior. Il engage une conversation IPsec avec un systme du LAN en
mode transport, le tout encapsul dans un tunnel IPsec tabli entre le road warrior lui-
mme et la passerelle de scurit. Dans ce cas, les datagrammes du tunnel sont de type
AH ou ESP et les datagrammes utiliss 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 sappuient sur des algorithmes
cryptographiques, et reposent donc sur des clefs. Si celles-ci sont grables manuellement
dans le cas o peu dhtes seront amens engager des conversations IPsec, ceci
devient un vritable cauchemar quand le systme commence prendre un peu
dextension (le nombre de couples de clefs augmentant de manire quadratique avec le
nombre de systmes). Cest pourquoi la spcification IPsec propose galement des
procds dchange automatique de clefs, dont les aspects les plus importants sont ici
voqus. Une prsentation complte de cette procdure dpasse toutefois le cadre de cet
article. La RFC 2401 prcise quune implmentation IPsec est tenue de supporter la
gestion manuelle de clefs et la mthode dchange automatique de clefs IKE, bien que
dautres algorithmes existent. Un point important est que la gestion de clefs automatique
est considre comme plus sre que la gestion manuelle.
Le protocole IKE (internet key exchange) est dcrit par la RFC 2409. Il permet lchange
de clefs entre deux htes dadresses IP connues pralablement ou inconnues selon le
mode dchange de clefs slectionn. Parmi ses avantages figure le mode agressif (cette
caractristique nest pas obligatoire), qui permet dacclrer la ngociation, au prix de la
protection didentit. Lidentit est toutefois protge dans le cas dune ngociation IKE
authentifie laide de signatures clef publique.
Deux manires dchanger des clefs sont abondamment utilises : les clefs pr-partages,
et les certificats X.509 (dans ce dernier cas, deux systmes dadresses initialement
inconnues pourront protger leurs changes).
La seconde manire de procder a lavantage de permettre des clients dadresses IP
dynamiques et changeant ventuellement de crer des SAs, mais nest pas
obligatoirement supporte par les implmentations conformes la RFC 2409.
Enfin, une dfinition qui peut savrer utile lors de la lecture de documentations techniques
sur IPsec : la PFS (perfect forward secrecy) est dfinie par la RFC 2409 comme la notion
selon laquelle la compromission dune clef ne permettra laccs quaux donnes protges
par cette clef, mais ne sera pas suffisante pour dchiffrer tout lchange IPsec, seule la

https://astuces-top.blogspot.com
partie de la communication protge par la clef corrompue sera dchiffrable.

5 La compression des enttes

La RFC 3095 dcrit un protocole de compression denttes pouvant sappliquer RTP,
UDP, et ESP sur IP. La compression des donnes elles-mmes nest malheureusement
pas couverte par cette spcification, il nest donc pas prvu, lheure actuelle, de les
compresser. En revanche, il est conu pour saccommoder des taux derreurs de
transmission importants des communications par voie hertzienne. Enfin, la compression
dcrite sappuie sur une couche de liens garantissant la transmission des donnes dans
leur ordre dmission et sans duplication, ce qui peut rendre dangereuse son utilisation sur
certains rseaux. Enfin, la couche de liens doit permettre la ngociation des paramtres
ROHC (robust header compression), cette ngociation peut cependant se faire priori ou
en sappuyant sur dautres protocoles.

6 Problmes divers
Lutilisation simultane dIPsec et dautres protocoles ou de certains quipements rseau
pose, dans certains cas, quelques problmes. 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 dunicit offerts par AH et ESP sappuient sur des numros de squence
initialiss 0 lors de la cration dune SA et incrments lors de lenvoi de chaque
datagramme. Ces numros de squence sont stocks dans un entier de 32 bits, qui ne
doit jamais tre diminu. Le nombre maximal de datagrammes quune SA peut permettre
dchanger est donc de lordre de quatre milliards. Pass cette limite, il est ncessaire de
crer une nouvelle SA et donc une nouvelle clef. Ceci rend pnible la mise en oeuvre
simultane de la gestion manuelle de clefs et de la protection contre la duplication de
datagrammes. Cette dernire tant optionnelle, il est possible de la dsactiver, auquel cas
le numro de squence peut tre annul lorsquil a atteint sa valeur maximale.

6.2 Broadcast et multicast

Lutilisation dIPsec pour lenvoi et la rception de datagrammes multicast et broadcast
pose quelques problmes dont certains ne sont pas encore rsolus. Des problmes de
performances dune part, et des difficults quune simple augmentation de la puissance de
calcul ne saurait rsoudre, comme la vrification des numros de squence. Le service de
protection contre la duplication des donnes nest donc pas utilisable en environnement
multicast et broadcast lheure actuelle.

6.3 Firewalls
Le filtrage de datagrammes IPsec est dlicat pour deux raisons :
les RFCs ne prcisent pas si, sur un systme remplissant simultanment les
fonctions de passerelle de scurit et de Firewall, le dcodage de lIPsec doit avoir
lieu avant ou aprs lapplication des rgles de firewalling
il nest pas possible au code de firewalling de lire certaines donnes, par exemple

https://astuces-top.blogspot.com
 des numros de port, dans des donnes chiffres, ou transmises dans un format
quil ne connat pas
Il est donc important de lire la documentation de limplmentation IPsec utilise sur les
systmes destins grer simultanment IPsec et firewalling. Il est galement utile de
noter que les systmes qui appliquent les rgles de firewalling avant le dcodage IPsec
sont nanmoins souvent capables de filtrer les datagrammes dcods en utilisant des
outils de tunneling comme ipip et gif, ou en filtrant au niveau de linterface de sortie des
donnes. Enfin, AH utilise le numro de protocole 51 et ESP le numro de protocole 50.
Quant IKE, il utilise le numro de port UDP 500. Ces informations sont indispensables
lors de la configuration dun firewall qui doit laisser passer ou bloquer les changes IPsec.

6.4 NATs
Thoriquement, toute translation dadresse sur un datagramme IPsec devrait tre vite,
car ce type dopration modifie le contenu des datagrammes, ce qui est incompatible avec
les mcanismes de protection de lintgrit des donnes dIPsec. Il existe une solution
ce problme, propose par SSH Communications Security : lIPsec NAT-Traversal. Il sagit
dun draft, donc encore incomplet, mais suffisant pour envisager ce que lavenir rserve.
Certains quipement permettent dailleurs dj de traverser des NAT, en utilisant des
protocoles plus ou moins normaliss et avec plus ou moins de bonheur. Comme il ne
sagit que dun draft, il est dcrit dans des documents dont le nom et ladresse changent
souvent, mais un moyen simple de le retrouver est dentrer la chane 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 simultanment.

6.5 Protocoles autres quIP

Un inconvnient dIPsec est que ce protocole ne prvoit que le convoyage scuris de
datagrammes IP. Ceci nest pas suffisant, car dautres standards comme IPX et NetBIOS
sont utiliss sur un grand nombre de rseaux. Il existe cependant une solution ce
problme : encapsuler les donnes protger dans du PPP, lui-mme transport par
IPsec. Le rle de PPP est en effet de permettre la transmission de diffrents protocoles
au-dessus dun lien existant. Ceci implique de pouvoir encapsuler PPP dans les
datagrammes IPsec, cette opration est dcrite dans les paragraphes suivants.

6.5.1 PPTP
La premire solution permettant cette encapsulation est le protocole PPTP, dcrit par
la RFC 2637. PPTP offre ainsi un client, dit PAC (PPTP access concentrator), la
possibilit dtablir un lien PPP avec un serveur dit PNS (PPTP network server),
encapsul dans des datagrammes IP. Si le client a pralablement tabli une SA avec une
passerelle de scurit (ventuellement distincte du PNS), qui lui permet de protger ces
datagrammes IP, les donnes PPP seront donc galement scurises, de mme que les
protocoles de niveau suprieur sappuyant sur le lien PPP. Deux points savrent
importants lors de la configuration dun firewall plac entre un PAC et un PNS :
PPTP sappuie sur le protocole dencaspulation gnral GRE, auquel lIANA a
attribu le numro 47
un lien PPTP est contrl par une connexion TCP vers le port 1723 du PNS
Enfin, PPTP seul, cest--dire sans IPsec, peut tre et a t utilis pour crer des VPNs,

https://astuces-top.blogspot.com
assurant des changes authentifis, en protgeant les mots de passes utiliss dun
ventuel attaquant, mais sans chiffrer le reste de la communication. Cependant, ce
systme offre une authentification nettement moins fiable que ce quil est possible
dobtenir avec IPsec. En outre, de nombreuses implmentations de ce protocole,
notamment celles de Microsoft, ont fait lobjet de dcouvertes de vulnrabilits et
dincapacit protger efficacement les mots de passe des utilisateurs. Aussi lusage de
ce systme est-il risqu.

6.5.2 L2TP
Une deuxime solution dencapsulation de PPP dans IP est le protocole L2TP, dcrit par
la RFC 2661. Il permet la transmission de PPP laide des protocoles de niveau 2 comme
ethernet. Il offre galement un mcanisme dencapsulation de PPP dans UDP. Ainsi, il est
possible de protger PPP laide dUDP encapsul dans IPsec. L2TP offre en outre une
architecture plus modulaire que PPTP : on suppose le client capable dchanger des
trames par lintermdiaire dun protocole de niveau 2 ou des datagrammes UDP avec un
LAC (L2TP access concentrator), qui transmet les donnes un LNS (L2TP network
server). Si le LAC et le LNS sont situs physiquement sur le mme systme, celui-ci joue
alors exactement le mme rle que le PNS de PPTP.
Un dtail important lors du paramtrage dun firewall : le L2TP encapsul dans UDP utilise
le port 1701.

6.5.3 PPTP ou L2TP ?

Lutilisation de PPTP ou L2TP ne change pas grand-chose du point de vue de la scurit,
celle-ci tant assure par la couche infrieure IPsec. La question qui se pose est donc
celle de la consommation de bande passante, parce que toutes ces encapsulations
commencent reprsenter un volume de donnes non ngligeable. Dans le cas dun
client se connectant un ISP et tablissant ensuite le tunnel vers un rseau destination,
PPTP devrait permettre dconomiser les enttes UDP. En revanche, dans le cas dun
client se connectant, par exemple laide dun modem ou dune ligne ISDN, directement
sur le rseau priv, et disposant donc dun lien de niveau 2 vers ce rseau, L2TP semble
plus conome. Un dernier point prendre compte est que los tournant sur le serveur
imposera parfois des limitations :
pour Windows 2000 et ultrieures, Microsoft semble privilgier trs fortement L2TP
les versions prcdentes de Windows ne supportent pas L2TP
les Unix-like libres semblent accuser un lger retard en matire de support L2TP

7 Quelques implmentations actuelles

Cette partie donne un aperu des capacits de quelques OS populaires en matire de
support IPsec. Les informations fournies constituent une synthse des sites des OS, des
diteurs et des FAQs des logiciels concerns : de plus amples dtails sont donc
disponibles sur ces sites.

7.1 Windows
Windows XP et 2000 incluent un support du mode transport dIPsec et de lchange de
clefs laide de certificats en natif. Il existe de trs nombreux logiciels permettant de crer

https://astuces-top.blogspot.com
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. Dautre part, Windows 95, 98 et NT 4
disposent dune grande quantit dimplmentations IPsec commerciales et peu prs
toutes les versions de Windows depuis 95 sont capables de crer des tunnels PPTP. Une
solution intressante est galement propose par SSH Communications Security. Leur
implmentation est lheure actuelle lune 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
Limplmentation IPsec la plus utilise sous Linux est sous licence GPL, il sagit
de FreeS/WAN. La partie kernel de cette implmentation sappelle KLIPS. Sont
notamment supports :
lchange dynamique de clefs IKE laide du logiciel pluto, qui permet lutilisation
de clefs pr-partages aussi bien que de certificats
la protection des connexions dun road warrior un LAN, mme si son adresse IP
est attribue dynamiquement et est susceptible de changer
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
la cration de tunnels PPTP (ct client), grce au logiciel PPTP-linux
la cration de tunnels L2TP, grce au logiciel l2tpd
le chiffrement opportuniste, qui permet la protection des donnes changes entre
deux systmes totalement trangers jusqualors (les clefs publiques sont alors
changes laide de la DNS)
Les principaux problmes connus lors de lcriture de ce document taient :
KLIPS prsente une trs lgre fuite de mmoire
si plusieurs connexions sont tablies entre deux passerelles de scurit, la
compression denttes doit tre active pour toutes ou aucune de ces connexions
KLIPS ne gre pas les datagrammes dans lesquels des options IP sont prsentes
Enfin, FreeS/WAN dcode les paquets IPsec avant de les transmettre au code de
firewalling. Les rgles de firewalling peuvent nanmoins tester si les datagrammes ont t
envoys en clair ou non.

7.3 NetBSD
NetBSD utilise KAME, une implmentation IPsec (et plus gnralement IPv6) sous licence
BSD. La foire aux questions concernant IPsec pour NetBSD. Sont notamment supports :
lutilisation simultane dIPsec en mode tunnel ou transport avec IPv6, au moins
pour la version courante de NetBSD
la configuration socket par socket ( laide de lappel systme setsockopt(2))
la cration de tunnels IPsec grce aux ports pptp et pptp-server
un nombre quasiment illimit de SA imbriques
lchange dynamique de clefs IKE, en utilisant soit racoon, qui peut fonctionner

https://astuces-top.blogspot.com
 laide de clefs pr-partages ou de certificats, soit isakmpd, qui en est encore son
stade alpha, et supporte galement ces deux mthodes
Les principaux problmes connus lors de lcriture de ce document taient :
les clefs associes une SA mise en place laide de lappel setsockopt(2) ne
peuvent tre ngocies par racoon
le protocole AH en mode tunnel ne fonctionne pas correctement
Enfin, lors dune utilisation conjointe de KAME et IPfilter sous NetBSD, les datagrammes
sont traits par le firewall avant dtre dcods par KAME.

7.4 FreeBSD
FreeBSD sappuie galement KAME. Lutilisation dIPsec sous FreeBSD est documente.
Sont notamment supports :
lutilisation simultane dIPsec en mode tunnel ou transport avec IPv6, au moins
pour la version courante de FreeBSD
la cration de tunnels PPTP (ct client)
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
la cration de tunnels L2TP, grce au logiciel (dont le portage sous FreeBSD en
est encore au stade alpha) l2tpd
lchange dynamique de clefs IKE, en utilisant racoon

7.5 OpenBSD
A linstar de FreeBSD et NetBSD, OpenBSD utilise KAME. La documentation relative
lutilisation dIPsec sous OpenBSD. Sont notamment supports :
lchange dynamique de clefs ISAKMP grce au logiciel isakmpd, qui supporte le
mode agressif et lutilisation de certificats comme de clefs pr partages, et la
cration de SAs avec des clients dadresse IP variables et attribues
dynamiquement, photuris peut galement tre employ, mais il est encore en stade
alpha et peu document
la cration de tunnels PPTP (ct client), grce au port pptp
la cration de tunnels PPTP (ct serveur), grce au logiciel PoPToP
lchange dynamique de clefs selon le standard Photuris, en sappuyant sur le
logiciel photurisd

7.6 Solutions hardware

Si de nombreuses SA doivent tre maintenues, compte tenu de la forte charge CPU lie
au chiffrement, il sera peut-tre ncessaire davoir recours lune 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

https://astuces-top.blogspot.com
place de VPNs laide dIPsec de parfaitement comprendre quoi la protection va
sappliquer. Il est en effet trs facile de commettre des erreurs aux consquences
extrmement graves. Par exemple, placer une passerelle de scurit derrire
un Firewall et configurer ce dernier pour laisser passer tout trafic IPsec implique un
paramtrage soigneux de la passerelle de scurit, pour viter quun attaquant lutilise
pour contourner le firewall. Notamment, si cette passerelle met en oeuvre le chiffrement
opportuniste de limplmentation FreeS/WAN, le firewall peut ne plus tre daucune utilit.
Il est de manire gnrale recommand dappliquer des rgles de firewalling aprs au
mme titre quavant les traitements IPsec (pour fixer les ides, une manire simple bien
quexorbitante dappliquer ce conseil est de placer un premier firewall avant la passerelle
de scurit et un second aprs cette passerelle).
En outre, le chiffrement des donnes ne doit pas crer lillusion de la scurit,
comme SSL la trop souvent fait : chiffrer nest pas authentifier (un attaquant peut trs bien
engager une conversation chiffre avec une passerelle de scurit), et authentifier le
systme metteur dun datagramme laide du protocole AH ne suffit pas ncessairement
assurer la scurit : si un administrateur utilise un protocole permettant une
authentification en clair comme telnet, en encapsulant les donnes dans des
datagrammes protgs par AH, un attaquant pourra lire son mot de passe, et sil est
ensuite possible dtablir des connexions non authentifies laide dIPsec vers le
systme, ce dernier peut alors tre considr comme compromis.
Ces deux exemples illustrent la complexit de la mise en place dIPsec. Cette complexit
ne saurait que difficilement saccommoder de solutions soi-disant magiques et clefs en
mains, paramtres en quelques clics de souris. IPsec est excessivement complexe, et
masquer cette complexit derrire des interfaces graphiques nappelant pas les choses
par leurs noms est aussi dangereux quirresponsable (serait-il grand temps de mettre un
terme lanarchie dans le vocabulaire ?-D).

https://astuces-top.blogspot.com