9.1. Paquets IP Encapsulés dans IP (IP packets encapsulated in IP)

L'encapsulation d'en-têtes de paquets IP dans des tunnels est utilisée dans de nombreux endroits, y compris IPsec et IP in IP [RFC2003]. Cette section considère les problèmes liés à l'interaction entre ECN et les tunnels IP, et spécifie deux solutions alternatives. Cette discussion est complétée par le RFC 2983 sur l'interaction entre les Services Différenciés et diverses formes de tunnels IP [RFC 2983], car les Services Différenciés utilisent les six bits restants de l'octet d'en-tête IP utilisés par ECN (voir Figure 2 dans la section 5).

Certains modes de tunnel IP sont basés sur l'ajout d'un nouvel en-tête IP "externe" qui encapsule l'en-tête IP "intérieur" ou original et son paquet associé. Dans de nombreux cas, le nouvel en-tête IP "externe" peut être ajouté et supprimé à des points intermédiaires le long de la connexion, permettant au réseau d'établir des tunnels sans nécessiter la participation des points de terminaison. Nous ferons référence aux tunnels qui jettent l'en-tête externe au point de sortie du tunnel comme des "tunnels simples" (simple tunnels).

ECN utilise le champ ECN dans l'en-tête IP pour la signalisation entre les routeurs et les points de terminaison de connexion. ECN interagit avec les tunnels IP basé sur le traitement du champ ECN dans l'en-tête IP. Dans un tunnel IP simple, l'octet contenant le champ ECN est copié ou mappé de l'en-tête IP intérieur à l'en-tête IP extérieur à l'entrée du tunnel IP, et cette copie de ce champ de l'en-tête extérieur est jetée à la sortie du tunnel IP. Si l'en-tête externe est simplement jeté sans attention au traitement du champ ECN, et qu'un routeur compatible ECN a défini le codepoint CE (Congestion Experienced, Congestion Expérimentée) dans un paquet dans un tunnel IP simple, alors cette indication sera jetée à la sortie du tunnel, perdant l'indication de congestion.

Ainsi, l'utilisation d'ECN sur des tunnels IP simples entraînerait des routeurs essayant d'utiliser l'en-tête IP externe pour signaler la congestion aux points de terminaison, mais ces avertissements de congestion n'arriveraient jamais car l'en-tête externe est jeté au point de sortie du tunnel. Le RFC 2481 a rencontré ce problème d'ECN et d'IPsec en mode tunnel, et a recommandé de ne pas utiliser ECN avec les tunnels IPsec simples plus anciens pour éviter ce comportement et ses conséquences. Lorsque ECN sera largement déployé, les tunnels simples qui peuvent transporter du trafic compatible ECN devront être modifiés. Si le trafic compatible ECN est transporté à travers des tunnels simples via des routeurs compatibles ECN congestionnés, cela pourrait entraîner l'abandon de paquets ultérieurs pour ce flux en raison de l'augmentation de la taille moyenne de la file d'attente au niveau du routeur congestionné, comme discuté dans la section 8 ci-dessus.

D'un point de vue sécurité, l'utilisation d'ECN dans l'en-tête externe d'un tunnel IP peut poser des problèmes de sécurité car un adversaire pourrait falsifier les informations ECN qui se propagent au-delà des points de terminaison du tunnel. Sur la base de l'analyse de ces problèmes et des risques qui en résultent dans les sections 18 et 19, notre approche globale est de faire du support d'ECN une option pour les tunnels IP, de sorte que les tunnels IP puissent être spécifiés ou configurés pour utiliser ou ne pas utiliser ECN dans l'en-tête externe du tunnel. Ainsi, dans les environnements ou protocoles de tunnel où les risques liés à l'utilisation d'ECN sont jugés supérieurs à ses avantages, le tunnel peut simplement ne pas utiliser ECN dans l'en-tête externe. Alors la seule indication de congestion expérimentée au niveau des routeurs dans le tunnel sera via la perte de paquets.

Le résultat est qu'il existe deux options viables pour le comportement des connexions compatibles ECN sur les tunnels IP (y compris les tunnels IPsec) :

• L'option de fonctionnalité limitée (limited-functionality option), où ECN est conservé dans l'en-tête intérieur mais désactivé dans l'en-tête extérieur. Dans ce cas, le seul mécanisme pour indiquer la congestion se produisant dans le tunnel est la perte de paquets.

• L'option de fonctionnalité complète (full-functionality option), avec support d'ECN dans les en-têtes intérieurs et extérieurs, et propagation des avertissements de congestion des nœuds dans le tunnel vers les points de terminaison.

Le support de ces options nécessite des degrés variables de modifications du traitement d'en-tête IP aux entrées et sorties de tunnel. Un petit sous-ensemble de ces modifications nécessaires pour supporter uniquement l'option de fonctionnalité limitée est suffisant pour éliminer toute incompatibilité entre ECN et les tunnels IP.

Un objectif de ce document est de fournir des conseils sur les compromis entre les options de fonctionnalité limitée et complète. Les sections 18 et 19 discutent en détail des impacts potentiels d'un adversaire modifiant le champ ECN.