Re: [tcpm] WGLC on draft-ietf-tcpm-persist

["Anantha Ramaiah (ananth)" <[e-mail]>]

John,
    We have been through this in the past and the authors have clarified the reasons for some of the questions being posed by you and others. Here is yet another attempt. Pl see inline responses :-

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> John Heffner
> Sent: Monday, January 31, 2011 3:05 PM
> To: Wesley Eddy
> Cc: [e-mail]
> Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist
> 
> First, apologies for missing the last call deadline.  But I'd like for
> the record to state that I don't believe the authors have addressed
> the substantive criticisms raised on the list.  I'm also not sure that
> consensus has been reached on this document, but that is for the
> working group chairs to decide.

Pl go read the emails threads on this list on this subject. The only issue, if I recall correctly was, the mention of a socket API in the document. Now, this is an informational document and the mention of the socket API is purely for illustrations only and thus doesn't mandate any new protocol changes. We have also noted very clearly that it is up to the implementation to chose whatever API it wants to. 

> 
> To summarize my position in a single phrase, closing a TCP connection
> because it is in the persist state is a mistake.  And this document

Nobody is advocating that. We are just clarifying that it is OK to close a connection at any time, persist state in no exception to this rule. These 2 are different things. What makes you carry an impression that we are asking implementations to close the connection stuck in persist state? We are simply clarifying the it is inline with RFC's spirits if the decision is made consciously. 

> describes a mechanism to do exactly that.  If the language in RFC1122
> needs to be clarified, the clarification should be that a connection
> may be aborted while in the persist state.  It should not be aborted
> *because* it is in the persist state.

Where did you get the impression? this has been your stance since day one, I suggest this as a way to move forward. The authors have tried their best put the verbiage to clarify the intent. Now, you seem to be not convinced, it would be nicer if you can :-

- read the document and state which sections are not conformant.
- suggest a modified text.

It is a very short document and hence I guess this shouldn't be a big deal.

> 
> To be more specific, the majority of the doc describes a DoS attack by
> resource exhaustion; however, the persist condition is only a small
> subset of this class of resource exhaustion attacks.  Addressing only
> connections in the persist state ignores the rest of the problem.  The
> document does not address this very simple well-know attack:
> <http://shlang.com/netkill/>.  This document also does not address
> connections where, for example, one byte of window is opened every 60
> seconds, and how they might be prioritized relative to connections in
> the persist state.  Using the mechanism described in the document
> leaves a system completely vulnerable to resource exhaustion by such a
> slow-acking attacker.  As a developer, why would I choose to implement
> this?  Unless these simple variations are addressed, I think it's a
> waste of time.

Well, we removed all the resource management stuff from the document since the WG wanted this document as a simple clarification document. I thought we added the case of one byte window being opened etc., and why addressing such a thing is beyond the scope of this document. I can check the document again...

> 
> Additionally, most implementations already provide an API for handling
> closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER
> option.  I don't think this document makes a sufficient justification
> for why this existing mechanism is inadequate, or why the proposed API
> is necessary or sufficient.

We explained this earlier. SO_LINGER applies only during connection close. Applications would like to know the reason for connection not making any progress which includes persist. Now, application is simply telling TCP layer that if the connection is in persist for more then a stipulated time, TCP can go ahead and kill the connection in the same manner like retransmit timeout. Now, I don't want the above statement to say that RTO and persist need to be treated the same way, we are just saying that "as long as application closes the connection or has indicated its willingness to close the connection" it can do so and it is in spirits of RFC 1122.  

I am at loss to understand your concers on this very simple document. It would be nicer if you can point to the exact sections where this document is vague or isn't clear.

Side note :- now this is typical, someone is going to snip portions of my response and get hung up one statement (may be a language weakness or something that is not intended etc., ) hence I am urging folks to read the response in its entirety while responding and not pick (nitpick) on some text.

-Anantha

> 
> Thanks,
>   -John
> 
> 
> On Sun, Jan 30, 2011 at 11:27 PM, Wesley Eddy <[e-mail]>
> wrote:
> > On 1/13/2011 10:38 PM, Wesley Eddy wrote:
> >>
> >> Based on the discussion of section 7 (programming considerations),
> the
> >> document on clarifying the persist condition has been updated by the
> >> authors.
> >>
> >> The document can be found at:
> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-persist/
> >>
> >> We think this is ready for working group last call now, so with this
> >> email, I'd like to start a two-week WGLC on the document to last
> until
> >> 1/28. Please send your comments to the TCPM list by then.
> >
> >
> > Since this last call has concluded, I'm planning to do the PROTO
> writeup and
> > send up the document to the IESG late this week.  Since this document
> is
> > fairly short, includes relatively simple technical material, and was
> > well-discussed earlier in its history, I wasn't concerned by the lack
> of
> > WGLC feedback, but will note it in the writeup.
> >
> > If there's any disagreement on this, or someone wants more time to
> review,
> > please shout in the next couple days, before I submit the document to
> the
> > IESG for publication.
> >
> > --
> > Wes Eddy
> > MTI Systems
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm