12. Résumé des Changements Requis dans IP et TCP (Summary of changes required in IP and TCP)

Ce document spécifie deux bits dans l'en-tête IP pour ECN. Le codepoint not-ECT indique que le protocole de transport ignorera le codepoint CE. C'est la valeur par défaut pour le codepoint ECN. Le codepoint ECT indique que le protocole de transport est disposé et capable de participer à ECN.

Les routeurs définissent le codepoint CE pour indiquer la congestion aux nœuds terminaux. Le codepoint CE dans l'en-tête de paquet NE DOIT JAMAIS être réinitialisé par les routeurs.

TCP nécessite trois modifications pour ECN, une phase de configuration et deux nouveaux drapeaux dans l'en-tête TCP. Le drapeau ECN-Echo est utilisé par le récepteur de données pour informer l'expéditeur de données de la réception d'un paquet CE. Le drapeau Congestion Window Reduced (CWR, Fenêtre de Congestion Réduite) est utilisé par l'expéditeur de données pour informer le récepteur de données que la fenêtre de congestion a été réduite.

Lorsque ECN (Explicit Congestion Notification, Notification Explicite de Congestion) est utilisé, il est nécessaire que les indications de congestion générées dans un tunnel IP ne soient pas perdues à la sortie du tunnel. Nous spécifions des modifications mineures du traitement du champ ECN par le protocole IP lors de l'encapsulation et de la décapsulation pour permettre aux flux qui subissent un transport de tunnel IP d'utiliser ECN.

Deux options sont spécifiées pour ECN dans les tunnels :

1. L'option de fonctionnalité limitée (limited-functionality option), qui n'utilise pas ECN dans le tunnel IP, en définissant le champ ECN sur not-ECT dans l'en-tête externe et en ne modifiant pas l'en-tête intérieur lors de la décapsulation.

2. L'option de fonctionnalité complète (full-functionality option), en définissant le champ ECN dans l'en-tête externe sur le codepoint not-ECT ou l'un des codepoints ECT en fonction du champ ECN dans l'en-tête intérieur. Lors de la décapsulation, si le codepoint CE est défini dans l'en-tête externe et que l'en-tête intérieur est défini sur l'un des codepoints ECT, alors le codepoint CE est copié dans l'en-tête intérieur.

Pour les tunnels IPsec, ce document définit également un attribut optionnel d'Association de Sécurité (Security Association, SA) IPsec qui permet la négociation de l'utilisation d'ECN dans les tunnels IPsec, ainsi qu'un champ optionnel dans la Base de Données d'Association de Sécurité (Security Association Database) pour indiquer si ECN est autorisé en mode tunnel sur le SA. Les modifications requises pour les tunnels IPsec utilisant ECN modifient le RFC 2401 [RFC2401], qui définit l'architecture IPsec et spécifie certains aspects de son implémentation. Le nouvel attribut SA IPsec complète les attributs déjà définis dans la section 4.5 de [RFC2407].

Ce document rend obsolète le RFC 2481 "A Proposal to add Explicit Congestion Notification (ECN) to IP", qui définissait ECN comme un protocole expérimental pour la communauté Internet. Le reste de cette section décrit la relation entre ce document et son prédécesseur.

Le RFC 2481 incluait une brève discussion sur l'utilisation d'ECN avec les paquets encapsulés, et notait que pour les spécifications IPsec à l'époque (janvier 1999), les flux ne pouvaient pas utiliser ECN en toute sécurité s'ils allaient traverser des tunnels IPsec. Le RFC 2481 décrivait également les modifications qui pourraient être apportées aux spécifications de tunnel IPsec pour les rendre compatibles avec ECN.

Ce document intègre également le travail effectué après le RFC 2481. Le premier est une description détaillée des modifications des tunnels IPsec et une discussion approfondie des implications de sécurité d'ECN (maintenant incluses comme sections 18 et 19 de ce document). Le second est l'extension de la discussion sur les tunnels IPsec pour inclure tous les tunnels IP. Étant donné que les anciens tunnels IP sont incompatibles avec l'utilisation d'ECN par les flux, le déploiement d'ECN sur Internet créera une forte pression pour que les anciens tunnels IP soient mis à niveau vers des versions compatibles ECN, en utilisant soit l'option de fonctionnalité limitée soit l'option de fonctionnalité complète.

Ce document ne traite pas de la question de l'inclusion d'ECN dans les tunnels non-IP tels que MPLS, GRE, L2TP ou PPTP. Un document préliminaire antérieur sur l'ajout du support ECN à MPLS n'a pas été poursuivi.

Le troisième nouveau travail après le RFC2481 est la description des procédures ECN pour les paquets retransmis, à savoir que le codepoint ECT NE DEVRAIT PAS être défini sur les paquets retransmis. La motivation de cette spécification supplémentaire est d'éliminer une voie possible pour les attaques par déni de service contre les connexions TCP existantes. Certains TCP compatibles ECN déployés précédemment peuvent ne pas être conformes à l'exigence (nouvelle) de ne pas définir le codepoint ECT sur les paquets retransmis ; nous pensons que cela n'entraînera pas de problèmes significatifs en pratique.

Ce document étend également légèrement la spécification pour la négociation ECN utilisant les paquets SYN. Bien que certains TCP compatibles ECN déployés précédemment puissent ne pas être conformes aux exigences spécifiées dans ce document, nous pensons que cela n'entraînera aucun problème de performance ou de compatibilité pour les connexions TCP avec des points de terminaison ayant des combinaisons d'implémentations TCP.

Ce document inclut également la spécification du codepoint ECT(1), qui peut être utilisé par TCP dans le cadre de l'implémentation du nonce ECN.