Re: [tcpm] New I-D

John Heffner <jheffner@psc.edu> Wed, 21 February 2007 22:38 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK067-00027x-El; Wed, 21 Feb 2007 17:38:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK066-0001we-9q for tcpm@ietf.org; Wed, 21 Feb 2007 17:38:02 -0500
Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK061-0007oA-Up for tcpm@ietf.org; Wed, 21 Feb 2007 17:38:02 -0500
Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.13.8/8.13.3) with ESMTP id l1LMbnRl013562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Feb 2007 17:37:50 -0500 (EST)
Message-ID: <45DCC9BB.4010302@psc.edu>
Date: Wed, 21 Feb 2007 17:37:47 -0500
From: John Heffner <jheffner@psc.edu>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: tcpm@ietf.org
Subject: Re: [tcpm] New I-D
References: <20070221144454.3D3E01827FD@lawyers.icir.org>
In-Reply-To: <20070221144454.3D3E01827FD@lawyers.icir.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 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

I think I agree with Wes, David and Mark that this is more of an OS than 
a protocol issue (if I'm characterizing their comments correctly), and 
Fernando that the approach is not powerful enough to solve the broader 
problem when viewed as an attack.

To expand a bit, I had a hallway conversation a couple years ago with 
Stanislav Shalunov about his netkill [1] attack, and more generally 
about contention for send buffer memory.  (I think the problem you're 
addressing falls precisely into this broader category.)  What I took 
away from this (Stas may or may not agree) is that since the resource 
contention occurs at the operating system level (competing for scarce 
kernel memory), that is the right place to arbitrate the contention. 
Each host may want to apply a different policy based on what it 
considers important.

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


[1] http://shlang.com/netkill/

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