III.2.2.2 ESP (Encapsulating Security Payload)
ESP est le second protocole de protection des données
qui fait partie de la spécification IPSec. Il est détaillé
dans la RFC 2406 [RF406]. Contrairement à AH, ESP ne protège pas
les en-têtes des datagrammes IP utilisés pour transmettre les
communications. Seules les données sont protégées. En mode
transport, il assure :
v' La confidentialité des données (optionnelle) :
la partie donnée des datagrammes IP
transmis est chiffrée. L'authentification (optionnelle,
mais obligatoire en l'absence de confidentialité) : la partie
donnée des datagrammes IP reçus ne peut avoir été
émise que par l'hôte avec lequel a lieu l'échange IPSec,
qui ne peut s'authentifier avec succès que s'il connaît la
clé associée à la communication ESP. Il est
également
important de savoir que l'absence d'authentification nuit
à la confidentialité en la rendant plus vulnérable
à certaines attaques actives.
v' L'unicité (optionnelle, à la discrétion
du récepteur).
v' L'intégrité : les données n'ont pas
été modifiées depuis leur émission.
En mode tunnel, ces garanties s'appliquent aux données
du datagramme dans lequel est encapsulé le trafic utile, donc à
la totalité (en-têtes et options inclus) du datagramme
encapsulé. Dans ce mode, deux avantages supplémentaires
apparaissent:
v' Une confidentialité limitée des flux de
données (en mode tunnel uniquement, lorsque
la confidentialité est assurée) : un attaquant
capable d'observer les données transitant par un lien n'est pas à
même de déterminer quel volume de données est
transféré entre deux hôtes particuliers. Par exemple, si la
communication entre deux sous réseaux est chiffrée à
l'aide d'un tunnel ESP, le volume total de données
échangées entre ces deux sous réseaux est calculable par
cet attaquant, mais pas la répartition de ce volume entre les
différents systèmes de ces sous réseaux.
v' La confidentialité des données, si elle est
demandée, s'entend à l'ensemble des
champs, y compris les en-têtes du datagramme IP
encapsulé dans le datagramme protégé par ESP.
Enfin, ESP et AH ne spécifient pas d'algorithmes de
signature et/ou de chiffrement particuliers. Ceux-ci sont décrits
séparément.
Une implémentation conforme au RFC 2402 (AH) est tenue
de supporter les algorithmes MD5 [RFC1321] et SHA-1[SHA] tandis qu'une
implémentation conforme au RFC 2406 (ESP) est tenue de supporter
l'algorithme de chiffrement DES [DES] en mode CBC et les signatures à
l'aide des fonctions de hachage MD5 et SHA-1.
Pour mieux comprendre le fonctionnement d'AH et ESP, consultons
le Tableau III.1 qui résume la fonctionnalité
des modes tunnel et transport par rapport à AH ET ESP.
Tableau III- 1: Fonctionnalité des
modes tunnel et transport
|
Mode transport
|
Mode tunnel
|
|
AH
|
Authentifie l'information utile IP et
certaines portions de
l'en-tête IP et
les en-têtes d'extension IPv6
|
Authentifie le paquet IP tout entier
plus certaines portions
de l'en-tête IP et
les en-têtes d'extension IPv6 externes.
|
|
ESP
|
Chiffre l'information utile IP et
tout en-tête
d'extension IPv6
suivant l'entête ESP
|
Chiffre le paquet IP tout entier
|
|
ESP AVEC
AUTHENTICA
TION
|
Chiffre l'information utile IP et tout
en-tête
d'extension IPv6
suivant l'en-tête ESP.
Authentifie l'information
et
utilise IP mais pas l'en-tête IP
|
Chiffre le paquet IP tout entier.
Authentifie le paquet
IP.
|
| 
