[tcpm] Is this a problem?

Mahesh Jethanandani <mahesh@cisco.com> Mon, 29 October 2007 21:52 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcXO-0001Qn-Sl; Mon, 29 Oct 2007 17:52:46 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImcXN-0001Q0-Nt for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 17:52:45 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImcXN-0001Pc-CA for tcpm@ietf.org; Mon, 29 Oct 2007 17:52:45 -0400
Received: from sj-iport-2-in.cisco.com ([] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImcXM-00027m-QB for tcpm@ietf.org; Mon, 29 Oct 2007 17:52:45 -0400
X-IronPort-AV: E=Sophos;i="4.21,344,1188802800"; d="scan'208,217";a="411403808"
Received: from sj-dkim-1.cisco.com ([]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2007 14:47:38 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com []) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9TLlcXO005104 for <tcpm@ietf.org>; Mon, 29 Oct 2007 14:47:38 -0700
Received: from [] (sjc-vpnasa-718.cisco.com []) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9TLlbJr013042 for <tcpm@ietf.org>; Mon, 29 Oct 2007 21:47:37 GMT
Message-ID: <472654F9.5030308@cisco.com>
Date: Mon, 29 Oct 2007 14:47:37 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: tcpm@ietf.org
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3842; t=1193694458; x=1194558458; c=relaxed/simple; s=sjdkim1004; 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:=20Is=20this=20a=20problem? |Sender:=20; bh=KYEBnwurpKqF2tgLBHFfZmR2Y5/XQMRcdK9rfSoiCFo=; b=rVz3UMaEwXeqcc7whM0T7McfVnHLELMDMwIdz0j9WoKRV0BEMfsJpTezLuGL7wxGks3A0Esa 8qOX/xE9mPMFq5mxPab/OtF7FKpxzTclJ/XQt0ZMo3rgfkGA5lNIcWUKLS+FVPGZfuDYac/7D1 ZeskdiHhFn7ucnw1pPoM5OQ/0=;
Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Subject: [tcpm] Is this a problem?
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>
Content-Type: multipart/mixed; boundary="===============1911801472=="
Errors-To: tcpm-bounces@ietf.org


We have documented a case of HTTP servers that are prone to resource starvation with the use of a small user level program. The program does not require any special privileges or changes in the kernel. The user level program on the client opens a connection to a HTTP server, sends a GET request for a large file (larger than the advertised window of the client) but never reads the response.

Three well-known, public sites were tested for this vulnerability. The two most common HTTP servers, Apache and IIS were the target. While one site had put mitigation technique in place, the others had none. With the latter two we were able to hold connections in ESTABLISHED state for days. The former site had a mitigation in place with a fixed timeout of 11 min., which was easy to guess and work around.

We (the authors) believe that this is a huge problem. What do you folks feel?

Previous responses to this documentation has been that it is a application problem. It is clear from our experimentation that most HTTP servers (and FTP too) have not implemented any mitigation techniques. We believe that this problem exists across the whole range of TCP based applications prevalent on the internet, although our experiments were limited to the web application. Where applications have tried to put mitigation techniques in place, workaround has been easy. This is mainly because applications do not have the same amount of visibility as TCP does on the state of the connection.

If you are interested in reading the draft, you will find it here <http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-02.txt>.


tcpm mailing list