6.1.5 Retransmitted TCP packets

6.1.5 Retransmitted TCP packets

This document specifies that an ECN-capable TCP implementation MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header of retransmitted packets, and that the TCP data receiver should ignore the ECN field on arriving packets that are outside the receiver's current window. This is for increased protection from denial-of-service attacks, and for robustness to ECN congestion indications on packets that are later dropped in the network.

First, we note that if a TCP sender were to set the ECT codepoint on retransmitted packets, then if an unnecessarily-retransmitted packet were later dropped in the network, the end-nodes would never receive a congestion indication from a router setting the CE codepoint. Thus, setting the ECT codepoint on retransmitted packets would be incompatible with the reliable delivery of the congestion indication, even for packets that are later dropped in the network.

In addition, an attacker able to forge the IP source address of a TCP sender could send packets with arbitrary sequence numbers, and with the CE codepoint set in the IP header. On receipt of such a forged packet, the TCP data receiver would determine that the data was not within the current receive window, and would return a duplicate acknowledgement. We will define an out-of-window packet at the TCP data receiver as a packet with data outside the receiver's current window. On receipt of an out-of-window packet, the TCP data receiver must decide whether or not to treat the CE codepoint in the packet header as a valid congestion indication, and therefore whether or not to return an ECN-Echo indication to the TCP data sender. If the TCP data receiver ignores the CE codepoint in out-of-window packets, then the TCP data sender will not receive this potentially-legitimate indication of congestion from the network, resulting in a violation of end-to-end congestion control. On the other hand, if the TCP data receiver honors the CE indication in out-of-window packets and reports the congestion indication to the TCP data sender, then the malicious node creating forged out-of-window packets has succeeded in "attacking" the TCP connection, forcing the data sender to unnecessarily reduce (halve) its congestion window. To prevent this denial-of-service attack, we specify that a legitimate TCP data sender MUST NOT set the ECT codepoint on retransmitted packets, and that a TCP data receiver should ignore the CE codepoint on out-of-window packets.

One disadvantage of not setting ECT(0) or ECT(1) on retransmitted packets is that it denies ECN protection to retransmitted packets. However, for an ECN-capable TCP connection in a fully ECN-capable environment with light congestion, the occasions when packets are dropped due to congestion should be rare, and therefore instances of retransmitted packets should be rare as well. If a packet is being retransmitted, then there is already packet loss (from corruption or from congestion) that could not be prevented by ECN.

We note that if a router sets the CE codepoint for an ECN-capable packet within a TCP connection, then the TCP connection is guaranteed to receive that congestion indication, or to receive some other congestion indication within the same window of data, even if that packet is dropped or reordered in the network. We consider two cases, when the packet is later retransmitted, and when the packet is not later retransmitted.

In the first case, if the packet is dropped or delayed, and is at some point retransmitted by the data sender, then the retransmission is the result of either a Fast Retransmit or a Retransmit Timeout for that packet or for some previous packet in the same window of data. In this case, because the data sender has already retransmitted the packet, we know that the data sender has already responded to a congestion indication for some packet within the same window of data as the original packet. Therefore, it doesn't matter that the first transmission of the packet had the CE codepoint set and was later dropped or delayed in the network, and therefore ignored as an out-of-window packet by the data receiver, because the sender has already responded to a congestion indication for that window of data.

In the second case, if the packet is never retransmitted by the data sender, then the packet was the only copy of that data received by the data receiver, and therefore arrived at the data receiver as an in-window packet, however much the packet might have been delayed or reordered. In this case, if the CE codepoint was set on the packet in the network, this would have been treated by the data receiver as a valid congestion indication.