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/