North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: TCP receive window set to 0; DoS or not?
On Thu, 7 Sep 2006 19:24:02 -0400, Richard A Steenbergen <[email protected]> wrote: > 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. This can be caused by any number of things, from a > completely bogged down box, to an application which isn't read()ing off > its socket buffer (thus for all intents and purposes the kernel is out of > resources to buffer any more data for that socket). It doesn't kill the > TCP session, it just throttles it back. The sender then goes into problem > the zero window mode, waiting for this condition to go away. It is > described in RFC 1122 section 22.214.171.124: > > Probing of zero (offered) windows MUST be supported. > > A TCP MAY keep its offered receive window closed > indefinitely. As long as the receiving TCP continues to > send acknowledgments in response to the probe segments, the > sending TCP MUST allow the connection to stay open. > > etc etc etc > Advertising a zero window is perfectly proper, Probing one is mandatory, per RFC 793: The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. The sending TCP must regularly retransmit to the receiving TCP even when the window is zero. Two minutes is recommended for the retransmission interval when the window is zero. This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other. But closing an open window is a bad idea: The mechanisms provided allow a TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted that much data. This, so called "shrinking the window," is strongly discouraged. The robustness principle dictates that TCPs will not shrink the window themselves, but will be prepared for such behavior on the part of other TCPs. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb