TCP window scaling and broken routers [LWN.net]

TCP window scaling and broken routers

Posted Jul 10, 2004 0:19 UTC (Sat) by dlang (✭ supporter ✭, #313)
Parent article: TCP window scaling and broken routers

let's see with ECN people were up in arms about those nasty firewalls that blocked backets that did unknown things with the undefined bits in the header (even before ECN was an approved spec) and said that they should have zerod out the bits instead of blocking the packet.

in this case the nasty firewalls zero out the bits in the unknown option and people are complaining

putting these two togeather it sounds like what people really want is for the firewalls/routers to just let everything through and not try to enforce anything.

why am I not surprised that this doesn't "just happen"

(Log in to post comments)

Posted Jul 10, 2004 2:53 UTC (Sat) by Ross (subscriber, #4065) [Link]

You misunderstand the standard: "must be zero" means that they must be
set to zero for software adhering to this version of the standard. They
absolutely must be ignored by software adhering to that version of the
standard. If they are dropped when not zero then the implementation is
broken because it is not upwards-compatible with other implementations.
TCP/IP is specifically designed to be upwards compatible. If you don't
understand options you are supposed to ignore them, otherwise there is
no point in having an extendable protocol.

But in any case, even for those who can't read RFCs properly, there was a
draft RFC at the time and it's now official. So there are absolutely,
positively no excuses anymore but there are still lots of broken vendors
and even more unpatched routers and firewalls (one only wonders what
security problems these systems must have).

TCP window scaling and broken routers

Posted Jul 21, 2004 18:31 UTC (Wed) by schabi (subscriber, #14079) [Link]

"this case the nasty firewalls zero out the bits in the unknown option and people are complaining"

It's different. With ECN, the router had two different, valid options: Leave the bits in the flag word as they are, or clear them and thus deleting the option. ECN was designed carefully enough that both ways worked. Blocking or dropping the packed is no option.

The Window scaling is not bits in the flag word, but an separately added option field. There, the firewall has two valid options: let the packet pass as it is, or remove the window scaling option field entirely. Communication continues to work with both options. Fiddling around inside the header field and wildly mangling the values is no option.

TCP window scaling and broken routers

Posted Dec 1, 2005 23:06 UTC (Thu) by walken (subscriber, #7089) [Link]

That sounds like a good idea, but - is there any way to get iptables to do what you describe ? From my own little netfilter experience, I know how to pass, drop or reject packets, but not how to filter bits (well, I think there is an option to do that with ECN, but what about OTHER must-be-zero bits) or how to drop arbitrary unknown tcp options.

Sounds a bit hypocritical for linux developers to complain about firewalls in the field if their own firewalling functionality does not allow this either.

But then again I'm not a netfilter expert so I could be mistaken.

TCP window scaling and broken routers

Posted Feb 7, 2008 21:12 UTC (Thu) by shemminger (subscriber, #5739) [Link]

The problem is firewall's that want to enforce window sizes but are too stupid and try to do
this without tracking the state of window scaling of the connection.

I will pick out OpenBSD as particularly broken in that regard, and they haven't fixed it.