Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

Murali Bashyam <> Fri, 03 October 2008 00:13 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 404993A6ADD; Thu, 2 Oct 2008 17:13:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCCF53A68E0 for <>; Thu, 2 Oct 2008 17:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9zJg-uJdRYRH for <>; Thu, 2 Oct 2008 17:13:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D62F23A6AEF for <>; Thu, 2 Oct 2008 17:13:36 -0700 (PDT)
Received: from exchsvr01.ocarina.local ([]) by exchsvr01.ocarina.local ([]) with mapi; Thu, 2 Oct 2008 17:13:54 -0700
From: Murali Bashyam <>
To: John Heffner <>, David Borman <>
Date: Thu, 02 Oct 2008 17:13:50 -0700
Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
Thread-Index: Ackiw1TZsuAj/be9Tea1xNDmnzYShwCKV4SA
Message-ID: <EC7B72027914A242B991C029F5F213CF2AB0CCA6AA@exchsvr01.ocarina.local>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "" <>, "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: John Heffner []
> Sent: Monday, September 29, 2008 11:10 PM
> To: David Borman
> Cc:; Anantha Ramaiah (ananth); Murali Bashyam
> Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
> On Fri, Sep 26, 2008 at 12:37 PM, David Borman
> <> wrote:
> > At Dublin a presentation was made on draft-ananth-tcpm-persist-
> 00.txt.  Not
> > a lot of people had read the document at the time of the
> presentation, but
> > there didn't seem to be any objections to adopting it as a TCPM WG
> document.
> >
> > The authors posted a summary to the mailing list, have responded to
> all
> > issues that were raised, and have a new version of the document ready
> for
> > publication.  We (Wes and I) feel that there is support for adopting
> this as
> > a WG document, but as always, we need to verify this on the mailing
> list.
> >  So, if you have any objections to adopting this as a WG document,
> please
> > speak up now.  Also speak up if you support adopting it as a WG
> document.
> >
> > I'll be the first to say I support adopting this as a WG document.
> If there
> > are no serious objections, the authors can submit their updated
> version next
> > week and Wes and I will add it to our list of WG documents.
> I have reservations about moving forward with this draft as a wg
> document.  While the information is technically correct, it is overly
> specific to the point of possibly being misleading rather than
> clarifying.  An operating system may terminate a tcp connection at any
> time, not just when the connection is in the persist state.  Further,
> I would actually argue that terminating a connection *because* it's in
> the persist state is a bad idea and should be discouraged.  (The
> reason for termination should be for its use of resources, not TCP's
> state.)

No implementation today (the well-known ones BSD, Windows and Linux) terminates the TCP connection in that persist state as long as ACKs are being reliably received from the peer. Those three implementations are not doing what you are saying they should be doing, and if it's crystal clear from the standard that they should be doing so, why aren't they? They are all following the letter of the standard (1122) which dictates that they MUST do so. Linux even has a comment in the code that says RFC 1122 prevents it from doing so.

The *informational* document's goals are the following:
 - Clarify 1122's position on this sender behaviour.
 - Bring to light a consequence of persisting indefinitely, leading to a DoS vulnerability triggered easily by a user-space receiving application. The mitigation techniques for this are not going to be described in this doc, as discussed in the mailing list before. It's possible that some of the OS's existing techniques for mitigating resource exhaustion can already address this scenario, but that's out of scope of this document.
 - Expose the indefinite persisting behavior to allow the application to control that behavior and terminate the connection (possibly even when resources are available).


>   -John
tcpm mailing list