3.3. Outbound Packet Processing (Traitement des paquets sortants)

En mode transport, l'expéditeur encapsule les informations du protocole de couche suivante entre les champs d'en-tête ESP et de trailer ESP, et conserve l'en-tête IP spécifié (et tous les en-têtes d'extension IP dans le contexte IPv6). En mode tunnel, les en-têtes/extensions IP externes et internes peuvent être interdépendants de diverses manières. La construction de l'en-tête/des extensions IP externes pendant le processus d'encapsulation est décrite dans le document d'architecture de sécurité.

3.3.1. Security Association Lookup (Recherche d'association de sécurité)

ESP est appliqué à un paquet sortant uniquement après qu'une implémentation IPsec détermine que le paquet est associé à une SA qui nécessite un traitement ESP. Le processus de détermination du traitement IPsec, le cas échéant, appliqué au trafic sortant est décrit dans le document d'architecture de sécurité.

3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation (Chiffrement de paquet et calcul ICV)

Dans cette section, nous parlons en termes de chiffrement toujours appliqué en raison des implications de formatage. Cela est fait en comprenant que «aucune confidentialité» est offerte en utilisant l'algorithme de chiffrement NULL (RFC 2410). Il existe plusieurs options algorithmiques.

3.3.2.1. Separate Confidentiality and Integrity Algorithms (Algorithmes de confidentialité et d'intégrité séparés)

Si des algorithmes de confidentialité et d'intégrité séparés sont utilisés, l'expéditeur procède comme suit:

Encapsuler (dans le champ ESP Payload):
- pour le mode transport -- uniquement les informations du protocole de couche suivante d'origine.
- pour le mode tunnel -- l'intégralité du datagramme IP d'origine.
Ajouter tout rembourrage nécessaire -- Rembourrage TFC optionnel et rembourrage (de chiffrement)
Chiffrer le résultat en utilisant la clé, l'algorithme de chiffrement et le mode d'algorithme spécifiés pour la SA et en utilisant toutes les données de synchronisation cryptographique requises.
- Si des données de synchronisation cryptographique explicites, par exemple un IV, sont indiquées, elles sont entrées dans l'algorithme de chiffrement selon la spécification de l'algorithme et placées dans le champ Payload.
- Si des données de synchronisation cryptographique implicites sont utilisées, elles sont construites et entrées dans l'algorithme de chiffrement selon la spécification de l'algorithme.
- Si l'intégrité est sélectionnée, le chiffrement est effectué en premier, avant l'application de l'algorithme d'intégrité, et le chiffrement n'englobe pas le champ ICV. Cet ordre de traitement facilite la détection et le rejet rapides des paquets rejoués ou faux par le récepteur, avant de déchiffrer le paquet, réduisant ainsi potentiellement l'impact des attaques par déni de service (DoS). Il permet également la possibilité de traitement parallèle des paquets au niveau du récepteur, c'est-à-dire que le déchiffrement peut avoir lieu en parallèle avec la vérification de l'intégrité. Notez que comme l'ICV n'est pas protégé par le chiffrement, un algorithme d'intégrité avec clé doit être utilisé pour calculer l'ICV.
Calculer l'ICV sur le paquet ESP moins le champ ICV. Ainsi, le calcul de l'ICV englobe le SPI, le numéro de séquence, les données de charge utile, le rembourrage (s'il est présent), la longueur de rembourrage et l'en-tête suivant. (Notez que les 4 derniers champs seront sous forme de texte chiffré, car le chiffrement est effectué en premier.) Si l'option ESN est activée pour la SA, les 32 bits de poids fort du numéro de séquence sont ajoutés après le champ Next Header aux fins de ce calcul, mais ne sont pas transmis.

Pour certains algorithmes d'intégrité, la chaîne d'octets sur laquelle le calcul de l'ICV est effectué doit être un multiple d'une taille de bloc spécifiée par l'algorithme. Si la longueur du paquet ESP (comme décrit ci-dessus) ne correspond pas aux exigences de taille de bloc de l'algorithme, un rembourrage implicite DOIT être ajouté à la fin du paquet ESP. (Ce rembourrage est ajouté après le champ Next Header, ou après les 32 bits de poids fort du numéro de séquence, si ESN est sélectionné.) La taille de bloc (et donc la longueur du rembourrage) est spécifiée par la spécification de l'algorithme d'intégrité. Ce rembourrage n'est pas transmis avec le paquet. Le document qui définit un algorithme d'intégrité DOIT être consulté pour déterminer si un rembourrage implicite est requis comme décrit ci-dessus. Si le document ne spécifie pas de réponse à cette question, alors la valeur par défaut est de supposer qu'un rembourrage implicite est requis (si nécessaire pour faire correspondre la longueur du paquet à la taille de bloc de l'algorithme.) Si des octets de rembourrage sont nécessaires mais que l'algorithme ne spécifie pas le contenu du rembourrage, alors les octets de rembourrage DOIVENT avoir une valeur de zéro.

3.3.2.2. Combined Confidentiality and Integrity Algorithms (Algorithmes de confidentialité et d'intégrité combinés)

Si un algorithme de confidentialité/intégrité combiné est utilisé, l'expéditeur procède comme suit:

Encapsuler dans le champ ESP Payload Data:
- pour le mode transport -- uniquement les informations du protocole de couche suivante d'origine.
- pour le mode tunnel -- l'intégralité du datagramme IP d'origine.
Ajouter tout rembourrage nécessaire -- comprend un rembourrage TFC optionnel et un rembourrage (de chiffrement).
Chiffrer et protéger l'intégrité du résultat en utilisant la clé et l'algorithme en mode combiné spécifiés pour la SA et en utilisant toutes les données de synchronisation cryptographique requises.
- Si des données de synchronisation cryptographique explicites, par exemple un IV, sont indiquées, elles sont entrées dans l'algorithme en mode combiné selon la spécification de l'algorithme et placées dans le champ Payload.
- Si des données de synchronisation cryptographique implicites sont utilisées, elles sont construites et entrées dans l'algorithme de chiffrement selon la spécification de l'algorithme.
- Le numéro de séquence (ou numéro de séquence étendu, le cas échéant) et le SPI sont des entrées de l'algorithme, car ils doivent être inclus dans le calcul de la vérification d'intégrité. Les moyens par lesquels ces valeurs sont incluses dans ce calcul sont une fonction de l'algorithme en mode combiné utilisé et donc non spécifiés dans cette norme.
- Le champ ICV (explicite) PEUT faire partie du format de paquet ESP lorsqu'un algorithme en mode combiné est utilisé. S'il n'est pas utilisé, un champ analogue fera généralement partie de la charge utile de texte chiffré. L'emplacement de tous les champs d'intégrité, et les moyens par lesquels le numéro de séquence et le SPI sont inclus dans le calcul d'intégrité, DOIVENT être définis dans un RFC qui définit l'utilisation de l'algorithme en mode combiné avec ESP.

3.3.3. Sequence Number Generation (Génération de numéro de séquence)

Le compteur de l'expéditeur est initialisé à 0 lorsqu'une SA est établie. L'expéditeur incrémente le compteur de numéro de séquence (ou ESN) pour cette SA et insère les 32 bits de poids faible de la valeur dans le champ Sequence Number. Ainsi, le premier paquet envoyé en utilisant une SA donnée contiendra un numéro de séquence de 1.

Si l'anti-rejeu est activé (par défaut), l'expéditeur vérifie que le compteur n'a pas bouclé avant d'insérer la nouvelle valeur dans le champ Sequence Number. En d'autres termes, l'expéditeur NE DOIT PAS envoyer un paquet sur une SA si cela provoquerait le bouclage du numéro de séquence. Une tentative de transmission d'un paquet qui entraînerait un débordement du numéro de séquence est un événement auditable. L'entrée du journal d'audit pour cet événement DEVRAIT inclure la valeur SPI, la date/heure actuelle, l'adresse source, l'adresse de destination et (en IPv6) l'ID de flux en clair.

L'expéditeur suppose que l'anti-rejeu est activé par défaut, sauf notification contraire du récepteur (voir section 3.4.3). Ainsi, le comportement typique d'une implémentation ESP exige que l'expéditeur établisse une nouvelle SA lorsque le numéro de séquence (ou ESN) boucle, ou en prévision de ce bouclage de valeur.

Si la clé utilisée pour calculer un ICV est distribuée manuellement, une implémentation conforme NE DEVRAIT PAS fournir de service anti-rejeu. Si un utilisateur choisit d'utiliser l'anti-rejeu en conjonction avec des SA à clés manuelles, le compteur de numéro de séquence au niveau de l'expéditeur DOIT être correctement maintenu lors des redémarrages locaux, etc., jusqu'à ce que la clé soit remplacée. (Voir section 5.)

Si l'anti-rejeu est désactivé (comme indiqué ci-dessus), l'expéditeur n'a pas besoin de surveiller ou de réinitialiser le compteur. Cependant, l'expéditeur incrémente toujours le compteur et lorsqu'il atteint la valeur maximale, le compteur revient à zéro. (Ce comportement est recommandé pour les SA multicast multi-expéditeurs, sauf si des mécanismes anti-rejeu en dehors de la portée de cette norme sont négociés entre l'expéditeur et le récepteur.)

Si ESN (voir annexe) est sélectionné, seuls les 32 bits de poids faible du numéro de séquence sont transmis dans le champ Sequence Number, bien que l'expéditeur et le récepteur maintiennent tous deux des compteurs ESN complets de 64 bits. Les 32 bits de poids fort sont inclus dans la vérification d'intégrité d'une manière spécifique à l'algorithme/mode, par exemple les 32 bits de poids fort peuvent être ajoutés après le champ Next Header lorsqu'un algorithme d'intégrité séparé est utilisé.

Note: Si un récepteur choisit de ne pas activer l'anti-rejeu pour une SA, alors le récepteur NE DEVRAIT PAS négocier ESN dans un protocole de gestion SA. L'utilisation d'ESN crée un besoin pour le récepteur de gérer la fenêtre anti-rejeu (afin de déterminer la valeur correcte pour les bits de poids fort de l'ESN, qui sont utilisés dans le calcul de l'ICV), ce qui est généralement contraire à la notion de désactivation de l'anti-rejeu pour une SA.

3.3.4. Fragmentation

Si nécessaire, la fragmentation est effectuée après le traitement ESP au sein d'une implémentation IPsec. Ainsi, le mode transport ESP est appliqué uniquement aux datagrammes IP entiers (et non aux fragments IP). Un paquet IP auquel ESP a été appliqué peut lui-même être fragmenté par les routeurs en route, et ces fragments doivent être réassemblés avant le traitement ESP au niveau d'un récepteur. En mode tunnel, ESP est appliqué à un paquet IP, qui peut être un fragment d'un datagramme IP. Par exemple, une passerelle de sécurité ou une implémentation IPsec «bump-in-the-stack» ou «bump-in-the-wire» (comme définie dans le document d'architecture de sécurité) peut appliquer le mode tunnel ESP à de tels fragments.

NOTE: Pour le mode transport -- Comme mentionné à la fin de la section 3.1.1, les implémentations bump-in-the-stack et bump-in-the-wire peuvent devoir d'abord réassembler un paquet fragmenté par la couche IP locale, puis appliquer IPsec, puis fragmenter le paquet résultant.

NOTE: Pour IPv6 -- Pour les implémentations bump-in-the-stack et bump-in-the-wire, il sera nécessaire d'examiner tous les en-têtes d'extension pour déterminer s'il existe un en-tête de fragmentation et donc que le paquet nécessite un réassemblage avant le traitement IPsec.

La fragmentation, qu'elle soit effectuée par une implémentation IPsec ou par des routeurs le long du chemin entre les pairs IPsec, réduit considérablement les performances. De plus, l'exigence pour un récepteur ESP d'accepter des fragments pour réassemblage crée des vulnérabilités de déni de service. Ainsi, une implémentation ESP PEUT choisir de ne pas prendre en charge la fragmentation et peut marquer les paquets transmis avec le bit DF, pour faciliter la découverte de MTU de chemin (PMTU). Dans tous les cas, une implémentation ESP DOIT prendre en charge la génération de messages ICMP PMTU (ou une signalisation interne équivalente pour les implémentations d'hôte natif) pour minimiser la probabilité de fragmentation. Les détails du support requis pour la gestion MTU sont contenus dans le document d'architecture de sécurité.