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

> -----Original Message-----
> From: John Heffner [mailto:johnwheffner@gmail.com]
> Sent: Monday, September 29, 2008 11:10 PM
> To: David Borman
> Cc: tcpm@ietf.org; 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
> <david.borman@windriver.com> 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).

Murali

>
>   -John
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm