2.6. Next Header (En-tête suivant)

Le Next Header est un champ obligatoire de 8 bits qui identifie le type de données contenues dans le champ Payload Data, par exemple un paquet IPv4 ou IPv6, ou un en-tête et des données de la couche suivante. La valeur de ce champ est choisie dans l'ensemble des numéros de protocole IP définis sur la page web de l'IANA, par exemple une valeur de 4 indique IPv4, une valeur de 41 indique IPv6 et une valeur de 6 indique TCP.

Pour faciliter la génération et l'élimination rapides du trafic de bourrage à l'appui de la confidentialité du flux de trafic (voir section 2.4), la valeur de protocole 59 (qui signifie "pas d'en-tête suivant") DOIT être utilisée pour désigner un paquet "factice". Un émetteur DOIT être capable de générer des paquets factices marqués avec cette valeur dans le champ de protocole suivant, et un récepteur DOIT être prêt à rejeter de tels paquets, sans indiquer d'erreur. Tous les autres champs d'en-tête et de trailer ESP (SPI, Sequence Number, Padding, Pad Length, Next Header et ICV) DOIVENT être présents dans les paquets factices, mais la partie en texte clair de la charge utile, autre que ce champ Next Header, n'a pas besoin d'être bien formée, par exemple le reste des Payload Data peut consister uniquement en octets aléatoires. Les paquets factices sont jetés sans préjudice.

Les implémentations DEVRAIENT fournir des contrôles de gestion locaux pour permettre l'utilisation de cette capacité sur une base par SA. Les contrôles devraient permettre à l'utilisateur de spécifier si cette fonctionnalité doit être utilisée et également fournir des contrôles paramétriques; par exemple, les contrôles pourraient permettre à un administrateur de générer des paquets factices de longueur aléatoire ou de longueur fixe.

DISCUSSION: Les paquets factices peuvent être insérés à intervalles aléatoires pour masquer l'absence de trafic réel. On peut également "façonner" le trafic réel pour qu'il corresponde à une certaine distribution à laquelle du trafic factice est ajouté comme dicté par les paramètres de distribution. Comme avec la facilité de bourrage de longueur de paquet pour la sécurité du flux de trafic (TFS), l'approche la plus sûre serait de générer des paquets factices au taux nécessaire pour maintenir un taux constant sur une SA. Si les paquets sont tous de la même taille, alors la SA présente l'apparence d'un flux de données à débit binaire constant, analogue à ce qu'une crypto de liaison offrirait aux couches 1 ou 2. Cependant, cela est peu susceptible d'être pratique dans de nombreux contextes, par exemple lorsqu'il y a plusieurs SA actives, car cela impliquerait de réduire la bande passante autorisée pour un site, en fonction du nombre de SA, et cela minerait les avantages de la commutation de paquets. Les implémentations DEVRAIENT fournir des contrôles pour permettre aux administrateurs locaux de gérer la génération de paquets factices à des fins TFC.