3.2. Algorithms (Algorithmes)

Les algorithmes obligatoires à implémenter pour une utilisation avec ESP sont décrits dans un RFC séparé, afin de faciliter la mise à jour des exigences algorithmiques indépendamment du protocole en tant que tel. Des algorithmes supplémentaires, au-delà de ceux mandatés pour ESP, PEUVENT être pris en charge. Notez que bien que la confidentialité et l'intégrité soient toutes deux optionnelles, au moins l'un de ces services DOIT être sélectionné, donc les deux algorithmes NE DOIVENT PAS être simultanément NULL.

3.2.1. Encryption Algorithms (Algorithmes de chiffrement)

L'algorithme de chiffrement utilisé pour protéger un paquet ESP est spécifié par la SA via laquelle le paquet est transmis/reçu. Étant donné que les paquets IP peuvent arriver dans le désordre et que tous les paquets peuvent ne pas arriver (perte de paquets), chaque paquet doit porter toutes les données requises pour permettre au récepteur d'établir une synchronisation cryptographique pour le déchiffrement. Ces données peuvent être transportées explicitement dans le champ de charge utile, par exemple sous forme d'IV (comme décrit ci-dessus), ou les données peuvent être dérivées des portions en texte clair de l'en-tête du paquet (IP externe ou ESP). (Notez que si les informations d'en-tête en texte clair sont utilisées pour dériver un IV, ces informations peuvent devenir critiques pour la sécurité et donc la frontière de protection associée au processus de chiffrement peut s'élargir. Par exemple, si l'on devait utiliser le numéro de séquence ESP pour dériver un IV, la logique de génération de numéro de séquence (matérielle ou logicielle) devrait être évaluée dans le cadre de l'implémentation de l'algorithme de chiffrement. Dans le cas de FIPS 140-2 [NIST01], cela pourrait considérablement étendre la portée d'une évaluation de module cryptographique.) Étant donné qu'ESP prévoit le rembourrage du texte clair, les algorithmes de chiffrement utilisés avec ESP peuvent présenter des caractéristiques de mode bloc ou de mode flux. Notez que comme le chiffrement (confidentialité) PEUT être un service optionnel (par exemple ESP à intégrité seule), cet algorithme PEUT être "NULL" [Ken-Arch].

Pour permettre à une implémentation ESP de calculer le rembourrage de chiffrement requis par un algorithme de chiffrement en mode bloc, et de déterminer l'impact MTU de l'algorithme, le RFC pour chaque algorithme de chiffrement utilisé avec ESP doit spécifier le module de rembourrage pour l'algorithme.

3.2.2. Integrity Algorithms (Algorithmes d'intégrité)

L'algorithme d'intégrité utilisé pour le calcul de l'ICV est spécifié par la SA via laquelle le paquet est transmis/reçu. Comme c'était le cas pour les algorithmes de chiffrement, tout algorithme d'intégrité utilisé avec ESP doit prévoir des dispositions pour permettre le traitement des paquets qui arrivent dans le désordre et pour s'adapter à la perte de paquets. La même mise en garde notée ci-dessus s'applique à l'utilisation de données en texte clair pour faciliter la synchronisation du récepteur des algorithmes d'intégrité. Notez que comme le service d'intégrité PEUT être optionnel, cet algorithme peut être "NULL".

Pour permettre à une implémentation ESP de calculer tout rembourrage d'algorithme d'intégrité implicite requis, le RFC pour chaque algorithme utilisé avec ESP doit spécifier le module de rembourrage pour l'algorithme.

3.2.3. Combined Mode Algorithms (Algorithmes en mode combiné)

Si un algorithme en mode combiné est utilisé, les services de confidentialité et d'intégrité sont tous deux fournis. Comme c'était le cas pour les algorithmes de chiffrement, un algorithme en mode combiné doit prévoir une synchronisation cryptographique par paquet, pour permettre le déchiffrement des paquets qui arrivent dans le désordre et pour s'adapter à la perte de paquets. Les moyens par lesquels un algorithme en mode combiné fournit l'intégrité pour la charge utile, et pour les champs SPI et numéro de séquence (étendu), peuvent varier selon les différents choix d'algorithmes. Afin de fournir une approche uniforme et indépendante de l'algorithme pour l'invocation d'algorithmes en mode combiné, aucune sous-structure de charge utile n'est définie. Par exemple, les champs SPI et numéro de séquence pourraient être répliqués dans l'enveloppe de texte chiffré et un ICV peut être ajouté au trailer ESP. Aucun de ces détails ne devrait être observable de l'extérieur.

Pour permettre à une implémentation ESP de déterminer l'impact MTU d'un algorithme en mode combiné, le RFC pour chaque algorithme utilisé avec ESP doit spécifier une formule (simple) qui donne la taille de la charge utile chiffrée, en fonction des tailles de la charge utile en texte clair et du numéro de séquence.