Re: [tcpm] Is this a problem?

The problem directly stems from TCP's choice to persist indefinitely. It seems a very simple
notion of allowing the application to be the master here (borrowing Joe's words :-)), and providing
a ceiling on how long this behaviour will continue. This is fully in spirit with how the other TCP timers
have evolved and added over the years. Now this alone does not address the requirements of a co-ordinated
distributed DOS attack, but the point here is how long the connection should be allowed to (re)try sending data is purely
an *application* decision i.e it MUST be under application control. It's a bad design to have an indefinite retry like this 
in the transport layer without providing an override to the app.  This feature alone has value even in legitimate
applications such as gaming where this override is desirable (non DOS scenario here).

Do we believe this timeout is useful or not? If so, then this is no different than any other TCP timer, and standardizing
it is a relevant discussion.

To consider and extend this timeout for DoS scenarios, one must get into aspects of why 
    1. that timeout must be adaptive.
    2.  the scheme must be fair i.e  an algorithm that penalizes persist state connections before penalizing connections that are 
         experiencing transient or permanent network congestion is clearly superior to one that just does it purely based on 
         the connection backlog. 

Murali

----- Original Message ----
From: Mark Allman <mallman@icir.org>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Cc: John Heffner <jheffner@psc.edu>; Mahesh Jethanandani <mahesh@cisco.com>; tcpm@ietf.org
Sent: Monday, November 19, 2007 5:35:38 AM
Subject: Re: [tcpm] Is this a problem? 

> Clearly there seems to be no consensus on where the problem lies.

That is my read of this thread.

> It seems to me that all of these approaches have a key flaw in that
> they leave the solution to be handled by a proprietary method of
> defending against the attack. Solving the problem in the transport
> layer would make the solution a standard one 

I think a key question here is whether we need a standard solution.  If
this were solved in a 'proprietary' manner, why would that be a big
deal?  I don't understand this notion that we need some sort of
 standard
behavior here.  Please explain.

allman

      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

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