Re: [tcpm] New I-D

John Heffner <jheffner@psc.edu> Fri, 06 July 2007 02:20 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dQx-0003bC-7L; Thu, 05 Jul 2007 22:20:35 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dQw-0003b6-NX for tcpm@ietf.org; Thu, 05 Jul 2007 22:20:34 -0400
Received: from mailer1.psc.edu ([128.182.58.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dQw-0005T6-Fd for tcpm@ietf.org; Thu, 05 Jul 2007 22:20:34 -0400
Received: from [192.168.0.103] (rdbck-3869.wasilla.mtaonline.net [12.104.83.59]) (authenticated bits=0) by mailer1.psc.edu (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: <468DA6C1.5060107@psc.edu>
Date: Thu, 05 Jul 2007 18:19:45 -0800
From: John Heffner <jheffner@psc.edu>
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
To: Mahesh Jethanandani <mahesh@cisco.com>
Subject: Re: [tcpm] New I-D
References: <20070221144454.3D3E01827FD@lawyers.icir.org> <45DCC9BB.4010302@psc.edu> <46856FC2.90309@cisco.com>
In-Reply-To: <46856FC2.90309@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: tcpm@ietf.org, weddy@grc.nasa.gov, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Mahesh Jethanandani wrote:
> Context is the draft - 
> http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt
> 
> 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.

Thanks,
   -John

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