Stig Venaas writes:
Well, the real issue is who has a broken TCP implementation, or
firewall or other device that mishandles those packets.
The real issue is whether an ECN bit is reserved, or not reserved. If
it is reserved, dropping connections that set it is appropriate
behavior; if it is not reserved, then properly processing the bit is
appropriate behavior. However, the notion that software that considers
the bit reserved should just ignore it and keep on going is very
dangerous. RFC 3360 takes this attitude, and it's a risky one, no
matter how useful it might be to Linux hobbyists.
It's not appropriate to simply ignore reserved bits on input, because,
if any of them are set, your correspondent is obviously using
functionality that you don't have, and you know the functionality is not
backwards compatible because reserved bits are being set. Truly
backwards-compatible features will use reserved bits in ways that leaves
them unchanged (i.e., zero) in compatible modes.
So what is the "correct" behavior? Well, ECN is not
backwards-compatible. So a system that supports ECN should first
attempt to establish a connection that uses it, with the appropriate
bits set. If the remote host understands this, the connection will
continue normally. If the remote host does not understand ECN, then the
proper remote behavior is to DROP THE CONNECTION, at which point the
local host must REESTABLISH the connection, this time WITHOUT ECN, and
with the reserved bits all set to zero.
The principle of "liberal in what you accept, conservative in what you
expect" does indeed apply, but here people are applying it to the wrong
host. It is prudent to drop connections that set reserved bits, because
you have no idea why those bits are set, or what the other end may
expect in consequence. It is not prudent to set reserved bits and then
expect every other host to tolerate that; the entire world will not
upgrade at once and you must be able to deal with older implementations.
So the correct behavior is for the ECN-aware host to first attempt a
connection with ECN, then attempt again without it if the remote system
demonstrates that it is unable to support ECN (by resetting the
connection when it sees "reserved" bits mysteriously in use).
That's how compatibility is supposed to work, but apparently someone got
it wrong, and now the wrong parties are being blamed for the mistake.