Re: [tcpm] Please read

Joe Touch <touch@ISI.EDU> Thu, 31 July 2008 18:44 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A702C3A6ADB; Thu, 31 Jul 2008 11:44:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A87F328C2AD for <>; Thu, 31 Jul 2008 11:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Y1Q8ffkqJZz for <>; Thu, 31 Jul 2008 11:44:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A6403A679F for <>; Thu, 31 Jul 2008 11:44:29 -0700 (PDT)
Received: from [] ([]) by (8.13.8/8.13.8) with ESMTP id m6VIgNF2011351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 11:42:26 -0700 (PDT)
Message-ID: <>
Date: Thu, 31 Jul 2008 11:41:46 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Mahesh Jethanandani <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] Please read
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hash: SHA1

FWIW, I agree with this.

In addition, "unless otherwise instructed to do so" should be extended
to address the resource limit issue: "unless otherwise instructed to do
so, e.g., in the case where the OS is running out of resources, or a
user timeout occurs"

Regarding that last point, I understood it to be related - i.e., that
current implementations won't allow a user timeout to kill a connection
in persist. Is that the case? If so, that's worth noting under
motivation for the document as well.


Mahesh Jethanandani wrote:
| 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, 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
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list