Re: TCP receive window set to 0; DoS or not?

["Steven M. Bellovin" <smb () cs columbia edu>]

On Thu, 7 Sep 2006 19:24:02 -0400, Richard A Steenbergen
<ras () e-gerbil net> 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 4.2.2.17:
>
>             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