8. Backward-Compatibility Considerations (Considérations de rétrocompatibilité)
8. Backward-Compatibility Considerations (Considérations de rétrocompatibilité)
Il n'y a pas de numéro de version dans ESP et aucun mécanisme permettant aux pairs IPsec de découvrir ou de négocier quelle version d'ESP chacun utilise ou devrait utiliser. Cette section discute des problèmes de rétrocompatibilité qui en découlent.
Tout d'abord, si aucune des nouvelles fonctionnalités disponibles dans ESP v3 n'est employée, alors le format d'un paquet ESP est identique dans ESP v2 et v3. Si un algorithme de chiffrement en mode combiné est employé, une fonctionnalité prise en charge uniquement dans ESP v3, alors le format de paquet résultant peut différer de la spécification ESP v2. Cependant, un pair qui n'implémente que ESP v2 ne négocierait jamais un tel algorithme, car ils sont définis pour une utilisation uniquement dans le contexte ESP v3.
La négociation du numéro de séquence étendu (ESN) est prise en charge par IKE v2 et a été traitée pour IKE v1 par l'addendum ESN au domaine d'interprétation (DOI) d'IKE v1.
Dans le nouvel ESP (v3), nous faisons deux dispositions pour mieux prendre en charge la confidentialité du flux de trafic (TFC):
- remplissage arbitraire après la fin d'un paquet IP
- une convention de rejet utilisant Next Header = 59
La première fonctionnalité ne devrait pas causer de problèmes pour un récepteur, puisque le champ de longueur totale IP indique où le paquet IP se termine. Ainsi, tous les octets de remplissage TFC après la fin du paquet devraient être supprimés à un moment donné pendant le traitement du paquet IP, après le traitement ESP, même si le logiciel IPsec ne supprime pas un tel remplissage. Ainsi, il s'agit d'une fonctionnalité ESP v3 qu'un émetteur peut employer indépendamment du fait qu'un récepteur implémente ESP v2 ou ESP v3.
La deuxième fonctionnalité permet à un émetteur d'envoyer une charge utile qui est une chaîne arbitraire d'octets qui ne constituent pas nécessairement un paquet IP bien formé, à l'intérieur d'un tunnel, à des fins TFC. C'est une question ouverte de savoir ce qu'un récepteur ESP v2 fera lorsque le champ Next Header dans un paquet ESP contient la valeur "59". Il pourrait rejeter le paquet lorsqu'il trouve un en-tête IP mal formé, et enregistrer cet événement, mais il ne devrait certainement pas planter, car un tel comportement constituerait une vulnérabilité DoS par rapport au trafic reçu de pairs authentifiés. Ainsi, cette fonctionnalité est une optimisation qu'un émetteur ESP v3 peut utiliser indépendamment du fait qu'un récepteur implémente ESP v2 ou ESP v3.