RE: [tcpm] TCP zero window timeout?

Just to second what Murali said :

Having a timeout on the persist state in case of proxy devices is
advantagous because :

- prevents resource exhaustion from mis-behaving, malicious clients.

- Buggy applications/TCP stacks, which doesn't read data and may also
shrink the window to 0. 

Of course the robustness priniciple does say "be liberal in what you
accept and conservative in what you send" and this applies to window
shrinking ie never shrink the window, but if the peer has shrunk the
window to 0 suddenly and sits tight in that  state for a long time, then
is is a problem. Typically applications have control on this persist
timeout value, but in case of situations which Mahesh points a TCP level
timeout seems to make sense. The question becomes whether do you want a
TCP level protection for this scenario or not?

-Anantha
> -----Original Message-----
> From: MURALI BASHYAM [mailto:murali_bashyam@yahoo.com] 
> Sent: Saturday, August 26, 2006 4:06 PM
> To: Fernando Gont; Mahesh Jethanandani (mahesh); Mahdavi, Jamshid
> Cc: tcpm@ietf.org; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] TCP zero window timeout?
> 
> 
> Fernando
> 
> I collaborated with mahesh on this, so let me try making the 
> case for it a little better.
> 
> The problem was found on a TCP proxy, which does not have any 
> applicaton awareness. In fact application awareness is not a 
> goal in that environment. Hence the TCP level solution.
> 
> Having said that, i'd say this timeout is in the same spirit 
> as the upper bound on the retransmit mechanism of TCP. TCP 
> could indefinitely retransmit and have the application 
> timeout too, correct? The problem is that TCP has a persist 
> state which can potentially exist infinitely long  and which 
> lends itself to abuse by a malicious peer. Just based purely 
> on this consideration, don't you think TCP should have a 
> mechanism that reduces the impact of this problem by either 
> limiting the number of probes (a la retransmit
> timeout) or the duration. And the application can turn it on 
> per connection via a socket option and set a value which 
> makes sense for that application, so there is per application 
> per connection control anyway.
> 
> Murali
> 
> --- Fernando Gont <fernando@gont.com.ar> wrote:
> 
> > At 21:00 25/08/2006, Mahesh Jethanandani wrote:
> > 
> > >The situation I was referring to is a little
> > different and applies
> > >to persist timer. In our situation the client stops
> > reading data. 
> > >These clients are machines out in the Internet and
> > as such the
> > >server has no control over their behavior. So while
> > there is
> > >unacknowledged data, it is not that the client is
> > not acking any
> > >data. It is responding to the probe but that it
> > continuously
> > >advertises a window of zero.  There is currently to
> > my knowledge no
> > >timeout for this state for the server. This can
> > manifest itself as a
> > >DOS situation if there are several such connections
> > where the server
> > >is forced to hold data.
> > 
> > I'd argue that this should be handled by an application-level timer.
> > 
> > The problem with the scenario you point out is that there 
> will always 
> > be one more way to do the same thing.
> > 
> > If we're talking about connections wasting resources, there 
> are many 
> > protocols (POP3, SMTP) in which after the initial greeting by the 
> > server, the client is supposed to go ahead. In all those cases, the 
> > client could just sit there. And only an application-layer timeout 
> > would help you.
> > 
> > I'm not sure how many servers implement this type of
> > 
> > application-layer timer. But there are some (Apache) that I have 
> > checked, and do.
> > 
> > Nevertheless, I'm interested in the behaviour you described. Is it 
> > supposed to be malicious activity?
> > 
> > Kindest regards,
> > 
> > --
> > Fernando Gont
> > e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 
> > 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> > 
> > 
> > 
> > 
> > > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/tcpm
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
> 

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm