>Yes, but if you're a firewall that stepped into a temporal stasis box >before 3168 was published, you're still thinking that the bits are >reserved, and that the Japanese haven't surrendered, and you should >fight on, discarding evil packets that have the reserved bits set.... Actually, it has nothing to do with a firewall that still thinks that the ECN bits in the IP or TCP header are reserved. As RFC 3360 on "Inappropriate TCP Resets Considered Harmful" explains (in Section 11), it has to do with a port-scanning tool that used testing for ECN-capability as one of its many tests, back in the days when ECN was Experimental instead of Proposed Standard. Such testing for ECN-capability uses the two ECN bits in the TCP header, which used to be reserved. This was followed by a security article that said that anying using these two bits in the TCP header in a TCP SYN packet could be assumed to have malicious intentions. This was shortly followed by commercial products that blocked any TCP SYN packets using these two bits in the TCP header (but that did not block packets using the other four "Reserved" bits in the TCP header). That is, this is not about firewalls blocking TCP connections that use any of the previously-reserved bits in the TCP header, this is about firewalls that block only the two specific bits used for ECN. >From Section 11 of RFC 3360: Unfortunately, misconceived security concerns are one of the reasons for the problems described in this document in the first place. An August, 2000, article on "Intrusion Detection Level Analysis of Nmap and Queso" described the port-scanning tool Queso as sending SYN packets with the last two Reserved bits in the TCP header set, and said the following: "[QUESO] is easy to identify, if you see [these two Reserved bits and the SYN bit] set in the 13th byte of the TCP header, you know that someone has malicious intentions for your network." As is documented on the TBIT Web Page, the middleboxes that block SYNs using the two ECN-related Reserved flags in the TCP header do not block SYNs using other Reserved flags in the TCP header. One lesson appears to be that anyone can effectively "attack" a new TCP function simply by using that function in their publicly- available port-scanning tool, thus causing middleboxes of all kinds to block the use of that function. Section 3.1 of RFC 3360 is about those TCP implementations (i.e., Linux) that choose not to implement the fixes to TCP's ECN negotiation procedures that allow TCP to work even in the presence of these broken firewalls. The work-around is exactly what one might think, that is, if the first SYN is Reset or ignored, then one gets to try again without trying to negotiate ECN this time. This has been around as the suggested fix since 2000: 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... - Sally http://www.icir.org/floyd/