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