L'extension ESP (Encapsulating Security Payload) décrite dans le RFC 2406 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur et d'encapsuler ces informations dans l'en-tête de confidentialité. Cela nécessite bien entendu l'existence d'une association de sécurité précisant entre autres le(s) algorithme(s) de chiffrement, la (les) clé(s) et un indice de paramètres de sécurité.

Deux modes de protection

L'extension ESP est composée d'un en-tête ESP, d'une queue ESP et d'un authentificateur ESP. Suivant le mode de protection sélectionné, l'étendue des champs protégés diffère :

• En mode transport, seules les données de niveau transport du paquet IP (de type TCP, UDP, ICMP) sont protégées. Plus précisément, le chiffrement porte sur les données et sur la queue ESP avec la possibilité de porter sur l'extension destination à condition que celle-ci soit placée dans l'extension ESP (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). La protection en intégrité/authentification porte sur toute l'extension ESP excepté l'authentificateur placé dans le champ authentificateur. Elle assure ainsi la protection des données de niveau transport du paquet IP. L'extension ESP est insérée dans le paquet IP juste après l'en-tête du paquet IP et les extensions avec la possibilité d'avoir l'extension destination placée juste avant l'extension ESP ou encapsulée dans l'extension ESP en première position.

• En mode tunnel, la protection porte sur tout le paquet IP original. C'est-à-dire, le paquet IP original est chiffré avant d'être encapsulé dans l'extension ESP. Cette extension est alors placée dans un nouveau paquet IP dont les en-têtes IP sont en clair (non chiffrés) pour permettre au réseau IP de correctement acheminer le paquet (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). Il s'agit du classique chiffrement des artères. La protection en intégrité/authentification porte sur l'extension ESP (comprenant le paquet IP original) excepté l'authentificateur ESP. L'extension ESP rend le service de confidentialité du flux de façon limitée en ce sens que ce service n'est rendu qu'en mode tunnel et ne porte que sur la confidentialité des adresses IP. En effet, l'extension ESP en mode tunnel réalise le chiffrement de l'intégralité des paquets IP originaux, y compris leurs adresses IP. De ce fait, si les équipements qui mettent en oeuvre IPsec ne sont pas l'émetteur et le destinataire final des paquets, leurs adresses masqueront celles de ces derniers. Un intrus placé en écoute sur le réseau au niveau d'un tunnel IP (entre les passerelles de sécurité) ne pourra pas dans ce cas là connaître les adresses des stations en communication.

Contenu de l'extension ESP

L'extension ESP est composée des champs suivants (cf. figure Format de l'extension d'ESP) :

• Le champ indice de paramètres de sécurité (SPI) combiné à l'adresse du (des) destinataire(s), identifie l'association de sécurité utilisée pour construire cette extension.
• Le numéro de séquence permet de détecter les rejeux de paquet IP.
• Le champ charge utile peut contenir soit un paquet IP complet (en-tête IP + extensions + données de niveau transport), soit l'extension destination suivie de données de niveau transport, soit des données de niveau transport uniquement.

Ce champ peut également contenir des données de synchronisation selon les algorithmes de chiffrement utilisés.

• Le champ bourrage permet d'ajouter des bits de bourrage pour aligner les données à chiffrer sur un nombre d'octets dépendant de l'algorithme de chiffrement utilisé. Le champ bourrage est optionnel. Sa présence est précisée par l'association de sécurité utilisée.
• Le champ longueur du bourrage indique la longueur en octets du champ bourrage.
• Le champ en-tête suivant identifie le type de données contenues dans le premier champ du champ charge utile.
• Le champ authentificateur est optionnel et sa présence dépend de l'association de sécurité utilisée (SPI + adresse(s) de destination + ESP). Il est calculé à l'aide de l'algorithme et de la clé correspondant à l'association de sécurité.

Notez que le champ en-tête ESP inclut l'indice des paramètres de sécurité et le numéro de séquence, tandis que le champ queue ESP comprend les champs bourrage, longueur du bourrage et en-tête suivant.

La détection de rejeu est optionnelle car lors de la génération d'une extension ESP, il est nécessaire de préciser un numéro de séquence adéquat dans le champ numéro de séquence tandis qu'à l'extraction de l'extension ESP, la vérification du numéro de séquence n'est pas obligatoire.

Le RFC 2406 précise les algorithmes de chiffrement que doivent obligatoirement implémenter les équipements IPsec pour rendre le service de confidentialité. Si dans le RFC 2406, seul l'algorithme DES dans le mode d'utilisation CBC (Cipher Block Chaining) est mentionné obligatoire, au fil du temps, l'IETF a fait évoluer la liste en ajoutant en 1999 le triple DES et plus récemment l'AES (Advanced Encryption Stantard). Quant à la génération de l'authentificateur, les mêmes mécanismes que pour l'extension AH sont préconisés par défaut, à savoir HMAC- MD5, HMAC-SHA-1.

Le chiffrement des données dans l'extension ESP n'est pas obligatoire. Dans ce cas, seuls les services d'intégrité/authentification sont rendus, mais ils ne portent que sur l'extension ESP, contrairement à l'extension AH qui porte sur tout le paquet IP excepté certains champs "modifiables" par le réseau. Dans certains cas, suivant le niveau de protection en intégrité souhaité, il peut être nécessaire d'utiliser les deux extensions AH et ESP dans le même paquet, l'extension ESP ne rendant alors que le service de confidentialité.

L'extension ESP souffre tout comme l'extension AH d'incompatibilités avec le mécanisme de traduction d'adresse, et ce, bien que l'authentification réalisée ne porte que sur le contenu de l'en-tête ESP ; cependant contrairement à AH, il existe une solution palliative présentée ci-dessous. Le problème d'incompatibilité de ESP en mode transport avec la traduction d'adresses seules est lié aux protocoles TCP et UDP qui définissent un champ de contrôle dont le calcul fait intervenir les adresses IP ; ainsi la modification d'une adresse suppose la modification de ce contrôle, ce qui n'est pas réalisable avec ESP en mode transport ; en effet, soit le chiffrement est activé dans ESP et le champ de contrôle est inaccessible car chiffré ; soit les services d'authentification/intégrité sont activés, et la modification du champ de contrôle conduira à la détection d'un problème d'intégrité du paquet et au rejet du paquet par l'équipement IPsec récepteur.

Le fait de traduire en plus des adresses les numéros de port ajoute encore davantage d'incompatibilités. Pour ESP, c'est l'encapsulation elle-même qui pose problème car elle rend les numéros de port soit inaccessibles (chiffrement activé), soit interdits de modification (car protégés en intégrité). Enfin, noter que pour ESP en mode tunnel, les numéros de port sont inexistants.

Une solution est aujourd'hui définie pour pallier à cette incompatibilité. Elle consiste à n'utiliser que le protocole ESP (mode transport ou tunnel) et à réaliser une encapsulation UDP supplémentaire. Plus précisément, un tunnel UDP doit être établi entre les deux équipements IPsec ; les données encapsulées dans ce tunnel sont protégées par le protocole ESP. Ainsi, la traduction des adresses/numéros de port donne lieu à la modification du champ de contrôle de UDP sans porter atteinte à l'intégrité de l'en-tête ESP et la traduction de numéros de port est faite sur les numéros de port UDP qui sont accessibles ici. Afin de détecter la traversée d'un équipement de traduction d'adresse et n'activer l'encapsulation UDP que lorsque nécessaire, les passerelles IPsec peuvent faire appel au mécanisme de NAT-traversal [RFC 3947] [RFC 3948] lors de l'établissement dynamique d'une association de sécurité.

Évolutions prévues

La prochaine version de l'extension ESP intègre les mêmes évolutions que AH concernant l'identification des associations de sécurité et les numéros de séquence. Tout comme pour AH, il est prévu que la liste des algorithmes obligatoires soit précisée dans un document indépendant et tenu à jour.

Il est également prévu de permettre l'usage d'un plus grand nombre d'algorithmes, comme les algorithmes dits "combinés" qui permettent simultanément de chiffrer et de protéger en intégrité. Ces algorithmes combinés nécessitent un aménagement du format de ESP. En effet, certains d'entre eux n'assurent l'intégrité que sur les données chiffrées ; d'autres peuvent étendre la protection en intégrité sur des champs extérieurs. Compte tenu que l'indice de paramètres de sécurité et le numéro de séquence ne sont pas chiffrés mais nécessitent d'être protégés en intégrité, il peut être nécessaire de les faire apparaître deux fois dans le paquet : dans l'en-tête ESP et dans la charge utile. De façon à rendre l'extension ESP ouverte à un grand nombre d'algorithmes, le champ authentificateur n'est plus tenu de tenir sur un nombre entier de 32 mots.

Afin de se prémunir des analyses statistiques portant sur les flots de données chiffrés, la prochaine version de la RFC 2406 prévoit d'assurer le service de confidentialité du flux. La technique utilisée consiste à introduire des données de bourrage (sans signification) dans les paquets IP. À cette fin, un nouveau champ optionnel - Traffic Flow Confidentiality - est défini et se trouve positionner dans la charge utile.

Enfin, trois configurations de ESP sont distinguées suivant que sont rendus le service d'intégrité seul, le service de confidentialité seul ou simultanément les services d'intégrité et de confidentialité. Cette distinction permet d'optimiser le traitement des paquets, et de permettre l'usage d'algorithmes combinés. Noter que le service de confidentialité est optionnel et peut donc ne pas être implémenté dans ESP.