Untitled Document

Le présent mémoire spécifie l’incorporation de la notification explicite d’encombrement (ECN, Explicit Congestion Notification) à TCP et IP, en incluant l’utilisation par ECN de deux bits dans l’en-tête IP.

On commence par décrire l'utilisation par TCP des abandons de paquet comme indication d'encombrement. Ensuite, on explique qu'avec l'ajout de la gestion active de file d'attente (par exemple, RED) à l'infrastructure Internet, où les routeurs détectent l'encombrement avant le débordement de la file d'attente, les routeurs ne sont plus limités à l'abandon de paquet comme indication d'encombrement. Les routeurs peuvent alors régler le codet Encombrement (CE, Congestion Experienced) dans l'en-tête IP des paquets provenant de transports à capacité ECN. On décrit quand le codet CE est à établir par les routeurs, ainsi que les modifications nécessaires à TCP pour le rendre capable d'ECN. Les modifications aux autres protocoles de transport (par exemple, les protocoles de transport en envoi individuel ou en diffusion groupée non fiables, la diffusion groupée fiable, ou d'autres protocoles de transport fiables en envoi individuel) pourraient être considérés comme ceux qui sont développés et avancent dans le processus de normalisation. On décrit aussi dans le présent document les questions qui impliquent l'utilisation de ECN dans les tunnels IP, et en particulier dans les tunnels IPsec.

Un des principes directeurs du présent document est que, dans la mesure du possible, les mécanismes spécifiés ici peuvent être déployés par incrément. Un des défis du principe du déploiement incrémentaire a été l'existence préalable de certains tunnels IP qui ne sont pas compatibles avec l'utilisation de ECN. Avec le déploiement de ECN, les tunnels IP non compatibles devront être mis à niveau pour se conformer au présent document.

Le présent document rend obsolète la RFC 2481, "Proposition pour ajouter la notification explicite d'encombrement (ECN) à IP", qui définissait ECN comme un protocole expérimental pour la communauté de l'Internet. Le présent document met aussi à jour la RFC 2474, "Définition des champs de services différenciés (champ DS) dans les en-têtes IPv4 et IPv6", en définissant le champ ECN dans l'en-tête IP, la RFC 2401, "Architecture de sécurité pour le protocole Internet" en changeant le traitement de l'octet TOS IPv4 et de l'octet Classe de trafic IPv6 dans la construction de l'en-tête en mode tunnel pour le rendre compatible avec l'utilisation de ECN, et la RFC 793, "Protocole de contrôle de transmission", en définissant deux nouveaux fanions dans l'en-tête TCP.

Les algorithmes de contrôle et d'évitement d'encombrement de TCP se fondent sur la notion que le réseau est une boîte noire [Jacobson88, Jacobson90]. L'état d'encombrement ou autre du réseau est déterminé par la vérification de l'état du réseau par les systèmes d'extrémité, en accroissant graduellement la charge du réseau (en augmentant la fenêtre des paquets qui sont sortants vers le réseau) jusqu'à ce que le réseau devienne encombré et qu'un paquet soit perdu. Traiter le réseau comme une "boîte noire" et traiter la perte comme une indication d'encombrement du réseau est approprié pour les données "au mieux" pures portées par TCP, avec peu ou pas du tout de sensibilité au retard ou à la perte des paquets individuels. De plus, les algorithmes de gestion de l'encombrement de TCP ont des techniques incorporées (telles que Retransmission rapide et Récupération rapide) pour minimiser l'impact des pertes, du point de vue du débit. Cependant, ces mécanismes ne sont pas destinés à aider les applications qui sont en fait sensibles au retard ou à la perte d'un ou plusieurs paquets individuels. Le trafic interactif comme telnet, la navigation sur la Toile, et le transfert de données audio et vidéo, peuvent être sensibles à la perte de paquets (spécialement en utilisant un transport de livraison de données non fiable tel que UDP) ou à la latence croissante des paquets causée par la nécessité de retransmettre le paquet après une perte (avec la sémantique de livraison fiable des données fournie par TCP).

Comme TCP détermine la fenêtre d'encombrement appropriée à utiliser en augmentant graduellement la taille de la fenêtre jusqu'à rencontrer un paquet abandonné, cela cause la construction de la file d'attente au routeur engorgé. Avec la plupart des politiques d'abandon de paquet chez les routeurs qui ne sont pas sensibles à la charge qui pèse sur chaque flux individuel (par exemple, abandon de la fin de la file ou débordement de la file) cela signifie que certains des paquets des flux sensibles à la latence peuvent être abandonnés. De plus, de telles politiques d'abandon conduisent à la synchronisation des pertes à travers plusieurs flux.

Les mécanismes de gestion active de file d'attente détectent l'encombrement avant le débordement de la file d'attente, et fournissent une indication de cet encombrement aux nœuds d'extrémité. Et donc, la gestion active de file d'attente peut réduire les délais de file d'attente inutiles pour tout le trafic qui partage cette queue. Les avantages de la gestion active de file d'attente sont exposés dans la [RFC2309]. La gestion active de file d'attente évite certaines des mauvaises propriétés de l'abandon en cas de débordement de file d'attente, y compris la synchronisation indésirable des pertes à travers plusieurs flux. Plus important, la gestion active de file d'attente signifie que les protocoles de transport qui ont les mécanismes de contrôle de l'encombrement (par exemple, TCP) ne s'appuient pas sur le débordement de mémoire tampon comme seule indication d'encombrement.

Les mécanismes de gestion active de file d'attente peuvent utiliser une des méthodes d'indication de l'encombrement aux nœuds d'extrémité. L'une d'elles est d'utiliser l'abandon de paquet, comme c'est le cas actuellement. Cependant, la gestion active de file d'attente permet au routeur de séparer les politiques de mise en file d'attente ou d'abandon de paquet des politiques d'indication de l'encombrement. Et donc, la gestion active de file d'attente permet aux routeurs d'utiliser le codet Encombrement (CE, Congestion Experienced) dans un en-tête de paquet comme une indication d'encombrement, au lieu de s'appuyer seulement sur les abandons de paquets. Il y a là un potentiel de réduction de l'impact des pertes sur les flux sensibles à la latence.

Il existe des boîtiers de médiation (pare-feu, équilibreurs de charge, ou système de détection d'intrusion) dans l'Internet qui abandonnent un paquet SYN TCP configuré pour négocier ECN, ou répondent par un RST (Réinitialisation de la connexion, RFC793). Le présent document spécifie les procédures que les mises en œuvre de TCP peuvent utiliser pour fournir une connexité robuste même en la présence de tels équipements.

Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDE", "NON RECOMMANDE", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans le BCP 14, RFC 2119.

Dans cette section, on décrit les principes et hypothèses de conception importants pour guider les choix de cette proposition.

* Parce que ECN sera vraisemblablement adopté graduellement, préparer la migration est essentiel. Certains routeurs peuvent encore seulement abandonner des paquets pour indiquer l'encombrement, et certains systèmes d'extrémité peuvent n'avoir pas la capacité ECN. La stratégie la plus viable est celle qui s'accommode de développements par incréments sans avoir recours à des "îlots" d'environnements capables de ECN et d'autres environnements sans cette capacité.

* Les nouveaux mécanismes de contrôle et d'évitement de l'encombrement doivent coexister et coopérer avec les mécanismes existants de contrôle de l'encombrement. En particulier, les nouveaux mécanismes doivent coexister avec les méthodes actuelles de TCP d'adaptation à l'encombrement et avec la pratique actuelle des routeurs d'abandon des paquets dans les périodes d'encombrement.

* L'encombrement peut persister sur des échelles de temps différentes. L'échelle de temps qui nous concerne avec les événements d'encombrement est celle de ceux qui peuvent durer plus longtemps qu'un délai d'aller-retour.

* Le nombre de paquets dans un flux individuel (par exemple, une connexion TCP ou un échange utilisant UDP) peut aller d'un petit nombre de paquets à un assez grand nombre. Nous sommes intéressés par la gestion des encombrements causés par des flux qui envoient assez de paquets pour qu'ils soient encore actifs lorsque le retour du réseau les atteint.

* L'acheminement asymétrique va vraisemblablement être un phénomène normal sur l'Internet. Le chemin (séquence de liaisons et de routeurs) suivi par les paquets de données peut être différent du chemin suivi par l'accusé de réception des paquets dans la direction inverse.

* De nombreux routeurs traitent les en-têtes "réguliers" dans les paquets IP plus efficacement qu'ils ne traitent les informations d'en-tête dans les options IP. Cela suggère de garder les informations sur l'encombrement rencontré dans les en-têtes réguliers d'un paquet IP.

* On doit reconnaître que tous les systèmes d'extrémité ne vont pas coopérer aux mécanismes de contrôle de l'encombrement. Cependant, les nouveaux mécanismes ne devraient pas rendre plus facile aux applications TCP de désactiver le contrôle d'encombrement TCP. Le bénéfice d'un mensonge sur la participation aux nouveaux mécanismes tels que la capacité ECN devrait être minime.

La détection précoce aléatoire (RED, Random Early Detection) est un des mécanismes de la gestion active de file d'attente (AQM, Active Queue Management) qui ont été proposés pour détecter l'encombrement naissant [FJ93], et il est actuellement déployé dans l'Internet [RFC2309]. AQM est destiné à être un mécanisme général utilisant une des solutions de remplacement pour indiquer l'encombrement, mais en l'absence de ECN, AQM se restreint à utiliser l'abandon de paquet comme mécanisme d'indication d'encombrement. AQM abandonne les paquets sur la base de la longueur moyenne de la file d'attente dépassant un seuil, plutôt que seulement quand la file d'attente déborde. Cependant, parce que AQM peut abandonner des paquets avant que la file d'attente ne déborde réellement, AQM n'est pas toujours forcé d'éliminer le paquet par les limitations de mémoire.

AQM peut établir un codet Encombrement (CE, Congestion Experienced) dans l'en-tête de paquet au lieu d'abandonner le paquet, lorsque un tel champ est fourni dans l'en-tête IP et est compris par le protocole de transport. L'utilisation du codet CE avec ECN permet aux receveurs de recevoir le paquet, évitant le risque de retards excessifs dus aux retransmissions après la perte du paquet. On utilise le terme "paquet CE" pour noter un paquet où le codet CE est établi.

Le présent document spécifie que l'Internet fournit une indication d'encombrement pour un encombrement naissant (comme dans RED et dans un travail précédent [RJ90]) où la notification peut parfois se faire par le marquage de paquets plutôt que par leur abandon. Cela utilise un champ ECN dans l'en-tête IP avec deux bits, faisant quatre codets ECN, '00' à '11'. Les codets Transport à capacité ECN (ECT, ECN-Capable Transport) '10' et '01' sont établis par l'envoyeur des données pour indiquer que les points d'extrémité du protocole de transport sont capables d'ECN ; on les appelle respectivement ECT(0) et ECT(1). Dans le présent document, la phrase "le codet ECT" se réfère à l'un ou l'autre des deux codets ECT. Les routeurs traitent les codets ECT(0) et ECT(1) comme équivalents. Les envoyeurs ont toute liberté pour utiliser le codet ECT(0) ou le codet ECT(1) pour indiquer ECT, paquet par paquet.

L'utilisation des deux codets pour ECT, ECT(0) et ECT(1), est principalement motivée par le désir de permettre aux mécanismes d'envoi des données de vérifier que les éléments du réseau n'écrasent pas le codet CE, et que le receveur des données fait correctement rapport à l'envoyeur de la réception des paquets avec le codet CE mis, comme requis par le protocole de transport. Les lignes directrices pour que les envoyeurs et receveurs fassent la différence entre les codets ECT(0) et ECT(1) seront traitées dans des documents distincts, pour chaque protocole de transport. En particulier, le présent document ne traite pas les mécanismes pour que les nœuds d'extrémité TCP fassent la différence entre les codets ECT(0) et ECT(1). Les protocoles et envoyeurs qui n'exigent qu'un seul codet ECT DEVRAIT utiliser ECT(0).

Le codet non-ECT '00' indique qu'un paquet n'utilise pas ECN. Le codet CE '11' est mis par un routeur pour indiquer l'encombrement aux nœuds d'extrémité. Les routeurs qui ont un paquet qui arrive sur une file d'attente pleine abandonnent le paquet, exactement comme ils le font en l'absence d'ECN.

L'utilisation des deux codets ECT donne essentiellement un nom occasionnel ECN d'un bit dans les en-têtes de paquet, et les routeurs "écrasent" nécessairement le nom occasionnel lorsque ils établissent le codet CE [SCWA99]. Par exemple, les routeurs qui écrasent le codet CE vont faire face à de nouvelles difficultés pour reconstruire le nom occasionnel original, et donc l'écrasement répété du codet CE va très vraisemblablement être détecté par les nœuds d'extrémité. Le nom occasionnel ECN peut aussi régler le problème de la mauvaise conduite des receveurs de transport qui mentent à l'envoyeur du transport sur la question de savoir si le codet CE était ou non établi dans un paquet. Les motifs de l'utilisation des deux codets ECT sont exposés plus en détails dans la Section 20, avec une discussion sur les possibilités de remplacement pour le quatrième codet ECT (c'est à dire, le codet '01'). La rétrocompatibilité avec les mises en œuvre précoces de ECN qui ne comprennent pas le codet ECT(1) est exposée dans la Section 11.

Dans la [RFC2481], le champ ECN était divisé en bit Transport à capacité ECN (ECT) et bit CE. Le champ ECN avec le seul bit Transport à capacité ECN (ECT) mis à 1 de la RFC 2481 correspond au codet ECT(0) dans le présent document, et le champ ECN avec les deux bits ECT et CE de la RFC 2481 correspond au codet CE dans le présent document. Le codet '01' a été laissé indéfini dans la RFC 2481, et c'est la raison pour laquelle on recommande l'utilisation de ECT(0) lorsqu'on a seulement besoin d'un seul codet ECT.

0	1	2	3	4	5	6	7
Champ DS, DSCP						Champ ECN

Les bits 6 et 7 de l'octet de TOS IPv4 sont appelés le champ ECN. L'octet de TOS IPv4 correspond à l'octet Classe de trafic dans IPv6, et le champ ECN est défini de façon identique dans les deux cas. Les définitions pour l'octet TOS IPv4 [RFC791] et l'octet Classe de trafic IPv6 ont été remplacées par le champ de six bits DS (Services différenciés) des [RFC2474, RFC2780]. Les bits 6 et 7 figurent dans la [RFC2474] comme actuellement non utilisés, et sont spécifiés dans la [RFC2780] comme approuvés en utilisation expérimentale pour ECN. La Section 22 donne un bref historique de l'octet TOS.

À cause de l'histoire instable de l'octet TOS, l'utilisation du champ ECN comme spécifiée dans le présent document ne peut pas être garantie comme rétro compatible avec les utilisations passées de ces deux bits qui datent d'avant ECN. Les dangers potentiels de ce manque de rétro compatibilité sont exposés à la Section 22.

À réception par un transport à capacité ECN d'un seul paquet CE, les algorithmes de contrôle d'encombrement qui sont suivis par les systèmes d'extrémité DOIVENT être essentiellement les mêmes que la réponse de contrôle d'encombrement à un *seul* paquet abandonné. Par exemple, pour TCP à capacité ECN, le TCP de source est requis de diminuer par deux sa fenêtre d'encombrement pour toute fenêtre de données contenant soit un abandon de paquet soit une indication ECN.

Une raison pour exiger que la réponse de contrôle d'encombrement au paquet CE soit essentiellement la même que la réponse à un paquet abandonné est de s'accommoder du déploiement incrémentaire de ECN à la fois dans les systèmes d'extrémité et dans les routeurs. Certains routeurs peuvent abandonner des paquets à capacité ECN (par exemple, en utilisant les mêmes politiques AQM pour la détection d'encombrement) alors que d'autres routeurs établissent le codet CE, pour des niveaux d'encombrement équivalents. De même, un routeur pourrait abandonner un paquet non capable d'ECN mais établir le codet CE dans un paquet à capacité ECN, pour des niveaux d'encombrement équivalents. Si il y avait des réponses de contrôle d'encombrement différentes à un codet CE et à un abandon de paquet, il pourrait en résulter un traitement inéquitable pour les différents flux.

Un objectif supplémentaire est que les systèmes d'extrémité devraient réagir à l'encombrement au plus une fois par fenêtre de données (c'est-à-dire, au plus une fois par délai d'aller-retour) pour éviter de réagir plusieurs fois à plusieurs indications d'encombrement dans un même aller-retour.

Pour un routeur, le codet CE d'un paquet à capacité ECN DEVRAIT n'être établi que si le routeur aurait autrement abandonné le paquet comme indication d'encombrement aux nœuds d'extrémité. Lorsque la mémoire tampon d'un routeur n'est pas encore pleine et que le routeur est prêt à abandonner un paquet pour informer les nœuds d'un encombrement naissant, le routeur devrait d'abord vérifier pour voir si le codet ECT est mis dans l'en-tête IP de ce paquet. S'il en est ainsi, au lieu d'abandonner le paquet, le routeur PEUT alors plutôt établir le codet CE dans l'en-tête IP.

Un environnement dans lequel tous les nœuds d'extrémité seraient à capacité ECN pourrait permettre de développer de nouveaux critères pour régler le codet CE, et de nouveaux mécanismes de contrôle d'encombrement pour la réaction des nœuds d'extrémité aux paquets CE. Cependant, c'est encore un sujet de recherches, et n'est donc pas traité dans le présent document.

Lorsque un paquet CE (c'est-à-dire, un paquet qui a le codet CE établi) est reçu par un routeur, le codet CE est laissé inchangé, et le paquet est transmis comme d'habitude. Lorsque un encombrement sévère survient et que la file d'attente du routeur est pleine, le routeur n'a alors pas d'autre choix que d'abandonner un paquet lorsqu'il en arrive un nouveau. On prévoit que de telles pertes de paquets deviendront relativement peu fréquentes lorsque une majorité des systèmes d'extrémité deviendront à capacité ECN et participeront à TCP ou à d'autres mécanismes de contrôle d'encombrement compatibles. Dans un environnement à capacité ECN qui est adéquatement provisionné, les pertes de paquets devraient principalement survenir de façon transitoire ou en présence de sources non coopératives.

La discussion ci-dessus sur le moment où CE peut être établi plutôt que d'abandonner un paquet s'applique par défaut à tous les comportements bond par bond (PHB, Per-Hop Behavior) de services différenciés [RFC2475]. Les spécifications de PHB PEUVENT être plus spécifiques sur la façon dont les mises en œuvre conformes vont choisir entre établir CE et abandonner un paquet, mais ceci N'EST PAS EXIGÉ. Un routeur NE DOIT PAS établir CE au lieu d'abandonner un paquet lorsque l'abandon qui surviendrait serait causé par des raisons autres que l'encombrement ou le désir d'indiquer un encombrement naissant aux nœuds d'extrémité (par exemple, un nœud bordure diffserv peut être configuré pour abandonner inconditionnellement certaines classes de trafic pour les empêcher d'entrer dans son domaine diffserv).

Il est prévu que les routeurs établissent le codet CE en réponse à un encombrement naissant comme indiqué par la taille moyenne de file d'attente, en utilisant les algorithmes RED suggérés dans [FJ93, RFC2309]. À notre connaissance, c'est la seule proposition actuellement en discussion dans l'IETF pour que les routeurs abandonnent activement des paquets, avant le débordement de mémoire tampon. Cependant, le présent document n'essaye pas de spécifier un mécanisme particulier pour une gestion active de file d'attente, laissant cette entreprise, si nécessaire, à d'autres domaines de l'IETF. Alors que ECN est inextricablement lié au besoin d'un mécanisme raisonnable de gestion active de file d'attente au niveau du routeur, l'inverse n'est pas vrai ; des mécanismes de gestion active de file d'attente ont été développés et déployés indépendamment de ECN, utilisant l'abandon de paquet comme indications d'encombrement en l'absence de ECN dans l'architecture IP.

On souligne que un *seul* paquet avec le codet CE établi dans un paquet IP cause la réponse de la couche transport, en termes de contrôle d'encombrement, comme elle le ferait à un abandon de paquet. La taille instantanée de la file d'attente va vraisemblablement connaître des variations considérables même lorsque le routeur ne rencontre pas d'encombrement persistant. À ce titre, il est important qu'un encombrement transitoire à un routeur, reflété par la taille instantanée de la file d'attente qui atteint un seuil beaucoup plus petit que la capacité de la file d'attente, ne déclanche pas une réaction à la couche transport. Donc, le codet CE ne devrait pas être établi par un routeur sur la base de la taille instantanée de la file d'attente.

Par exemple, comme les mécanismes ATM et relais de trame pour l'indication d'encombrement ont normalement été définis sans la notion associée de taille moyenne de file d'attente comme base de détermination de l'encombrement d'un nœud intermédiaire, nous pensons qu'ils fournissent un signal très bruyant. La réaction de l'envoyeur TCP spécifiée dans le présent document pour ECN N'EST PAS la réaction appropriée pour un signal de notification d'encombrement aussi bruyant. Cependant, si les routeurs qui font l'interface avec le réseau ATM ont un moyen de maintenir la file d'attente moyenne à l'interface, et de l'utiliser pour arriver à une détermination fiable de l'encombrement du sous-réseau ATM, ils peuvent utiliser la notification ECN qui est définie ici.

Nous continuons d'encourager les expériences de techniques de couche 2 (par exemple, dans les commutateurs ATM ou de relais de trame) pour tirer parti de ECN. Par exemple, en utilisant un schéma tel que RED (où le marquage de paquet se fonde sur la longueur moyenne de file d'attente au delà d'un seuil) les appareil de couche 2 pourraient fournir une indication raisonnablement fiable de l'encombrement. Lorsque tous les appareils de couche 2 d'un chemin établissent le propre codet Encombrement de cette couche (par exemple, le bit EFCI pour ATM, le bit FECN en relais de trame) de cette façon fiable, le routeur qui fait l'interface avec ce réseau de couche 2 pourrait copier l'état de ce codet Encombrement de couche 2 dans le codet CE dans l'en-tête IP. Nous reconnaissons que ce n'est pas la pratique courante, ni que c'est dans les normes habituelles. Cependant, encourager les expérimentation dans ce domaine peut fournir les informations nécessaires pour permettre l'évolution des mécanismes existants de couche 2 pour fournir un moyen plus fiable d'indiquer l'encombrement, lorsque elles utilisent un seul bit pour indiquer l'encombrement.

Pour l'utilisation d'ECN proposée dans le présent document (c'est à dire, pour un protocole de transport tel que TCP pour lequel l'abandon d'un paquet de données est une indication d'encombrement), les nœuds d'extrémité détectent les paquets de données abandonnés, et la réponse d'encombrement des nœuds d'extrémité à un paquet de données abandonné est au moins aussi forte que la réponse d'encombrement à la réception d'un paquet CE. Pour s'assurer de la livraison fiable de l'indication d'encombrement du codet CE, un codet ECT NE DOIT PAS être établi dans un paquet à moins que la perte de ce paquet dans le réseau ne soit détectée par les nœuds d'extrémité et interprétée comme une indication d'encombrement.

Les protocoles de transport tels que TCP ne détectent pas nécessairement tous les abandons de paquet, comme l'abandon d'un "pur" paquet ACK ; par exemple, TCP ne réduit pas le taux d'arrivée des paquets ACK suivants en réponse à l'abandon d'un précédent paquet ACK. Toute proposition d'extension de la capacité ECN à de tels paquets devrait régler des problèmes comme le cas d'un paquet ACK marqué avec le codet CE mais abandonné ensuite dans le réseau. Nous pensons que cet aspect fait toujours l'objet d'études, de sorte que le présent document spécifie pour l'instant que les paquets ACK "purs" NE DOIVENT PAS indiquer la capacité ECN.

De même, si un paquet CE est abandonné ultérieurement dans le réseau parce qu'il est corrompu (erreurs binaires) les nœuds d'extrémité devraient encore invoquer le contrôle d'encombrement, tout comme le ferait aujourd'hui TCP en réponse à un paquet de données abandonné. Cette question des paquets CE corrompus devrait être prise en considération dans toute proposition que le réseau fasse la distinction entre les paquets abandonnés du fait de corruption, et les paquets abandonnés du fait de l'encombrement ou de la saturation de la mémoire tampon. En particulier, le déploiement général d'ECN ne serait pas par lui-même un développement suffisant pour permettre aux nœuds d'extrémité d'interpréter les abandons de paquet comme des indications de corruption plutôt que d'encombrement.

Les paquets à capacité ECN PEUVENT avoir le bit DF (Ne pas fragmenter) établi. Le réassemblage d'un paquet fragmenté NE DOIT PAS perdre les indications d'encombrement. En d'autres termes, si un fragment quelconque d'un paquet IP à réassembler a le codet CE établi, une des deux actions suivantes DOIT être entreprise :

* établir le codet CE sur le paquet réassemblé. Cependant, ceci NE DOIT PAS survenir si un des autres fragments qui contribuent à ce réassemblage porte le codet Non-ECT ;

* le paquet est abandonné, au lieu d'être réassemblé, pour une autre raison.

Si les deux actions sont applicables, l'une ou l'autre PEUT être choisie. Le réassemblage d'un paquet fragmenté NE DOIT PAS changer le codet ECN lorsque tous les fragments portent le même codet.

On notera que parce que la [RFC2481] ne spécifiait pas de comportement de réassemblage, les anciennes mises en œuvre d'ECN conformes à cette RFC expérimentale n'effectuaient pas nécessairement correctement le réassemblage, en termes de préservation du codet CE dans un fragment. L'envoyeur pourrait éviter les conséquences de ce comportement en établissant le bit DF dans les paquets à capacité ECN.

Il peut se trouver des situations dans lesquelles la spécification de réassemblage ci-dessus est insuffisamment précise. Par exemple, si il y a une entité malveillante ou déficiente sur le chemin après le point de fragmentation, les fragments de paquet pourraient porter un mélange de codets ECT(0), ECT(1), et/ou Non-ECT. La spécification de réassemblage ci-dessus ne pose pas d'exigence sur le réassemblage des fragments dans ce cas. Dans les situations où serait nécessaire un comportement de réassemblage plus précis, les spécifications de protocole DEVRAIENT plutôt spécifier que DF DOIT être établi dans tous les paquets à capacité ECN envoyés par le protocole.

ECN exige la prise en charge de la part du protocole de transport, en plus de la fonctionnalité donnée par le champ ECN dans l'en-tête de paquet IP. Le protocole de transport peut exiger la négociation entre les points d'extrémité durant l'établissement pour déterminer que tous les points d'extrémité sont à capacité ECN, de sorte que l'envoyeur peut établir le codet ECT dans les paquets transmis. Ensuite, le protocole de transport doit être capable de réagir de façon appropriée à la réception de paquets CE. Cette réaction pourrait prendre la forme d'une information par le receveur des données à l'envoyeur de la réception du paquet CE (par exemple, TCP), du receveur des données qui se désabonne d'un groupe de diffusion groupée en couches (par exemple, RLM [MJV96]), ou de quelque autre action qui réduise en fin de compte le taux d'arrivée de ce flux sur cette liaison encombrée. Les paquets CE indiquent un encombrement persistant plutôt que transitoire (voir au paragraphe 5.1) et donc les réactions à la réception de paquets CE devraient être celles appropriées pour l'encombrement persistant.

Le présent document ne vise que l'ajout de la capacité ECN à TCP, laissant les questions d'ECN dans les autres protocoles de transport à des études ultérieures. Pour TCP, ECN exige trois nouvelles fonctionnalités : la négociation entre les points d'extrémité durant l'établissement de la connexion pour déterminer si ils sont tous deux à capacité ECN ; un fanion ECN-Echo (ECE) dans l'en-tête TCP de telle sorte que le receveur des données puisse informer l'envoyeur des données de la réception d'un paquet CE ; et un fanion Réduction de fenêtre d'encombrement (CWR, Congestion Window Reduced) dans l'en-tête TCP de telle sorte que l'envoyeur des données puisse informer le receveur des données de ce que la fenêtre d'encombrement a été réduite. La prise en charge requise de la part des autres protocoles de transport sera vraisemblablement différente, en particulier pour les protocoles de transport de diffusion groupée fiables et non fiables, et devra être déterminée lorsque d'autres protocoles de transport seront proposés pour normalisation à l'IETF.

Par un léger abus de langage, on se réfère dans ce document à des "paquets TCP" au lieu de "segments TCP".

Les paragraphes qui suivent décrivent en détail l'utilisation proposée d'ECN dans TCP. Cette proposition est décrite essentiellement sous la même forme que dans [Floyd94]. On suppose que la source TCP utilise les algorithmes standard de contrôle d'encombrement Démarrage lent (Slow-start), Retransmission rapide (Fast Retransmit) et Récupération rapide (Fast Recovery) [RFC2581].

Cette proposition spécifie deux nouveaux fanions dans le champ Réservé de l'en-tête TCP. Le mécanisme TCP pour négocier la capacité ECN utilise le fanion ECN-Echo (ECE) dans l'en-tête TCP. Le bit 9 dans le champ Réservé de l'en-tête TCP est conçu comme étant le fanion ECN-Echo. La localisation du champ Réservé de six bits dans l'en-tête TCP est montrée à la Figure 4 de la [RFC793] (et est reproduite ci-dessous). Cette spécification du champ ECN laisse le champ Réservé comme un champ de 4 bits utilisant les bits 4 à 7.

Pour permettre au receveur TCP de déterminer quand arrêter d'établir le fanion ECN-Echo, on introduit un second nouveau fanion dans l'en-tête TCP, le fanion CWR. Le fanion CWR est alloué au bit 8 dans le champ Réservé de l'en-tête TCP.

Et donc, ECN utilise les fanions ECT et CE dans l'en-tête IP (comme montré à la Figure 1) pour la signalisation entre les routeurs et les points d'extrémité de connexion, et utilise les fanions ECN-Echo et CWR dans l'en-tête TCP (comme montré à la Figure 4) pour la signalisation de point d'extrémité TCP à point d'extrémité TCP. Pour une connexion TCP, une séquence d'événements normale dans une réaction à l'encombrement fondée sur ECN est comme suit :

* Un codet ECT est établi dans les paquets transmis par l'envoyeur pour indiquer qu'ECN est pris en charge par les entités de transport pour ces paquets.

* Un routeur à capacité ECN détecte un encombrement imminent et détecte qu'un codet ECT est mis dans le paquet qu'il est sur le point d'abandonner. Au lieu d'abandonner le paquet, le routeur choisit de mettre le codet CE dans l'en-tête IP et de transmettre le paquet.

* Le receveur reçoit le paquet avec le codet CE mis, et met le fanion ECN-Echo dans son prochain ACK TCP à l'envoyeur.

* L'envoyeur reçoit l'ACK TCP avec ECN-Echo mis, et réagit à l'encombrement comme si un paquet avait été abandonné.

* L'envoyeur met le fanion CWR dans l'en-tête TCP du prochain paquet envoyé au receveur pour accuser réception et réagir au fanion ECN-Echo.

La négociation pour l'utilisation d'ECN par les entités de transport TCP et l'utilisation des fanions ECN-Echo et CWR est décrite plus en détail dans les paragraphes qui suivent.

6.1.1 Initialisation TCP

Dans la phase d'établissement de la connexion TCP, la source et la destination TCP échangent des informations sur leur volonté d'utiliser ECN. Suite à l'achèvement de cette négociation, l'envoyeur TCP établit un codet ECT dans l'en-tête IP des paquets de données pour indiquer au réseau que le transport est capable de participer à ECN pour ce paquet et volontaire pour le faire. Cela indique aux routeurs qu'ils peuvent marquer ce paquet avec le codet CE, si il veulent utiliser cela comme méthode de notification d'encombrement. Si la connexion TCP ne souhaite pas utiliser la notification ECN pour un paquet particulier, le TCP qui envoie met le codet ECN à Non-ECT, et le receveur TCP ignorera le codet CE dans le paquet reçu.

Pour cet exposé, on appelle l'hôte initiateur hôte A et l'hôte qui répond hôte B. On appelle un paquet SYN avec les fanions ECE et CWR mis un "paquet SYN à ECN établi", et on appelle un paquet SYN avec au moins le fanion ECE ou CWR non mis un "paquet SYN à ECN non établi". De même, on appelle un paquet SYN-ACK avec seulement le fanion ECE mis mais le fanion CWR non mis un "paquet SYN-ACK à ECN établi", et on appelle un paquet SYN-ACK avec une autre configuration des fanions ECE et CWR un "paquet SYN-ACK à ECN non établi".

Avant qu'une connexion TCP puisse utiliser ECN, l'hôte A envoie un paquet SYN ECN établi, et l'hôte B envoie un paquet SYN-ACK ECN établi. Pour un paquet SYN, l'établissement des deux fanions ECE et CWR dans le paquet SYN ECN établi est défini comme une indication que le TCP qui envoie est à capacité ECN, plutôt qu'une indication d'encombrement ou d'une réponse d'encombrement. Plus précisément, un paquet SYN ECN établi indique que la mise en œuvre TCP qui transmet le paquet SYN va participer à ECN à la fois comme envoyeur et comme receveur. Précisément, comme receveur, elle va répondre aux paquets de données entrants qui ont le codet CE établi dans l'en-tête IP en établissant ECE dans les paquets d'accusé de réception (ACK) TCP sortants. Comme envoyeur, elle va répondre aux paquets entrants qui ont ECE établi en réduisant la fenêtre d'encombrement et en établissant CWR lorsque c'est approprié. Un paquet SYN ECN établi n'oblige pas l'envoyeur TCP à établir le codet ECT dans un ou dans tous les paquets qu'il peut transmettre. Cependant, l'obligation de répondre de façon appropriée aux paquets entrants avec le codet CE mis subsiste même si l'envoyeur TCP dans une transmission ultérieure, au sein de cette connexion TCP, envoie un paquet SYN sans ECE et CWR établis.

Lorsque l'hôte B envoie un paquet SYN-ACK ECN établi, il règle le fanion ECE mais pas le fanion CWR. Un paquet SYN-ACK ECN établi est défini comme une indication que le TCP qui transmet le paquet SYN-ACK est à capacité ECN. Comme avec le paquet SYN, un paquet SYN-ACK ECN établi n'oblige pas l'hôte TCP à établir le codet ECT dans les paquets transmis.

Les règles suivantes s'appliquent à l'envoi de paquets ECN établi au sein d'une connexion TCP, où une connexion TCP est définie par les règles standard pour l'établissement et la terminaison de connexion TCP.

* Si un hôte a reçu un paquet SYN ECN établi, il PEUT alors envoyer un paquet SYN-ACK ECN établi. Autrement, il NE DOIT PAS envoyer un paquet SYN-ACK ECN établi.

* Un hôte NE DOIT PAS établir ECT sur des paquets de données sauf si il a envoyé au moins un paquet SYN ou SYN-ACK ECN établi, et a reçu au moins un paquet SYN ou SYN-ACK ECN établi, et n'a pas envoyé de paquet SYN ou SYN-ACK non-ECN. Si un hôte a reçu au moins un paquet SYN ou SYN-ACK non-ECN, il NE DEVRAIT PAS alors établir ECT sur les paquets de données.

* Si un hôte établit le codet ECT sur un paquet de données, cet hôte DOIT alors établir/supprimer correctement le bit TCP CWR sur tous les paquets suivants dans la connexion.

* Si un hôte a envoyé au moins un paquet SYN ou SYN-ACK ECN établi, et n'a pas reçu de paquet SYN ou SYN-ACK non-ECN, si cet hôte reçoit alors des paquets de données TCP avec les codets ECT et CE mis dans l'en-tête IP, cet hôte DOIT alors traiter ces paquets comme spécifié pour une connexion à capacité ECN.

* Un hôte qui ne veut pas utiliser ECN sur une connexion TCP DEVRAIT supprimer les deux fanions ECE et CWR dans tous les paquets SYN et/ou SYN-ACK non-ECN qu'il envoie pour indiquer cette décision. Les receveurs DOIVENT traiter correctement toutes les formes de paquets SYN et SYN-ACK non-ECN.

Un client TCP entre dans l'état TIME-WAIT après avoir reçu un FIN-ACK, et passe à l'état CLOSED après une temporisation. De nombreuses mises en œuvre de TCP créent une nouvelle connexion TCP si elles reçoivent un paquet SYN dans la fenêtre durant l'état TIME-WAIT. Lorsque un hôte TCP entre dans l'état TIME-WAIT ou CLOSED, il devrait ignorer tout état antérieur sur la négociation de ECN pour cette connexion.

ECN introduit l'utilisation des fanions ECN-Echo et CWR dans l'en-tête TCP (comme montré à la Figure 3) pour l'initialisation. Il existe dans l'Internet des pare-feu fautifs, des équilibreurs de charge, et des systèmes de détection d'intrusion qui abandonnent un paquet SYN ECN établi ou répondent par un RST, croyant qu'un tel paquet (avec ces bits établis) sont la signature d'un outil d'examen des accès qui pourrait être utilisé dans une attaque de déni de service. Certains des équipements fautifs ont été identifiés, et une page de la Toile [FIXES] contient une liste des produits non conformes et les corrections envoyées par les fabricants, lorsque celles-ci sont disponibles. La page de la Toile [TBIT] fait la liste des serveurs de la Toile affectés par ces équipements fautifs. Nous mentionnons cela dans ce document à titre d'avertissement à la communauté sur ce problème.

Pour fournir une connexité robuste même en présence de tels équipements fautifs, un hôte qui reçoit un RST en réponse à la transmission d'un paquet SYN ECN établi PEUT renvoyer un SYN avec les fanions CWR et ECE supprimés (à zéro). Il pourrait en résulter l'établissement d'une connexion TCP sans utiliser ECN.

Un hôte qui ne reçoit pas de réponse à un SYN ECN établi durant l'intervalle normal de temporisation de retransmission SYN PEUT renvoyer le SYN et toutes les retransmissions SYN suivantes avec CWR et ECE à zéro. Pour surmonter la perte normale de paquet qui résulte de la perte du SYN original, l'hôte générateur peut retransmettre un ou plusieurs paquets SYN ECN établi avant d'abandonner et retransmettre le SYN avec les bits CWR et ECE à zéro.

(2) Hôte B : envoie un SYN/ACK ECN établi, le paquet est abandonné ou retardé.

Notons que dans ce cas, suivant les procédures ci-dessus, ni l'hôte A ni l'hôte B ne peuvent établir le bit ECT sur les paquets de données. De plus, une importante conséquence des règles d'établissement et d'utilisation d'ECN du paragraphe 6.1.1 est qu'il est interdit à un hôte d'utiliser la réception de paquets de données ECT comme signal implicite que l'autre hôte est à capacité ECN.

Il y a la question de savoir pourquoi on choisit d'avoir l'envoyeur du SYN TCP qui établit les deux fanions en rapport avec ECN dans le champ Réservé de l'en-tête TCP pour le paquet SYN, alors que le répondant TCP qui envoie le SYN-ACK établit seulement un fanion en rapport avec ECN dans le paquet SYN-ACK. Cette asymétrie est nécessaire pour la robustesse de la négociation de la capacité ECN avec certaines mises en œuvre existantes de TCP. Il existe au moins une mise en œuvre TCP fautive dans laquelle les receveurs TCP établissent le champ Réservé de l'en-tête TCP dans les paquets ACK (et donc le SYN-ACK) simplement pour refléter le champ Réservé de l'en-tête TCP dans le paquet de données reçu. Parce que le paquet SYN TCP établit les fanions ECN-Echo et CWR pour indiquer la capacité ECN, alors que le paquet SYN-ACK établit seulement le fanion ECN-Echo, le TCP d'envoi interprète correctement le reflet par un receveur de ses propres fanions dans le champ Réservé comme indication que le receveur n'est pas à capacité ECN. Le TCP d'envoi n'est pas trompé par une mise en œuvre TCP fautive qui envoie un paquet SYN-ACK qui reflète simplement le champ Réservé du paquet SYN entrant.

6.1.2 Envoyeur TCP

Pour une connexion TCP qui utilise ECN, de nouveaux paquets de données sont transmis avec un codet ECT établi dans l'en-tête IP. Lorsque seulement un codet ECT est nécessaire à un envoyeur pour tous les paquets envoyés sur une connexion TCP, ECT(0) DEVRAIT être utilisé. Si l'envoyeur reçoit un paquet ACK ECN-Echo (ECE) (c'est-à-dire, un paquet ACK avec le fanion ECN-Echo établi dans l'en-tête TCP) l'envoyeur sait alors que de l'encombrement a été rencontré dans le réseau sur le chemin allant de l'envoyeur au receveur. L'indication d'encombrement devrait être traitée juste comme une perte due à l'encombrement dans un TCP non-ECN. C'est à dire que la source TCP divise par deux la fenêtre d'encombrement "cwnd" et réduit le seuil de démarrage lent "ssthresh". Le TCP envoyeur NE DEVRAIT PAS augmenter la fenêtre d'encombrement en réponse à la réception d'un paquet ACK ECN-Echo.

TCP ne devrait pas réagir aux indications d'encombrement plus d'une fois par fenêtre de données (ou de façon moins stricte, plus d'une fois par délai d'aller-retour). C'est à dire que la fenêtre d'encombrement de l'envoyeur TCP ne devrait être réduite qu'une seule fois en réponse à une série de paquets CE et/ou abandonnés sur une seule fenêtre de données. De plus, la source TCP ne devrait pas diminuer le seuil de démarrage lent, ssthresh, si elle l'a déjà diminué durant le dernier temps d'aller-retour. Cependant, si des paquets retransmis sont abandonnés, c'est alors interprété par la source TCP comme une nouvelle instance d'encombrement.

Après que la source TCP a réduit sa fenêtre d'encombrement en réponse à un paquet CE, les accusés de réception entrants qui continuent d'arriver peuvent "pointer" les paquets sortants autant que le permet la fenêtre d'encombrement réduite. Si la fenêtre d'encombrement consiste seulement en un MSS (taille maximum de segment) et si le TCP d'envoi reçoit un paquet ACK d'ECN-Echo, le TCP d'envoi devrait alors en principe réduire encore sa fenêtre d'encombrement de moitié. Cependant, la valeur de la fenêtre d'encombrement a une limite inférieure de la valeur d'une MSS. Si le TCP d'envoi devait continuer ses envois, en utilisant une fenêtre d'encombrement de une MSS, il en résulterait la transmission d'un paquet par délai d'aller-retour. Il est nécessaire de réduire encore plus le taux d'envoi de l'envoyeur TCP, à réception d'un paquet ECN-Echo lorsque la fenêtre d'encombrement est de un. On utilise le temporisateur de retransmission comme moyen de réduire encore le taux dans ces circonstances. Donc, le TCP d'envoi DOIT remettre à zéro le temporisateur de retransmission à réception du paquet ECN-Echo lorsque la fenêtre d'encombrement est de un. Le TCP d'envoi ne sera alors capable d'envoyer un nouveau paquet qu'après l'arrivée à expiration du temporisateur de retransmission.

Lorsque un envoyeur TCP à capacité ECN réduit sa fenêtre d'encombrement pour une raison quelconque (à cause d'une fin de temporisation de retransmission, d'un Retransmission rapide, ou en réponse à une notification ECN) l'envoyeur TCP établit le fanion CWR dans l'en-tête TCP du premier nouveau paquet de données envoyé après la réduction de fenêtre. Si ce paquet de données est abandonné dans le réseau, le TCP d'envoi va alors devoir réduire à nouveau la fenêtre d'encombrement et retransmettre le paquet abandonné.

On s'assure que les informations de "Fenêtre d'encombrement réduite" sont livrées de façon fiable au receveur TCP. Cela vient à propos du fait que si le nouveau paquet de données qui porte le fanion CWR est abandonné, l'envoyeur TCP aura alors à réduire encore une fois sa fenêtre d'encombrement, et à envoyer un autre paquet de données avec le fanion CWR établi. Et donc, le bit CWR dans l'en-tête TCP NE DEVRAIT PAS être établi sur les paquets retransmis.

Lorsque l'envoyeur des données TCP est prêt à établir le bit CWR après avoir réduit la fenêtre d'encombrement, il DEVRAIT n'établir le bit CWR que dans le premier nouveau paquet de données qu'il transmet.

[Floyd94] discute des réponses de TCP à ECN plus en détail. [Floyd98] discute des essais de validation dans le simulateur ns, qui illustre une large gamme de scénarios ECN. Ces scénarios incluent le suivant : un ECN suivi par un autre ECN, un Retransmission rapide, ou un Fin de temporisation de retransmission ; un Fin de temporisation de retransmission ou un Retransmission rapide suivi par un ECN ; et une fenêtre d'encombrement de un paquet suivi par un ECN.

TCP suit les algorithmes existants pour l'envoi des paquets de données en réponse aux ACK entrants, pour les accusés de réception multiples dupliqués, ou pour les fin de temporisation de retransmission [RFC2581]. TCP suit aussi les procédures normales d'augmentation de la fenêtre d'encombrement lorsque il reçoit des paquets ACK sans le bit ECN-Echo établi [RFC2581].

6.1.3 Receveur TCP

Lorsque TCP reçoit un paquet de données CE sur le système d'extrémité de destination, le receveur des données TCP établit le fanion ECN-Echo dans l'en-tête TCP du paquet ACK suivant. Si un mécanisme quelconque de retrait de ACK est mis en œuvre, comme dans les applications TCP actuelles de "ACK retardé" où le receveur TCP peut envoyer un ACK pour deux paquets de données arrivés, le fanion ECN-Echo dans le paquet ACK sera mis à "1" si le codet CE est établi dans un des paquets de données dont il est accusé réception. C'est à dire que si un des paquets de données reçu est un paquet CE, le ACK retourné a le fanion ECN-Echo établi.

Pour permettre de surmonter la possibilité qu'un paquet ACK soit abandonné alors qu'il porte un fanion ECN-Echo, le receveur TCP établit le fanion ECN-Echo dans une série de paquets ACK envoyés à la suite les uns des autres. Le receveur TCP utilise le fanion CWR reçu de l'envoyeur TCP pour déterminer quand arrêter d'établir le fanion ECN-Echo.

Après qu'un receveur TCP a envoyé un paquet ACK avec le bit ECN-Echo établi, ce receveur TCP continue d'établir le fanion ECN-Echo dans tous les paquets ACK qu'il envoie (qu'ils accusent réception de paquets de données CE ou non-CE) jusqu'à ce qu'il reçoive un paquet CWR (un paquet avec le fanion CWR mis). Après la réception du paquet CWR, les accusés de réception pour les paquets de données non-CE suivants n'ont pas le fanion ECN-Echo mis. Si un autre paquet CE est reçu par le receveur des données, celui-ci va encore une fois envoyer des paquets ACK avec le fanion ECN-Echo mis. Alors que la réception d'un paquet CWR ne garantit pas que l'envoyeur des données a reçu le message ECN-Echo, cela suggère que l'envoyeur des données a réduit sa fenêtre d'encombrement à un certain point *après* l'envoi du paquet de données pour lequel le codet CE était mis.

Nous avons déjà précisé qu'un envoyeur TCP n'est pas obligé de réduire sa fenêtre d'encombrement plus d'une fois par fenêtre de données. Il faut faire attention si l'envoyeur TCP veut éviter des réductions inutiles de la fenêtre d'encombrement lorsque une fenêtre de données comporte à la fois des paquets abandonnés et des paquets CE (marqués). Ceci est illustré dans [Floyd98].

6.1.4 Encombrement sur le chemin de ACK

Pour la génération courante des algorithmes de contrôle d'encombrement sur TCP des paquets d'accusé de réception purs (par exemple, des paquets qui ne contiennent aucune données d'accompagnement) DOIVENT être envoyés avec le codet non-ECT. Les receveurs TCP courants n'ont aucun mécanisme pour réduire le trafic sur le chemin de ACK en réponse à la notification d' encombrement. Les mécanismes de réponse à l'encombrement sur le chemin de ACK sont des domaines de recherches actuelles et futures. (Une possibilité simple serait que l'envoyeur réduise sa fenêtre d'encombrement lorsque il reçoit un paquet ACK pur avec le codet CE mis). Pour les mises en œuvre actuelles de TCP, un seul ACK abandonné a généralement seulement un très petit effet sur le taux d'envoi de TCP.

6.1.5 Paquets TCP retransmis

Le présent document spécifie que les mises en œuvre de TCP à capacité ECN NE DOIVENT PAS établir le codet ECT (ECT(0) ou ECT(1)) dans l'en-tête IP pour les paquets de données retransmis, et que le receveur de données TCP DEVRAIT ignorer le champ ECN sur les paquets de données entrants qui sont en-dehors de la fenêtre actuelle du receveur. Ceci est destiné à une meilleure sécurité contre les attaques de déni de service, ainsi que pour la robustesse de l'indication d'encombrement ECN avec les paquets qui sont abandonnés plus tard dans le réseau.

D'abord, on note que si l'envoyeur TCP devait établir un codet ECT sur un paquet retransmis, et que si un paquet inutilement retransmis était ultérieurement abandonné dans le réseau, les nœuds d'extrémité ne recevraient jamais l'indication d'encombrement provenant du routeur qui établit le codet CE. Et donc, l'établissement d'un codet ECT sur des paquets de données retransmis n'est pas cohérent avec la livraison robuste de l'indication d'encombrement même pour les paquets qui sont ultérieurement abandonnés dans le réseau.

De plus, un attaquant capable de se faire passer pour l'adresse IP de source de l'envoyeur TCP pourrait envoyer des paquets de données avec des numéros de séquence arbitraires, avec le codet CE établi dans l'en-tête IP. À réception de ces paquets de données usurpés, le receveur des données TCP déterminerait que les données ne tiennent pas dans la fenêtre de réception actuelle et retournerait un accusé de réception dupliqué. On définit un paquet hors fenêtre chez le receveur des données TCP comme un paquet de données qui tombe en dehors de la fenêtre actuelle du receveur. À réception d'un paquet hors fenêtre, le receveur des données TCP doit décider si il va ou non traiter le codet CE dans l'en-tête du paquet comme une indication d'encombrement valide, et donc si il va retourner une indication ECN-Echo à l'envoyeur des données TCP. Si le receveur des données TCP ignorait le codet CE dans un paquet hors fenêtre, l'envoyeur des données TCP ne recevrait alors pas cette indication d'encombrement éventuellement légitime de la part du réseau, ce qui résulterait en une violation du contrôle d'encombrement de bout en bout. D'un autre côté, si le receveur des données TCP honore l'indication CE dans le paquet hors fenêtre, et fait rapport de l'indication d'encombrement à l'envoyeur des données TCP, le nœud malveillant qui a créé le paquet usurpé hors fenêtre aura réussi à attaquer la connexion TCP en forçant l'envoyeur des données à réduire sans nécessité (de moitié) sa fenêtre d'encombrement. Pour empêcher une attaque de déni de service, on spécifie qu'un envoyeur légitime de données TCP NE DOIT PAS établir un codet ECT sur les paquets de données retransmis, et que le receveur des données TCP DEVRAIT ignorer le codet CE sur les paquets hors fenêtre.

Un inconvénient de ne pas établir ECT(0) ou ECT(1) sur les paquets retransmis est que cela interdit la protection d'ECN pour les paquets retransmis. Cependant, pour une connexion TCP à capacité ECN dans un environnement entièrement à capacité ECN avec un encombrement modéré, les paquets devraient rarement être abandonnés du fait d'encombrement dans le premier endroit, et donc, des instances de paquets retransmis devraient rarement survenir. Si les paquets sont retransmis, c'est qu'il y a déjà des pertes de paquet (par corruption ou par encombrement) que ECN n'a pas été capable d'empêcher.

On note que si le routeur établit le codet CE pour un paquet de données à capacité ECN au sein d'une connexion TCP, il est alors garanti que la connexion TCP va recevoir cette indication d'encombrement, ou va recevoir quelque autre indication d'encombrement au sein de la même fenêtre de données, même si ce paquet est abandonné ou déclassé dans le réseau. On considère deux cas, lorsque le paquet est retransmis ultérieurement, et lorsque le paquet n'est pas retransmis ultérieurement.

Dans le premier cas, si le paquet est abandonné ou retardé, et à un certain moment retransmis par l'envoyeur des données, la retransmission est alors le résultat d'une Retransmission rapide ou d'une Fin de temporisation de retransmission, soit pour ce paquet, soit pour quelque paquet antérieur dans la même fenêtre de données. Dans ce cas, comme l'envoyeur des données a déjà retransmis ce paquet, on sait que l'envoyeur des données a déjà répondu à une indication d'encombrement pour un paquet au sein de la même fenêtre de données que celle du paquet d'origine. Et donc, même si la première transmission du paquet est abandonnée dans le réseau, ou est retardée, si il avait le codet CE établi, et si il est ultérieurement ignoré par le receveur des données comme paquet hors fenêtre, cela n'est pas un problème, parce que l'envoyeur a déjà répondu à une indication d'encombrement pour cette fenêtre de données.

Dans le second cas, si le paquet n'a jamais été retransmis par l'envoyeur des données, ce paquet de données est alors la seule copie de ces données reçue par le receveur des données, et donc qu'il arrive chez le receveur des données comme paquet dans la fenêtre, sans considération du temps pendant lequel le paquet a été retardé ou de combien il a été déclassé. Dans ce cas, si le codet CE est établi sur le paquet au sein du réseau, cela sera traité par le receveur des données comme une indication d'encombrement valide.

6.1.6 Sondes de fenêtre TCP

Lorsque le receveur des données TCP annonce une fenêtre de zéro, l'envoyeur des données TCP envoie des sondes de fenêtre pour déterminer si la fenêtre du receveur a augmenté. Les paquets de sonde de fenêtre ne contiennent aucune données d'usager sauf le numéro de séquence, qui est d'un octet. Si un paquet de sonde de fenêtre est abandonné dans le réseau, cette perte n'est pas détectée par le receveur. Donc, l'envoyeur de données TCP NE DOIT mettre ni un codet ECT ni le bit CWR sur les paquets de sonde de fenêtre.

Cependant, comme les sondes de fenêtre utilisent des numéros de séquence exacts, ils ne peuvent pas être facilement usurpés dans les attaques de déni de service. Donc, si une sonde de fenêtre arrive avec le codet CE mis, le receveur DEVRAIT alors répondre aux indications ECN.

La présente section discute des problèmes qui concernent la vulnérabilité de ECN aux nœuds d'extrémité non conformes (c'est-à-dire, les nœuds d'extrémité qui mettent le codet ECT dans les paquets transmis mais ne répondent pas aux paquets CE reçus). Nous expliquons que l'ajout de ECN à l'architecture IP ne va pas augmenter significativement la vulnérabilité actuelle de l'architecture aux flux qui ne répondent pas.

Même pour les environnements non-ECN, il y a de sérieux problèmes avec les dommages qui peuvent être causés par les flux non conformes ou qui ne répondent pas (c'est-à-dire, les flux qui ne répondent pas aux indications de contrôle d'encombrement en réduisant leur taux d'arrivée sur la liaison encombrée). Par exemple, un nœud d'extrémité pourrait "couper le contrôle d'encombrement" en ne réduisant pas sa fenêtre d'encombrement en réponse à des abandons de paquet. C'est un problème pour l'Internet actuel. Il a été avancé que les routeurs auront à déployer des mécanismes pour détecter et traiter de façon différenciée les paquets provenant de flux non conformes [RFC2309, FF99]. Il a aussi été suggéré que des techniques telles que la programmation et l'isolement de bout en bout flux par flux, des services différenciés, ou des réservations de bout en bout, pourraient supprimer certains des effets les plus dommageables des flux qui ne répondent pas.

Il pourrait sembler que par lui-même l'abandon de paquets soit une dissuasion adéquate pour la non conformité, et que l'utilisation de ECN supprime cette dissuasion. Nous répondons que (1) les routeurs à capacité ECN préservent le comportement d'abandon de paquet dans les périodes de fort encombrement ; et (2) même en période de fort encombrement, l'abandon des paquets n'est pas par lui-même une dissuasion adéquate pour la non conformité.

Tout d'abord, les routeurs à capacité ECN vont seulement marquer les paquets (au lieu de les abandonner) lorsque le taux de marquage de paquet est raisonnablement faible. Durant les périodes où la taille moyenne de file d'attente dépasse un seuil supérieur, et donc où le taux potentiel de marquage de paquet serait élevé, nous recommandons que les routeurs abandonnent les paquets plutôt que d'établir le codet CE dans les en-têtes de paquet.

Durant les périodes de taux de marquage de paquet faibles ou modérés où ECN sera déployé, il n'y aurait qu'un faible effet dissuasif à des flux qui ne répondent pas à l'abandon plutôt que de marquer ces paquets. Par exemple, des flux insensibles au retard qui utilisent la livraison fiable peuvent avoir une incitation à augmenter plutôt qu'à diminuer leur taux d'envoi en présence d'abandon de paquets. De même, des flux sensibles au retard qui utilisent une livraison non fiable peuvent augmenter leur utilisation de FEC en réponse à une augmentation du taux d'abandon de paquet, en accroissant plutôt qu'en diminuant leur taux d'envoi. Pou les mêmes raisons, nous ne croyons pas qu'en lui-même l'abandon de paquet soit une dissuasion efficace contre la non conformité même dans un environnement de fort taux d'abandon de paquet, lorsque tous les flux partagent le même taux d'abandon de paquet.

Plusieurs méthodes ont été proposées pour identifier et restreindre les flux non conformes ou sans réponse. L'ajout de ECN à l'environnement du réseau n'accroîtra en rien la difficulté de conception et de déploiement de tels mécanismes. Pour le moins, l'ajout de ECN à l'architecture facilitera légèrement l'identification des flux qui ne répondent pas. Par exemple, dans un environnement à capacité ECN, les routeurs ne sont pas limités aux informations sur les paquets qui sont abandonnés ou qui ont le codet CE mis à ce routeur lui-même ; dans un tel environnement, les routeurs pourraient aussi prendre note des CE de paquet arrivant qui indiquent l'encombrement rencontré par ce paquet plus tôt sur le chemin.

Cette section examine les questions qui se posent lorsqu'un routeur fonctionne, éventuellement de façon malveillante, pour modifier l'un ou l'autre des bits du champ ECN. On note que dans IPv4, l'en-tête IP est protégé de ces erreurs de bits par une somme de contrôle d'en-tête ; ce n'est pas le cas dans IPv6. Et donc pour IPv6 le champ ECN peut être accidentellement modifié par des erreurs binaires sur les liaisons ou dans les routeurs sans être détecté par une somme de contrôle d'en-tête IP.

En altérant les bits dans le champ ECN, un adversaire (ou un routeur détérioré) pourrait faire une ou plusieurs des actions suivantes : rapporter de faux encombrements, désactiver la capacité ECN pour un paquet individuel, écraser l'indication d'encombrement ECN, ou indiquer une fausse capacité ECN. La Section 18 examine systématiquement les divers cas de modification du champ ECN. Le critère important à considérer pour déterminer les conséquences de telles modifications est celui de la vraisemblance d'une dégradation du comportement dans une dimension quelconque (débit, délai, qualité ou fonctionnalités) par rapport à un abandon de paquet par le routeur.

Les deux premiers changements possibles, le faux rapport d'encombrement ou la désactivation de la capacité ECN pour un paquet individuel, ne sont pas pires que si le routeur devait simplement abandonner le paquet. Du point de vue du contrôle d'encombrement, régler le codet CE en l'absence d'encombrement par un routeur non conforme ne serait pas pire qu'un routeur qui abandonne un paquet sans nécessité. En "écrasant" un codet ECT d'un paquet qui est ensuite abandonné dans le réseau, l'action d'un routeur peut résulter en un abandon non nécessaire de ce paquet plus tard dans le réseau.

Cependant, comme exposé à la Section 18, un routeur qui écrase l'indication d'encombrement ECN ou indique faussement la capacité ECN pourrait éventuellement causer plus de dommages au flux que si il avait simplement abandonné le paquet. Un routeur malveillant ou défaillant qui "écrase" le codet CE dans les paquets CE arrivant empêcherait cette indication d'encombrement d'atteindre les receveurs vers l'aval. Il pourrait en résulter une défaillance du contrôle d'encombrement pour ce flux et une augmentation résultante de l'encombrement dans le réseau, avec pour résultat ultime d'autres abandons de paquets pour ce flux alors que la taille moyenne de file d'attente s'accroît au routeur encombré.

La Section 19 examine les répercussions potentielles de la subversion du contrôle d'encombrement de bout en bout soit par de fausses indications de capacité ECN soit par l'écrasement de l'indication d'encombrement dans ECN (du codet CE). On observe dans la Section 19 que la conséquence de la subversion du contrôle d'encombrement fondé sur ECN peut conduire à d'éventuelles inégalités, mais cela ne serait vraisemblablement pas pire que la subversion du contrôle d'encombrement fondé soit sur ECN soit sur l'abandon de paquet par les nœuds d'extrémité.

Si un routeur ou autre élément de réseau a accès à tous les paquets d'un flux, il ne pourrait pas causer plus de dommages à un flux en altérant le champ ECN qu'en abandonnant simplement tous les paquets de ce flux. Cependant, dans certains cas, un routeur malveillant ou défaillant pourrait avoir accès seulement à un sous-ensemble des paquets d'un flux. La question est la suivante : ce routeur peut-il, en altérant le champ ECN dans ce sous-ensemble des paquets, causer plus de dommages à ce flux que si il avait simplement abandonné cet ensemble de paquets ?

Ceci est aussi discuté en détail à la Section 18, qui tire la conclusion suivante : Il est vrai que l'adversaire qui a accès à seulement un sous-ensemble de paquets dans un agrégat pourrait, par subversion du contrôle d'encombrement fondé sur ECN, être capable de dénier le bénéfice d'ECN aux autres paquets de l'agrégat. Bien que ce soit indésirable, ce n'est pas un risque suffisant pour devoir désactiver ECN.

L'encapsulation d'en-têtes de paquet IP dans des tunnels est utilisée dans de nombreux endroits, y compris IPsec et IP dans IP [RFC2003]. Ce paragraphe examine les questions qui se rapportent aux interactions entre ECN et les tunnels IP, et spécifie deux solutions de remplacement. Cette discussion est complétée par celle de la RFC 2983 sur les interactions entre services différenciés et tunnels IP de diverses formes [RFC2983], car DifServ utilise les six bits restants de l'octet d'en-tête IP qui est utilisé par ECN (voir la Figure 2 de la Section 5).

Certains modes de tunnel IP se fondent sur l'ajout d'un nouvel en-tête IP "externe" qui encapsule celui d'origine, ou en-tête IP "interne" et son paquet associé. Dans de nombreux cas, le nouvel en-tête IP "externe" peut être ajouté et retiré à des points intermédiaires le long d'une connexion, permettant au réseau d'établir un tunnel sans exiger la participation de points d'extrémité. On appelle le tunnel qui spécifie que l'en-tête externe soit éliminé à la sortie du tunnel un "tunnel simple".

ECN utilise le champ ECN dans l'en-tête IP pour la signalisation entre routeurs et points d'extrémité de la connexion. ECN interagit avec les tunnels IP sur la base du traitement du champ ECN dans l'en-tête IP. Dans les tunnels simples IP, l'octet qui contient le champ ECN est copié ou transposé de l'en-tête IP interne à l'en-tête IP externe à l'entrée du tunnel IP, et la copie de l'en-tête externe de ce champ est éliminée à la sortie du tunnel IP. Si l'en-tête externe devait être simplement éliminé sans veiller à s'occuper du champ ECN, et si un routeur à capacité ECN devait établir le codet CE (Encombrement rencontré) au sein d'un paquet dans un tunnel simple IP, cette indication serait éliminée à la sortie du tunnel, perdant l'indication d'encombrement.

Et donc, l'utilisation de ECN sur un tunnel simple IP aurait pour résultat que des routeurs essayeraient d'utiliser l'en-tête IP externe pour signaler l'encombrement aux points d'extrémité, mais ces avertissements d'encombrement n'arriveraient jamais parce que l'en-tête externe est supprimé au point de sortie du tunnel. Ce problème a été rencontré avec ECN et IPsec en mode tunnel, et la RFC 2481 recommande que ECN ne soit pas utilisé avec l'ancien tunnel IPsec simple afin d'éviter ce comportement et ses conséquences. Lorsqu ECN deviendra largement utilisé, les tunnels simples qui ont des chances de porter du trafic à capacité ECN devront avoir été changés. Si un trafic à capacité ECN est porté par un simple tunnel à travers un routeur à capacité ECN encombré, il pourrait en résulter que les paquets suivants soient abandonnés parce que ce flux a une augmentation de la taille moyenne de file d'attente au routeur encombré, comme exposé à la Section 8 ci-dessus.

Du point de vue de la sécurité, l'utilisation de ECN dans l'en-tête externe d'un tunnel IP pourrait soulever des problèmes de sécurité parce qu'un adversaire pourrait altérer les informations ECN qui se propagent au delà du point d'extrémité du tunnel. Sur la base de l'analyse des Sections 18 et 19 sur ces problèmes et des risques qui en résultent, notre opinion globale est de faire de la prise en charge d'ECN une option pour les tunnels IP, de telle sorte qu'un tunnel IP puisse être spécifié ou configuré à utiliser ou non ECN dans l'en-tête externe du tunnel. Et donc, dans des environnements ou des protocoles de tunnelage où les risques de l'utilisation de ECN sont estimés dépasser ses bénéfices, le tunnel peut tout simplement ne pas utiliser ECN dans l'en-tête externe. La seule indication d'encombrement rencontrée alors au routeurs à l'intérieur du tunnel sera la perte de paquet.

Il en résulte qu'il y a deux options viables pour le comportement des connexions à capacité ECN sur un tunnel IP, y compris les tunnels IPsec :

* une option de fonctionnalité limitée dans laquelle ECN est préservé dans l'en-tête interne, mais désactivé dans l'en-tête externe. Le seul mécanisme disponible pour signaler l'encombrement survenant au sein du tunnel est dans ce cas l'abandon de paquets.

* une option de pleine fonctionnalité qui prend en charge ECN dans les deux en-têtes interne et externe, et propage les avertissements d'encombrement des nœuds aux sein du tunnel aux points d'extrémité.

La prise en charge de ces options exige des quantités variables de changements au traitement des en-têtes IP à l'entrée et la sortie du tunnel. Un petit sous-ensemble de ces changements suffisant pour prendre en charge seulement l'option de fonctionnalité limitée serait suffisant pour éliminer toute incompatibilité entre ECN et les tunnels IP.

Un des buts de ce document est de donner des lignes directrices sur les compromis entre les options de fonctionnalité limitée et de pleine fonctionnalité. Une discussion complète des effets potentiels des modifications par un adversaire du champ ECN figure dans les Sections 18 et 19.

9.1.1 Options Fonctionnalité limitée et Fonctionnalité pleine

L'option de fonctionnalité limitée pour l'encapsulation ECN dans les tunnels IP fait établir le codet non ECT dans l'en-tête externe (encapsulant) sans considération de la valeur du champ ECN dans l'en-tête interne (encapsulé). Avec cette option, le champ ECN dans l'en-tête interne n'est pas altéré à la désencapsulation. L'inconvénient de cette approche est que le flux n'a pas le soutien d'ECN pour cette partie du chemin qui utilise le tunnelage IP, même si le paquet encapsulé (provenant de l'envoyeur TCP d'origine) est à capacité ECN. C'est à dire que si le paquet encapsulé arrive à un routeur encombré qui est à capacité ECN, et si le routeur peut décider d'abandonner ou de marquer le paquet comme une indication d'encombrement aux nœuds d'extrémité, le routeur n'aura pas l'autorisation d'établir le codet CE dans l'en-tête du paquet, mais devra plutôt abandonner le paquet.

L'option de pleine fonctionnalité pour l'encapsulation ECN est de copier le codet ECN de l'en-tête interne dans l'en-tête externe à l'encapsulation si l'en-tête interne est non ECT ou ECT, et d'établir le codet ECN de l'en-tête externe à ECT(0) si le codet ECN de l'en-tête interne est CE. À la désencapsulation, si le codet CE est mis dans l'en-tête externe, le codet CE est alors aussi mis dans l'en-tête interne. Autrement, le codet ECN de l'en-tête interne est laissé inchangé. C'est à dire que pour la pleine prise en charge de ECN, le traitement d'encapsulation et de désencapsulation implique ce qui suit : à l'entrée du tunnel, l'option de pleine fonctionnalité établit le codet ECN dans l'en-tête externe. Si le codet ECN dans l'en-tête interne est non ECT ou ECT, il est alors copié dans le codet ECN dans l'en-tête externe. Si le codet ECN dans l'en-tête interne est CE, le codet ECN dans l'en-tête externe est alors mis à ECT(0). À la désencapsulation à la sortie du tunnel, l'option pleine fonctionnalité établit le codet CE dans l'en-tête interne si le codet CE est mis dans l'en-tête externe. Autrement, aucun changement n'est fait à ce champ dans l'en-tête interne.

Avec l'option pleine fonctionnalité, un flux peut tirer parti de ECN dans les portions du chemin qui peuvent utiliser le tunnelage IP. L'inconvénient de l'option pleine fonctionnalité du point de vue de la sécurité est que le tunnel IP ne peut pas protéger le flux de certaines modifications des bits ECN dans l'en-tête IP au sein du tunnel. Les dangers potentiels provenant de modifications des bits ECN dans l'en-tête IP sont décrits en détail aux Sections 18 et 19.

(1) Un tunnel IP DOIT modifier le traitement de l'octet de champ DS aux points d'extrémité du tunnel IP en mettant en œuvre soit l'option de fonctionnalité limitée soit l'option de pleine fonctionnalité.

(2) Facultativement, un tunnel IP PEUT permettre aux points d'extrémité d'un tunnel IP de négocier le choix entre l'option de fonctionnalité limitée et l'option de pleine fonctionnalité pour ECN dans le tunnel.

Le minimum requis pour rendre ECN utilisable avec les tunnels IP est l'option de fonctionnalité limitée, qui empêche ECN d'être activé dans l'en-tête externe du tunnel. La pleine prise en charge de ECN exige l'utilisation de l'option de pleine fonctionnalité. Si il n'y a pas de mécanisme facultatif pour que les points d'extrémité du tunnel négocient un choix entre l'option de fonctionnalité limitée et celle de pleine fonctionnalité, il peut y avoir un accord préexistant entre les points d'extrémité du tunnel pour prendre en charge l'option ECN de fonctionnalité limitée ou l'option de pleine fonctionnalité.

Tous les tunnels IP DOIVENT mettre en œuvre l'option de fonctionnalité limitée, et DEVRAIENT prendre en charge l'option de pleine fonctionnalité.

De plus, il est RECOMMANDÉ que les paquets avec le codet CE dans l'en-tête externe soient abandonnés si ils arrivent au point de sortie du tunnel pour un tunnel qui utilise l'option de fonctionnalité limitée, ou pour un tunnel qui utilise l'option de pleine fonctionnalité mais pour lequel le codet non ECT est mis dans l'en-tête interne. Ceci est motivé par la rétro compatibilité et pour assurer qu'aucune modification non autorisée du champ ECN n'ait lieu, et est exposé plus en détails au paragraphe 9.1.2.

9.1.2 Changements au champ ECN au sein d'un tunnel IP

La présence d'une copie du champ ECN dans l'en-tête interne d'un paquet en mode tunnel IP donne l'opportunité de détection de modifications non autorisées du champ ECN dans l'en-tête externe. La comparaison des champs ECT dans les en-têtes interne et externe entre dans deux catégories pour les mises en œuvre qui se conforment au présent document :

* Si le tunnel IP utilise l'option de pleine fonctionnalité, le codet non ECT devrait être mis dans l'en-tête externe si et seulement si il est aussi mis dans l'en-tête interne.

* Si le tunnel utilise l'option de fonctionnalité limitée, le codet non ECT devrait être mis dans l'en-tête externe.

La réception d'un paquet qui ne satisfait pas à la condition appropriée pourrait causer des problèmes.

Considérons le cas d'un tunnel IP où le point d'entrée du tunnel n'a pas été mis à jour selon les exigences du présent document, alors que le point de sortie du tunnel a été mis à jour pour prendre en charge ECN. Dans ce cas, le tunnel IP n'est pas explicitement configuré pour prendre en charge l'option ECN de pleine fonctionnalité. Cependant, le point d'entrée du tunnel se comporte de façon identique à un point d'entrée de tunnel qui prend en charge l'option de pleine fonctionnalité. Si les paquets provenant d'une connexion à capacité ECN utilisent ce tunnel, le codet ECT sera mis dans l'en-tête externe au point d'entrée du tunnel. L'encombrement au sein du tunnel peut alors avoir pour résultat qu'un routeur à capacité ECN établisse CE dans l'en-tête externe. Parce que le tunnel n'a pas été explicitement configuré pour prendre en charge l'option de pleine fonctionnalité, le point de sortie du tunnel s'attend à ce que le codet non ECT soit mis dans l'en-tête externe. Lorsque un point de sortie de tunnel à capacité ECN reçoit un paquet avec le codet ECT ou CE dans l'en-tête externe, dans un tunnel qui n'a pas été configuré pour prendre en charge l'option de pleine fonctionnalité, ce paquet devrait être traité conformément au fait que le codet CE a été mis ou non, comme suit. Il est RECOMMANDÉ que sur un tunnel qui n'a pas été configuré pour prendre en charge l'option de pleine fonctionnalité, les paquets soient abandonnés au point de sortie si le codet CE est mis dans l'en-tête externe mais pas dans l'en-tête interne, et sinon, qu'ils devraient être transmis.

Un tunnel IP ne peut pas fournir de protection contre l'effacement de l'indication d'encombrements sur la base du changement du codet ECN de CE à ECT. L'effacement de l'indication d'encombrement peut impacter le réseau et les autres flux de façons qui ne seraient pas possibles en l'absence de ECN. Il est important de noter que l'effacement de l'indication d'encombrement ne peut être effectué que pour des indications d'encombrement placées par des nœuds au sein du tunnel ; la copie du champ ECN dans l'en-tête interne préserve les notifications d'encombrement provenant des nœuds en amont de l'entrée du tunnel (sauf si l'en-tête interne est aussi effacé). Si l'effacement des notifications d'encombrement est jugée présenter un risque pour la sécurité qui excède le bénéfice de la gestion d'encombrement de ECN, les tunnels pourraient être spécifiés ou configurés de façon à utiliser l'option de fonctionnalité limitée.

IPsec prend en charge une communication sécurisée sur des composants de réseau potentiellement non sûrs, tels que des routeurs intermédiaires. Les protocoles IPsec prennent en charge deux modes de fonctionnement, le mode transport et le mode tunnel, qui s'étendent sur une large gamme d'exigences de sécurité et d'environnements de fonctionnement. Les en-tête de protocole de sécurité en mode transport sont insérés entre l'en-tête IP (IPv4 ou IPv6) et les en-têtes de protocole de couche supérieure (par exemple, TCP), et donc le mode transport peut seulement être utilisé pour la sécurité de bout en bout sur une connexion. Le mode IPsec tunnel se fonde sur l'ajout d'un nouvel en-tête IP "externe" qui encapsule l'original, ou en-tête IP "interne" et son paquet associé. Les en-têtes de sécurité en mode tunnel sont insérés entre ces deux en-têtes IP. À la différence du mode transport, le nouvel en-tête IP "externe et les en-tête de sécurité de mode tunnel peuvent être ajoutés et supprimés à des points intermédiaires le long d'une connexion, permettant aux passerelles de sécurité de sécuriser des portions vulnérables d'une connexion sans exiger la participation de points d'extrémité aux protocoles de sécurité. Un important aspect de la sécurité de mode tunnel est que dans la spécification d'origine, l'en-tête externe est éliminé à la sortie du tunnel, assurant que les menaces pour la sécurité fondées sur la modification de l'en-tête IP ne se propagent pas au-delà du point d'extrémité du tunnel. On trouvera un exposé plus complet sur IPsec dans la [RFC2401].

Le protocole IPsec tel que défini à l'origine dans les [RFC2402] [RFC2406] exigeait que le champ ECN de l'en-tête interne ne soit pas changé par le processus de désencapsulation IPsec au nœud de sortie d'un tunnel ; cela aurait écarté la possibilité du mode à pleine fonctionnalité pour ECN. En même temps, cela va assurer que les modifications du champ ECN par un agresseur ne peuvent pas être utilisées pour lancer des attaques de vol ou de déni de service à travers un point d'extrémité de tunnel IPsec, car de telles modifications seront éliminées au point d'extrémité du tunnel.

En principe, permettre l'utilisation de la fonctionnalité ECN dans l'en-tête externe d'un tunnel IPsec soulève des problèmes de sécurité parce qu'un agresseur peut altérer les informations qui se propagent au delà du point d'extrémité du tunnel. Sur la base d'une analyse (qui figure aux Sections 18 et 19) de ces problèmes et des risques associés, notre approche globale a été de fournir une prise en charge par configuration des changements à IPsec pour supprimer le conflit avec ECN.

En particulier, en mode tunnel, le tunnel IPsec DOIT prendre en charge l'option de fonctionnalité limitée décrite au paragraphe 9.1.1, et DEVRAIT prendre en charge l'option de pleine fonctionnalité décrite au paragraphe 9.1.1.

Cela fait de la permission d'utiliser la fonctionnalité ECN dans l'en-tête externe d'un tunnel IPsec une partie configurable de l'association de sécurité (SA, Security Association) IPsec correspondante, de telle sorte qu'elle peut être désactivée dans des situations où les risques sont jugés dépasser les bénéfices. Il en résulte qu'un administrateur de sécurité IPsec se trouve en face d'une alternative pour le comportement des connexions à capacité ECN au sein d'un tunnel IPsec, la fonctionnalité limitée ou la pleine fonctionnalité décrites plus tôt.

De plus, le présent document spécifie comment les points d'extrémité d'un tunnel IPsec pourraient négocier l'activation de la fonctionnalité ECN dans les en-têtes externes de ce tunnel sur la base d'une politique de sécurité. La capacité à négocier l'utilisation de ECN entre les points d'extrémité d'un tunnel permettrait à un administrateur de sécurité de désactiver ECN dans des situations où il estime que les risques (par exemple, la perte de notifications d'encombrement) surpassent les bénéfices de ECN.

Le protocole IPsec, tel que défini dans les [RFC2402] [RFC2406] n'inclut pas le champ ECN d'en-tête IP dans un de ses calculs cryptographiques (dans le cas du mode tunnel, le champ ECN d'en-tête IP externe n'est pas inclus). Et donc, la modification du champ ECN par un nœud du réseau n'a aucun effet sur la sécurité IPsec de bout en bout, parce que elle ne peut pas causer l'échec d'une vérification d'intégrité IPsec. Par conséquent, IPsec ne donne aucune défense contre une modification hostile du champ ECN (c'est-à-dire, une attaque par interposition) car la modification hostile n'aura aucun effet sur la sécurité IPsec de bout en bout. Dans certains environnements, la capacité à modifier le champ ECN sans affecter les vérifications d'intégrité d'IPsec peut constituer un canal secret ; si il est nécessaire d'éliminer un tel canal ou de réduire sa bande passante, le tunnel IPsec devrait alors travailler en mode à fonctionnalité limitée.

9.2.1 Négociation entre points d'extrémité de tunnel

Ce paragraphe décrit les changements détaillés pour permettre l'usage de ECN sur les tunnels IPsec, y compris la négociation de la prise en charge de ECN entre les points d'extrémité du tunnel. Cela est pris en charge par trois modifications à IPsec :

* Un champ facultatif Base de données d'association de sécurité (SAD, Security Association Database) qui indique si le traitement d'encapsulation et de désencapsulation de tunnel permet ou interdit l'utilisation d'ECN dans l'en-tête IP externe.

* Un attribut facultatif Association de sécurité qui permet la négociation de ce champ SAD entre les deux points d'extrémité d'une SA qui prend en charge le mode tunnel.

* Des changements au traitement d'encapsulation et de désencapsulation du mode tunnel pour permettre ou interdire l'usage de ECN dans l'en-tête IP externe sur la base de la valeur du champ SAD. Lorsque l'usage d'ECN est permis dans l'en-tête IP externe, le codet ECT est mis dans l'en-tête externe pour une connexion à capacité ECN et les notifications d'encombrement (indiquées par le codet CE) provenant de telles connexions sont propagée à l'en-tête interne à la sortie du tunnel.

Si la négociation de l'usage d'ECN est mise en œuvre, le champ SAD DEVRAIT alors aussi être mis en œuvre. D'un autre côté, la négociation de l'usage d'ECN est FACULTATIVE dans tous les cas, même pour les mises en œuvre qui prennent en charge le champ SAD. Les changements au processus d'encapsulation et désencapsulation sont EXIGÉS, mais PEUVENT être mis en œuvre sans les deux autres changements en supposant que l'usage d'ECN est toujours interdit. La solution de pleine fonctionnalité pour l'usage d'ECN sur les tunnels IPsec comporte le champ SAD et la version complète des changements du processus d'encapsulation et de désencapsulation, avec ou sans la prise en charge de la négociation FACULTATIVE. La solution de la fonctionnalité limitée comporte un sous-ensemble des changements à l'encapsulation et la désencapsulation qui interdit toujours l'usage d'ECN.

Ces changements sont traités plus en détails dans les trois paragraphes qui suivent.

La pleine fonctionnalité ECN ajoute un nouveau champ à SAD (voir la [RFC2401]):

Indique si des connexions à capacité ECN utilisant cette SA en mode tunnel ont l'autorisation de recevoir des notifications d'encombrement ECN pour un encombrement survenant au sein du tunnel. La valeur "admis" permet les notifications d'encombrement ECN. La valeur "interdit" désactive de telles notifications, ce qui fait que tout encombrement est indiqué par des abandons de paquets.

[FACULTATIF. La valeur de ce champ DEVRAIT être supposée "interdit" dans les mises en œuvre qui ne l'acceptent pas.]

Si cet attribut est mis en œuvre, la spécification SA dans une entrée de base de données de politique de sécurité (SPD) DOIT accepter un attribut correspondant, et cet attribut SPD DOIT être couvert par l'interface administrative de SDP (actuellement décrit au paragraphe 4.4.1 de la [RFC2401]).

Un nouvel attribut IPsec Association de sécurité est défini pour permettre la prise en charge des notifications d'encombrement ECN sur la base de l'en-tête IP externe à négocier pour les tunnels IPsec (voir la [RFC2407]). Cet attribut est FACULTATIF, bien que les mises en œuvre qui le prennent en charge DEVRAIENT aussi prendre en charge le champ SAD défini au paragraphe 9.2.1.1.

La valeur de l'attribut SA d'IPsec de 10 a été allouée par l'IANA pour indiquer que l'attribut SA de tunnel ECN est en cours de négociation ; le type de cet attribut est Basique (voir au paragraphe 4.5 de la [RFC2407]). Les valeurs de classe sont utilisées pour conduire la négociation. Voir dans les [RFC2407, RFC2408, RFC2409] des informations complémentaires y compris les formats de codage et les exigences pour négocier cet attribut SA.

Spécifie si la fonctionnalité ECN est admise en utilisation avec le mode d'encapsulation de tunnel. Cela affecte le traitement d'encapsulation et de désencapsulation du tunnel - voir au paragraphe 9.2.1.3.

Les valeurs 3 à 61 439 sont réservée à l'IANA. Les valeurs 61 440 à 65 535 sont pour utilisation privée.

Si elle n'est pas spécifiée, la valeur par défaut doit être supposée être Interdit.

Tunnel ECN est un nouvel attribut SA, et donc les initiateurs qui l'utilisent peuvent s'attendre à rencontrer des correspondants qui ne le comprennent pas, et vont donc rejeter les propositions qui le contiennent. Pour la rétro compatibilité avec de telles mises en œuvre, les initiateurs DEVRAIENT toujours inclure aussi une proposition sans l'attribut Tunnel ECN pour permettre à un tel correspondant de choisir une transformation ou une proposition qui ne contient pas l'attribut Tunnel ECN. La RFC 2407 exige actuellement que les correspondants rejettent toutes les propositions si l'une d'elles contient un attribut inconnu ; il est prévu que cette exigence soit changée pour exiger d'un correspondant de ne pas choisir de proposition ou transformation contenant des attributs inconnus.

Pour la pleine prise en charge d'ECN, le traitement de l'encapsulation et de la désencapsulation pour le champ TOS IPv4 et le champ Classe de trafic IPv6 est changé par rapport à celui spécifié dans la [RFC2401] en ce qui suit :

(5)(6) Si le paquet entre immédiatement dans un domaine pour lequel la valeur DSCP dans l'en-tête externe n'est pas appropriée, cette valeur DOIT être transposée en une valeur appropriée pour le domaine [RFC2474]. Voir aussi la [RFC2475] pour plus d'informations.

(7) Si la valeur du champ Tunnel ECN dans l'entrée de SAD pour cette SA est "admis" et si le champ ECN dans l'en-tête interne est mis à toute valeur autre que CE, copier ce champ ECN dans l'en-tête externe. Si le champ ECN dans l'en-tête interne est mis à CE, régler alors le champ ECN de l'en-tête externe à ECT(0).

(8) Si la valeur du champ Tunnel ECN dans l'entrée de SAD pour cette SA est "admis" et si le champ ECN dans l'en-tête interne est mis à ECT(0) ou ECT(1) et si le champ ECN dans l'en-tête externe est mis à CE, copier alors le champ ECN de l'en-tête externe dans l'en-tête interne. Autrement, ne faire aucun changement au champ ECN dans l'en-tête interne.

(5) et (6) sont identiques pour correspondre à l'utilisation dans la [RFC2401], bien qu'ils soient différents dans la [RFC2402].

La description ci-dessus s'applique aux mises en œuvre qui prennent en charge le champ Tunnel ECN dans le SAD ; de telles mises en œuvre DOIVENT appliquer ce traitement plutôt que de traiter l'octet TOS IPv4 et l'octet Classe de trafic IPv6 définis dans la [RFC2401]. Cela constitue la solution de pleine fonctionnalité pour l'utilisation d'ECN avec les tunnels IPsec.

Une mise en œuvre qui ne prend pas en charge le champ Tunnel ECN dans le SAD DOIT mettre en œuvre ce traitement en supposant que la valeur du champ Tunnel ECN du SAD est "Interdit" pour toute SA. Dans ce cas, le traitement du champ ECN se réduit à :

Cela constitue la solution de fonctionnalité limitée pour l'utilisation d'ECN avec les tunnels IPsec.

Pour la rétro compatibilité, les paquets avec le codet CE mis dans l'en-tête externe DEVRAIENT être abandonnés si ils arrivent sur une SA qui utilise l'option de fonctionnalité limitée, ou qui utilise l'option de pleine fonctionnalité avec le codet non ECN mis dans l'en-tête interne.

9.2.2 Changements au champ ECN au sein d'un tunnel IPsec

Si le champ ECN est changé de façon inappropriée au sein d'un tunnel IPsec, et si ce changement est détecté à la sortie du tunnel, la réception d'un paquet qui ne satisfait pas à la condition appropriée pour la SA est un événement qui doit être répertorié. Une mise en œuvre PEUT créer des enregistrements d'audit avec un compte par SA des paquets incorrects sur une certaine période plutôt que de créer un enregistrement d'audit pour chaque paquet erroné. Un tel enregistrement d'audit DEVRAIT contenir les en-têtes d'au moins un des paquets erronés, mais ne doit pas nécessairement contenir les en-têtes de tous les paquets représentés par l'entrée.

9.2.3 Commentaires pour la prise en charge de IPsec

Des commentaires substantiels ont été reçus sur deux domaines de ce document durant la révision par le groupe de travail IPsec. Ce paragraphe décrit ces commentaires et explique pourquoi les changements proposés n'ont pas été retenus.

Le premier commentaire indiquait que la configuration par nœud est plus facile à mettre en œuvre que la configuration par SA. Après une réflexion sérieuse et en dépit de certains encouragement initiaux en faveur de la configuration par nœud, il n'a pas semblé que ce doit une bonne idée. Le problème est que la capacité ECN étant progressivement déployée dans IPsec, de nombreuses mises en œuvre IPsec à capacité ECN vont se trouver en communication avec un mélange de points d'extrémité de tunnels IPsec à capacité ECN et sans capacité ECN. Dans un tel environnement avec une configuration par nœud, la seule chose raisonnable à faire est d'interdire l'utilisation d'ECN pour tous les tunnels IPsec, ce qui n'est pas le résultat désiré.

Dans le second domaine, plusieurs réviseurs ont noté que la négociation de SA est complexe, et de plus non triviale. L'un d'eux a suggéré d'utiliser ICMP après l'établissement du tunnel comme solution de remplacement possible. Dans le présent document, l'ajout de la négociation de SA est FACULTATIVE et le restera ; les mises en œuvre sont libres de l'ignorer. Les auteurs estiment que l'assurance qu'elle apporte peut être utile dans un certain nombre de situations. En pratique, si elle n'est pas mise en œuvre, elle peut être supprimée à une étape suivante du processus de normalisation. Étendre ICMP à la négociation d'ECN après l'établissement du tunnel est plus complexe que d'étendre la négociation de l'attribut SA. Certains tunnels ne permettent pas que le trafic soit adressé au point d'extrémité de sortie du tunnel, et donc le paquet ICMP devrait être adressé ailleurs, examiné par le point de sortie, et éliminé là ou à sa destination réelle. De plus, la livraison ICMP n'est pas fiable, et donc il y a la possibilité qu'un paquet ICMP soit abandonné, entraînant l'invention d'encore un autre mécanisme d'accusé de réception/retransmission. Il semble bien plus simple de spécifier une extension FACULTATIVE au mécanisme existant de négociation de SA.

Un ensemble de questions différent est soulevé à propos d'ECN, lorsque les paquets IP sont encapsulés dans des tunnels avec des en-têtes de paquet non IP. Cela survient avec MPLS [RFC2702], GRE [RFC1701], L2TP [RFC2661], et PPTP [RFC2637]. Pour ces protocoles, il n'y a pas de conflit avec ECN ; c'est simplement que ECN ne peut pas être utilisé au sein du tunnel si un codet ECN ne peut pas être spécifié pour l'en-tête du protocole encapsulant. Des travaux précédents ont examiné une proposition préliminaire d'incorporer ECN dans MPLS, et les propositions d'incorporer ECN dans GRE, L2TP, ou PPTP seront examinées en tant que de besoin.

Une possibilité est que les appareils de surveillance et de régulation (ou de façon plus informelle, les "boîtes de pénalité") soient installés dans le réseau pour surveiller si les flux au mieux répondent de façon appropriée à l'encombrement, et si ils abandonnent de façon préférentielle les paquets provenant des flux déterminés comme n'utilisant pas de procédures adéquates de contrôle d'encombrement de bout en bout.

Nous recommandons que toute "boîte de pénalité" qui détecte un flux ou un agrégat de flux qui ne répond pas au contrôle d'encombrement de bout en bout passe d'abord du marquage des paquets à leur abandon pour ce flux, avant de prendre des mesures supplémentaires pour restreindre la bande passante disponible pour ce flux. Donc, initialement, le routeur peut abandonner les paquets dans lesquels le routeur aurait autrement établi le codet CE. Cela pourrait inclure d'abandonner les paquets arrivant pour ce flux qui sont à capacité ECN et ont déjà le codet CE établi. De cette façon, toute indication d'encombrements vue par ce routeur pour ce flux sera sûre d'être vue aussi par les nœuds d'extrémité, même en présence de routeurs malveillants ou défaillants ailleurs dans le chemin. Si nous supposons que la première mesure prise à toute "boîte de pénalité" pour un flux à capacité ECN sera d'abandonner les paquets au lieu de les marquer, il n'y a alors aucun moyen pour un adversaire qui subvertit un contrôle d'encombrement de bout en bout fondé sur ECN de causer la caractérisation d'un flux comme non coopératif et de lui faire subir une mesure plus sévère au sein de la "boîte de pénalité".

Les appareils de surveillance et de régulation qui sont en fait déployés pourraient être bien en deçà de l'appareil de surveillance "idéal" décrit ci-dessus, en ce que la surveillance est appliquée non sur un seul flux, mais sur un agrégat de flux (par exemple, ceux qui partagent un seul tunnel IPsec). Dans ce cas, le passage du marquage à l'abandon s'appliquerait à tous les flux qui s'agrègent, refusant le bénéfice de ECN à tous les autres flux de l'agrégat. Au plus haut niveau d'agrégation, une autre forme de désactivation d'ECN survient même en l'absence d'appareils de surveillance et régulation, lorsque des files d'attente RED à capacité ECN passent du marquage à l'abandon de paquets comme indication d'encombrement lorsque la taille moyenne de file d'attente excède un certain seuil.

La présente section expose certains des travaux qui essayent d'évaluer l'utilisation d'ECN. La page ECN de la Toile [ECN] a des pointeurs sur d'autres articles, ainsi que sur des mises en œuvre d'ECN.

[Floyd94] examine les avantages et les inconvénients de l'ajout de ECN à l'architecture TCP/IP. Comme le montrent les comparaisons fondées sur des simulations, un des avantages d'ECN est d'éviter les abandons inutiles de paquet pour les connexions TCP courtes ou sensibles au retard. Un second avantage d'ECN est d'éviter certaines temporisations inutiles de retransmission dans TCP. Cet article expose en détail l'intégration d'ECN dans les mécanismes de contrôle d'encombrement de TCP. L'inconvénient possible d'ECN exposé dans cet article est qu'une connexion TCP non conforme pourrait s'annoncer faussement comme à capacité ECN, et qu'un paquet ACK TCP portant un message Écho ECN pourrait être lui-même perdu dans le réseau. La première de ces deux questions est discutée dans l'appendice au présent document, et le second est traité par l'addition du fanion CWR dans l'en-tête TCP.

Les évaluations expérimentales d'ECN incluent la [RFC2884] et [K98]. Les conclusions de [K98] et [RFC2884] sont que le TCP ECN a un débit légèrement meilleur que le TCP non ECN ; que les flux TCP ECN sont à égalité avec les flux TCP non ECN et TCP ECN est robuste avec le trafic bidirectionnel (avec de l'encombrement dans les deux directions) et avec plusieurs passerelles encombrées. Les expériences avec de nombreux petits transferts montrent que, alors que la plupart des connexions courtes ont des temps de transfert similaires avec ou sans ECN, un plus petit pourcentage des connexions courtes a de très long temps de transfert pour les expériences non ECN par rapport aux expériences ECN.

L'utilisation des deux codets ECT, ECT(0) et ECT(1), peut donner un nom occasionne ECN d'un bit dans les en-têtes de paquet [SCWA99]. La principale motivation en est le désir de permettre des mécanismes pour que l'envoyeur des données vérifie que les éléments de réseau n'écrasent pas le codet CE, et que les receveurs des données rapportent correctement à l'envoyeur la réception des paquets avec le codet CE établi, comme exigé par le protocole de transport. Cette section expose les problèmes de rétro compatibilité avec les mises en œuvre d'ECN IP dans les routeurs qui se conforment à la RFC 2481, dans laquelle un seul codet ECT était défini. On ne pense pas que le développement incrémentaire de mises en œuvre ECN qui comprennent le codet ECT(1) va causer des problèmes significatifs de fonctionnement. C'est très vraisemblablement le cas lorsque la mise en place du codet ECT(1) commence par les routeurs, avant que le codet ECT(1) ne commence à être utilisé par les nœuds d'extrémité.

11.2.1 Déploiement incrémentaire de ECT(1) dans les routeurs

ECN a été une norme expérimentale depuis janvier 1999, et il y a déjà des mises en œuvre d'ECN dans les routeurs qui ne comprennent pas le codet ECT(1). Lorsque l'utilisation du codet ECT(1) sera normalisée pour TCP ou pour d'autres protocoles de transport, cela pourra signifier qu'un envoyeur de données utilise le codet ECT(1), mais que ce codet n'est pas compris par un routeur encombré sur le chemin.

Si c'est permis par le protocole de transport, un envoyeur de données serait libre de ne pas utiliser du tout ECT(1), et d'envoyer tous les paquets à capacité ECN avec le codet ECT(0). Cependant, si un envoyeur à capacité ECN utilise ECT(1), et si le routeur encombré sur le chemin n'a pas compris le codet ECT(1), le routeur devrait alors cesser de marquer le ECT(0) des paquets et abandonner certains des paquets ECT(1) comme indications d'encombrement. Comme il est exigé de TCP qu'il réagisse aussi bien aux paquets marqués qu'abandonnés, ce comportement d'abandon de paquets qui auraient pu être marqués ne présente pas de menace significative pour le réseau et est cohérent avec l'approche globale d'ECN qui permet aux routeurs de déterminer quand et si marquer les paquets à leur convenance (voir la Section 5).

Le présent document a spécifié deux bits dans l'en-tête IP pour être utilisés pour ECN. Le codet non ECT indique que le protocole de transport va ignorer le codet CE. C'est la valeur par défaut pour le codet ECN. Les codets ECT indiquent que le protocole de transport veut et est capable de participer à ECN.

Le routeur établit le codet CE pour indiquer l'encombrement aux nœuds d'extrémité. Le codet CE dans un en-tête de paquet NE DOIT PAS être remis à zéro par un routeur.

TCP exige trois changements pour ECN, une phase d'établissement et deux nouveaux fanions dans l'en-tête TCP. Le fanion ECN-Echo est utilisé par le receveur des données pour informer l'envoyeur des données d'un paquet CE reçu. Le fanion Fenêtre d'encombrement réduite (CWR, Congestion Window Reduced) est utilisé par l'envoyeur des données pour informer le receveur des données de la réduction de la fenêtre d'encombrement.

Lorsque ECN (Notification explicite d'encombrement) est utilisé, il est exigé que les indications d'encombrement générées au sein d'un tunnel IP ne soient pas perdues à la sortie du tunnel. On a spécifié une modification mineure au traitement du champ ECN par le protocole IP durant l'encapsulation et la désencapsulation pour permettre aux flux qui vont subir un tunnelage IP d'utiliser ECN.

1) Une option de fonctionnalité limitée qui n'utilise pas ECN à l'intérieur du tunnel IP, en réglant le champ ECN dans l'en-tête externe à non-ECT, et qui n'altère pas l'en-tête interne au moment de la désencapsulation.

2) Une option de pleine fonctionnalité, qui règle le champ ECN dans l'en-tête externe soit à non-ECT soit à un des codets ECT, selon le champ ECN dans l'en-tête interne. À la désencapsulation, si le codet CE est mis dans l'en-tête externe, et si l'en-tête interne est réglé à un des codets ECT, le codet CE est alors copié dans l'en-tête interne.

Pour les tunnels IPsec, le présent document définit aussi un attribut facultatif d'association de sécurité (SA) IPsec qui active la négociation de l'utilisation d'ECN au sein des tunnels IPsec et un champ facultatif dans la base de données des associations de sécurité pour indiquer si ECN est permis en mode tunnel sur une SA. Les changements nécessaires pour les tunnels IPsec pour l'utilisation de ECN modifient la [RFC2401] qui définit l'architecture IPsec et spécifie certains aspects de sa mise en œuvre. Le nouvel attribut SA IPsec vient en plus de ceux déjà définis au paragraphe 4.5 de la [RFC2407].

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

Le présent document incorpore aussi des travaux qui ont été faits après la RFC 2481. Les premiers ont été pour décrire les détails des changements aux tunnels IPsec, et discuter de façon extensive les implications d'ECN pour la sécurité (maintenant incluses comme Sections 18 et 19 du présent document). Les seconds ont été pour étendre l'exposé des tunnels IPsec à tous les tunnels IP. Parce que les plus anciens tunnels IP n'étaient pas compatibles avec l'utilisation d'ECN par un flux, le déploiement d'ECN dans l'Internet va créer une forte pression pour que les anciens tunnels IP soient mis à jour avec une version compatible ECN, en utilisant l'option de fonctionnalité limitée ou l'option de pleine fonctionnalité.

Le présent document ne traite pas 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 de la prise en charge d'ECN à MPLS n'a pas eu de suites.

Un troisième travail postérieur à la RFC2481 était de décrire la procédure d'ECN avec les paquets de données retransmis, selon laquelle un codet ECT ne devrait pas être établi sur des paquets de données retransmis. Le motif de cette spécification supplémentaire est d'éliminer une ouverture possible à des attaques de déni de service sur une connexion TCP existante. Certains développements antérieurs de TCP à capacité ECN pourraient ne pas se conformer à la (nouvelle) exigence de ne pas établir un codet ECT sur les paquets retransmis ; on ne pense pas que cela cause de problèmes pratiques significatifs.

Le présent document développe un peu la spécification de l'utilisation des paquets SYN pour la négociation d'ECN. Bien que certains développements antérieurs de TCP à capacité ECN puissent n'être pas conformes aux exigences spécifiées dans le présent document, on ne pense pas que cela doive conduire à des problèmes de performances ou de compatibilité pour les connexions TCP avec une combinaison de mises en œuvre de TCP aux points d'extrémité.

Le présent document inclut aussi la spécification du codet ECT(1), qui peut être utilisé par TCP au titre de la mise en œuvre d'un nom occasionnel ECN.

Vu les efforts actuels pour mettre en œuvre AQM, on pense que c'est le bon moment pour mettre en place des mécanismes d'évitement d'encombrement qui ne dépendent pas seulement de l'abandon de paquet. Avec le développement accru d'applications et de transports sensibles au retard et à la perte d'un seul paquet (par exemple, le trafic en temps réel, les transferts courts sur la Toile ), dépendre de la perte de paquet comme mécanisme normal de notification d'encombrement apparaît insuffisant (ou au minimum, non optimal).

On a examiné les conséquences des modifications du champ ECN au sein du réseau, en analysant toutes les opportunités qu'un adversaire change le champ ECN. Dans de nombreux cas, le changement du champ ECN n'est pas pire que l'abandon d'un paquet. Cependant, on note que certains changements ont pour conséquence plus sérieuse de subvertir le contrôle d'encombrement de bout en bout. On souligne quand même que le dommage potentiel est alors limité, et est similaire à la menace présentée par les systèmes d'extrémité refusant intentionnellement de coopérer au contrôle d'encombrement de bout en bout.

De nombreuses personnes ont contribué à ce travail et à ce document, y compris de nombreuses personnes qui ne sont pas citées directement dans ce document. De plus, nous tenons à remercier Kenjiro Cho pour sa proposition du mécanisme TCP pour la négociation de la capacité ECN, Kevin Fall pour sa proposition du bit CWR, Steve Blake pour les matériaux sur le recalcul de la somme de contrôle d'en-tête IPv4, Jamal Hadi-Salim pour l'exposé sur les questions de ECN, et Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, et Vern Paxson pour les discussions sur les questions de sécurité. Des remerciements au groupe de travail de recherches sur l'Internet de bout en bout pour les discussions en cours sur ces questions.

Les discussions par messagerie avec un certain nombre de gens, parmi lesquels Dax Kelson, Alexey Kuznetsov, Jamal Hadi-Salim, et Venkat Venkatsubra, ont traité les questions soulevées par les équipements non conformes dans l'Internet qui ne répondent pas aux paquets SYN TCP avec les fanions ECE et CWR mis. Nous remercions Mark Handley, Jitentra Padhye, et d'autres pour les discussions sur les procédures d'initialisation de TCP.

La discussion des considérations sur ECN et tunnel IP s'appuie fortement sur les discussions et documents sur ce sujet dans le groupe de travail Services différenciés. Nous remercions Tabassum Bint Haque de Dhaka, Bangladesh, pour ses réactions sur les tunnels IP. Nous remercions Derrell Piper et Kero Tivinen pour leurs propositions de modifications à la RFC 2407 qui améliorent l'utilisation de la négociation de l'attribut SA de tunnel ECN.

Nous remercions David Wetherall, David Ely, et Neil Spring pour la propositions du nom occasionnel ECN. Nous remercions aussi Stefan Savage pour son exposé sur la question, Bob Briscoe et Jon Crowcroft pour avoir soulevé la question de la fragmentation dans IP, sur une solution de remplacement pour la sémantique du quatrième codet ECN, et plusieurs autres sujets. Merci à Richard Wendland pour ses réactions sur plusieurs questions traitées dans le document.

Nous tenons aussi à remercier l'IESG, et en particulier les directeurs de la zone Transport qui au fil des années ont fourni des réactions et pour leur travail en faveur de la normalisation de ECN.

(Les liens sur le numéro de RFC renvoient au texte anglais, ceux sur des mots du titre renvoient à la traduction française)

[ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html". Référence pour information.

[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/". Référence pour info.

[FJ93] S. Floyd et V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, août 1993, p. 397-413.

[Floyd94] S. Floyd, "TCP et Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, octobre 1994, p. 10-23.

[Floyd98] S. Floyd, "The ECN Validation Test in the NS Simulator", URL "http://www-mash.cs.berkeley.edu/ns/", test tcl/test/test-all- ecn. Référence pour information.

[FF99] S. Floyd et K. Fall, "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, août 1999.

[FRED] D. Lin et Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, septembre 1997.

[Jacobson88] V. Jacobson, "Congestion Avoidance et Control", Proc. ACM SIGCOMM '88, pp. 314-329.

[Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", Message à la liste de diffusion end2end-interest, avril 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".

[K98] Krishnan, H., "Analyzing Explicit Congestion Notification (ECN) benefits for TCP", thèse de doctorat, UCLA, 1998. Citation pour remerciements.

[MJV96] S. McCanne, V. Jacobson, et M. Vetterli, "Receiver-driven Layered Multicast", SIGCOMM '96, août 1996, pp. 117-130.

[RFC791] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC793] J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet", STD 7, septembre 1981.

[RFC1141] T. Mallory et A. Kullberg, "Mise à jour incrémentaire de la somme de contrôle Internet", janvier 1990. (MàJ par RFC1624)

[RFC1349] P. Almquist, "Type de service dans la suite de protocole Internet", juillet 1992. (Obsolète, voir RFC2474)

[RFC1455] D. Eastlake, "Type de service Sécurité de la liaison physique", mai 1993. (Obsolète, voir RFC2474)

[RFC1701] S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement", octobre 1994.

[RFC1702] S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement sur réseaux IPv4", octobre 1994.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2309] B. Braden et autres, "Recommendations sur la gestion de file d'attente et l'évitement d'encombrement dans l'Internet", avril 1998.

[RFC2401] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voir RFC4301)

[RFC2402] S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, RFC4835)

[RFC2406] S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité dans IP", novembre 1998. (Obsolète, voir RFC4303, RFC4835)

[RFC2407] D. Piper, "Le domaine d'interprétation de sécurité IP de l'Internet pour ISAKMP", novembre 1998. (Obsolète, voir RFC4306)

[RFC2408] D. Maughan, M. Schertler, M. Schneider et J. Turner, "Association de sécurité Internet et protocole de gestion de clés (ISAKMP)", novembre 1998. (Obsolète, voir RFC 4306)

[RFC2409] D. Harkins et D. Carrel, "L'échange de clés Internet (IKE)", novembre 1998. (Obsolète, voir RFC 4306)

[RFC2474] K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260)

[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre 1998. (MàJ par RFC3260)

[RFC2481] K. Ramakrishnan S. Floyd, "Proposition d'ajout de la notification d'emcombrement explicite (ECN) à IP", janvier 1999. (Obsolète, voir RFC3168)

[RFC2637] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little et G. Zorn, "Protocole de tunnelage point à point (PPTP)", juillet 1999.

[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn et B. Palter, "Protocole de tunnelage de couche 2 "L2TP"", août 1999.

[RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell et J. McManus, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999.

[RFC2884] J. Hadi Salim et U. Ahmed, "Évaluation des performances de la notification d'emcombrement explicite (ECN) dans les réseaux IP", juillet 2000.

[RFC2780] S. Bradner et V. Paxson, "Lignes directrices pour les allocations par l'IANA des valeurs du protocole Internet et des en-têtes qui s'y rapportent", BCP 37, mars 2000. (MàJ par les RFC4443, RFC5237)

[RJ90] K. K. Ramakrishnan et Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, n° 2, pp. 158-181, mai 1990.

[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, et Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, octobre 1999.

[TBIT] Jitendra Padhye et Sally Floyd, "Identifying the TCP Behavior of Web Servers", ICSI TR-01-002, février 2001. URL "http://www.aciri.org/tbit/".

Les considérations pour la sécurité sont exposées aux Sections 7, 8, 18, et 19.

Le recalcul de somme de contrôle d'en-tête IPv4 est un problème avec certaines architectures de routeur de haut niveau qui utilisent un commutateur à mise en mémoire tampon de sortie, car la plupart sinon toutes les manipulations d'en-tête sont effectuées du côté entrée du commutateur, alors que la décision sur ECN devrait être faite en local sur la mémoire tampon de sortie. Ce n'est pas un problème pour IPv6, car il n'y a pas de somme de contrôle d'en tête sur IPv6. L'octet TOS de IPv4 est le dernier octet d'un demi mot de 16 bits.

La [RFC1141] discute de la mise à jour incrémentaire de la somme de contrôle IPv4 après que le champ TTL est décrémenté. La mise à jour incrémentaire de la somme de contrôle IPv4 après que le codet CE a été établi fonctionnerait comme suit : soit HC la somme de contrôle d'en-tête originale pour un paquet ECT(0), et soit HC' la nouvelle somme de contrôle d'en-tête après que le bit CE a été établi. C'est à dire que le champ ECN a changé de '10' à '11'. Puis pour les sommes de contrôle d'en-tête calculées avec une soustraction de complément à un, HC' serait recalculé comme suit :

Pour les sommes de contrôle d'en-tête calculées sur des machines à complément à deux, HC' serait recalculé comme suit après que le bit CE est établi :

Une mise à jour incrémentaire similaire de la somme de contrôle IPv4 peut être menée à bien lorsque le champ ECN est changé de ECT(1) à CE, c'est-à-dire, de ' 01' à '11'.

Cette section expose en détail les changements possibles du champ ECN dans le réseau, comme un faux rapport d'encombrement, désactivant la capacité ECN pour un paquet individuel, écrasant l'indication ECN d'encombrement, ou une fausse indication de capacité ECN.

18.1.1 Écrasement de l'indication d'encombrement

D'abord, considérons les changements que pourrait faire un routeur qui résulteraient en un écrasement effectif de l'indication d'encombrement après qu'il a été établi par un routeur en amont. La convention suivie est :

Remplacer le codet CE par le codet ECT(0) ou ECT(1) écrase effectivement l'indication d'encombrement. Cependant, avec l'utilisation de deux codets ECT, un routeur qui écrase le codet CE n'a aucun moyen de savoir si le codet ECT original était ECT(0) ou ECT(1). Et donc, il est possible au protocole de transport de déployer des mécanismes pour détecter de tels écrasements du codet CE.

La conséquence de l'écrasement du codet CE pour le routeur amont est qu'il y a pendant un certain temps un potentiel de construction d'encombrement, parce que l'indication d'encombrement n'atteint pas la source. Cependant, le paquet sera reçu et acquitté.

L'effet potentiel de l'écrasement de l'indication d'encombrement est complexe, et est discuté en profondeur à la Section 19 ci-dessous. Noter que l'effet de l'écrasement de l'indication d'encombrement est différent de l'abandon d'un paquet dans le réseau. Lorsque un paquet de données est abandonné, l'abandon est détecté par l'envoyeur TCP, et interprété comme une indication d'encombrement. De même, si un nombre suffisant d'accusés de réception de paquets consécutifs sont abandonnés, causant le non avancement du champ de cumul des accusés de réception chez l'envoyeur, celui-ci est empêché par la limite de la fenêtre d'encombrement d'envoyer des paquets supplémentaires, et finalement le temporisateur de retransmission va arriver à expiration.

À l'opposé, un écrasement systématique du bit CE par un routeur en aval peut avoir pour effet de causer la construction d'une file d'attente chez un routeur amont, y compris la perte possible de paquets due à un débordement de la mémoire tampon. Il y a une injustice potentielle dans le fait qu'un autre flux qui passe à travers le routeur encombré pourrait réagir au bit CE établi alors que le flux qui a eu le bit CE écrase pourrait avoir eu de meilleures performances. Les limitations de cette injustice potentielle sont exposées plus en détails à la Section 19 ci-dessous.

Le dernier des trois changements est de remplacer le codet CE par le codet non-ECT, écrasant ainsi l'indication d'encombrement et désactivant en même temps la capacité ECN.

L'écrasement de l'indication d'encombrement n'est efficace que si le paquet ne finit pas par être marqué ou abandonné à nouveau par un routeur en aval. Si le codet CE est remplacé par un codet ECT, le paquet reste à capacité ECN, et pourrait être soit marqué soit abandonné par un routeur en aval comme indication d'encombrement. Si le codet CE est remplacé par le codet non-ECT, le paquet n'est plus à capacité ECN, et peut donc être abandonné mais pas marqué par un routeur aval comme indication d'encombrement.

18.1.2 Encombrement rapporté à tort

Ce changement est d'établir le codet CE lorsque un codet ECT a déjà été établi, bien qu'il n'y ait pas d'encombrement. Ce changement n'affecte pas le traitement de ce paquet le long du reste du chemin. En particulier, un routeur n'examine pas le codet CE pour décider si il abandonne ou marque un paquet arrivant.

Cependant, il pourrait résulter de ceci que l'application invoque sans nécessité le contrôle d'encombrement de bout en bout, et réduise son taux d'arrivées. En soi, ce n'est pas pire (pour l'application ou pour le réseau) que si le routeur vicieux avait en fait abandonné le paquet.

18.1.3 Désactiver la capacité ECN

Ce changement met à zéro le codet ECT d'un paquet. Cela signifie que si le paquet rencontre plus tard de l'encombrement (par exemple, en arrivant à une file d'attente RED avec une taille modérée de file d'attente moyenne) il va être abandonné au lieu d'être marqué. En soi, ceci n'est pas pire (pour l'application) que si le routeur vicieux avait réellement abandonné le paquet. Ce qui sauve dans ce cas particulier est qu'il n'y a pas de routeur encombré en amont qui attende une réaction à l'établissement du bit CE.

18.1.4 Capacité ECN indiquée à tort

Ce changement va marquer incorrectement un paquet comme à capacité ECN. Le paquet peut avoir été envoyé par un transport à capacité ECN ou par un transport qui n'a pas la capacité ECN.

Si le paquet rencontre plus tard un encombrement modéré chez un routeur à capacité ECN, celui-ci peut établir le codet CE au lieu d'abandonner le paquet. Si le protocole de transport n'est en fait pas à capacité ECN, le transport ne va alors jamais recevoir cette indication d'encombrement, et ne va pas réduire son taux d'envoi en réponse. Les conséquences potentielles d'une fausse indication de capacité ECN sont exposées plus en détails à la Section 19.

Si le paquet ne rencontre jamais d'encombrement chez un routeur à capacité ECN, le premier de ces deux changements n'aura alors aucun effet, autre qu'une possible interférence avec l'utilisation du nom occasionnel ECN par le protocole de transport. Cependant, le dernier changement aurait pour effet de donner de faux rapports d'encombrement à un appareil de surveillance le long du chemin. Si le protocole de transport est à capacité ECN, ce changement pourrait alors avoir aussi un effet au niveau transport, en combinant la fausse indication de capacité ECN avec de faux rapports d'encombrement. Pour un transport à capacité ECN, cela serait cause que le transport réagisse inutilement à l'encombrement. Dans ce cas particulier, le routeur qui a changé incorrectement le champ ECN pourrait avoir abandonné le paquet. Et donc, pour ce cas d'un transport à capacité ECN, la conséquence de ce changement du champ ECN n'est pas pire que l'abandon du paquet.

Pour TCP, un receveur TCP à capacité ECN informe son homologue TCP qu'il est à capacité ECN au niveau TCP, en convoyant cette information dans l'en-tête TCP au moment de l'établissement de la connexion. Le présent document n'examine pas les dangers potentiels introduits par les changements dans l'en-tête de transport au sein du réseau. On note que lorsque IPsec est utilisé, l'en-tête de transport est protégé à la fois dans le mode tunnel et dans le mode transport [RFC2402, RFC2406].

Un autre problème concerne les paquets TCP avec une adresse IP de source usurpée qui portent des informations ECN invalides dans l'en-tête de transport. Pour être complets, nous examinerons ici certaines des façons possible dont un nœud qui usurpe l'adresse IP de source d'un autre nœud pourrait utiliser les deux fanions ECN dans l'en-tête TCP pour lancer une attaque de déni de service. Cependant, ces attaques exigeraient que l'attaquant ait la capacité d'utiliser des numéros de séquence TCP valides, et tout attaquant qui a cette capacité ainsi que celle d'usurper des adresses IP de source pourrait causer des dommages à la connexion TCP sans utiliser les fanions ECN. Donc, ECN n'ajoute aucune nouvelle faiblesse à cet égard.

Un paquet d'accusé de réception avec une adresse IP de source usurpée de la part du receveur des données TCP pourrait comporter le bit ECE établi. Si il est accepté par l'envoyeur des données TCP comme paquet valide, ce paquet d'accusé de réception usurpé pourrait avoir pour résultat que l'envoyeur des données TCP diminue par deux sans nécessité sa fenêtre d'encombrement. Cependant, pour être accepté par l'envoyeur des données, un tel paquet d'accusé de réception usurpé devrait avoir le numéro de séquence correct de 32 bits ainsi qu'un numéro d'accusé de réception correct. Un attaquant qui pourrait réussir à envoyer un tel paquet d'accusé de réception usurpé pourrait aussi envoyer un paquet RST usurpé, ou accomplir d'autres opérations également dommageables pour la connexion TCP.

Les paquets avec une adresse IP de source usurpée provenant de l'envoyeur des données TCP pourraient comporter le bit CWR établi. Cette fois encore, pour être accepté, un tel paquet devrait avoir un numéro de séquence valide. De plus, un tel paquet falsifié aurait un impact limité sur les performances. Falsifier un paquet de données avec le bit CWR établi pourrait avoir pour résultat que le receveur des données TCP va envoyer moins de paquets ECE qu'il n'aurait fait autrement, si le receveur des données envoyait des paquets ECE lorsque il a reçu le paquet CWR falsifié.

Dans certains cas, un routeur malveillant ou défectueux pourrait avoir accès à seulement un sous ensemble des paquets d'un flux. La question est la suivante : ce routeur peut il, en altérant le champ ECN dans ce sous-ensemble de paquets, faire plus de dommages à ce flux que si il avait simplement éliminé cet ensemble de paquets ?

Nous allons classer les paquets du flux en paquets A et B, et supposer que l'adversaire n'a accès qu'aux paquets A. Supposons que l'adversaire subvertisse le contrôle d'encombrement de bout en bout le long du chemin parcouru seulement par les paquets A, soit en indiquant faussement la capacité ECN en amont du point où survient un encombrement, soit en écrasant l'indication d'encombrement vers l'aval. Considérons aussi qu'il existe un appareil de surveillance qui voir aussi bien les paquets A que B, et va "punir" les deux paquets A et B si le flux total est convaincu de ne pas répondre de façon appropriée aux indications d'encombrement. Une autre caractéristique clé dont nous pensons qu'elle a des chances d'être vraie est que l'appareil de surveillance, avant de "punir" le flux A&B, va d'abord abandonner des paquets au lieu d'établir le codet CE, et va abandonner les paquets arrivant de ce flux qui ont déjà le codet CE établi. Si les nœuds d'extrémité utilisent en fait le contrôle d'encombrement de bout en bout, ils vont voir toutes les indications d'encombrement vues par l'appareil de surveillance, et vont commencer à répondre à ces indications d'encombrement. Et donc, l'appareil de surveillance réussit à fournir les indications au flux à un stade précoce.

Il est vrai que l'adversaire qui a seulement accès aux paquets A pourrait, en subvertissant le contrôle d'encombrement fondé sur ECN, être capable de dénier le bénéfice d'ECN aux autres paquets de l'agrégat A&B. Bien que ce soit regrettable, ce n'est pas une raison suffisante pour désactiver ECN.

Une variante des faux rapports d'encombrement survient lorsque il y a deux adversaires le long d'un chemin, où le premier adversaire fait de faux rapports d'encombrement, et le second adversaire `écrase ces rapports. (À la différence de l'abandon de paquets, les rapports d'encombrement ECN peuvent être "reversés" ultérieurement dans le réseau par un routeur malveillant ou défectueux. Cependant, l'utilisation d'un nom occasionnel ECN pourrait aider le transport à détecter ce comportement.) Bien que ceci soit transparent pour le nœud d'extrémité, il est possible qu'un appareil de surveillance entre le premier et le second adversaire voit les fausses indications d'encombrement. Il faut garder en mémoire notre recommandation qu'avant de "punir" un flux pour n'avoir pas répondu correctement à l'encombrement, le routeur passe d'abord à l'abandon plutôt que de marquer comme indication d'encombrement, pour ce flux. Lorsque ceci inclut d'abandonner les paquets arrivants qui proviennent de ce flux et ont le codet CE établi, cela assure que ces indications d'encombrement vont être vues par les nœuds d'extrémité. Et donc, il n'y a pas de dommages supplémentaires par rapport à ce que nous avons déjà constaté, lorsque plusieurs adversaires sont en concurrence.

La présente section se concentre sur les répercussions potentielles de la subversion du contrôle d'encombrement de bout en bout par la fausse indication de la capacité ECN ou par l'écrasement de l'indication d'encombrement dans ECN (le codet CE). La subversion du contrôle d'encombrement par l'une de ces deux méthodes peut avoir des conséquences aussi bien pour l'application que pour le réseau. Elles sont exposées séparément ci-dessous.

La première méthode pour subvertir le contrôle d'encombrement de bout en bout, celle de la fausse indication de capacité ECN, ne bouleverse effectivement le contrôle d'encombrement de bout en bout que si le paquet rencontre ultérieurement un encombrement qui résulte en l'établissement du codet CE. Dans ce cas, le protocole de transport (qui peut n'être pas à capacité ECN) ne reçoit pas l'indication d'encombrement de ces routeurs d'aval encombrés.

La seconde méthode pour subvertir le contrôle d'encombrement de bout en bout, qui "écrase" le codet CE dans un paquet, ne bouleverse effectivement le contrôle d'encombrement de bout en bout que lorsque le codet CE dans le paquet était établi précédemment par un routeur encombré. Dans ce cas, le protocole de transport ne reçoit pas l'indication d'encombrement des routeurs d'amont encombrés.

L'une et l'autre de ces deux méthodes de subversion du contrôle d'encombrement de bout en bout peut introduire plus de dommages au réseau (et éventuellement au flux lui-même) que si l'adversaire avait simplement éliminé les paquets de ce flux. Cependant, comme nous allons le montrer plus loin dans cette section et dans la Section 7, ce dommage potentiel est limité.

Le codet CE du champ ECN est seulement utilisé par les routeurs comme indication d'encombrement durant des périodes d'encombrement "modéré". Les routeurs à capacité ECN devraient éliminer plutôt que marquer les paquets durant les encombrement lourds même si la file d'attente du routeur n'est pas encore pleine. Par exemple, pour des routeurs qui utilisent la gestion active de file d'attente fondée sur RED, le routeur devrait abandonner plutôt que marquer les paquets qui arrivent lorsque les tailles moyennes de file d'attente excèdent le seuil maximum de file d'attente RED.

Une conséquence pour le réseau de la subversion du contrôle d'encombrement de bout en bout est que les flux qui ne reçoivent pas l'indication d'encombrements de la part du réseau peuvent accroître leur taux d'envoi jusqu'à ce qu'ils amènent le réseau à un encombrement encore plus lourd. Alors, le routeur encombré pourrait commencer à éliminer plutôt que marquer les paquets arrivants. Pour les flux qui ne sont pas isolés par une forme quelconque de programmation par flux ou autres mécanismes par flux, mais sont plutôt agrégés de façon indifférenciée avec d'autres flux dans une seule file d'attente, cet abandon de paquet aux routeurs encombrés s'appliquerait à tous les flux qui partagent cette file d'attente. La conséquence serait donc d'augmenter le niveau d'encombrement dans le réseau.

Dans certains cas, l'augmentation du niveau d'encombrement va conduire à une substantielle construction de tampons à la file d'attente encombrée qui va être suffisante pour faire passer la file d'attente encombrée du régime de marquage de paquets à celui de l'abandon de paquets. Cette transition pourrait survenir soit à cause du débordement de la mémoire tampon, soit à cause de la politique de gestion active de file d'attente décrite ci-dessus qui abandonne les paquets lorsque la taille moyenne de la file d'attente est au dessus du seuil maximum de RED. À ce point, tous les flux, y compris le flux subverti, vont commencer à voir des abandons de paquet au lieu du marquage des paquets, et un routeur malveillant ou déficient ne va plus être capable d'écraser ces indications d'encombrement dans le réseau. Si les nœuds d'extrémité ont développé un contrôle d'encombrement de bout en bout approprié, le flux subverti va réduire son taux d'arrivée en réponse à l'encombrement. Lorsque le niveau d'encombrement est suffisamment réduit, la file d'attente encombrée peut retourner du régime d'abandon de paquet au régime de marquage de paquet. Le schéma de régime permanent pourrait être celui d'une file d'attente encombrée qui oscille entre ces deux régimes.

Dans d'autres cas, la conséquences de la subversion du contrôle d'encombrement de bout en bout ne sera pas assez sévère pour amener la liaison encombrée à un encombrement suffisamment sévère pour que les paquets soient abandonnés au lieu d'être marqués. Dans ce cas, les implications pour les flux en concurrence dans le réseau seront un taux légèrement accru de marquage ou d'abandon de paquets, et une diminution correspondante de la bande passante disponible pour ces flux. Cela peut être un état stable si le taux d'arrivée du flux subverti est suffisamment faible, par rapport à la bande passante de la liaison, pour que la taille moyenne de la file d'attente au routeur encombré reste sous contrôle. En particulier, le flux subverti pourrait avoir une demande de bande passante limitée sur la liaison à ce routeur, tout en en obtenant quand même plus que sa "juste" part de la liaison. Cette demande limitée pourrait être due à une demande limitée à partir de la source des données; une limitation provenant de la fenêtre TCP annoncée; d'un canal d'accès à bande passante inférieure; ou à d'autres facteurs. La subversion du contrôle d'encombrement fondé sur ECN peut encore conduire à des injustices, dont nous pensons qu'il est approprié de parler ici.

La menace posée au réseau par la subversion du contrôle d'encombrement fondé sur ECN dans le réseau est essentiellement la même que la menace posée par un système d'extrémité qui échoue intentionnellement à coopérer avec le contrôle d'encombrement de bout en bout. Le développement de mécanismes dans les routeurs pour faire face à cette menace est une question de recherche encore ouverte, et elle est discutée plus en détails à la Section 10.

Prenons l'exemple décrit au paragraphe 18.1.1, où le codet CE qui était établi dans un paquet est écrasé : {'11' -> '10' ou
'11' -> '01'}. La conséquence pour le routeur amont encombré qui a établi le codet CE est que cette indication d'encombrement n'atteint pas les nœuds d'extrémité pour ce flux. La source (même une qui est complètement coopératrice et non malveillante) est donc autorisée à continuer d'augmenter son taux d'envoi (si c'est un flux TCP, en accroissant sa fenêtre d'encombrement). Le flux obtient potentiellement un meilleur débit que les autres flux qui partagent aussi le routeur encombré, en particulier si il n'y a pas de mécanisme de régulation ou de mécanisme de mise en file d'attente par flux sur ce routeur. Considérons le comportement des autres flux, en particuliers si ils coopèrent : c'est-à-dire des flux qui ne rencontrent pas de contrôle d'encombrement de bout en bout subverti. Ils vont vraisemblablement réduire leur charge (par exemple, en réduisant leur taille de fenêtre) sur le routeur encombré, bénéficiant ainsi du flux subverti. Il en résulte une injustice. Comme nous l'avons exposé plus haut, cette injustice pourrait être transitoire (parce que la file d'attente encombrée est conduite dans le régime de marquage de paquet), oscillante (parce que la file d'attente encombrée oscille entre le régime de marquage de paquet et l'abandon de paquet), ou dans un état plus modéré mais stable persistant (parce que la file d'attente encombrée n'est jamais conduite au régime d'abandon de paquet).

Les résultats seraient similaires si le flux subverti évitait intentionnellement le contrôle d'encombrement de bout en bout . Une différence est qu'un flux qui évite intentionnellement le contrôle d'encombrement de bout en bout aux nœuds d'extrémité peut éviter le contrôle d'encombrement de bout en bout même lorsque la file d'attente encombrée est en mode d'abandon de paquet, en refusant de réduire son taux d'envoi en réponse aux abandons de paquet dans le réseau. Donc pour le réseau, le problème de la subversion du contrôle d'encombrement fondé sur ECN est moins sévère que le problème causé par l'évitement intentionnel du contrôle d'encombrement de bout en bout aux nœuds d'extrémité. Le fait est qu'il est considérablement plus difficile de contrôler le comportement des nœuds d'extrémité que de contrôler le comportement de l'infrastructure elle-même. Ce n'est pas pour dire que les problèmes posés au réseau par la subversion du contrôle d'encombrement fondé sur ECN sont minimes ; simplement qu'ils sont dépassés par les problèmes de réseau posés par la subversion des mécanismes de contrôle d'encombrement soit fondés sur ECN soit sur d'autres mécanismes actuellement connus fondés sur le paquet par les nœuds d'extrémité.

Lorsque une source indique qu'elle est à capacité ECN, on s'attend à ce que les routeurs qui dans le réseau sont capables de participer à ECN utilisent le codet CE pour l'indication d'encombrement. Il y a le bénéfice potentiel de l'utilisation d'ECN en réduisant la quantité de paquets perdus (en plus de la réduction des délais de file d'attente à cause des politiques de gestion active de file d'attente). Lorsque le paquet s'écoule à travers un tunnel IPsec où les nœuds que traversent les paquets tunnelés ne sont pas de confiance d'une façon quelconque, ce qu'on attend d'IPsec est de protéger le flux de la subversion qui résulte en des conséquences indésirables.

Dans de nombreux cas, un flux subverti va bénéficier de la subversion du contrôle d'encombrement de bout en bout pour ce flux dans le réseau, en recevant plus de bande passante qu'il n'en aurait eu autrement, par rapport aux flux concurrents non subvertis. Si la file d'attente encombrée atteint le stade de l'abandon de paquet, la subversion du contrôle d'encombrement de bout en bout peut ou non être globalement bénéficiaire pour le flux subverti, selon les compromis relatifs de ce flux entre débit, perte et délai.

Une forme de subversion du contrôle d'encombrement de bout en bout est de faussement indiquer la capacité ECN en établissant le codet ECT. Cela a pour conséquence que les routeurs encombrés en aval établissent le codet CE en vain. Cependant, comme décrit au paragraphe 9.1.2, si un codet ECT est changé dans un tunnel IP, cela peut être détecté au point de sortie du tunnel, pour autant que l'en-tête interne n'a pas été changé dans le tunnel.

La seconde forme de subversion du contrôle d'encombrement de bout en bout est d'écraser l'indication d'encombrement en écrasant le codet CE. Dans ce cas, ce sont les routeurs encombrés de l'amont qui établissent le codet CE en vain.

Si un codet ECT est écrasé dans un tunnel IP, cela peut alors être détecté au point de sortie du tunnel, pour autant que l'en-tête interne n'a pas été changé dans le tunnel. Si le codet CE est mis en amont du tunnel IP, tout écrasement du codet CE de l'en-tête externe dans le tunnel n'aura aucun effet parce que l'en-tête interne préserve la valeur établie du codet CE. Cependant, si le codet CE est mis dans le tunnel, et écrasé soit dans le tunnel, soit en aval du tunnel, cela n'est pas nécessairement détecté au point de sortie du tunnel.

Avec cette subversion du contrôle d'encombrement de bout en bout, un transport de système d'extrémité ne répond pas aux indications d'encombrement. En plus de l'injustice accrue pour les flux non subvertis décrite au paragraphe précédent, la file d'attente du routeur encombré pourrait continuer d'augmenter, résultant en pertes de paquets au routeur encombré – ce qui est dans tous les cas un moyen d'indiquer l'encombrement au transport. Dans l'intérim, le flux peut rencontrer de plus forts délais de mise en file d'attente, éventuellement avec une bande passante accrue par rapport aux autres flux non subvertis. Mais les transports ne font par nature pas d'hypothèse sur la possibilité de rencontrer des files d'attentes bien gérées sur le chemin. Nous pensons que ces formes de subversion du contrôle d'encombrement de bout en bout ne sont pas pires pour le flux subverti que si l'adversaire avait simplement éliminé lui-même les paquets de ce flux.

Nous avons montré que, dans de nombreux cas, un routeur malveillant ou défectueux qui est capable de changer les bits dans le champ ECN ne peut pas causer plus de dommages que si il avait simplement éliminé le paquet en question. Cependant, cela n'est pas vrai dans tous les cas, en particulier dans ceux où le routeur défectueux subvertit le contrôle d'encombrement de bout en bout en indiquant faussement la capacité ECN ou en écrasant l'indication d'encombrement ECN (dans le codet CE). Bien qu'il y ait de nombreuses façons dont un routeur puisse causer du tort à un flux en éliminant les paquets, un routeur ne peut pas subvertir le contrôle d'encombrement de bout en bout en éliminant les paquets. Par exemple, un routeur ne peut pas subvertir le contrôle d'encombrement de TCP en éliminant les paquets de données, les paquets d'accusé de réception, ou les paquets de contrôle.

Bien que l'abandon de paquet ne puisse être utilisé pour subvertir le contrôle d'encombrement de bout en bout, il y a des méthodes non fondées sur ECN pour subvertir le contrôle d'encombrement de bout en bout que pourraient utiliser un routeur malveillant ou défectueux. Par exemple, un routeur défectueux pourrait dupliquer des paquets de données, et donc annuler effectivement les effets du contrôle d'encombrement de bout en bout le long de certaines portions du chemin. (Pour un routeur qui a dupliqué des paquets au sein d'un tunnel IPsec, l'administrateur de sécurité peut causer l'élimination des paquets dupliqués en configurant une protection anti répétition pour le tunnel.) Cette duplication des paquets au sein du réseau aurait des implications similaires pour le réseau et pour le flux subverti que celles décrites aux paragraphes 18.1.1 et 18.1.4 ci-dessus.

La nécessité d'un codet ECT est motivée par le fait qu'ECN va être déployé de façon incrémentaire dans un Internet où certains protocoles de transport et routeurs comprennent ECN et d'autre pas. Avec un codet ECT, le routeur peut abandonner des paquets de flux qui ne sont pas à capacité ECN, mais peuvent *au lieu de cela* établir le codet CE dans des paquets qui *sont* à capacité ECN. Parce que le codet ECT permet à un nœud d'extrémité d'avoir le codet CE établi dans un paquet *au lieu* d'avoir un paquet abandonné, un nœud d'extrémité peut sentir quelque incitation à déployer ECN.

Si il n'y avait pas de codet ECT, le routeur devrait alors établir le codet CE pour les paquets provenant de flux à capacité ECN aussi bien que de flux sans capacité ECN. Dans ce cas, il n'y aurait pas d'incitation pour les nœuds d'extrémité à déployer ECN, et aucun chemin viable de déploiement incrémentaire d'un monde non ECN à un monde à capacité ECN. Considérons les premiers stades d'un tel déploiement incrémentaire, où un sous ensemble des flux est à capacité ECN. Au commencement de l'encombrement, lorsque le taux de marquage de paquets à abandonner reste faible, les routeurs vont seulement établir le codet CE, plutôt que d'éliminer les paquets. Cependant, seuls les flux qui sont à capacité ECN vont comprendre et répondre aux paquets CE. Le résultat est que les flux à capacité ECN vont rétrograder, et ceux qui ne le sont pas ne vont pas être au courant des signaux ECN et vont continuer d'ouvrit leur fenêtre d'encombrement.

Dans ce cas, il y a deux résultats possibles : (1) les flux à capacité ECN rétrogradent, les flux sans capacité ECN prennent toute la bande passante, et l'encombrement reste modéré, ou (2) les flux à capacité ECN rétrogradent, les flux sans capacité ECN ne le font pas, et l'encombrement augment jusqu'à ce que le routeur passe de l'établissement du codet CE à l'abandon de paquets. Bien que le second résultat soit plus juste, les flux à capacité ECN vont quand même tirer peu de profit d'être à capacité ECN, parce que l'encombrement accru va conduire le routeur à un comportement d'abandon de paquets.

Un flux qui ne s'annonce pas lui-même comme à capacité ECN mais ne répond pas aux codets CE est fonctionnellement équivalent à un flux qui désactive le contrôle d'encombrement, comme exposé plus haut dans ce document.

Donc, dans un monde où un sous-ensemble de flux est à capacité ECN, mais où les flux à capacité ECN n'ont pas de mécanisme pour indiquer ce fait aux routeurs, le contrôle d'encombrement dans l'Internet sera moins efficace et moins juste, d'où résultera une forte incitation à ce que les nœuds d'extrémité ne déploient pas ECN.

La principale motivation des deux codets ECT est de fournir un nom occasionnel ECN de un bit. Le nom occasionnel ECN permet le développement de mécanismes pour que l'envoyeur vérifie la probabilité que des éléments de réseau n'écrasent pas le codet CE, et que les receveurs des données fassent correctement rapport à l'envoyeur de la réception des paquets avec le codet CE établi.

Une autre possibilité pour les envoyeurs de détecter les éléments de réseau ou les receveurs qui se comportent mal serait que l'envoyeur des données envoie occasionnellement un paquet de données avec le codet CE établi, pour voir si le receveur rapporte la réception du codet CE. Bien sûr, si ces paquets rencontrent de l'encombrement dans le réseau, le routeur peut ne faire aucun changement aux paquets, parce que le codet CE serait déjà établi. Donc, pour les paquets envoyés avec le codet CE établi, les nœuds d'extrémité TCP ne pourraient pas déterminer si certains routeurs avaient l'intention d'établir le codet CE dans ces paquets. Pour cette raison, l'envoi de paquets avec le codet CE aurait été fait avec parcimonie, et aurait été une vérification moins efficace des mauvais comportements d'éléments de réseau et de receveurs que ne le serait le nom occasionnel ECN.

L'allocation du quatrième codet ECN à ECT(1) empêche l'utilisation de ce codet à d'autres fins. Pour être clairs, nous énumérons brièvement ici ces autres fins possibles.

Une possibilité aurait pu être que l'envoyeur des données utilise le quatrième codet ECN pour indiquer une sémantique de remplacement à ECN. Cependant, il nous semble plus approprié de signaler l'utilisation du codet des services différentiés dans le champ DS.

Une seconde utilisation possible pour le quatrième codet ECN aurait été de donner au routeur deux codets séparés pour l'indication d'encombrement, CE(0) et CE(1), pour l'encombrement respectivement modéré et sévère. Bien que cela puisse être utile dans certains cas, cela ne semble certainement pas une exigence pressante pour le moment. S'il se révélait qu'il y en ait un besoin pressant, les complications d'un déploiement incrémentaire nécessiteraient très vraisemblablement plus qu'un seul codet pour cette fonction.

Une troisième utilisation a été proposée de façon informelle pour le codet ECN dans certaines formes de contrôle d'encombrement dans la diffusion groupée, sur la base de procédures d'aléation pour la duplication de paquets marqués chez les routeurs. Certaines procédures proposées pour la duplication de paquets de diffusion groupée se fondent sur un nouveau codet ECN qui (1) porte le fait que de l'encombrement est survenu en amont du point de duplication qui a marqué le paquet avec ce codet et (2) peut détecter de l'encombrement en aval de ce point de duplication. ECT(1) peut servir à cette fin parce qu'il est à la fois distinct de ECT(0) et est remplacé par CE lorsque le marquage ECN survient en réponse à l'encombrement ou à l'encombrement naissant. L'explication de la façon dont cette version améliorée d'ECN serait utilisée par le contrôle d'encombrement de diffusion groupé sort du domaine d'application du présent document, comme le sont les procédures de duplication de paquet de diffusion groupée à capacité ECN et le traitement du champ ECN de receveurs de diffusion groupée dans tous les cas (c'est-à-dire, sans considération de la ou des procédures de duplication de paquet de diffusion groupée utilisées).

La spécification dans ce document des modifications du tunnel IP pour ECN suppose que le seul changement fait au champ ECN de l'en-tête IP externe entre les points d'extrémité du tunnel est d'établir le codet CE pour indiquer l'encombrement. Cela n'est pas cohérent avec certaines des utilisations proposées de ECT(1) par les procédures de duplication de diffusion groupée du paragraphe précédent, et de telles procédures NE DEVRAIENT PAS être déployées tant que n'aura pas été résolue cette incohérence entre procédures de duplication de diffusion groupée et tunnels IP avec pleine fonctionnalité ECN. La fonctionnalité ECN limitée peut être utilisée à la place, bien qu'en pratique de nombreux protocoles de tunnel (y compris IPsec) ne vont pas fonctionner correctement si la duplication de trafic de diffusion groupée survient dans le tunnel.

Sachant le besoin d'une indication d'ERT dans l'en-tête IP, il reste encore la question de savoir si les codets ECT (Transport à capacité ECV) et CE (Encombrement rencontré) devraient avoir été surchargés sur un seul bit. Cette solution de remplacement consistant en un bit surchargé, explorée dans [Floyd94], aurait impliqué un seul bit avec deux valeurs. Une valeur, "ECT et non CE", aurait représenté un Transport à capacité ECN, et l'autre valeur, "CE ou non ECT", aurait représenté soit Encombrement rencontré soit un transport sans capacité ECN

Une différence entre les mises en œuvre de un bit et celles de deux bits concerne les paquets qui traversent plusieurs routeurs encombrés. Considérons un paquet CE qui arrive à un second routeur encombré, et est choisi par la gestion active de file d'attente à ce routeur pour le marquage ou l'abandon. Dans la mise en œuvre à un bit, le second routeur encombré n'a d'autre choix que d'éliminer le paquet CE, parce qu'il ne peut pas distinguer entre un paquet CE et un paquet non ECT. Dans la mise en œuvre à deux bits le second routeur encombré a le choix entre abandonner le paquet CE ou le laisser continuer avec le codet CE établi.

Une autre différence entre la mise en œuvre à un bit et celle à deux bits vient du fait que avec celle à un bit, les receveurs dans un seul flux ne peuvent pas distinguer entre les paquets CE et non ECT. Donc, dans la mise en œuvre à un bit, un envoyeur de données à capacité ECN aurait à indiquer de façon non ambiguë au ou aux receveurs si chaque paquet a été envoyé comme à capacité ECN ou comme non capable d'ECN. Une possibilité serait que l'envoyeur indique dans l'en-tête de transport si le paquet a été envoyé comme à capacité ECN. Une seconde possibilité qui impliquerait une limitation fonctionnelle pour la mise en œuvre à un bit serait que l'envoyeur indique sans ambiguïté qu'il va envoyer *tous* ses paquets comme à capacité ECN ou comme non capables d'ECN. Pour un protocole de transport de diffusion groupée, cette indication non ambiguë devrait être apparente pour les receveurs lorsque ils se joignent à une session de diffusion groupée en cours.

Un autre problème qui a été décrit antérieurement (et qui est recommandé dans le présent document) est que les transports (en particulier TCP) ne devraient pas marquer les paquets de pur ACK ou les paquets retransmis, comme étant à capacité ECN. Un paquet de pur ACK provenant d'un transport non à capacité ECN pourrait être éliminé, sans nécessairement avoir un impact sur le transport du point de vue du contrôle d'encombrement (parce que les ACK suivants sont cumulatifs). Un transport à capacité ECN qui réagit au codet CE dans un paquet de pur ACK en réduisant la fenêtre serait désavantagé par rapport à un transport non à capacité ECN. Pour cette raison (et pour les raisons décrites antérieurement en relation avec les paquets retransmis) il est souhaitable d'avoir le codet ECT établi paquet par paquet.

Un autre avantage de l'approche à deux bits est qu'elle est un peu plus robuste. La question la plus critique, exposée à la Section 8, est que l'indication par défaut devrait être celle d'un transport sans capacité ECN. Dans une mise en œuvre à deux bits, cette exigence pour la valeur par défaut signifie simplement que le codet non ECT devrait être la valeur par défaut. Dans la mise en œuvre à un bit, cela signifie que le bit surchargé unique devrait par défaut être dans la position "CE ou non ECT". Cela est moins clair et moins direct, et éventuellement plus ouvert à des mises en œuvre incorrectes dans les nœuds d'extrémité ou dans les routeurs.

En résumé, alors que la mise en œuvre à un bit pourrait être possible, elle a des limitations significatives par rapport à celle à deux bits. D'abord, la mise en œuvre à un bit a une fonctionnalité plus limitée pour le traitement des paquets CE chez un second routeur encombré. Ensuite, la mise en œuvre à un bit exige que des informations supplémentaires soient portées dans l'en-tête de transport des paquets provenant de flux à capacité ECN (pour convoyer la fonctionnalité du second bit ailleurs, à savoir dans l'en-tête de transport) ou que l'envoyeur dans les flux à capacité ECN acceptent la limitation que les receveurs doivent être capables de déterminer à priori quels paquets sont à capacité ECN et ceux qui ne le sont pas. Troisièmement, la mise en œuvre à un bit est éventuellement plus ouverte aux erreurs de la part de mises en œuvre fautives qui choisissent la mauvaise valeur par défaut pour le bit ECN. Nous pensons que l'utilisation du bit supplémentaire dans l'en-tête IP pour le bit ECT est extrêmement précieuse pour surmonter ces limitations.

La [RFC791] définit l'octet ToS (Type de service) dans l'en-tête IP. Dans la RFC 791, les bits 6 et 7 de l'octet ToS sont marqués "Réservés pour utilisation future", et sont mis à zéro. Les deux premiers champs de l'octet ToS sont définis comme champs Préséance et Type de service (TOS).

La RFC 1122 inclut les bits 6 et 7 dans le champ TOS, bien qu'elle n'expose pas d'usage spécifique pour ces deux bits :

Le bit 6 du champ TOS a été défini dans la RFC 1349 comme "Minimise les coûts". En plus des champs Préséance et Type de service (TOS), le dernier champ, MBZ (pour "must be zero", doit être à zéro) a été défini comme non utilisé actuellement. La RFC 1349 déclarait que "le générateur d'un datagramme règle le champ [MBZ] à zéro (sauf participation à une expérience du protocole Internet qui utiliserait ce bit)."

La [RFC1455] définit une norme expérimentale qui utilise les quatre bits du champ TOS pour demander un niveau garanti de sécurité de la liaison.

La RFC 1349 et la RFC 1455 ont été rendues obsolètes par la "définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6" [RFC2474] dans laquelle les bits 6 et 7 du champ DS sont marqués comme Non utilisé actuellement (NU). La [RFC2780] spécifiait ECN comme une utilisation expérimentale du champ à deux bits. La RFC 2780 mettait à jour la définition du champ DS pour seulement mettre en application les six premiers bits de cet octet et non tous les huit bits ; ces six premiers bits sont définis comme codet Services différenciés (DSCP, Differentiated Services CodePoint) :

À cause de cette histoire tourmentée, il ne peut être garanti que la définition du champ ECN dans le présent document soit rétro compatible avec toutes les utilisations passées de ces deux bits.

Avant la RFC 2474, il n'était pas permis aux routeurs de modifier les bits des champs DSCP ou ECN dans les paquets transmis à travers eux, et donc, les routeurs qui se conforment seulement aux RFC antérieures à la 2474 ne devraient pas affecter ECN. Pour les nœuds d'extrémité, le bit 7 (le second bit ECN) doit être transmis à zéro pour toute mise en œuvre conforme aux seules RFC antérieures à la 2474. De tels nœuds peuvent transmettre le bit 6 (premier bit ECN) à un pour la disposition de "Minimiser le coût" de la RFC 1349 ou pour l'expérience autorisée par la RFC 1455 ; ni cet aspect de la RFC 1349 ni l'expérience de la RFC 1455 n'ont été largement mises en œuvre ni utilisées. Les dommages qui pourraient être causés par un routeur non conforme inclurait "d'écraser" le codet CE pour un paquet à capacité ECN qui arriverait au routeur avec le codet CE établi, ou d'établir le codet CE même en l'absence d'encombrement. Cela a été exposé au paragraphe sur la "non conformité dans le réseau".

Les dommages qui pourraient être faits dans un environnement à capacité ECN par un nœud d'extrémité non ECN qui transmettrait des paquets avec le codet ECT mis ont été exposés au paragraphe "Non conformité des nœuds d'extrémité".

La présente section contient les espaces de noms qui ont été créés dans la présente spécification, ou les valeurs allouées dans les espaces de noms existants gérés par l'IANA.

Les codets pour le champ ECN de l'en-tête IP sont spécifiés par action de normalisation de la présente RFC, comme exigé par la RFC 2780.

Lorsqu'un document est publié comme RFC, l'IANA devrait créer un nouveau registre, "Octet de ToS IPv4 et octet de classe de trafic IPv6", avec l'espace de nom suivant :

Bits 0-5 : voir le registre des codets du champ Services différenciés (http://www.iana.org/assignments/dscp-registry)

Les codets pour les fanions CWR et ECE dans l'en-tête TCP sont spécifiés par action de normalisation de la présente RFC, comme exigé par la RFC 2780.

Lorsque ce document sera publié comme RFC, l'IANA devra créer un nouveau registre, "Fanions d'en-tête TCP", avec l'espace de noms suivant :

Le protocole de commande de transmission (TCP) comporte un champ réservé de 6 bits défini dans la RFC 793, réservé pour utilisation future, dans les octets 13 et 14 de l'en-tête TCP, comme illustré ci-dessous. Les six autres bits de commande sont définis séparément par la RFC 793.

La RFC 3168 définit deux des six bits du champ Réservé afin de les utiliser pour ECN, comme suit :

L'IANA a alloué la valeur 10 à l'attribut d'association de sécurité IPSec pour l'utilisation du tunnel ECN décrite au paragraphe 9.2.1.2 ci-dessus à la demande de David Black en novembre 1999. L'IANA a changé la référence de cette allocation à la demande de David Black à la présente RFC.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	K. Ramakrishnan, TeraOptic Networks
Request for Comments : 3168	S. Floyd, ACIRI
RFC mises à jour : 2474, 2401, 793	D. Black, EMC
RFC rendue obsolète : 2481	septembre 2001
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle

	<-- Comment l'en-tête externe se rapporte à l'en-tête interne -->
	En-tête externe à l'encapsuleur	En-tête interne au désencapsuleur
Champs d'en-tête IPv4 :
Champ DS	copié de l'en-tête interne (5)	pas de changement
Champ ECN	construit (7)	construit (8)

Champs d'en-tête IPv6 :
Champ DS	copié de l'en-tête interne (6)	pas de changement
Champ ECN	construit (7)	construit (8)

HC' =	{ HC – 1	HC > 1
	{ 0x0000	HC = 1

HC' =	{ HC – 1	HC > 0
	{ 0xFFFE	HC = 0

Binaire	Mot clé	Références
00	Non-ECT (Transport sans la capacité ECN)	[RFC 3168]
01	ECT(1) (Transport(1) à capacité ECN)	[RFC 3168]
10	ECT(0) (Transport(0) à capacité ECN)	[RFC 3168]
11	CE (Encombrement)	[RFC 3168]

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Longueur d'en-tête				Réservé						U	A	P	R	S	F
										R	C	S	S	Y	I
										G	K	H	T	N	N

Bit	Nom	Référence
8	CWR (Fenêtre d'encombrement réduite)	[RFC 3168]
9	ECE (Écho ECN)	[RFC 3168]

K. K. Ramakrishnan	Sally Floyd	David L. Black
TeraOptic Networks, Inc.	ACIRI	EMC Corporation
téléphone : +1 (408) 666-8650	téléphone : +1 (510) 666-2989	42 South St.
mèl : kk@teraoptic.com	mèl : floyd@aciri.org	Hopkinton, MA 01748
	URL : http://www.aciri.org/floyd/	téléphone : +1 (508) 435-1000 x75140
		mèl : black_david@emc.com