2.4. Padding (for Encryption) (Bourrage pour le chiffrement)

Deux facteurs principaux nécessitent ou motivent l'utilisation du champ Padding.

Si un algorithme de chiffrement est employé qui nécessite que le texte en clair soit un multiple d'un certain nombre d'octets, par exemple la taille de bloc d'un chiffrement par blocs, le champ Padding est utilisé pour remplir le texte en clair (composé des champs Payload Data, Padding, Pad Length et Next Header) à la taille requise par l'algorithme.
Le bourrage peut également être requis, indépendamment des exigences de l'algorithme de chiffrement, pour s'assurer que le texte chiffré résultant se termine sur une limite de 4 octets. Plus précisément, les champs Pad Length et Next Header doivent être alignés à droite dans un mot de 4 octets, comme illustré dans les figures de format de paquet ESP ci-dessus, pour s'assurer que le champ ICV (s'il est présent) est aligné sur une limite de 4 octets.

Le bourrage au-delà de celui requis pour l'algorithme ou les raisons d'alignement citées ci-dessus pourrait être utilisé pour dissimuler la longueur réelle de la charge utile, à l'appui du TFC. Cependant, le champ Padding décrit est trop limité pour être efficace pour le TFC et ne devrait donc pas être utilisé à cette fin. Au lieu de cela, le mécanisme séparé décrit ci-dessous (voir section 2.7) devrait être utilisé lorsque le TFC est requis.

L'expéditeur PEUT ajouter de 0 à 255 octets de bourrage. L'inclusion du champ Padding dans un paquet ESP est facultative, sous réserve des exigences notées ci-dessus, mais toutes les implémentations DOIVENT prendre en charge la génération et la consommation de bourrage.

Dans le but de s'assurer que les bits à chiffrer sont un multiple de la taille de bloc de l'algorithme (première puce ci-dessus), le calcul de bourrage s'applique aux Payload Data à l'exclusion de tout IV, mais y compris les champs de trailer ESP. Si un mode d'algorithme combiné nécessite la transmission du SPI et du Sequence Number pour effectuer l'intégrité, par exemple la réplication du SPI et du Sequence Number dans les Payload Data, alors les versions répliquées de ces éléments de données, et toutes données équivalentes à l'ICV associées, sont incluses dans le calcul de la longueur de bourrage. (Si l'option ESN est sélectionnée, les 32 bits de poids fort de l'ESN entreraient également dans le calcul, si l'algorithme en mode combiné nécessite leur transmission pour l'intégrité.)
Dans le but de s'assurer que l'ICV est aligné sur une limite de 4 octets (deuxième puce ci-dessus), le calcul de bourrage s'applique aux Payload Data y compris l'IV, les champs Pad Length et Next Header. Si un algorithme en mode combiné est utilisé, toutes données répliquées et données équivalentes à l'ICV sont incluses dans les Payload Data couverts par le calcul de bourrage.

Si des octets de Padding sont nécessaires mais que l'algorithme de chiffrement ne spécifie pas le contenu du bourrage, alors le traitement par défaut suivant DOIT être utilisé. Les octets de Padding sont initialisés avec une série de valeurs entières (non signées, 1 octet). Le premier octet de bourrage ajouté au texte en clair est numéroté 1, les octets de bourrage suivants constituant une séquence monotone croissante: 1, 2, 3, .... Lorsque ce schéma de bourrage est employé, le récepteur DEVRAIT inspecter le champ Padding. (Ce schéma a été sélectionné en raison de sa simplicité relative, de sa facilité de mise en œuvre dans le matériel, et parce qu'il offre une protection limitée contre certaines formes d'attaques "couper-coller" en l'absence d'autres mesures d'intégrité, si le récepteur vérifie les valeurs de bourrage lors du déchiffrement.)

Si un algorithme de chiffrement ou en mode combiné impose des contraintes sur les valeurs des octets utilisés pour le bourrage, ils DOIVENT être spécifiés par la RFC définissant comment l'algorithme est employé avec ESP. Si l'algorithme nécessite la vérification des valeurs des octets utilisés pour le bourrage, cela aussi DOIT être spécifié dans cette RFC.