[tcpm] New I-D

Mahesh Jethanandani <mahesh@cisco.com> Sun, 21 October 2007 07:01 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjUo2-0002DZ-8f; Sun, 21 Oct 2007 03:01:02 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IjUo0-00029p-RZ for tcpm-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 03:01:00 -0400
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjUgx-00082C-Gq for tcpm@ietf.org; Sun, 21 Oct 2007 02:53:43 -0400
Received: from sj-iport-6.cisco.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjUgn-0003DY-4y for tcpm@ietf.org; Sun, 21 Oct 2007 02:53:33 -0400
X-IronPort-AV: E=Sophos;i="4.21,305,1188802800"; d="scan'208";a="240325089"
Received: from sj-dkim-1.cisco.com ([]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2007 23:53:32 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com []) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9L6rWlp010078; Sat, 20 Oct 2007 23:53:32 -0700
Received: from [] (sjc-vpnasa-610.cisco.com []) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9L6rUsZ003899; Sun, 21 Oct 2007 06:53:31 GMT
Message-ID: <471AF76A.3040306@cisco.com>
Date: Sat, 20 Oct 2007 23:53:30 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: tcpm@ietf.org
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=1567; t=1192949612; x=1193813612; 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:=20New=20=20I-D |Sender:=20; bh=qPfhHly4ca0E2xE8YHVTE2qhfr95q740nbvsKzsQGbU=; b=uIef4H470rEg9mWDfIDe6EJEduqlWC8iIMJqkjPr1LH4YO+BbV6r2mJOcH3sSIAYDgO1EL0d O1RiQNx9TQHH+ORmm9Gd1cKW/0LuXm/35O1ZQ3KoXvjY/EtZbUpYtX1uVYE74TxU01aFc0yxHt aL9RwLavppGlEzLwRsTfqZS74=;
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: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [tcpm] New I-D
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

A new version of an I-D has been posted on the IETF web site.

"TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 27-Oct-07, <draft-mahesh-persist-timeout-02.txt> 


   This document describes how a connection can remain infinitely in
   persist condition, and its Denial of Service (DoS) implication on the
   system, if there is no mechanism to recover from this anomaly.

    In this version of the draft, we have documented our experiment 
using a simple user level program to create the DoS scenario. The tests 
were run against both Apache and IIS HTTP servers. The test was run on a 
larger scale in the lab environment, where we were able to document the 
behavior of the servers. The test was then run against public and well 
known sites but on a smaller scale. Sniffer traces were captured to see 
the behavior of the connections.

Our observations were that of the three well known public sites 
exhibited the DoS scenario. While site A had some mitigation technique 
in place, it was fairly easy to beat that. Site B and C had no 
mitigation in place and are currently vulnerable to the DoS attack.

The draft documents some suggested solutions and describes why they are 
better than any of the techniques out there. In particular it talks 
about UTO and why UTO cannot solve this problem. It also talks about the 
role of applications and how they can help.

Comments are welcome.


tcpm mailing list