Re: [tcpm] Is this a problem?

Mahesh Jethanandani <mahesh@cisco.com> Wed, 28 November 2007 19:06 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 1IxSF9-0005rc-81; Wed, 28 Nov 2007 14:06:43 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxSF7-0005pz-MT for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 14:06:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSF7-0005oj-Bf for tcpm@ietf.org; Wed, 28 Nov 2007 14:06:41 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSF6-0003CL-SF for tcpm@ietf.org; Wed, 28 Nov 2007 14:06:41 -0500
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2007 11:06:40 -0800
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lASJ6eg1027543; Wed, 28 Nov 2007 11:06:40 -0800
Received: from [10.21.104.24] (sjc-vpnasa1-24.cisco.com [10.21.104.24]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lASJ6dgK023726; Wed, 28 Nov 2007 19:06:40 GMT
Message-ID: <474DBC41.4090000@cisco.com>
Date: Wed, 28 Nov 2007 11:06:41 -0800
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: John Heffner <jheffner@psc.edu>
Subject: Re: [tcpm] Is this a problem?
References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com> <20071106203212.GG5881@elb.elitists.net> <47333FD9.8010508@cisco.com> <473B1851.2020502@psc.edu>
In-Reply-To: <473B1851.2020502@psc.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1992; t=1196276800; x=1197140800; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=GDQTmF6HOsJ/YmGhi1oT6OA3aSOhj1JVhdOOtNbmBiw=; b=CpPwMT6ISlFeSKHFMJ4YmZFW/Av43VyKhtNxCbD+bDqb6gOPX1dsqwjfFeha+LkIzmOcUXFW p5NftQ/1c8qa81RCpvlYuUGB7DeQshvsOjrkuLcEdVZMoM8nV8NSjChS;
Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: tcpm@ietf.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


John Heffner wrote:
> It's actually an easy and generally more effective attack to just drop 
> all the packets on the floor rather than continue ACKing with zero 
> window.  The connection will eventually time out, but it takes so 
> long, it's easy to initiate another one in this time to take its 
> place.  Once again, please look carefully at Stas's netkill: 
> <http://shlang.com/netkill/>.  It's a simple short perl script.  The 
> defense you are proposing does nothing for this attack.
That is true. The attack is very similar to the one we describe. It 
applies to a different state in TCP - FIN_WAIT_1. I would suggest that 
your attack is not just a "mbuf exhaustion" but also a TCP connection 
resource attack. It is possible to run either or both of them out. The 
defense we propose is specifically for connections in persist condition. 
We found it more tricky to simulate the situation you describe because 
it required the amount of data requested to fit in the receiver 
advertised window. In addition, it does have a timeout (albeit a long 
one) and requires more active clients to attack the server. However ...
>
> I don't think it's critical to determine whether a connection is 
> stalled while limited by cwnd or rwin.  This *may* be useful 
> information, but it's not the most important.  In my view, the more 
> important thing to know is (1) whether the connection is making 
> progress, and (2) how much memory (the contended resource) it is 
> using.   Using this information, you can implement a policy that 
> resets connections that are consuming resources with no benefit 
> (progress).  This solves the more general problem -- both the netkill 
> attack and a persist attack.
... our solution keeps track of connections that are in persist 
condition and keeps track of connections that are not making progress 
and consuming memory. The framework of the solution is amenable to 
include connections in FIN_WAIT_1 state.


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