On Wed, Jul 24, 2002 at 10:32:22AM +0200, Brian E Carpenter wrote:
The issue here is that there is a MAY in RFC 3168 that IMHO should
be a SHOULD. That's the first MAY in section 6.1.1.1. If your ECN
code implemented that MAY, you would not have seen a problem.
Nope, not true. The problem is most of the problematic firewalls
silently drop SYN packets without sending an RST. So simply
implementing the first MAY does little good.
The second MAY addresses that concern, but it adds a large amount of
complexity, because you have to deal with situations where one of the
packets are lost, and what happens if one side retransmits while the
otherside retries the SYN without the ECN bits. The discussion in RFC
3168 is incomplete about whether the SYN packet which is retransmitted
without the ECN bit needs to be done with a new set of sequence
numbers, and how to make sure both sides don't end up with a
conflicting idea of whether or not ECN is enabled. It certainly
increases the complexity of the TCP state transition diagram to
implement the second MAY, and the rules of how it should work are not
fully specified --- there is a lot of hand-waving going on there.
There is also the question of whether this kind of complexity should
be added, when arguably the firewalls involved are broken. At the
very least, they violate the internet dictum of being liberal in what
you accept --- with no security benefit whatsoever.
Furthermore, it should be noted that as far as I know, all of these
broken firewalls have updated firmware which fix the problem. The
issue is getting the firmware updated. (And not surprisingly, all of
the commercial e-comerce sites have this bug fixed for a very long
time. It's the non-profit sites which have been lame.)
- Ted