6.1.5. Paquets TCP Retransmis (Retransmitted TCP packets)

Ce document spécifie que les implémentations TCP compatibles ECN NE DOIVENT ABSOLUMENT PAS définir l'un ou l'autre des codepoints ECT (ECT(0) ou ECT(1)) dans l'en-tête IP des paquets retransmis, et que le récepteur de données TCP DEVRAIT ignorer le champ ECN sur les paquets arrivant en dehors de la fenêtre actuelle du récepteur. Ceci est destiné à renforcer la sécurité contre les attaques par déni de service, ainsi que la robustesse contre les indications de congestion ECN pour les paquets qui sont ensuite abandonnés dans le réseau.

Premièrement, nous notons que si l'expéditeur TCP définit le codepoint ECT sur les paquets retransmis, alors si un paquet retransmis inutilement est ensuite abandonné dans le réseau, les nœuds terminaux ne recevront jamais l'indication de congestion du routeur définissant le codepoint CE. Ainsi, la définition du codepoint ECT sur les paquets retransmis est incompatible avec la livraison fiable de l'indication de congestion même pour les paquets qui sont ensuite abandonnés dans le réseau.

De plus, un attaquant capable de falsifier l'adresse IP source de l'expéditeur TCP peut envoyer des paquets avec des numéros de séquence arbitraires et le codepoint CE défini dans l'en-tête IP. À la réception de ce paquet falsifié, le récepteur de données TCP déterminerait que les données ne sont pas dans la fenêtre de réception actuelle et retournerait un accusé de réception dupliqué. Nous définissons un paquet hors fenêtre (out-of-window packet) au niveau du récepteur de données TCP comme un paquet en dehors de la fenêtre actuelle du récepteur. À la réception d'un paquet hors fenêtre, le récepteur de données TCP doit décider s'il doit traiter le codepoint CE dans l'en-tête de paquet comme une indication de congestion valide et donc retourner une indication ECN-Echo à l'expéditeur de données TCP. Si le récepteur de données TCP ignore le codepoint CE dans le paquet hors fenêtre, alors l'expéditeur de données TCP ne recevra pas cette indication de congestion potentiellement légitime du réseau, entraînant une violation du contrôle de congestion de bout en bout. D'autre part, si le récepteur de données TCP respecte l'indication CE dans le paquet hors fenêtre et signale l'indication de congestion à l'expéditeur de données TCP, alors un nœud malveillant créant des paquets hors fenêtre falsifiés a réussi à "attaquer" la connexion TCP, forçant l'expéditeur de données à réduire (de moitié) inutilement sa fenêtre de congestion. Pour éviter cette attaque par déni de service, nous spécifions que les expéditeurs de données TCP légitimes NE DOIVENT ABSOLUMENT PAS définir le codepoint ECT sur les paquets retransmis, et que les récepteurs de données TCP DEVRAIENT ignorer le codepoint CE sur les paquets hors fenêtre.

Un inconvénient de ne pas définir ECT(0) ou ECT(1) sur les paquets retransmis est qu'il refuse la protection ECN pour les paquets retransmis. Cependant, pour une connexion TCP compatible ECN dans un environnement entièrement compatible ECN avec une congestion légère, les cas de paquets abandonnés en raison de congestion devraient être rares, et donc les instances de paquets retransmis devraient être peu fréquentes. Si un paquet est retransmis, il y a déjà eu une perte de paquets que ECN ne pouvait pas empêcher (due à la corruption ou à la congestion).

Nous notons que si un routeur définit le codepoint CE sur un paquet compatible ECN pour une connexion TCP, alors la connexion TCP est garantie de recevoir cette indication de congestion, ou de recevoir une autre indication de congestion dans la même fenêtre de données, même si ce paquet est abandonné ou réordonné dans le réseau. Nous considérons deux cas, lorsque le paquet est ensuite retransmis, et lorsque le paquet n'est ensuite pas retransmis.

Dans le premier cas, si le paquet est abandonné ou retardé et est retransmis à un moment donné par l'expéditeur de données, alors la retransmission est le résultat d'une retransmission rapide ou d'un délai de retransmission pour ce paquet ou pour un paquet antérieur dans la même fenêtre de données. Dans ce cas, parce que l'expéditeur de données a retransmis le paquet, nous savons que l'expéditeur de données a déjà répondu à une indication de congestion pour un paquet dans la même fenêtre de données que le paquet original. Ainsi, même si la première transmission du paquet est abandonnée ou retardée dans le réseau si elle avait le codepoint CE défini et est ensuite ignorée par le récepteur de données comme un paquet hors fenêtre, ce n'est pas un problème car l'expéditeur a déjà répondu à une indication de congestion pour cette fenêtre de données.

Dans le deuxième cas, si le paquet n'est jamais retransmis par l'expéditeur de données, alors le paquet est la seule copie de ces données reçue par le récepteur de données et arrive donc au récepteur de données comme un paquet dans la fenêtre, quelle que soit la quantité de retard ou de réordonnancement que le paquet a pu subir dans le réseau. Dans ce cas, si le codepoint CE a été défini sur le paquet dans le réseau, cela sera traité comme une indication de congestion valide par le récepteur de données.