Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt

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

John,

Firstly I am alarmed at the timing of your emails. For the last call comments which you provided (albeit late), in consultations with the chairs we incorporated all the LC comments received including yours(IOHO) and the next version was out. I had sent a note to the list (you were cc'ed and so as TCPM, you should have received at least 1 or 2 copies of the same email). Here is the link (for the sake of reference) :-

http://www.ietf.org/mail-archive/web/tcpm/current/msg06319.html

I did not see any comments to the above post. Now you have an email saying your comments have not been incorporated when the last call process commenced again. You may want to relax your filter rules esp. when you have commented on something and authors have taking the pain to incorporate them and waiting for a reply. (if you need more time, that's fine..) Only sounds as a fair practice to me.

Anyways, lets come to the point :-

You had made the following comments during the last call :

========================================
<BEGIN QUOTE>

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.

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 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.

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.

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.

Thanks,
  -John

<END QUOTE>
=========================================

Response to some of the claims you make above :-

C1 : "close connections because it is persist state". "it also doesn't say a connection may be aborted because it is in persist state". 

Response :- where in the document it is mentioned like you said above? We will be glad to correct it.

C2 : "majority of the document describes a DoS attack by resource exhaustion". 

Response: Can you explain why you feel so? 

C3:
" The document does not address this very simple well-know attack:
<http://shlang.com/netkill/>"

Response : It is not the purpose of the document to address attacks since the WG consensus was for clarification of RFC 1122 text. 

C4:

"handling closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER option".

Response : SO_LINGER works only during connection close.  The API which is being illustrated in the document is not a proposal. It is the one which we used and we needed that API since it informs the resource manager about the connection that is not making any progress which in the current case is in persist state. Actually by mentioning the SO_LINGER etc., and explaining why it was inadequate simply implies that we are trying to propose a new API. This is not the case since we are simply adhering to the WG consensus of being "informational draft + clarification of persist condition".

Further..
<snip>

> For the record, none of my previous comments have not been addressed.
> At a minimum, I strongly suggest removing the last paragraph of
> Section 5:
> "In order to provide some level of robustness to DoS attacks, a TCP
>    implementation MAY provide a feedback regarding the persist
> condition
>    to the application if requested to do so or an application or other
>    resource manager can query the health of the TCP connection allowing
>    it to take the desired action.  All such techniques are in complete
>    compliance of TCP [RFC0793] and Requirements for Internet Hosts
>    [RFC1122]."
> and all of Appendix A.

Please note the "desired action" A desired action can mean nothing or it could be mean aborting a connection. It is up to the application or resource manager to decide what to do. There is no harm in the above sentence, in fact it only clarifies the current spirit of RFC 1122, IMO. Querying about a connection, taking action etc., are all normal, we are not suggesting anything implicit.  

Can you elaborate/send text?

Thanks,
-Anantha

> 
> Thanks,
>   -John
> 
> 
> On Mon, Mar 14, 2011 at 1:40 PM, Wesley Eddy <[e-mail]>
> wrote:
> > On 2/16/2011 1:31 PM, Anantha Ramaiah (ananth) wrote:
> >>
> >> Greetings,
> >>      This new version posted addresses the concerns raised during
> the
> >> last call. It also contains the idnits changes suggested by Fernando
> and
> >> Lars. Special thanks goes to Wes for going through the draft and
> >> providing some useful text which primarily aims at addressing the
> >> concerns raised during the LC. If folks in the to list can review
> the
> >> new version and check if this version addresses the issues raised by
> >> them, and provide feedback to the list, it would be great.
> >
> >
> > I haven't seen responses to this, but as the document shepherd, it
> looks to
> > me like the comments have been incorporated to good extent.  This
> note is
> > just to be explicit about the process being followed.  David is
> planning to
> > make a review of it this week, and our plan is that if he agrees with
> that
> > assessment, we'll forward the request for publication to the IESG.
> >
> >
> > --
> > 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