2. Encapsulating Security Payload Packet Format (Format de paquet ESP)
L'en-tête de protocole (externe) (IPv4, IPv6 ou Extension) qui précède immédiatement l'en-tête ESP DOIT contenir la valeur 50 dans son champ Protocol (IPv4) ou Next Header (IPv6, Extension) (voir la page web IANA à http://www.iana.org/assignments/protocol-numbers). La figure 1 illustre le format de niveau supérieur d'un paquet ESP. Le paquet commence par deux champs de 4 octets (Security Parameters Index (SPI) et Sequence Number). Ces champs sont suivis des Payload Data, qui ont une sous-structure qui dépend du choix de l'algorithme de chiffrement et du mode, ainsi que de l'utilisation du bourrage TFC, ce qui sera examiné plus en détail ultérieurement. Les Payload Data sont suivis des champs Padding et Pad Length, ainsi que du champ Next Header. Le champ optionnel Integrity Check Value (ICV) complète le paquet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Format de niveau supérieur d'un paquet ESP
* Si des données de synchronisation cryptographique sont incluses dans le champ Payload, par exemple un vecteur d'initialisation (IV, voir section 2.3), elles ne sont généralement pas chiffrées en tant que telles, bien qu'elles soient souvent considérées comme faisant partie du texte chiffré.
Le trailer ESP (transmis) se compose des champs Padding, Pad Length et Next Header. Des données de trailer ESP supplémentaires implicites (qui ne sont pas transmises) sont incluses dans le calcul d'intégrité, comme décrit ci-dessous.
Si le service d'intégrité est sélectionné, le calcul d'intégrité englobe le SPI, le Sequence Number, les Payload Data et le trailer ESP (explicite et implicite).
Si le service de confidentialité est sélectionné, le texte chiffré se compose des Payload Data (à l'exception de toutes données de synchronisation cryptographique qui peuvent être incluses) et du trailer ESP (explicite).
Comme indiqué ci-dessus, les Payload Data peuvent avoir une sous-structure. Un algorithme de chiffrement qui nécessite un vecteur d'initialisation (IV) explicite, par exemple le mode Cipher Block Chaining (CBC), préfixe souvent les Payload Data à protéger avec cette valeur. Certains modes d'algorithme combinent le chiffrement et l'intégrité en une seule opération; ce document fait référence à ces modes d'algorithme sous le nom d'"algorithmes en mode combiné". L'adaptation des algorithmes en mode combiné nécessite que l'algorithme décrive explicitement la sous-structure de charge utile utilisée pour transmettre les données d'intégrité.
Certains algorithmes en mode combiné fournissent l'intégrité uniquement pour les données chiffrées, tandis que d'autres peuvent fournir l'intégrité pour certaines données supplémentaires qui ne sont pas chiffrées pour la transmission. Étant donné que les champs SPI et Sequence Number nécessitent l'intégrité dans le cadre du service d'intégrité et qu'ils ne sont pas chiffrés, il est nécessaire de s'assurer qu'ils bénéficient de l'intégrité chaque fois que le service est sélectionné, quel que soit le style de mode d'algorithme combiné employé.
Lorsqu'un algorithme en mode combiné est employé, l'algorithme lui-même est censé renvoyer à la fois le texte en clair déchiffré et une indication de réussite/échec pour la vérification d'intégrité. Pour les algorithmes en mode combiné, l'ICV qui apparaîtrait normalement à la fin du paquet ESP (lorsque l'intégrité est sélectionnée) peut être omis. Lorsque l'ICV est omis et que l'intégrité est sélectionnée, il incombe à l'algorithme en mode combiné d'encoder dans les Payload Data un moyen équivalent à l'ICV de vérifier l'intégrité du paquet.
Si un algorithme en mode combiné offre l'intégrité uniquement aux données chiffrées, il sera nécessaire de répliquer le SPI et le Sequence Number dans les Payload Data.
Enfin, une nouvelle disposition est prise pour insérer un bourrage pour la confidentialité du flux de trafic après les Payload Data et avant le trailer ESP. La figure 2 illustre cette sous-structure pour les Payload Data. (Remarque: ce diagramme montre les bits sur le fil. Donc, même si des numéros de séquence étendus sont utilisés, seuls 32 bits du Sequence Number seront transmis (voir section 2.2.1).)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Sous-structure des Payload Data
* Si le mode tunnel est utilisé, l'implémentation IPsec peut ajouter un bourrage Traffic Flow Confidentiality (TFC) (voir section 2.4) après les Payload Data et avant le champ Padding (0-255 octets).
Si un mode d'algorithme combiné est employé, l'ICV explicite montré dans les figures 1 et 2 peut être omis (voir section 3.3.2.2 ci-dessous). Étant donné que les algorithmes et les modes sont fixés lors de l'établissement d'une SA, le format détaillé des paquets ESP pour une SA donnée (y compris la sous-structure des Payload Data) est fixe pour tout le trafic sur la SA.
Les tableaux ci-dessous se réfèrent aux champs des figures précédentes et illustrent comment plusieurs catégories d'options algorithmiques, chacune avec un modèle de traitement différent, affectent les champs notés ci-dessus. Les détails de traitement sont décrits dans les sections ultérieures.
Tableau 1. Algorithmes de chiffrement et d'intégrité séparés
| Champ | Nombre d'octets | Requis [1] | Couverture chiffrement | Couverture intégrité | Transmis |
|---|---|---|---|---|---|
| SPI | 4 | M | Y | plain | |
| Seq# (bits de poids faible) | 4 | M | Y | plain | |
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher[3] |
| TFC padding [4] | variable | O | Y | Y | cipher[3] |
| Padding | 0-255 | M | Y | Y | cipher[3] |
| Pad Length | 1 | M | Y | Y | cipher[3] |
| Next Header | 1 | M | Y | Y | cipher[3] |
| Seq# (bits de poids fort) | 4 | if ESN [5] | Y | not xmtd | |
| ICV Padding | variable | if need | Y | not xmtd | |
| ICV | variable | M [6] | plain |
[1] M = obligatoire; O = optionnel; D = factice
[2] Si mode tunnel -> datagramme IP; Si mode transport -> en-tête suivant et données
[3] texte chiffré si le chiffrement a été sélectionné
[4] Ne peut être utilisé que si la charge utile spécifie sa "vraie" longueur
[5] Voir section 2.2.1
[6] obligatoire si un algorithme d'intégrité séparé est utilisé
Tableau 2. Algorithmes en mode combiné
| Champ | Nombre d'octets | Requis [1] | Couverture chiffrement | Couverture intégrité | Transmis |
|---|---|---|---|---|---|
| SPI | 4 | M | plain | ||
| Seq# (bits de poids faible) | 4 | M | plain | ||
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher |
| TFC padding [3] | variable | O | Y | Y | cipher |
| Padding | 0-255 | M | Y | Y | cipher |
| Pad Length | 1 | M | Y | Y | cipher |
| Next Header | 1 | M | Y | Y | cipher |
| Seq# (bits de poids fort) | 4 | if ESN [4] | Y | [5] | |
| ICV Padding | variable | if need | Y | [5] | |
| ICV | variable | O [6] | plain |
[1] M = obligatoire; O = optionnel; D = factice
[2] Si mode tunnel -> datagramme IP; Si mode transport -> en-tête suivant et données
[3] Ne peut être utilisé que si la charge utile spécifie sa "vraie" longueur
[4] Voir section 2.2.1
[5] Le choix de l'algorithme détermine si ceux-ci sont transmis, mais dans les deux cas, le résultat est invisible pour ESP
[6] La spécification de l'algorithme détermine si ce champ est présent
Les sous-sections suivantes décrivent les champs du format d'en-tête. "Optionnel" signifie que le champ est omis si l'option n'est pas sélectionnée, c'est-à-dire qu'il n'est présent ni dans le paquet tel qu'il est transmis ni tel qu'il est formaté pour le calcul d'un ICV (voir section 2.7). Le fait qu'une option soit sélectionnée ou non est déterminé dans le cadre de l'établissement de l'association de sécurité (SA). Ainsi, le format des paquets ESP pour une SA donnée est fixe pour la durée de la SA. En revanche, les champs "obligatoires" sont toujours présents dans le format de paquet ESP, pour toutes les SA.
Remarque: tous les algorithmes cryptographiques utilisés dans IPsec attendent leur entrée dans l'ordre des octets du réseau canonique (voir l'annexe de RFC 791 [Pos81]) et génèrent leur sortie dans l'ordre des octets du réseau canonique. Les paquets IP sont également transmis dans l'ordre des octets du réseau.
ESP ne contient pas de numéro de version, donc s'il y a des préoccupations concernant la compatibilité descendante, elles DOIVENT être résolues en utilisant un mécanisme de signalisation entre les deux pairs IPsec pour assurer des versions compatibles d'ESP (par exemple, Internet Key Exchange (IKEv2) [Kau05]) ou un mécanisme de configuration hors bande.