Examples of TCP Initialization with ECN
by Sally Floyd

The addition of ECN to IP and TCP is specified in [RFC2481] and
[RFB01].  In the TCP connection setup phase, the source and destination
TCPs exchange information about their willingness to use ECN.
Unfortunately, there exist some faulty firewalls and other equipment
in the Internet that either ignore an ECN-setup SYN packet or
respond with a RST, in the belief that such a packet (with these
bits set) is a signature for a port-scanning tool that could be
used in a denial-of-service attack.  It has been suggested that,
because of the presence of such faulty equipment, a TCP host that
receives no reply to an ECN-setup SYN within the normal SYN
retransmission timeout interval MAY resend the SYN and any subsequent
SYN retransmissions as non-ECN-setup SYNs.  This note gives examples
of TCP Initializations that could result.

Example scenarios.

Example 1, a dropped SYN:

 (1) Host A: Sends an ECN-setup SYN, packet is dropped.
 (3) Host A: Sends a non-ECN-setup SYN.
 (4) Host B: Sends a non-ECN-setup SYN/ACK. 

In this case, following the procedures in [RFB01], a TCP connection
is established, but neither Host A nor Host B may set the ECT bit
on data packets,

Example 2, a dropped SYN-ACK:

 (1) Host A: Sends an ECN-setup SYN. 
 (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped.
 (3) Host A: Sends a non-ECN-setup SYN.
 (4) Host B: Sends a non-ECN-setup SYN/ACK. 

Again, in this case, following the procedures in [RFB01], neither
Host A nor Host B may set the ECT bit on data packets,

Example 3, a delayed and then a dropped SYN/ACK 

 (1) Host A: Sends an ECN-setup SYN.
 (2) Host B: Sends an ECN-setup SYN/ACK, packet is delayed.
 (3) Host A: Sends a non-ECN-setup SYN.
 (4) Host B: Sends a non-ECN-setup SYN/ACK, packet is dropped.
 (5) Host A receives the first, delayed ECN-setup SYN/ACK. 

Again, in this case, following the procedures in [RFB01],
neither Host A nor Host B may set the ECT bit on data packets,

Example 4, a delayed SYN/ACK and a dropped SYN:

In this example, the two TCP end-points would have different
guidelines concerning the use of ECN.

 (1) Host A: Sends an ECN-setup SYN.
 (2) Host B: Sends an ECN-setup SYN/ACK, packet is delayed.
 (3) Host A: Sends a non-ECN-setup SYN, packet is dropped.
 (4) Host A receives the first, delayed ECN-setup SYN/ACK.

In this case, Host B assumes an ECN-Capable connection, and may
set the ECT bit on data packets.  Host A may not set the ECT bit
on data packets.  However, from the procedures in [RFB01],
Host A must respond appropriately to ECT packets from Host B.

We note that a host never uses the reception of ECT data packets
as an implicit signal that the other host is ECN-capable.

References

[RFC2481] K. Ramakrishnan and S. Floyd,
A Proposal to add Explicit Congestion Notification (ECN) to IP,
RFC 2481, January 1999.

[RFB01] K. Ramakrishnan, S. Floyd, and D. Black,
The Addition of Explicit Congestion Notification (ECN) to IP,
internet-draft, work in progress, March 2001.