North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: TCP receive window set to 0; DoS or not?
- From: Richard A Steenbergen
- Date: Fri Sep 08 02:50:19 2006
On Thu, Sep 07, 2006 at 11:28:47PM -0700, Jim Shankland wrote:
> Richard A Steenbergen <email@example.com> 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
Ok, looking at the error condition in further detail I do believe that
you're righ. So, per RFC1122:
126.96.36.199 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 188.8.131.52) 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
> 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"
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.
Richard A Steenbergen <firstname.lastname@example.org> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)