Re: [tcpm] New I-D

John Heffner <> Fri, 06 July 2007 02:20 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1I6dQx-0003bC-7L; Thu, 05 Jul 2007 22:20:35 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1I6dQw-0003b6-NX for; Thu, 05 Jul 2007 22:20:34 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1I6dQw-0005T6-Fd for; Thu, 05 Jul 2007 22:20:34 -0400
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.3) with ESMTP id l662JnLD021576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2007 22:19:53 -0400 (EDT)
Message-ID: <>
Date: Thu, 05 Jul 2007 18:19:45 -0800
From: John Heffner <>
User-Agent: Thunderbird (Macintosh/20070509)
MIME-Version: 1.0
To: Mahesh Jethanandani <>
Subject: Re: [tcpm] New I-D
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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: <>, <>

Mahesh Jethanandani wrote:
> Context is the draft - 
> John Heffner wrote:
>> As proof of concept, I wrote up a simple script (I think only about 30 
>> lines of python) that used the TCP ESTATS MIB to monitor connections, 
>> and kill off ones making no progress while consuming the most memory. 
>> This proved an effective defense against netkill, and I think would 
>> solve the problem described in the draft as well.  It would be easy 
>> enough to write a kernel thread to do the same if the system doesn't 
>> do ESTATS.
>>   -John
> John,
> The issue with Netkill or any other application trying to kill 
> connections is that they cannot distinguish between connections that are 
> held up because of network issues where packets are getting dropped and 
> connections that are in persist state because the client refuses to open 
> the zero window. TCP can distinguish between the connections and 
> determine which ones need to go. Wouldn't you agree?
> m/

That's going back a ways.  I think I've paged the original thread back 
in to memory. ;)

It may be important to distinguish between recovery and persist (the 
ESTATS MIB will do this).  I mention netkill because it is pretty 
effective at running the attacked system out of buffer memory without 
using the persist state.  I think a more general defense is better 
located at the operating system level (either a daemon or in the 
kernel), since that is the point where resource contention is resolved 
and policy enforced.


tcpm mailing list