[tcpm] Please read
Mahesh Jethanandani <mahesh@cisco.com> Thu, 31 July 2008 17:50 UTC
Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86213A6D31; Thu, 31 Jul 2008 10:50:01 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018B23A6CE5 for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 10:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.617
X-Spam-Level:
X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdBRlI7A8qEp for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 10:49:58 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 432E13A6D32 for <tcpm@ietf.org>; Thu, 31 Jul 2008 10:49:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="91662152"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2008 17:49:58 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VHnw5U000851 for <tcpm@ietf.org>; Thu, 31 Jul 2008 10:49:58 -0700
Received: from [10.21.51.198] ([10.21.51.198]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6VHnvxJ008747 for <tcpm@ietf.org>; Thu, 31 Jul 2008 17:49:57 GMT
Message-ID: <4891FB44.50704@cisco.com>
Date: Thu, 31 Jul 2008 10:49:56 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: tcpm@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4758; t=1217526598; x=1218390598; 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:=20Please=20read |Sender:=20; bh=AuAIPOlPYeSqJxbYPG5OmwT9VzTko+2ywYKwCXS62yc=; b=KeyjXeYxF68dF5rxXf8PhBcwjwU4+7aoFdIA7iHW/YvnqeGp8MZnR6LSae r2ZCm4L9OinpKjzpOemOPC/WilzJr+bajQ6RstUJZYM4CJbzzXhmmhZLojQw uB/teVPNIefclxAGLz5c1TYgPP3hUE05AXUmlnqt32kldf3uQwd4c=;
Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Subject: [tcpm] Please read
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
During the TCPM meeting in Dublin, Wes wanted to encourage readers on this mailing list to read the short (2 pages if you remove the boiler plate part) draft on "Clarification of Sender Behavior Under Persist Condition" draft. To enable a quick read, I have cut and pasted the relevant sections here. As noted in the meeting, this draft tries to clarify the sender behavior without getting into the details of the DoS scenario and the possible solutions. Just to reiterate, it is this draft and not the original persist draft that we are trying to table for adoption as a WG item. 1. Introduction RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY keep it's offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. The RFC goes on to say that it is important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. The condition where the sender goes into the ZWP mode is typically known as the persist condition. The problem is applicable to TCP and TCP derived transport protocols like SCTP. A consequence of adhering to the above requirement mandated by RFC 1122 is that multiple TCP receivers (clients) advertising a zero window to a busy server indefinitely (by reliably acknowledging the ZWP), could exhaust the connection and buffer resources of the sender (server). In such cases, to achieve robustness, the system should be able to take appropriate action on those TCP connections and reclaim resources. The purpose of this document is to clarify that such actions are in the spirit of RFC 1122 and they don't violate RFC 1122. The remainder of the document briefly describes the DoS scenario, analyzes the current verbiage surrounding the ZWP in RFC 1122 and attempts to disambiguate the notion presented by RFC 1122. 2. Discussion Having the sender accumulate buffers and connection table entries when the receiver has deliberately and maliciously closed the window ultimately leads to resource exhaustion on the sender. This particular dependence on the receiver to open its zero window can be easily exploited by a malicious receiver TCP application to launch a DoS attack against the sender. In this scenario the sender's legitimate connections do not get established and already established well behaved TCP connections are unable to transmit any data. The sender enters the persist condition and is stuck waiting indefinitely for the receiver to open up its window. To illustrate this, consider the case where the client application opens a TCP connection with a HTTP [RFC2616] server, sends a GET request for a large page and stops reading the response. This would cause the client TCP to advertise a zero window to the server. For every large HTTP response, the server is left holding on to all the response data in it's send queue. If the client never clears the persist condition, the server will continue to hold that data indefinitely. Multiple such TCP connections stuck in the same scenario on the server would cause resource depletion resulting in a DoS situation on the server. In such scenarios it should be possible for the application or the system or a resource management entity to instruct TCP to terminate connections stalled in the persist condition. These actions are necessary to prevent resource exhaustion on the server. An extensive discussion took place recently about this issue on the TCPM WG mailing list [TCPM]. The general opinion seemed to be that terminating a TCP connection in persist condition does not violate RFC 1122. In particular the operating system, a resource manager, or an application can instruct TCP to abort a connection in the persist condition. TCP itself SHOULD not take any action and continue to keep the connection open as mandated by RFC 1122 unless otherwise instructed to do so. The exact mechanism by which the instruction to abort the connection is conveyed to TCP is an implementation decision and falls beyond the scope of the current memo. To determine which TCP connection to abort the entity can use the connection attributes obtained from some interface similar to STATUS call mentioned in RFC 793. -- mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Please read Mahesh Jethanandani
- Re: [tcpm] Please read Joe Touch
- Re: [tcpm] Please read Caitlin Bestler
- Re: [tcpm] Please read Stefanos Harhalakis
- Re: [tcpm] Please read Matt Mathis
- Re: [tcpm] Please read Murali Bashyam
- Re: [tcpm] Persist condition clarification draft,… Mahesh Jethanandani