Richard A Steenbergen <ras@e-gerbil.net> writes:
> Advertising a window of 0 is a perfectly valid way of telling the other
> side that you are temporarily out of resoruces, and would like them to
> stop sending you data....
Except that that's not what's going on here. This message appears
when the TCP peer shrinks the window, withdrawing a previously granted
permission to send bytes -- a protocol violation. For example, you're
free to tell me (with your window advertisement) that you're
authorizing me to send you 32K bytes, and then, after I've sent you
32K bytes, to close the window until you're ready to accept more.
You're not free to tell me it's OK to send 32K bytes, then change your
mind and advertise a window size of 0 after I've sent you only 16K
bytes.
Ok, looking at the error condition in further detail I do believe that
you're righ. So, per RFC1122:
4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41
A TCP receiver SHOULD NOT shrink the window, i.e., move the
right window edge to the left. However, a sending TCP MUST
be robust against window shrinking, which may cause the
"useable window" (see Section 4.2.3.4) to become negative.
It is a warning message generated by a "SHOULD NOT" violation, during the
"MUST be robust against this behavior" section of code.
Looking at other such messages in the Linux kernel which are wrapped in
#ifdef TCP_DEBUG, they all appear to be equally esoteric and probably not
worth mentioning to the end user. However it looks like TCP_DEBUG is
enabled by default (don't ask me why), which when combined with a
relatively inane message using "alarm provoking" words, serves only to
confuse. 
To address the "DoS" question, I don't see how this protocol violation
enables a DoS attack. More likely, it's simply somebody's buggy
TCP stack misbehaving. That "somebody" is unlikely to be Windows, MacOS,
FreeBSD, or Linux. My money is on some flavor of $50 NAT/"home router"
box.
Did a little poking into this condition on other platforms as well, and as
previously mentioned it does appear to be fairly contained to "mobile
devices" (not sure which ones though). I guess if you have a small
portable device with limited memory, this may be an issue.