On Thu, Dec 11, 2003 at 01:05:15PM -0800, Sally Floyd wrote:
> A work-around for maintaining connectivity in the face of the broken
> equipment was described in [Floyd00], and has been specified in RFC
> 3168 as a procedure that may be included in TCP implementations.
> ...
> Some TCP implementors have so far decided not to deploy these
> workarounds...
>
> One might hope that Linux implementors would make a better decision
> next time around. And that firewall designers would not be so quick
> to block some new functionality just because it is used in the
> latest port-scanning tool. But I wouldn't count on it...
To continue quoting from RFC 3360, there were some good reasons stated
in that document for why reasonable implementors might not choose to
implement the workaround:
* The work-arounds would result in ECN-capable hosts not responding
properly to the first valid reset received in response to a SYN
packet.
* The work-arounds would limit ECN functionality in environments
without broken equipment, by disabling ECN where the first SYN or
SYN-ACK packet was dropped in the network.
* The work-arounds in many cases would involve a delay of six seconds
or more before connectivity is established with the remote server,
in the case of broken equipment that drops ECN-setup SYN packets.
By accommodating this broken equipment, the work-arounds have been
judged as implicitly accepting both this delay and the broken
equipment that would be causing this delay.
It should also be noted that RFC 3168 did not require the workaround
as a MUST. If RFC 3168 had required the use of the workaround (which
presumably would have required the working group to come to a
consensus that the tradeoffs listed above were less important than
coddling trashy firewall implementations), then I'm sure the Linux
implementors would have respected such a MUST requirement in RFC 3168.
- Ted