✬ ✫ ✩ ✪ Rapport de stage —— ETUDE IPSec ET INTEGRATION DE L’EXTENSION ✭✭ MODE CONFIG ✮✮ DANS LE MODULE IPSec DES UTMs NETASQ Jigar SOLANKI Avril-Septembre 2008 Master 2 Cryptologie et S´ ecurit´ e Informatique Responsables Universit´ e: Emmanuel Fleury NETASQ : Yvan Vanhullebus Abdou Guermouche Universit´ e Bordeaux 1 NETASQ - We Secure IT 351, Cours de la Lib´ eration 3 rue Archim` ede 33405 Talence Cedex 59650 Villeneuve d’Ascq
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Je voudrais en tout premier lieu adresser mes sinceres remerciements a Yvan Vanhullebus, qui
a bien voulu me faire l’honneur d’accepter de superviser mes travaux au sein de NETASQ. Son
attention et sa disponibilite, dont j’ai use et abuse, m’ont ete d’une aide tout a fait precieuse ; ses
recommandations et ses conseils reellement enrichissants.
Je dois egalement beaucoup a Damien Deville et, plus indirectement a Frederic Raynal, sans
qui je ne serai sans doute jamais arrive a NETASQ.
Mes chaleureux remerciements a tous ceux que j’ai pu cotoyer, de pres ou de loin, a NETASQ et
en particluer, a l’ensemble des equipes du laboratoire R&D. M’avoir acceuilli avec cette amabilite
et gentillesse qui les caracterisent m’ont ete d’un reel reconfort tout au long de cette periode. Etre
entoure de personnes extremement competentes dans leur domaine n’a fait qu’accroıtre mon envie
de progresser et d’apporter ma minuscule petite pierre a l’edifice. Que ce soit a travers l’ambiance
chaleureuse au sein de la societe, ou encore a travers ces dejeuners copieux, propres a ces chers
ch’tis, rendant souvent les apres-midi compliques, j’y ai passe de tres agreables moments.
Un grand merci a Abdou Guermouche d’avoir accepte d’etre rapporteur et a Emmanuel Fleury
pour sa disponibilite et sa reactivite a l’universite. L’ensemble des remarques dont ils m’ont fait
part m’ont ete d’un grand secours.
Une pensee pour l’ensemble de mes amis qui m’ont toujours aide, encourage et soutenu, dans
les bons moments comme dans les mauvais. Leur bonne humeur et joie de vivre m’ont ete d’un
reconfort inestimable. Qu’ils trouvent ici ma plus profonde gratitude.
Un immense merci a ma famille, mes parents, qui m’ont permis de poursuivre dans la voie qui
m’interessait et qui m’ont toujours aide a aller de l’avant, et enfin, a celle qui m’a soutenu sans
faille aucune et sans qui je ne serai surement pas la aujourd’hui, merci a toi !
A mes parents.
Introduction
Truth never damages a cause that is just.
— Mahatma Gandhi
Les protocoles IPSec sont deployes a des echelles de plus en plus grandes, qu’il s’agisse de re-
lier des reseaux d’agences et de sucursalles par l’Internet, ou de proteger des reseaux difficilement
securisables comme le WiFi.
De plus avec l’apparition du nomadisme, de plus en plus de personnes cherchent a pouvoir acceder
aux ressources internes de l’entreprise de maniere securisee de l’exterieur. On peut citer les com-
merciaux terrains, les ingenieurs travaillant de chez eux ou encore les directeurs en deplacement.
NETASQ propose des solutions robustes de securisation des flux, et transparente pour l’utilisa-
teur, bases sur des VPN/IPSec en particulier. Plus generalement, NETASQ fournit des solutions
de securite, d’antivirus ou de pare-feux a des entreprises de tailles differentes, allant de la petite
PME aux grands comptes ou encore a l’Armee Francaise.
Le module VPN/IPSec NETASQ propose aujourd’hui embarquer l’ensemble de le configuration
reseau necessaire aux clients nomades pour qu’ils puissent acceder aux ressources internes de l’en-
treprise. Ce module est destine a etre ameliore, notamment par l’integration d’une extension IPSec
appellee Mode Configuration. Cette extension permet d’envoyer cette configuration reseau au client
nomade de maniere securisee, dynamiquement a la volee, pour que celui ci n’aie plus a embarquer
ces informations de maniere statique sur sa machine. D’autre part, cette integration permettra
d’alleger la charge de l’administrateur qui n’aura plus a maintenir individuellement l’ensemble du
parc des machines nomades de son entreprise.
Apres avoir expose les activites principales de la societe NETASQ, nous presenterons les ob-
jectifs principaux du stage. On detaillera un plan des principaux chapitres traites afin de guider le
lecteur, averti ou pas.
NETASQ en quelques mots . . .
Cree en 1998, NETASQ est l’une des societes europeennes majeures sur le marche de la securite
informatique dont le siege social est a Villeneuve d’Ascq dans le nord de la France. Elle propose des
solutions qui permettent de repondre aux enjeux et problematiques de la securite des entreprises
sur plusieurs segments : la securite unifiee par les appliances UTMs firewalls, la detection des
vulnerabilites par SEISMO ou encore le filtrage et la protection des messageries par les boitiers
MFILTRO.
NETASQ commercialise donc toute une gamme de solutions de securite unifiee (UTM). D’autre
part, l’ensemble des UTMs NETASQ integrent l’ASQ (Active Security Qualification), technologie
de prevention d’intrusion en temps reel protegee par plusieurs brevets.
NETEASQ a ete presente des le debut en Europe, notamment en Belgique, en Italie et au Roy-
aume uni. Aujourd’hui presente dans plus de cinquante pays, par l’intermediaire de partenaires
certifies, elle apporte des solutions adaptees aux marches locaux.
Ces clients viennent de secteurs et de tailles tres variees, des petites entreprises jusqu’aux grands
comptes comme Orange Business Services ou Portugal Telecom.
A la pointe de l’innovation technologique, toujours a l’affut des dernieres avancees en termes
de securite, integrant sa technologie de prevention ASQ sur l’ensemble de sa gamme, les raisons
faisant de NETASQ une societe en securite informatique en avance sur son temps ne manquent pas.
Certifiee par plusieurs organismes, NETASQ a, entre autres, ete recompensee par le Fast 50 en
France pendant deux annees consecutives. Elle a en outre recu la certification internationale des
Criteres Communs V2.2 au niveau EAL2+ (norme ISO 15408 et ISO 18045). Les UTMs
sont testes dans des conditions reelles d’exploitation par des appliances SPIRENT.
Enfin, les retours des clients etant revelateurs de la qualite des produits d’une societe, on peut
notamment citer Sebastien Truttet, responsable des infrastructures du groupe IS Altran : (( Nous
avons decide de supprimer les pare-feux de l’autre fabriquant et de n’utiliser que des pare-feux
NETASQ comme barriere de securite unique ))et dans un tout autre domaine, Frederic Andre,
Responsable Technique et Informatique du Centre Hospitalier de Valenciennes : (( Depuis plus de
trois ans, nous apprecions la reactivite de NETASQ aussi bien sur les mises a jours que sur le
service apres vente )).
- 11 -
Objectifs du stage
Le module VPN/IPSec du firmware NETASQ est base sur le projet ipsec-tools, sous licence
BSD. ipsec-tools est constitue de setkey, utilisaire de manipulation et d’injection de politiques
de securite, de racoon, demon de negociation IKE que nous allons manipuler tout au long du stage,
et de racoonctl, utilitaire de manipulation de racoon.
Le but principal du stage consite a integrer l’extension IKE Mode Configuration dans le
firwmare NETASQ. Cette extension permet d’envoyer les informations de configuration reseau
aux clients mobiles nomades. On appelle ces clients des road warriors, ils ont la particularite de ne
pas avoir d’adresse IP fixe connue de la passerelle.
Cette integration pourrait se faire en plusieurs etapes :
– Dans un premier temps, prendre en main l’environnement de travail sous FreeBSD, et avoir
une pile IPSec operationnelle.
– Etudier les extensions IKE XAuth, Hybrid et Mode Configuration, puisque les trois extensions
sont activees par une seule option de racoon.
– Evaluer l’implementation actuelle du Mode Configuration d’ipsec-tools, a travers une lecture
et un audit de code, une batterie de tests destines a confirmer ou infirmer la stabilite. Le
cas echeant, modifier le code d’ipsec-tools afin de corriger d’eventuels bugs ou erreurs de
conception et d’en ameliorer les performances.
– Prendre en main les UTMs NETASQ, etudier les differentes fonctionalites et modules disponibles
et se familiariser avec le firmware NETASQ.
– Effectuer un travail de conception avec l’ensemble de l’equipe R&D afin d’etendre le fichier
de configuration VPN NETASQ pour y integrer le Mode Configuration.
– Implementer les differentes librairies.
– Effectuer les premiers tests pour valider l’implementation.
– Effectuer des tests beaucoup plus pousses avec l’equipe de Qualification, notamment des tests
de performances sur des SPIRENT et des tests de non-regression.
– Repartir sur un travail de conception avec l’equipe IHM afin qu’elle puisse integrer les boutons
et/ou fenetres Mode Configuration de la maniere la plus adequate possible compte tenu des
contraintes de racoon, mais egalement de la maniere la plus ergonomique possible pour le
client final.
Le Mode Config, si les objectifs sont atteints, sera disponible en tant que fonctionalite option-
nelle dans la future version du firmware NETASQ.
- 12 -
Plan du rapport
Ce rapport presente l’ensemble du travail realise sur ces six derniers mois, a travers essentielle-
ment quatre chapitres qui refletent le fil directeur que j’ai suivi durant le stage :
Chapitre 1 : IPSec Ce chapitre presente les protocoles IPSec, leur fonctionnement, leur design
et la maniere dont ils sont deployes. Cette etude permettra de mieux finaliser l’ensemble des
tests realises sur IPSec et le Mode Configuration en particulier.
Chapitre 2 : Extensions IPSec Ce chapitre decrit les extensions XAuth, Hybrid et Mode Con-
figuration. Ces extensions permettent d’avoir une authentification supplementaire durant la
phase de negociation (Hybrid et XAuth) et de transmettre les informations de maniere
dynamique et securisee (Mode Config). Une section est egalement consacree a certaines
problematiques de securite posees par les deploiements reel d’IPSec.
Chapitre 3 : UTM NETASQ On etudie, dans ce chapitre, les fonctionalites des firewalls NE-
TASQ. Une description du fonctionnement de l’ASQ permet de mieux comprendre le firmware
NETASQ.
Chapitre 4 : Integration du Mode Config On presente ici l’ensemble de nos travaux, apres
avoir pris en main l’environnement dans son ensemble (etude IPSec, prise en main des UTMs,
etude sur le firmware, etc). Le fichier de configuration NETASQ est etendu et les champs
Mode Configuration ajoutes. Une batterie de tests finaux finissent l’integration.
Un approndissement des principaux protocoles IPSec est disponible en annexe.
- 13 -
CHAPITRE I
Les protocoles IPSec
An error does not become truth by reason of multiplied propagation,
nor does truth become error because nobody sees it.
— Mahatma Gandhi
Resume :
IPSec est une suite de protocoles destines a securiser le trafic au niveau IP. Il a ete
initiallement developpe au sein du projet KAME pour IPv6, puis backporte a IPv4.
IPSec fournit notamment la confidentialite des donnees qui transitent, leur authen-
tification, leur integrite en mode non-connecte et une protection contre le rejeu. Il
permet ainsi de proteger l’ensemble des couches superieures reposant sur IP.
IPSec peut fonctionner suivant deux modes : en mode transport pour une utilisation
de type Host-To-Host ou en mode tunnel pour le deploiement de passerelle VPN (Gate-
To-Gate ou Host-To-Gate).
Les flux sont chiffres et/ou signes par des algorithmes cryptographiques a cle secrete, a
travers deux protocoles : AH assurant l’authentification et l’integrite des donnees et ESP
assurant principalement leur confidentialite mais permet de les authentifier egalement.
L’echange et le renouvellement de l’ensemble des cles cryptographiques est assure par
le protocole IKE - Internet Key Exchange qui lui meme est une instanciation du pro-
tocole ISAKMP - Internet Security Association and Key Managment Protocol
utilisant entre autres, le protocole Oakley permettant de realiser les echanges Diffie-Hellman
notamment.
Les parametres d’une politique de securite (identite de l’hote, algorithmes a utiliser, etc)
sont stockes dans une Security Association (SA). L’ensemble des SA sont alors stockees
dans une base de donnees de SA appellees Security Association Database (SAD).
Enfin, les differentes politiques de securite a appliquer aux paquets transitant par le
module IPSec sont stockees dans une structure noyau appellee Security Policy Database
(SPD).
CHAPITRE I. LES PROTOCOLES IPSEC
I.1 Presentation
I.1.1 Champ d’action d’IPSec
En matiere de securisation des echanges sur un reseau (a fortiori sur un reseau TCP/IP), les
services disponibles peuvent etre relativement differents suivant la couche de la pile reseau dans
laquelle ils operent. On peut citer :
– Les protections au niveau applicatif integres dans l’application en elle meme.
– Les protections au niveau de la couche transport (TCP, UDP...) en utilisant les protocoles
SSL/TLS et OpenVPN pour l’etablissement de tunnels SSL.
– Les protections au niveau de la couche liaison avec par exemple des tunnels PPTP.
Quant a IPSec (Internet Protocol Security), il definit une collection de protocoles destines a
securiser l’ensemble du trafic sur un reseau repute non securise, typiquement a travers l’Internet.
En effet, le protocole IP tel qu’il a ete concu ne prevoit pas la protection et la securisation des
donnees transmises. IPSec definit une extension d’IP destine a palier a ce manque. Il intervient
au niveau de la couche 3 - Reseau - du modele OSI (cf. Fig I.1) en securisant les flux IP. Il opere
donc de maniere totalement transparente pour l’utilisateur, moyennant le temps de latence du aux
negociations avec l’hote distant et aux traitements des paquets du point de vue cryptographique,
les algorithmes de chiffrement et d’authentification etant gourmands en ressources. Le support
d’une pile IPSec est optionnel pour IPv4, mais obligatoire pour toute implementation conforme
d’une pile IPv6. Normalise pour la premiere fois en 1998 dans la RFC 2401, l’architecture IPSec a
connu bien des evolutions en une decenie, qu’il s’agisse de la pile IPSec noyau ou des demons IKE
de negociation de cles ou de manipulation de regles de SPD.
I.1.2 Historique
Les piles IPSec
Une des toutes premieres implementations d’IPSec fut celle du projet KAME. Ce projet re-
groupait pres d’une dizaine de grosses compagnies japonaises, dont Fujitsu, Hitachi, NEC ou en-
core Toshiba, dans le but de fournir une implementation d’une pile IPv6, IPSec et IPMobile pour
les systemes BSD. Les systemes qui ont integre la pile KAME/IPSec s’avereront etre, par la suite,
FreeBSD et NetBSD. Dans le meme temps, il se trouve qu’OpenBSD avait deja implemente sa pro-
pre pile IPSec depuis la version 2.1 datant de 1997, avec ses differents avantages et inconvenients. Le
principal avantage de la pile IPSec d’OpenBSD etait l’integration de l’acceleration cryptographique
materielle en natif, permettant d’accroıtre considerablement les debits et les performances.
Concernant les systemes d’exploitation bases sur un noyau Linux, la toute premiere imple-
mentation d’une pile IPSec fut realisee par le projet FreeS/WAN dont la derniere version, 2.06,
- 15 -
I.1. PRESENTATION
Transport : TCP, UDP
Applications
Liaison, Physique
IPSec
IPSec
AnciennesPiles IPv4
Piles IPv4
IPSec
Intégrant
Récentes Pile IPv6Intégrant
NativementIPSec
Fig. I.1 – Positionnement d’IPSec dans la pile IP
date de 2004. FreeS/WAN fut alors divise en deux autres projets que sont OpenS/WAN et
StrongS/WAN. Toutefois, aucunes de ces trois piles IPSec ne fut integree dans les noyaux Linux.
En effet, a l’horizon 2002, deux developpeurs du noyau Linux, A. Kuznetsov et D. S. Miller ont
entierement implemente une pile IPSec en s’inspirant des des travaux du groupe USAGI IPv6.
Cette pile est celle qui est aujourd’hui integree en natif dans les noyaux 2.6.x.
Sur FreeBSD, la pile integree dans le noyau fut a l’origine la pile KAME/IPSec. Toutefois, un
portage de la pile IPSec d’OpenBSD integrant l’acceleration cryptographique materielle a ete
realise, ce qui a donne la pile FastIPSec. Deux piles IPSec ont alors ete maintenues, et lorsque
l’ensemble des fonctionalites presentes dans KAME/IPSec l’ont egalement ete dans FastIPSec, les
developpeurs FreeBSD ont abandonne la pile KAME. Ainsi, depuis la version FreeBSD 7.0, seule une
pile IPSec est integree et maintenue, a savoir FastIPSec.
Les demons en espace-utilisateur
Parallelement au developpement des differentes piles IPSec, il etait necessaire, comme nous le
verrons plus tard, d’avoir des demons s’executant une espace utilisateur afin de manipuler, config-
urer, maintenir, administrer les differentes configurations et politiques a appliquer aux flux ; comme
par exemple l’authentification du site distant, l’echange securise des cles cryptographiques, savoir
si le site distant est toujours disponible, etc.
Theoriquement, les demons en espace utilisateur sont independants de la pile IPSec dans le
- 16 -
CHAPITRE I. LES PROTOCOLES IPSEC
noyau, et il est possible d’utiliser n’importe quel demon sur toutes1 les piles IPSec decrites plus
haut. Nous verrons un peu plus tard pourquoi ce n’est pas totalement vrai, puisque l’interfacage a
travers lequel ils communiquent avec le noyau n’offre pas autant de requetes qu’il serait souhaitable
d’en avoir.
Ainsi, le projet KAME disposait de son propre demon, racoon, repris plus tard par le projet
ipsec-tools. C’est sur ce projet qu’est base en grande partie le stage. D’autre part, OpenBSD avait
implemente son demon en parallele de la pile, isakmpd aujourd’hui encore integre dans OpenBSD
4.x. Enfin, pour les systemes Linux, plusieurs ont vu le jour. On peut citer pluto, demon des
projets xS/WAN, ou encore racoon qui supporte Linux, FreeBSD et NetBSD.
IPSec est aujourd’hui tres largement deploye, en particulier pour la mise en place de VPNs2,
afin de securiser les echanges entre sites distants. L’avantage par rapport a d’autres solutions de
tunnelling comme OpenVPN, base sur SSL/TLS securisant TCP, reside dans la totale transparence
au niveau de l’utilisateur et la securisation de l’ensemble des couches basees sur IP, notamment
l’ensemble des couches de transport comme TCP et UDP.
Les implementations proprietaires
Toutes les implementations IPSec ne sont en effet pas OpenSource. Des grands comptes comme
Microsoft ou Cisco possedent aujourd’hui leur propre implementation de pile IPSec. Bien qu’IPSec
soit un moyen extremement robuste afin de transmettre du trafic chiffre, il n’en reste pas moins
vrai que l’interaction avec d’autres piles IPSec pose par moments des problemes de compatibilites.
I.1.3 Pourquoi deployer IPSec ?
Qu’il s’agisse de l’ensemble des services de securite fourni, ou de la flexibilite dans le deploiement,
ou encore du cout moindre par rapport a des lignes dediees, les VPN/IPSec sont de plus en plus
presents dans l’architecture reseau des entreprises.
Services de securite
Le pannel de services disponibles sous IPSec est assez varie ce qui lui permet d’etre tres flexi-
ble lors du deploiement de topologies reseaux securisees. On regroupe ici quelques mecanismes de
securite disponibles :
Authentification des correspondants : Il s’agit d’une authentification a double sens ou chaque
extremite s’assure de l’adresse de son correspondant. Il s’agit principalement des adresses IPs
des machines deploiyant IPSec et non pas des reels utilisateurs des dites machines. Nous ver-
rons la maniere dont les extentions ISAKMP/XAuth et ISAKMP/Hybrid permettent de remedier
a cela en offrant une authentification forte supplementaire des utilisateurs en plus de celle
1sous reserve que les demons soient bien en environnement compatible, racoon ne fonctionnera bien entendu pas
sur une architecture de type Win322VPN :Virtual Private Network, ou Reseaux Virtuels Prives (RVP)
- 17 -
I.1. PRESENTATION
des machines, notamment pour les clients mobiles possedant une IP dynamique.
Authentification des flux : Il s’agit de verifier que les flux qui circulent dans le tunnel ont bien
ete emis et/ou sont bien a destination de l’une ou l’autre des extremites. IPSec dispose prin-
cipalement de methodes de hachages afin de realiser cette operation, a travers le protocole
AH et/ou ESP.
Confidentialite des flux : Le payload des paquets IP est entierement chiffre a l’aide d’algo-
rithmes cryptographiques a cle secrete, envoye a travers le tunnel et dechiffre une fois arrive
a destination.
Integrite des flux : Lorsqu’un paquet IPSec3 subit une quelconque modification lors de son
trajet, elle est detectee et le paquet est ignore. L’integrite en mode non-connecte permet de
detecter une quelconque modification d’un datagramme individuel, mais pas sur l’ordre des
datagrammes, leur ordonnancement, ou la perte de paquets ou l’on parle d’integrite en mode
connecte. Cela protege les flux de toute alteration qu’ils peuvent subir et permet notamment
de se premunir contre des attaques actives. Nous verrons pourquoi ceci est tres problematique
lorsqu’il s’agit de traversser des equipements NAT4 et comment l’extension IPSec NAT-T per-
met d’y remedier.
Protection contre le rejeu et l’analyse de trafic : Bien qu’un attaquant ne puisse pas dechiffrer
ou modifier un paquet chiffre, il pourrait juste le capturer et le renvoyer plus tard. IPSec per-
met de se proteger contre ce type d’attaque par rejeu de paquets. Ceci apporte egalement
une protection supplementaire contre les eventuelles ecoutes et analyses de trafic puisque
l’ensemble du payload etant chiffre, un eventuel attaquant ne pourrait pas savoir quelle
couche de transport est utilisee (TCP UDP ICMP . . .) ou encore quelle type de protocole de
niveau superieur (HTTP FTP SMTP), etc.
Souplesse cryptographique : IPSec n’est lie a aucun algorithme cryptographique en parti-
culier. Il supporte de multiples algorithmes a cle secrete, et est capable de negocier dy-
namiquement les algorithmes supportes par tel ou tel hote tentant d’etablir une connexion.
Bien que cette souplesse de negociation soit avant tout un avantage, nous mettrons l’accent
sur le fait que cela peut etre d’un niveau de securite moindre lorsque certains parametres
ne sont pas choisis de maniere adequate. A titre d’exemple, un proposal check obey peut
faire en sorte que les hotes negocient le chiffrement DES alors que les deux supportent AES.
Services de flexibilite
Les passerelles VPN/IPSec sont typiquement deployees dans des entreprises qui disposent de
locaux geographiquement eloignes les uns des autres. L’ensemble des services disponibles sur le site
central doivent egalement l’etre sur les differents sites distants. Outre une grande souplesse dans
3paquet AH ou ESP4NAT - Network Address Translation
- 18 -
CHAPITRE I. LES PROTOCOLES IPSEC
la mise en place de tunnels VPNs, on peut noter :
Bande passante : Les WANs traditionnels utilises pour la communication inter-sites sont bases
sur Frame Relay5, ou sur ATM . Avec l’apparition de nouveaux services necessitant de plus
en plus de debit, il a fallu choisir entre multiplier les lignes entre les sites ou trouver d’autres
alternatives securisees et de debits acceptables. D’ou le compromis trouve d’adopter des so-
lutions basees sur IPSec.
Reduction des couts : Avec la diminution des couts des abonnements des fournisseurs d’acces,
avoir une ligne dediee coute beaucoup trop cher en terme de deploiement et de maintenance.
De plus en plus d’entreprises se tournent vers des fournisseurs d’acces et securisent leur flux
plutot que d’acheter des lignes dediees.
Disponibilite, adaptabilite : IPSec peut etre deploye en tout point disposant d’un acces reseau.
Tandis que la plupart des societes possedent deja des lignes de communication dediees entres
leurs differents sites distants, le debit est bien souvent insuffisant lorsqu’il s’agit d’acceder
a une panoplie de services de plus en plus gourmands en bande passante. Dans ces cas,
comme precedemment, il est possible de deployer des tunnels IPSec entre ces differents sites,
en y faisant passer les informations les moins critiques, alors que les donnees tres sensibles
continuent a etre acheminees a travers le WAN dedie.
I.2 Vue generale des protocolesIPSec regroupe toute une suite de protocoles, de specifications, d’acronymes decrits dans
differentes RFCs se referencant les unes aux autres, ce qui rend sa prise en main relativement
delicate de prime abord. On presente ici une vue d’ensemble de ces differents protocoles afin de
mieux comprendre ce que font les differents modules avant d’approfondir les caracteristiques des
protocoles en question.
I.2.1 Mode Transport, Mode Tunnel
Suivant les besoins et les utilisations, IPSec peut fonctionner sur deux modes, le mode Trans-
port et le mode Tunnel .
Mode Transport
IPSec en mode Transport (a ne pas confondre avec la couche transport du modele OSI) est
particulierement adapte pour la communication entre deux hotes. Cela presuppose donc l’installa-
tion et la configuration prealables d’une pile IPSec sur les deux systemes.
En mode Transport, les mecanismes de securisation viennent s’intercaler entre les couches
Transport et Reseau : les entetes IPSec appropriees (AH et/ou ESP) sont appliques apres que les
5Relai de trames : transfert de donnees par commutation par paquets, a haut debit et sur de longues distances,
evolution de X.25
- 19 -
I.2. VUE GENERALE DES PROTOCOLES
IPSec Transport Host To Host
Alice Bob
Host A Host B
Fig. I.2 – IPSec en Mode Transport
donnees soient passees par la couche -4- Transport et avant de les passer a la couche -3- Reseau.
Ce mode protege donc l’ensemble des donnees au dessus d’IP.
IP Hdr
IP Hdr
Data
IPSec Hdr Data
A Protéger
Fig. I.3 – En-tete en Mode Transport
Ainsi, le principal defaut de ce mode reside-t-il dans l’absence de masquage d’adresses puisque
les adresses IP des deux correspondants sont visibles.
Pour permettre une protection de tout le paquet IP, le mode le plus souvent deploye est le
mode Tunnel .
Mode Tunnel
IPSec en mode Tunnel est utilise pour le deploiement de passerelles VPNs et permet de re-
lier un ensemble de reseaux de maniere securisee a travers un reseau peu sur comme l’Internet.
L’ensemble des postes n’ont alors nullement besoin d’installer et/ou de configurer des systemes
supportant IPSec, seules les deux passerelles en sont dotees.
En mode Tunnel , les traitements IPSec sont appliques apres que l’ensemble des donnees aient
traverses la couche IP egalement. Les entetes (AH et/ou ESP) portent sur un datagramme IP en
entier et non plus seulement sur un datagramme TCP ou UDP ; et une nouvelle entete IP est rajoutee
- 20 -
CHAPITRE I. LES PROTOCOLES IPSEC
IPSec Gateway A IPSec Gateway B
Tunnel Gate To Gate
Fig. I.4 – IPSec en Mode Tunnel
au paquet.
IP Hdr
IP Hdr
Data
IPSec Hdr Data
A Protéger
New
IP Hdr
Fig. I.5 – En-tete en Mode Tunnel
Comme on peut le voir, les adresses source et destination sont entierement masquees, les corre-
spondants reels ne sont pas visibles, et l’on dispose d’une protection contre l’analyse de trafic. Le
mode Tunnel est le mode le plus souvent utilise et deploye a grande echelle.
I.2.2 Protocole AH, Protocole ESP
IPSec repose principalement sur deux protocoles destines a securiser le trafic :
AH : Le protocole AH - Authentication Header.
ESP : Le protocole ESP - Encapsulating Security Protocol.
- 21 -
I.2. VUE GENERALE DES PROTOCOLES
Protocole AH
AH (Authentication Header) est utilise principalement pour fournir une authentification et
un controle d’integrite des donnees.
AH ne permet pas de chiffrer les paquets. Il ne doit donc pas etre utilise lorsque l’on souhaite avoir
la confidentialite des donnees.
AH protege l’ensemble des donnees, ainsi que l’ensemble des en-tetes non modifiables (numero de
protocole, port de destination, etc). Il n’offre, en revanche, pas de protection sur l’ensemble des
en-tetes susceptibles d’etre modifiees lors du trajet du paquet comme par exemple le champ TTL
ou le champ ToS de l’en-tete IP.
Suivant le mode Transport ou Tunnel, la figure I.6 decrit la maniere dont AH encapsule les donnees.
IP Hdr
IP Hdr
Data
AH DataNew
IP Hdr
Authentifié sauf les champs modifiables dans New IP Hdr
Paquet Original
AHIP Hdr Data
Authentifié sauf les champs modifiables dans IP Hdr
Mode Transport
Mode Tunnel
Fig. I.6 – Authentication Header - AH
Comme on peut le voir, AH protege l’ensemble des champs non-modifiables du paquet. Il peut
etre utile lorsque la confidentialite des donnees n’est pas recherchee d’une part, et d’autre part
lorsqu’une authentification forte du paquet est exigee. La transmission du resultat d’une election
ou les donnees sont destinees a etre publiques mais doivent provenir de source sure est un bon
exemple.
- 22 -
CHAPITRE I. LES PROTOCOLES IPSEC
Protocole ESP
ESP est le deuxieme protocole definit dans la suite IPSec. Protocole le plus repandu dans la pra-
tique, ESP (Encapsulating Security Payload) offre egalement la confidentialite des donnees.
L’ensemble des donnees sont alors chiffrees avant detre transmises, suivant differents mecanismes
et protocoles que l’on detaille a la section I.2.3.
ESP chiffre, d’une part, le champ Data des paquets suivant un ensemble de parametres negocies
au prealable avec l’hote distant, et d’autre part, utilise des mecanismes d’authentification (comme
HMAC) afin de fournir une protection anti-rejeu ou encore une integrite des donnees. A ce titre,
ESP est un protocole tres complet, offrant toute une panoplie de protections allant du simple
chiffrement des donnees jusqu’a leur authentification en plus.
La figure I.7 decrit la maniere dont ESP encapsule l’ensemble des champs des paquets.
IP Hdr
IP Hdr
Data
DataNew
IP HdrESP
IP Hdr Data
CHIFFRE
Mode Transport
Mode Tunnel
Hdr
ESPTrailer
ESPAuth
AUTHENTIFIE
ESPHdr
Trailer AuthESPESP
CHIFFRE
AUTHENTIFIE
Fig. I.7 – Encapsulating Security Payload - ESP
- 23 -
I.2. VUE GENERALE DES PROTOCOLES
AH et ESP
Il est tout a fait possible d’utiliser les deux protocoles conjointement, meme si cela reste tres
peu utilise. Lorsque l’on recherche a avoir une confidentialite des donnees et une authentification
complete du paquet, il est possible d’utiliser dans un premier temps ESP afin de chiffrer les donnees
et authentifier les champs concernes, puis d’aposer AH sur le paquet ESP obtenu. On a ainsi une
authentification complete de tous les champs du paquet et un chiffrement des donnees.
Ce mode de fonctionnement est neanmoins tres lourd et gourmand en bande passante. En pra-
tique, le mode Tunnel ESP reste tres securise et offre l’ensemble des services de securite mentionnes
plus haut.
I.2.3 Etablissement d’une negociation IPSec
Phases IPSec
Il existe deux facons d’etablir des echanges chiffres entre deux hotes IPSec :
Dynamique : La negociation dynamique est la plus repandue, la plus securisee et la plus con-
seillee. Elle permet de negocier a la volee l’ensemble des parametres necessaires et assure le
renouvellement periodique des cles cryptographiques mises en jeu et leur echange de maniere
securisee.
Statique : Principalement maintenue pour des raisons de compatibilites, ce mode de (( negociation ))est
tres obsolete et presente quelques failles de securite, puisque les cles sont non seulement sta-
tiques, donc jamais renouvellees. Ainsi, les tentatives d’attaques par brute force ont plus de
chances d’aboutir. Cette methode de negociation ne sera pas abordee dans le cadre de ce
rapport.
Une negociation IPSec dynamique, c’est a dire utilisant un demon de negociation IKE, se fait
principalement en deux etapes ou phases.
Phase 1 : La premiere phase sert a authentifier mutuellement les deux correspondants et d’etablir
un canal de transmission securise. Par la suite, l’ensemble de la configuration et parametres
necessaires sont negocies afin de proteger les differents echanges (les duree de vie, les infor-
mations diverses, etc). Lorsque cette phase est terminee, les deux correspondants disposent
d’une ISAKMP SA. Il s’agit d’un canal de transmission securise par lequel les deux cor-
respondants vont s’echanger differentes informations, y compris les cles cryptographiques
destinees a chiffrer et/ou authentifier le trafic des donnees proprement dites.
Phase 2 : La deuxieme phase permet essentiellement de se mettre d’accord sur les protocoles
cryptographiques a utiliser pour chiffrer et authentifier tel ou tel type de trafic entre les deux
hotes ; et de transferer les cles cryptographiques necessaires. Une fois cette phase realisee, les
correspondants disposent de deux IPSec SA chacun.
- 24 -
CHAPITRE I. LES PROTOCOLES IPSEC
A partir de ce moment, les deux hotes peuvent alors s’echanger du trafic de maniere securisee.
Les SAs sont developpees plus en details dans la section I.3.2.
Politiques et Associations de securite
Etant donne un trafic qui doit etre chiffre avec tel protocole, un autre avec tel protocole et un
dernier ne devant pas l’etre, comment ce trafic est-il effectivement traite ?
Lorsque les paquets arrivent (cf Fig I.8) entre la couche Transport et la couche Reseau, le noyau
verifie tout d’abord si ce trafic doit subir un traitement IPSec ou non en fonction de differents
champs contenus, entre autres, dans l’en-tete IP. Pour cela, le noyau cherche une politique de
securite correspondant au paquet, dans une base de politiques (SPD) prealablement configuree par
l’administrateur. La SPD permet de savoir si un type de trafic doit subir un traitement IPSec ou
pas. Si ce n’est pas le cas, le paquet sera envoye en clair. On pourrait schematiser la SPD - Security
Policy Database - par une seconde table de routage.
Pqt en ClairIP
IPSecS P D
Consulte
IPSec : Oui / Non ?
S A D
SA1SA2SA3...
Consulte
Pqt en Clair
Tunnel IPSec
Pqt Chiffré
I K E
Maintient, Négocie
Modifie, Supprime
Demande de
Création de SA
Administrateur
logs
Configure
Fig. I.8 – Synoptique de Fonctionnement IPSec
Si c’est le cas, il faut a present savoir a quel type de tunnel il correspond. Le type (Tunnel,
Transport, ESP, AH) est egalement stocke dans la SPD. Une base de donnees de SA (SAD) est
maintenue en temps reel et contient l’ensemble des SAs des politiques IPSec actives. Dans le cas ou
le noyau trouve une SA correspondante, il va y lire les parametres necessaires (protocole a utiliser,
- 25 -
I.3. DESIGN ET ARCHITECTURE DE SECURITE
taille des cles, etc) et traiter le paquet en consequence (ESP ou AH, Tunnel ou Transport) avant
de l’envoyer.
Si la SA n’est pas trouve, le noyau demande au demon IKE – le demon racoon du projet
ipsec-tools en locurrence – de negocier une SA avec l’hote distant. Durant cette negociation,
l’ensemble des paquets devant subir un traitement IPSec a destination de cet hote sont ignores.
Ceci explique le temps de latence lors de la premiere communication a travers un tunnel IPSec.
Le detail et l’etude approndie des protocols AH et ESP est disponible dans l’annexe A.
Maintenant que l’on a etudie les protocoles de transmission d’IPSec, il s’agit de voir comment
les differents parametres, clefs de chiffrement, protocoles, identites des correspondants, etc. sont
geres dans le systeme.
Comment se fait le renouvellement periodique des cles ?
Comment detecte t-on lorsque l’hote en face ne repond plus ? Que faire dans ces cas la ?
Faut-il garder les parametres en esperant que l’absence soit temporaire ? Ou au contraire les sup-
primer directement ?
Autant de question auxquelles nous tenterons de repondre dans la section suivante.
I.3 Design et architecture de securite
L’architecture complexe d’IPSec repose sur le principe d’Association de Securite. Il s’agit d’une
structure contenant un ensemble de parametres negocies avec l’hote avec lequel l’on souhaite etablir
une connexion IPSec. Ces differentes associations sont stockees dans des bases de donnees d’asso-
ciations, afin de retrouver rapidement celle qui correspond a tel ou tel hote.
I.3.1 Extremites de tunnel, de trafic
On appelle extremite de tunnel (cf. Fig I.9) les deux extremites entre lesquelles le trafic sera
effectivement chiffre et/ou signe. Il s’agit des adresses des deux passerelles IPSec dans le cas d’une
configuration en mode tunnel ou de l’adresse des deux correspondants dans le cas d’une configu-
ration en mode transport.
On appelle extremite de trafic (cf. Fig I.9) les sous-reseaux qui sont autorises a emprunter le
tunnel de part et d’autre de la passerelle. Les extremites de trafic constituent un point essentiel de
l’architecture IPSec : un sous-reseau bien que faisant partie du reseau interne de l’entreprise, s’il
n’est pas autorise a envoyer du trafic IPSec vers telle ou telle passerelle sera detecte au moment
de la verification sur l’extremite de tunnel.
- 26 -
CHAPITRE I. LES PROTOCOLES IPSEC
Fig. I.9 – Extremites de tunnel, de trafic - www.cisco.com
I.3.2 Associations de Securite
Les SAs representent une structure au coeur de toute connexion IPSec. Il s’agit d’un ensemble
ou d’une collection de parametres permettant d’etablir un tunnel de commmunication securise
entre deux hotes. Les SAs sont unidirectionnelles, il en faut ainsi deux pour une communication
bi-directionnelle.
Lorsque deux entites communiquent au travers d’IPSec, il faut pouvoir distinguer la maniere
dont telles ou telles donnees sont chiffrees et/ou authentifiees de telles ou telles manieres. Les SAs
contiennent ainsi, pour un hote distant donne, le protocole a utiliser (AH et/ou ESP), les algo-
rithmes cryptographiques associes, les cles de chiffrement, la periode de renouvellement des cles, etc.
Elles sont identifiees par un numero de SPI (Security Parameter Index). Le SPI permet
de savoir comment un paquet arrive sur l’interface ipsec doit etre authentifie et/ou dechiffre en
allant consulter les parametres de la SA a laquelle il correspond ; ou alors, il permet de connaıtre
les protocoles et cles a utiliser lors du chiffrement d’un paquet a envoyer a un hote donne.
Le concept de SA permet d’avoir differents degres de chiffrement et/ou d’authentification entre
deux, voire plusieurs hotes. A titre d’exemple, si l’on considere deux filiales ou l’acces aux services
de mail est moins critique que l’acces a des applications financieres. Bien que le tunnel IPSec soit
physiquement le meme, il existera deux politiques de chiffrement, donc deux SAs de chaque cote
afin de chiffrer les paquets a destination des applications financieres a l’aide de methodes tres ro-
bustes (donc plus couteuses en temps et en ressources), et les flux a destination des services mails
a l’aide de chiffrement d’un degre moindre.
Les differentes SAs negociees avec les differents hotes sont stockees dans une base de donnees
- 27 -
I.4. PHASES DE NEGOCIATION
de SAs appellee SAD ou SADB (Security Association Database).
I.3.3 politiques de securite
Pour chaque paquet entrant ou sortant, il faut etre capable de determiner si ce paquet est des-
tine a une quelconque interface IPSec ou s’il doit etre envoye en clair sur le reseau. Il existe pour
cela une table d’entrees de politiques de securite, pouvant etre assimilee a une table de routage
interne, permettant de savoir a quel type de traffic est destine un paquet.
Ces differentes politiques sont stockees dans une SPD (Security Policy Database) qui est
donc consultee a chaque paquet sortant ou entrant. L’administrateur a la charge de configurer
et maintenir les politiques dans le noyau a travers des outils userland comme setkey du projet
ipsec-tools, largement utilise pendant le stage, de pair avec le demon IKE racoon.
Lorsqu’une SA n’existe pas ou n’est plus valide et qu’un paquet doit etre envoye au travers
d’une connexion IPSec, le noyau demande a un demon IKE de negocier une SA avec l’hote distant.
I.4 Phases de negociation
La negociation d’une SA se fait principalement en deux phases. A l’issue de la Phase 1, une
ISAKMP SA est cree. A partir de ce moment, les deux entites disposent d’un tunnel securise et
peuvent negocier les parametres de securisation des donnees en elles-memes : il s’agit de la Phase
2 et permet d’etablir une IPSEC SA.
I.4.1 Phase1 : ISAKMP SA
La Phase 1 represente la negociation initialle afin d’etablir la ISAKMP SA 6 entre les deux
hotes. Elle peut se faire de maniere robuste lorsque les conditions le permettent (notamment lorsque
l’adresse IP du correspondant est connue a l’avance), il s’agit dans ce cas du Main Mode ; ou elle
peut se faire par l’Aggressive Mode qui ne presuppose pas la connaissance de l’IP de l’hote.
La Phase 1 commence par envoyer la liste des propositions d’authentification, de chiffrement
ainsi que les durees de vies a negocier. Suivant la maniere dont est configure l’hote distant, la
negociation peut etre ou ne pas etre acceptee.
La deuxieme etape consiste a calculer des cles de session par l’intermediaire d’un echange Diffie-
Hellman. Une fois les cles de sessions etablies, tout le traffic a partir de ce moment est chiffre.
6Contrairement a une IPSEC SA, la ISAKMP SA est bidirectionnelle
- 28 -
CHAPITRE I. LES PROTOCOLES IPSEC
Authentification des correspondants
Il faut, a present, authentifier les deux correspondants. racoon dispose de plusieurs methodes
d’authentification, dont deux tres couramment utilisees :
Pre Shared Key : Il s’agit d’une cle pre-partagee a l’avance par les deux hotes (par hote, on
entend une adresse IP, un login ou encore un FQDN). A noter qu’a l’heure actuelle, dans le
demon racoon, il n’est pas possible de configurer une cle qui soit partagee par un ensemble
d’utilisateurs ou par tout le monde (appelle aussi Wildcard ou Goup Password chez TM), ce
qui presente des risques de securite non negligeables. C’est la methode d’authentification la
plus frequemment utilisee car la plus simple a mettre en place. Neanmoins, comme nous le
verrons dans le chapitre suivant, l’authentification en pre shared key est tres deconseillee
voire a proscrire lorsqu’il s’agit d’authentifier des hotes de types Road Warrior, c’est a dire
ceux dont l’adresse IP n’est pas connue a l’avance.
Certificats X509 : Utilisant une Public Key Infrastructure, c’est une methode d’authentification
par certificats numeriques X5097. Il s’agit de la methode la plus sure actuellement disponibles
a au moins deux conditions : avoir une CRL8 a jour tres regulierement et en ce qui concerne
les Road Warrior, avoir deux CA differentes, l’une pour signer le certificat de la passerelle
IPSec et la deuxieme pour signer les certificats utilisateurs.
Une fois l’authentification des correspondants achevee, chacun accuse de la bonne reception des
differents parametres et la ISAKMP SA est consideree comme etablie.
Main Mode - Aggressive Mode
L’etablissement de la ISAKMP SA peut se faire soit par six echanges (Main Mode) ou par
un couple d’echanges en moins (Aggressive Mode).
Le Main Mode (cf Fig. I.10) permet d’avoir la “ Protection des Identites ” des correspondants
(Identity Protection Mode) ! Les echanges des empreintes des differentes identites ne se font
qu’apres l’etablissement d’un secret commun partage par les deux entites : l’echange Diffie Hell-
man est fait au niveau 3 et 4 pour etablir la cle de session et l’echange des empreintes est faite au
niveau 5 et 6. L’identite et l’empreinte de l’identite sont tous deux chiffres avec la cle partagee. En
Main Mode avec une authentification en Pre Shared Key, comme les echanges 5 et 6 sont chiffres,
c’est l’adresse IP du correspondant qui fait office d’identifiant ; ce qui va devenir problematique
pour les road warriors puisque leur IP n’est a priori pas connue a l’avance !
L’ Aggressive Mode (cf Fig. I.11) en revanche ne supporte pas la “ Protection des Iden-
tites ”9 : les identifiants sont envoyes en clair sur le reseau. En effet, l’echange se fait avant
7Un certificat X509 est une methode d’authentification liant une cle publique a un nom ou une adresse email8CRL : liste de revocation mise a jour regulierement, elle a definir l’ensemble des certificats qui ne sont plus
valides.9Sauf lorsqu’il s’agit d’une authentification en Hybrid
rdr sis0 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis1 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis3 from 10.2.29.1/32 to 10.2.29.2/32 port = 22 -> 192.168.2.1 port 22 tcp
rdr sis0 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis1 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis3 from 0/0 to 10.2.29.2/32 port = 5900 -> 192.168.2.1 port 5099 tcp
rdr sis0 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
rdr sis1 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
rdr sis3 from 0/0 to 10.2.29.2/32 port = 5800 -> 192.168.2.1 port 5800 tcp
Il s’agit d’une configuration NAT basique permettant de translate un reseau, en locurrence
192.168.2.0/24, en une adresse IP, en locurrence 10.2.29.2 ; d’une redirection de port ssh,
TCP 22, et d’une redirection de port VNC, TCP 5800 et TCP 5900.
Lorsque dans le cahier des charges des versions futures du firmware, il ne sera plus question
d’utiliser ipnat, si cela arrive, le fichier NETASQ restera le meme. Seul changera la librairie de
parsing qui generera, cette fois ci, un fichier au format du nouveau module NAT.
Le fichier de configuration IPSec est base sur le meme principe, c’est ce fichier que nous nous
proposons d’etendre en vue de l’integration de l’extension Mode Config.
IV.2.2 Conception et extension du fichier
Conception
Apres ma prise en main des appliances NETASQ et le succes des nombreux tests realises avec
racoon, une nouvelle roadmap a ete etablie.
En fonction des demandes des clients, des champs Mode Config disponibles dans racoon, et du
delai imparti pour l’integration, il a finalement ete decide d’envoyer la configuration reseau suivante
aux clients mobiles :
– Une adresse IP de type RFC 1918 afin que l’interface IPSec du client mobile soit configuree
de telle maniere qu’elle croit etre sur le reseau interne, d’ou tout l’interet.
– Transmettre son extremite distante de trafic pour qu’il puisse negocier les IPSec SA sans
embarquer ces informations de maniere statique sur la machine.
- 72 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
– Transmettre l’adresse d’un serveur DNS2.
– Transmettre l’adresse d’un serveur WINS3
Fichier VPN
Un fichier de configuration NETASQ IPSec se presente de la maniere suivante :
[Global]
Tunnels=Tunnel_1
[Tunnel_1_1_1]
Dh=2
Hash=1/160
Enc=11/256
[Tunnel_1_2_1]
Mode=ESP,TUNNEL
Auth=3/160
Enc=11/256
Dh=2
Lifetime=3600
Src=any
Dst=merignac
keepalive=60
[Tunnel_1]
Name=tunnel_2
Method=PSK
Mode=MAIN
Lifetime=3600
CheckMode=Exact
ResponderOnly=1
AdvancedMode=1
dpd_mode=passive
Src=fw_out
Peer=merignac
State=1
2DNS - Domain Name System permet la resolution des noms.3WINS - Windows Internet Naming Service permet egalement la resolution de noms pour les systemes utilisant
NetBIOS.
- 73 -
IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC
Ce fichier de configuration, lorsqu’il sera parse, donne en sortie un fichier de configuration
racoon, qu’on appellera plus simplement le fichier racoon.conf par la suite.
Les differents champs sont volontairement intuitifs, afin de configurer les tunnels IPSec de la
maniere la plus ergonomique possible :
– La section [Tunnel_1_1_1] decrit l’ensemble des parametres de proposition de phase 1. Elle
comprend notamment le groupe Diffie-Hellman, les algorithmes de chiffrement et d’authen-
tification. Cette section donne une partie de la section proposal du racoon.conf.
– La section [Tunnel_1_2_1] decrit l’ensemble des parametres de Phase 2 et comprend notam-
ment les durees de vie des SAs proposees. Cette section sera parsee en la section sainfo{...}
du racoon.conf.
– Enfin la section [Tunnel_1] permet de configurer l’ensemble des parametres globaux relatifs
au tunnel mis en place. Cela comprend notamment le mode de negociation, la flexibilite de
negociation et les durees de vie proposees.
Les algorithmes de chiffrement et d’authentification sont renseignes dans une table maintenue
a part : l’ajout ou la suppression d’un algorithme se fait ainsi a un seul endroit. Cette facon de
proceder permet de se conformer a des contraintes legislatives en fournissant des versions ne com-
portant que certains algorithmes ou ne rendant possible l’utilisation que de certaines longueurs
de clef. Ceci est particulierement utile lorsqu’il s’agit d’exporter les appliances NETASQ vers des
pays ou l’Europe impose une legislation differente en terme d’algorithmes de chiffrement.
Definition des champs
Lors de la conception des differents champs destines a etre integre, l’accent a ete mis sur le fait
d’avoir une architecture peu gourmande en terme de taille de fichier.
Il existe deja un champ dst dans le fichier de configuration NETASQ : ce champ definit l’extremite
distante de trafic d’un tunnel IPSec. Parralelement, le champ src definit l’extremite locale de trafic
correspondante.
D’autre part, nous avons fait le choix de n’autoriser le Mode Config que dans le cas des road
warriors, c’est a dire dans le cas ou les adresses IP ne sont pas connues a l’avance, c’est a dire dans
le cas de configurations anonymes.
On se rend compte que l’extremite de trafic distante (definit par dst) est en fin de compte
limitee a une seule adresse, celle que l’on souhaite transmettre en Mode Config : les extremites
distantes de tunnel et de trafic sont confondues.
Il est ainsi judicieux d’utiliser le champ dst deja defini en tant que pool d’adresses IP a transmettre
aux differents clients, dans le cas d’une configuration en Mode Config.
Pour recapituler, lorsque l’option Mode Config n’est pas activee, le champ dst se comporte
comme etant l’extremite de trafic distante. Lorsque l’option Mode Config est activee, le champ dst
se comporte comme pool d’adresses IP. Une adresse est prise dans le pool et transmise au client.
- 74 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
L’activation de l’option Mode Config se fait par la definition de quatres champs crees a cette
fin :
cfg dns : Ce champ definit le serveur DNS a transmettre en Mode Config. Ce champ sera parse
en dns4 dans le racoon.conf.
cfg wins : Comme DNS, ce champ definit un serveur WINS a transmettre et sera parse en wins4.
cfg src : Ce champ peut etre positionne a 1 pour l’activer ou 0, valeur par defaut, permet de
transmettre l’extremite locale de trafic au client, stockee dans le champ src. Il correspond a
la partie du reseau interne auquel le client est autorise a acceder. Cette information est au-
jourd’hui embarquee statiquement sur les machines. Dorenavant, elle pourra etre transmises
a la volee, par Mode Config, suivant l’identite du client qui se presente.
cfg dst : Positionnable a 1 ou 0, valeur par defaut. Il s’agit du pool d’adresses IP disponibles
definit sous la forme d’un reseau et masque correspondant. A titre d’exemple, si cfg_dst est
positionne a 1 et le champ dst a 192.168.12.0/24, les road warriors qui se presentent auront
une IP du reseau 192.168.1.0/24 et 254 road warriors pourront negocier au maximum au
meme moment. Les adresses liberees sont ensuite recyclees par racoon.
IV.3 Integration et validation
IV.3.1 Imperatifs d’implementation
Implementer les fonctions dans la librairie afin de parser les quatres champs ne suffit pas pour
generer des configurations correctes. Il a fallu verouiller plusieurs champs afin qu’il ne puissent
interferer avec certaines configurations bancales ou interdites.
Le tout premier verrou a ete celui de l’utilisation du Mode Config uniquement dans le cadre
des road warriors. Rien n’empeche, en effet, a racoon de transmettre des informations en Mode
Config a un hote distant (( classique ))qui soit lui meme une passerelle IPSec. Les tentatives d’util-
isation du Mode Config lorsqu’il ne s’agit pas d’un tunnel anonyme n’aboutiront plus.
Ensuite s’est pose le probleme du champ dst qui peut tres bien etre positionne a any, l’ensemble
du trafic a destination de cet hote est alors du trafic IPSec. Dans le cas du Mode Config (donc le
champ cfg_dst = 1 , le champ dst ne peut valoir any, puisque dans ce cas, on ne definit aucun
pool d’IP dans lequel racoon pourrait piocher. Cette configuration a donc ete interdite egalement :
l’utilisation du Mode Config pour la transmission d’adresses RFC1918 impose la definition du
champ dst.
Les objectifs du cahier des charges ont ete correctement remplis, les imperatifs d’implementation
respectes. Une fois realisee, une maquette a alors ete montee et la validation a pu etre lancee.
IV.3.2 Premiers tests
Une fois la maquette en place, l’on a pu tester les quatres champs, d’abord un par un, puis en
essayant les combinaisons des differents champs :
[Tunnel_3_2_1]
Mode=ESP,TUNNEL
- 75 -
IV.3. INTEGRATION ET VALIDATION
Auth=3/160,4/128
Enc=11/128
Dh=2
Lifetime=3600
Src=Netasq_network
Dst=rw_test
Cfg_dst=1
Cfg_src=1
Cfg_dns=rw_dns
Cfg_wins=rw_wins
keepalive=0
Les quatres champs Mode Config ont ete definis. Au moment de l’activation de la configuration,
le fichier racoon.conf est genere et racoon est demarre. Si le parsing echoue ou s’il n’est pas valide,
racoon ne demarrera pas. On peut verifier le parsing correct :
mode_cfg
{
dns4 10.26.43.169 ;
wins4 10.26.42.247 ;
split_network include 10.2.0.0/16;
pool_size 254 ;
network4 10.2.29.0/24 ;
netmask4 255.255.255.0 ;
}
La section Mode Config est tout a fait correctement cree et les differents champs correctement
positionnes :
– Dns4 et Wins4 correspondent aux serveurs de noms a transmettre.
– Split network include correspond a l’extremite locale de trafic a transmettre, a savoir le
champ src du fichier NETASQ.
– Les trois derniers definissent la maniere dont les road warriors se voient attribuer leur
adresse IP RFC1918. On dispose ici d’un pool d’IPs de 254 adresses disponibles sur le reseau
10.2.29.0/24.
L’action de l’option Mode Config en elle meme aurait pu etre definie par un champ specifique.
Finalement, la presence d’un seul des quatres champs Mode Config suffit a activer l’option Mode
Config.
IV.3.3 Validation et Commit dans le firmware
Une fois les premiers tests passes avec succes, la nouvelle librairie de parsing et le nouveau
module IPSec ont ete testes et valides par l’equipe de Qualification au laboratoire R&D NETASQ.
NETASQ dispose, pour ses tests de validation et de non regression, entre autres, de deux Spirent.
La societe Spirent offre des solutions de tests, validation et monitoring de services reseaux. Sont
- 76 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
notamment testes le routage, la QoS, les protocoles Wireless, IPSec, etc.
Malheureusement, les systemes Spirent ne supportent pas le Mode Config et n’ont donc pas pu
etre mis a contribution lors de la validation du code.
Les tests ont ete realises avec ShrewSoft, non plus avec racoon d’ipsec-tools en face comme
nous l’avions fait lors de nos tests preliminaires, mais en face d’une appliance NETASQ integrant
le Mode Config dans son module IPSec.
L’ensemble des tests se sont deroules avec succes : la recuperation des informations en Mode
Config est correcte, les configurations interdites sont bien ignorees et les erreurs adequates sont
remontees a l’administrateur a chaque fois.
L’ensemble du code a donc pu etre officiellement integre dans le firmware NETASQ. Lors de
la prochaine sortie de version majeure, la version 8.0, dont la sortie officielle est prevue durant le
dernier trimestre de cette annee, les clients disposeront d’une option Mode Config operationnelle.
- 77 -
Conclusion et Bilan
Be the change that you want to see in the world.
— Mahatma Gandhi
La sortie de la prochaine version majeure est prevue pour le dernier trimestre 2008. Les pre-
miers retours sur l’utilisation du Mode Configuration d’IPSec devraient arriver dans le courant du
premier trimestre 2009. Pourtant, lors de mon arrivee a NETASQ rien ne predisait que le Mode
Configuration puisse etre effectivement integre dans un delai aussi court, delai comprenant la con-
ception, le developpement et surtout la validation a travers une batterie de tests de non-regression
et de performances, autant sur la partie ipsec-tools et projet OpenSource que sur la partie
firmware NETASQ.
Le stage sur IPSec et sur le Mode Configuration en particulier avait pour objectif de debroussailler
l’implementation de cette extension dans ipsec-tools avant tout : evaluer l’etat de l’implementation
actuelle du Mode Configuration a travers des tests sur des maquettes montees pour l’occasion,
evaluer les performances et confirmer ou infirmer la stabilite de racoon confronte a des configura-
tions reseaux complexes et pas forcement valides du point de vue des draft et des RFCs.
L’ensemble des tests effectues sur le Mode Configuration ont ete concluants, que racoon soit
en mode serveur ou en mode client : l’ensemble des informations sont transmises correctement a
la volee, juste apres l’etablissement de la ISAKMP-SA4.
Apres avoir valide de nombreuses configurations, j’ai pu mettre l’accent sur l’etude du produit en
lui meme, l’appliance NETASQ et son firmware : les differents modules en general, le processus
de ports de FreeBSD, l’ASQ, coeur du firmware, le fonctionnement par fichiers de configurations
NETASQ et leur librairies de parsing, la communication entre la suite graphique et le firewall, etc.
La prise en main de l’appliance NETASQ et l’etude du firmware ont ete facilitees par les certifi-
cations NETASQ Certified Administrator - NCA et NETASQ Certified Expert - NCE
que j’ai eu l’honneur de pouvoir passer.
4Sous reserve que l’authentification XAuth soit desactivee, si ce n’est pas le cas, les informations sont transmises
juste apres la validation de l’authentification en XAuth.
CHAPITRE IV. INTEGRATION DU MODE CONFIG
Cette etape a marque le debut du travail sur le firmware : integrer le Mode Configuration en
tenant compte de toutes les contraintes existantes. Ces contraintes ont ete de plusieurs ordres.
– Prendre en main le code des librairies de parsing deja existant.
– Tenir compte du fichier de configuration existant et l’etendre dans la mesure de l’acceptable :
pas d’ajout de champs inutiles, pas de configuration supplementaire non necessaire pour le
client.
– Comportement par defaut correct si le Mode Configuration n’est pas active. Il s’agit de
l’implementer comme une option a part entiere, pour que par defaut, le module IPSec se
comporte comme dans les versions precedentes.
– Tenir compte des contraintes indirectes, notamment en terme de Suite Graphique NETASQ :
la lecture des champs par defaut ne doit pas etre perturbee par l’apparition des nouveaux
champs que la suite graphique ne connait pas.
La prise en compte de l’ensemble de ces contraintes a ete sujette a plusieurs discussions fructueuses,
et a finalement mene a la creation des quatres champs Mode Configuration implementes dans le
firmware.
Une fois le Mode Configuration implemente, valide et operationnel, j’ai pu me concentrer sur
l’amelioration de l’implementation du Mode Configuration d’ipsec-tools par l’etude d’un nou-
veau champ dans racoon : le champ CLIENTADDR. Le CLIENTADDR permet de matcher l’identite de
l’hote distant suivant qu’il s’agisse de l’adresse IP de l’hote ou de l’adresse IP RFC1918 definie
dans la configuration Mode Configuration, si celui ci est active. Le CLIENTADDR peut etre utile pour
restreindre la generation de politiques de securite lors que racoon agit comme une passerelle pour
les clients mobiles.
Il se trouve que Matthiew Grooms avait deja realise une partie de l’implementation sur la branche
principale du projet ipsec-tools. J’ai porte le champ de la branche principale vers la version
stable d’ipsec-tools actuelle, 0.7.1.
Tout au long des six mois passes a NETASQ, plusieurs idees recues de l’etudiant terminant son
cursus ont ete bousculees, a juste titre et tant mieux. J’ai, avant tout, pu constater qu’il ne suffit
pas d’avoir une conception parfaite une bonne implementation pour qu’elle puisse etre integree
dans un firmware deja existant et soumis a un certains nombres de contraintes.
- 79 -
IV.3. INTEGRATION ET VALIDATION
Deja fascine par la securite a l’universite, j’ai pu porter un regard different sur ce monde qui
parait toujours renferme et reserve vu de l’exterieur. J’ai ainsi pu suivre l’evolution des failles
OpenSSL et DNS du point de vue d’une societe specialisee en securite informatique ou il fallait
toujours etre sur le qui-vive, suivre les differents PoC5 ou encore etudier les differents articles
et impressions sur de grandes conferences en securite informatique, qu’elles soient francophones
comme le SSTIC, ou internationales comme BlackHat ou DefCon.
Je citerai ici Ferdinand Foch - (( Il n’y a pas d’hommes cultives, il n’y a que des hommes qui se
cultivent ))- tout a fait approprie lorsqu’il s’agit de securite informatique ou de cryptologie.
Pendant toute cette periode, j’ai eu l’honneur d’etre entoure d’ingenieurs extremement competents
dans leur domaine, me permettant d’avoir les meilleurs conseils possibles de la part de la part de
personnes toujours disponibles et a l’ecoute. Je porte aujourd’hui un regard tout a fait different sur
un projet OpenSource, sur l’utilisation subtile des differentes licences (GPL, BSD, Libre, Open-
Source...). J’ai egalement pu ameliorer mon niveau en developpement de facon consequente, en
etant confronte a des styles de programmation differents tout en respectant la charte de program-
mation de NETASQ. D’autre part, j’ai pu remarquer l’aide apportee par la communeaute lorsqu’il
s’agit d’auditer du code source ou de comprendre une RFC ou se chevauchent des subtilites, souvent
anglaises, de termes comme MAY , MIGHT ou SHOULD ne facilitant pas toujours l’integration
de telle ou telle fonctionalite.
Enfin, le plus important a mes yeux concerne le regard critique que j’ai pu adopter face a la
formation que j’ai recue a l’universite. Cette experience m’a non seulement permis d’approndir
certains points cles, mais egalement de poser des bases solides pour commencer une carriere qui,
je l’espere, me permettra d’etre acteur plutot que spectateur dans le monde de la securite infor-
matique.
5PoC : Proof Of Concept
- 80 -
Annexe A : Protocole AH et ESP approfondis
En-tete IP
Les protocoles AH et ESP reposant sur sur IP, une description sommaire des champs d’IP est
donnee dans le tableau ??.
IP est un des protocoles reseau les plus repandu aujourd’hui, dans sa version IPv4 qui commence
a s’essoufler du manque d’adresses disponibles et dans version IPv6 deja massivement deploye au
Japon. Il apporte l’adressage en couche 3 permettant de router les paquets.
Les champs principaux de l’entete IP sont definis de la maniere suivante :
ver : Il s’agit de la version du protocole IP utilise (4 ou 6), code sur 4 bits. Place en tete, il permet
de verifier le format correct du paquet et de le detruire de suite en cas de version inconnue.
IHL : Pour Iinternet Header Lengh, IHL, code sur 4 bits, represente la longueur de l’en-tete IP
en mots de 32 bits. Sa valeur peut varier de 5 a 15 (donc de 15 ∗ 32 = 60octets max) suivant
les options IP et est a 5 (20 octets) par defaut.
TOS : Pour Type Of Service, sur 8 bits, permet de controler la QoS directement au niveau OSI
3. TOS regroupe des donnees comme la priorite, le delai ou encore le cout. TOS est l’unique
champ recupere par ESP pour l’encapsulation ESP-Tunnel.
pkt-len : Il s’agit de la longueur totale du paquet IP, code sur 16 bits, en-tete et donnees com-
prises. Exprimee en octets, la longueur totale maximale est donc de 216 = 65535octets.
ID : Code sur 16 bits, le champ Identification permet de reconstituer les differents fragments. Les
en-tetes IP des fragments sont les memes a l’exception de la longueur et du checksum.
Flags : Code sur 3 bits, ces flags permettent de connaıtre l’etat actuel de la fragmentation. Le
premier bit est a 1 (Reserved), le deuxieme autorise ou non la fragmentation (DF Don′t
Fragment) et le dernier indique s’il existe d’autres fragments (MF More Fragments).
frag offset : Code sur 13 bits, indique a quel position se trouve le fragment par rapport au pre-
mier. Le premier possede donc un champ frag offset a 0.
IV.3. INTEGRATION ET VALIDATION
TTL : Le champ Time TO Live indique la duree de vie maximale du paquet. Lorsqu’il baisse a
0, le paquet est detruit. A chaque passage dans un routeur, ce champ sera decremente. Ceci
permet d’eviter les boucles infinies dans la propagation des trames.
proto : Code sur 8 bits, il represente le champ Protocol. Les plus repandus sont -01-ICMP, -06-TCP
et -17- UDP. Les numeros de protocoles sont attribues par l’IANA - Internet Assigned Number
Security.
Checksum : Code sur 16 bits, la somme de controle permet de verifier la validite du paquet (et
uniquement celle du paquet et non pas des donnees qu’il contient : deux trames IP ayant les
meme champs auront la meme somme de controle).
Src IP address : Represente l’IP source codee sur 32 bits.
Dst IP address : Represente l’IP de destination codee sur 32 bits egalement.
IP Options : Code de 0 a 40 octets, ce champ permet de passer certaines options a IP, comme
la Classe ou le Numero permettant de lister les options disponibles.
ver IHL TOS pkt-len
ID flags frag offset
TTL proto = TCP header checksum
Src IP address
Dst IP address
Options IP (si presentes)
TCP Header (proto=6)
TCP Payload
32 bits
: Couvert par le checksum
Fig. IV.2 – Paquet IPv4 Generique
Ces champs nous serviront, par exemple, a definir la maniere dont ESP gere les priorites de
communications (par la recuperation du TOS) ou encore a comprendre pourquoi il etait tres dif-
ficile de deployer IPSec a travers des equipements NAT, avant le developpement de l’extentions
NAT − Traversal.
- 82 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
AH - Authentication Header
AH est uniquement utilise pour de l’authentification – pas de chiffrement –. Il permet de valider
l’identite de l’hote distant avec lequel on communique afin de se premunir des attaques MITM. Il
detecte ainsi toute alteration des donnees et offre une protection forte contre le rejeu de paquets.
En-tete AH
L’Authentification est faite a partir d’une empreinte cryptographique d’authentification base
sur l’ensemble des champs non modifiables du paquet IP. Cela exclut, par exemple, le champ TTL
est decremente, ou encore le checksum qui est recalcule a chaque passage dans un routeur.
Cette empreinte est alors apose au paquet avant que celui ci ne soit envoye. Lors de la reception du
paquet, l’hote distant calcule a son tour une empreinte du paquet fraıchement recu et le compare
avec celui contenu dedans afin de le valider.
next hdr AH lengh Reserved
SPI (Security Parameters Index)
Sequence Number
Authentication Data
hash MD5 ou SHA-1
Fig. IV.3 – Champ de l’en-tete AH
Champs de l’en-tete AH :
Next Header : Code sur un octet, il contient le numero de protocol de l’en-tete suivante, donc
le numero de protocole des donnees que le paquet transporte. Ce champ permet de lier les
differentes en-tetes.
AH lengh : Code sur un octet egalement, il contient la taille de l’en-tete AH en mots de 32 bits,
otee de 2 (ceci n’inclue pas les donnees mais l’en-tete uniquement). Les 64 bits sont enleves
afin d’etre coherent avec la maniere dont IPv6 calcule la taille de l’en-tete AH. IPSec dans
IPv6 n’est pas aborde dans ce rapport, on peut en trouver une description a ??.
Reserved : est comme son nom l’indique, un champ reserve pour un usage futur, code sur 16 bits.
- 83 -
IV.3. INTEGRATION ET VALIDATION
SPI : Le Security Parameter Index est un identifiant permettant de trouver a quel politique le
paquet doit-il etre soumis, et donc a quel SA dans la SAD il correspond. Le SPI est code sur
32 bits et sera developpe plus en details dans la section ??.
Sequence Number : Code sur 32 bits, il represente un compteur initialise a 0 lorsqu’une SA en-
tre deux hotes est etablie. Il est incremente pour chaque datagramme correspondant a cette
SA. Il permet d’identifier chaque paquet de maniere unique et ainsi de se proteger contre des
attaques par rejeu.
Authentication Data : Contient l’empreinte calculee par le protocole AH.
Comme decrit precedemment, IPSec peut fonctionner suivant le mode Tunnel ou Transport.
AH n’est donc pas calcule de la meme maniere.
AH en mode Tranport
En mode Transport, l’en-tete AH est inseree entre l’en-tete du protocole de Transport (TCP le
plus souvent) et l’en-tete IP (cf Fig. IV.4).
Comme l’en-tete AH vient s’intercaler entre les en-tete TCP et IP, les champs proto sont suc-
cessivement modifies :
Le champ proto du paquet IP, a l’origine en TCP, est modifie au profit de AH. AH, quant a lui,
garde dans son champ next une trace du protocole Transport utilise, a savoir TCP, ceci permet de
faire le lien entre les en-tetes.
AH n’offrant pas de chiffrement, un attaquant potentiel aura acces non seulement a l’en-tete,
mais egalement aux donnees, bien qu’il ne puisse pas alterer le paquet ou le rejouer.
Une fois que le paquet aura ete valide a la reception, il sera decapsule, l’en-tete AH enleve, les
champs remis a jour et le paquet sera passe a l’application concernee.
AH en mode Tunnel
En mode Tunnel, le paquet IP est entierement reencapsule dans un autre paquet IP avant d’etre
envoye.
Une en-tete AH est aposee au paquet, comme en mode Transport, ce qui permet de valider
l’authenticite du paquet a la reception et de se premunir de l’alteration des paquets sur le chemin.
Mais contrairement au mode AH-Transport, AH-Tunnel encapsule le paquet IP dans sa totalite,
c’est a dire l’en-tete IP et le payload. Les addresses reelles de l’emetteur et du destinataire sont
donc masquees (cf Fig. IV.5), seules les adresses des deux passerelles formant les deux bouts du
tunnel sont visibles.
- 84 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver len TOS pkt-len
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver len TOS pkt-len
nxt=TCP AH len Reserved
S P I
Seq. Number
Authentication Data
IPH
dr
TC
PH
dr+
Plo
adA
HH
dr
TC
PH
dr+
Plo
ad
IPH
drCouvert par AH
Fig. IV.4 – Hash AH en mode Transport
- 85 -
IV.3. INTEGRATION ET VALIDATION
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver len TOS pkt-len
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Prto=AH Checksum
ID flgs offset
ver len TOS pkt-len
nxt=IP AH len Reserved
S P I
Seq. Number
Authentication Data
IPH
dr
TC
PH
dr+
Plo
adA
HH
dr
TC
PH
dr+
IPH
dr+
Plo
ad
IPH
drCouvert par AH
Dst IP Address
Src IP Address
Prto=TCP Checksum
flgs offset
TOS pkt-lenver len
ID
TTL
Fig. IV.5 – Hash AH en mode Tunnel
- 86 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
Les verifications du paquet arrivant a destination sont les memes qu’en mode Transport : l’
Integrity Check Value est extrait d’une part, calcule sur les differents champs du paquet recu
d’autre part, puis compare. Lorsque le paquet est valide, il est decapsule et delivre a l’application
en attente, ou route vers le sous reseau de destination suivant l’IP reelle. A partir de ce moment,
il s’agit d’un paquet IP normal.
La difference entre le Mode Transport et le Mode Tunnel dans IPSec n’est pas explicite puisqu’il
n’existe pas de champ Mode a proprement parler. Elle se fait au niveau du champ Next Hdr :
lorsqu’il vaut IP, il s’agit du Mode Tunnel puisqu’il encapsule entierement un paquet IP. A l’in-
verse, lorsque ce champ est positionne a un autre protocole de transport comme TCP, UDP ou ICMP,
il s’agit la du Mode Transport qui securise le traffic de bout en bout.
ESP - Encapsulating Security Payload
En-tete ESP
ESP peut etre considere comme le coeur de la suite de protocoles IPSec. Il permet d’avoir un
chiffrement de toute les donnees presentes dans le paquet et eventuellement de les authentifier.
ESP est constitue d’un header (cf Fig. IV.6) et d’un trailer et peut etre utilise en mode Tunnel
comme en mode Transport tout comme AH.
Le chiffrement des donnees n’est lie a aucun algorithme cryptographique en particulier, comme
explique dans la presentation d’IPSec ??. Les plus couramment utilises sont AES, DES, TripleDES
et Blowfish. Les parametres de chiffrement et la cle utilisee sont dynamiquement negocies par un
demon IKE (racoon d’ipsec-tools en locurrence dans le cadre de notre cahier des charges) et
stockes dans une Security Association.
Les champs d’un paquet ESP sont principalement :
Payload chiffre : Correspond aux donnees chiffrees, de taille variable.
Next Header : utilise comme dans AH, permet de connaıtre le type de payload du paquet, a
savoir IP, TCP, UDP, etc.
Padding : il s’agit de bourrage permettant l’utilisation d’algorithmes cryptographiques par blocs
(comme AES en mode cbc par exemple).
Pad len : Taille du bourrage.
D’autre part, ESP fournit une authentification optionnelle. Lorsqu’elle est activee, l’empreinte
d’authentification vient se greffer apres le trailer ESP et utilise les meme mecanismes que dans AH
a ceci pres que l’authentification ESP est basee uniquement sur l’en-tete ESP et le payload, et non
pas sur le paquet IP en entier.
De l’exterieur, un attaquant ne peut determiner le contenu d’un paquet ESP, ni meme savoir
s’il contient une empreinte d’authentification ou non. Neanmoins, lors de l’encapsulation ESP, le
- 87 -
IV.3. INTEGRATION ET VALIDATION
S P ISequence Number
Encrypted Payload
paddingpad len nxt hdr
S P ISequence Number
Encrypted Payload
paddingpad len nxt hdr
Authentication Data
ES
PT
rlA
uth
ES
PH
dr
ES
PH
drE
SP
Trl
Chiffré
Fig. IV.6 – En-tete ESP avec (a d.) et sans (a g.) Authentification
champ ToS du paquet IP est recupere a partir du paquet original. Ce champ, comme nous l’avons
vu, sert entre autres, a definir le champ QoS utilise dans les transmissions de type VoIP par ex-
emple pour avoir un ordre de priorite important.
ESP en mode Transport
ESP en mode Transport (cf Fig. IV.7) fonctionne a peu de choses pres comme AH en mode
Transport.
Destine a securiser les transferts de donnees entre deux hotes A et B, ESP-Transport encapsule
uniquement le payload (donnees utiles). Comme pour AH, les adresses source et destination sont
donc visibles dans le paquet transmis.
ESP en mode Tunnel
Le mode ESP-Tunnel (cf Fig. IV.8) encapsule entierement le paquet IP original dans un autre
paquet IP. C’est ce qui se rapproche le plus d’un tunnel VPN au sens ou la plupart des utilisateurs
l’entendent : un tunnel chiffre parlequel ils peuvent faire transiter des flux sensibles de maniere
securisee afin de contacter un reseau distant.
C’est le mode le plus souvent utilise lorsqu’il s’agit de monter une passerelle IPSec.
- 88 -
CHAPITRE IV. INTEGRATION DU MODE CONFIG
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver len TOS pkt-len
TCP Payload
Dst IP Address
Src IP Address
TTL Checksum
ID flgs offset
ver len TOS pkt-len
S P I
Seq. Number
IPH
drT
CP
Hdr
+P
load
IPH
dr
Chiffré
Authentication Data
padlen nxthdr
padding
nxt=ESP
Authentifié
Fig. IV.7 – Paquet ESP en Mode Transport
- 89 -
IV.3. INTEGRATION ET VALIDATION
TCP Payload
TCP Header
Dst IP Address
Src IP Address
TTL Proto Checksum
ID flgs offset
ver len TOS pkt-len
TCP Payload
Dst IP Address
Src IP Address
TTL Checksum
ID flgs offset
ver len TOS pkt-len
S P I
Seq. Number
IPH
drT
CP
Hdr
+P
load
IPH
dr
Chiffré
Authentication Data
padlen nxthdr
padding
nxt=ESP
Authentifié
IP Hdr
Fig. IV.8 – Paquet ESP en Mode Tunnel
- 90 -
Annexe B : Echange Diffie-Hellman
Presentation
L’echange de cles Diffie-Hellman, ou pour etre plus exact, la negociation de cles par Diffie-
Hellman a ete developpe par Diffie et Hellman en 1976, et publie dans le (( New Directions in
Cryptography )). Ce protocole permet a deux utilisateurs, que nous appellerons traditionnellement
Alice et Bob, de s’echanger un secret a travers un canal non-securise.
Ce protocole est utilise dans des domaines varies, et intervient notamment dans la negociation
de cles de sessions IPSec.
Principe
Le protocole met en place deux parametres publics : p, un nombre premier, et g, un generateur,
inferieur a p defini comme suit :
Pour tout entier compris entre 1 et p− 1 inclus, il existe une puissance k de g telle que n = gk
mod p.
Supposons qu’Alice et Bob souhaitent echanger un secret par Diffie-Hellman, ils procedent alors
comme suit (cf. IV.9) (toutes les operations sont modulo p) :
– Alice choisit un nombre aleatoire a et Bob choisit un nombre aleatoire b.
– Alice calcule alors x = ga et Bob calcule y = gb.
– Alice envoie x a Bob et Bob envoie y a Alice.
– Alice calcule alors (gb)a = gab.
– Bob calcule (ga)b = gab.
– Alice et Bob se retrouvent tout deux avec gab.
Le secret partage par Alice et Bob est alors k = gab.