Re: [tcpm] TCP zero window timeout?

[MURALI BASHYAM <[e-mail]>]

Fernando

Today there is nothing that prevents a client side
application from simply stopping to read the TCP
receive socket buffer and causing the offered window
to go down to 0, and thus causing the sender to hold a
large send queue worth of data and probe forever. If
this is done by a large number of clients against the
same server, u have a distributed DOS attack on that
server. We have seen this in practice. 

To answer an earlier question u had raised, the
application cannot timeout on this connection because
it does not know when the connection enters and leaves
the persist state, only TCP knows that. The
application can definitely decide the timeout value,
but TCP needs to implement the timer because only it
is aware of the state of the peer. 

More comments inline.

--- Fernando Gont <[e-mail]> wrote:

> At 20:05 26/08/2006, MURALI BASHYAM wrote:
> 
> >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?
> 
> I disagree. In the case of the RTO, you don't have
> any hints of the 
> TCP segments getting to the remote TCP endpoint.
> Hence, after some 
> number of retransmission, you don;t have much else
> to do than to 
> abort the connection.
> 

I agree with you on that, but what i want to borrow
from that timer is the aspect of limiting the amount
of time trying to retransmit, which is what i meant.

> In the case of zero window, as far as TCP is
> concerned, there's 
> nothing wrong with an endpoint advertising a zero
> window. And you do 
> know that packets are getting to the remote TCP
> endpoint (that's why 
> you are getting the advertisements, after all).
> 

And i  am not disagreeing with you on that, let's
differentiate the legitimate ones from the bad ones or
minimize the impact of the bad ones.

> 
> 
> >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.
> 
> This is the same thing as saying that there should
> be an "idle 
> connection timeout", because a connection can be
> opened, and no data 
> needs to be transmitted on the connection for the
> connection to be kept open.
> 

An idle connection does not consume any buffer
resources, whereeas here the connection is holding up
precious buffer resources.

> That said, some upper limit on the number of
> window-probes might not 
> hurt, but then you get into which value to use.
> If too small, you may kill legitimate users. If too
> long, it may be useless.
> 
 
I agree, but in the event of a DOS like scenario, this
provides the administrator with a tool to control the
impact of these bad clients on the system, and he can
come up with a value which certainly does not impact
legitimate probes. In these scenarios, any limit is
better than infinite :-).

Murali

> And I doubt there really is something in between.
> 
> Kindest regards,
> 
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
> A9EF D076 FFF1
> 
> 
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm