Subject: Re: [tcpm] Is this a problem?

From: MURALI BASHYAM <[email-masked]>
Date: Mon, 19 Nov 2007 12:19:59 -0800 (PST)

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 <[email-masked]>
To: MURALI BASHYAM <[email-masked]>
Cc: John Heffner <[email-masked]>; Mahesh Jethanandani <[email-masked]>; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Mon, 19 Nov 2007 15:49:19 -0500

> 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.  

I don't follow this line of thinking.  Let's see ...

  + I don't know where we have added standard timers to TCP except where
    we have to (e.g., for time-wait or something).  We basically add
    timers when the only things we can count on is the passage of time.

  + It doesn't seem to me a problem that a connection does this persist
    business indefinitely because both ends are consenting.  It isn't
    like one end is silent or going away.

  + The application *is* in control.  The application can close a
    connection whenever it wants to close a connection.  Giving it a way
    to tell TCP when to kill a connection is a distinction without a
    difference. 

I don't think you answered my question in any way.  Why do we have to
standardize this?  It seems to me that if some server wants to implement
a policy that says "a connection can stay in zero window persist for 60
seconds" then great.  Fine.  I don't care.  Might work fine for the use
case of that server.  Might cause problems for its connections.  But, if
that is its policy then wonderful.  Who am I to say that is right or
wrong?  Change the policy and all that still applies.  Seems perfectly
consistent with lots of other things ....

  E.g., who am I to say which SYNs a TCP should accept?  If they are
  from "bad" IPs and I want to drop them on the floor who are you to
  tell me I am wrong?

  E.g., who am I to say how many retransmits you should conduct before
  determining the peer is somehow gone and you give up?

Why does this persist stuff need to be done in a standard fashion?

allman