Re: [tcpm] Is this a problem?

MURALI BASHYAM <> Mon, 19 November 2007 20:20 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IuD6D-0001os-IK; Mon, 19 Nov 2007 15:20:05 -0500
Received: from tcpm by with local (Exim 4.43) id 1IuD6B-0001oi-Hi for; Mon, 19 Nov 2007 15:20:03 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IuD6B-0001oZ-1v for; Mon, 19 Nov 2007 15:20:03 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1IuD68-0001qp-Jl for; Mon, 19 Nov 2007 15:20:03 -0500
Received: (qmail 86902 invoked by uid 60001); 19 Nov 2007 20:20:00 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=As2Lh0/ecgFM0zUSdH8C/pYlxk8PY830YQPx/6XV3KX0ZRepyKbnx1IP+R4w+odltGXIRhREQmC9XO8jbbjBddyiQyIctsJ+6GxyAx6VLuJqa0HnB8CII3mUWy7e7pSu3a+W8r+jEFBKLEh4CZxVjmZvQaXlgGSqyeEvJ5HpbIc=;
X-YMail-OSG: tTMZXokVM1l3gbaVu2a80EVeCBfpG9VjKTNtCypx6MAPq06fiweTKX5fKH9fjT3PvKIe_Lv.OuoCOW3K4CzkBPQVPk8K8ypcuH4zKXf1FSf1Xds-
Received: from [] by via HTTP; Mon, 19 Nov 2007 12:19:59 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157
Date: Mon, 19 Nov 2007 12:19:59 -0800
Subject: Re: [tcpm] Is this a problem?
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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. 


----- Original Message ----
From: Mark Allman <>
Cc: John Heffner <>; Mahesh Jethanandani <>;
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
behavior here.  Please explain.


Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

tcpm mailing list