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

From: Ted Faber <[email-masked]>
Date: Tue, 1 Feb 2011 21:23:58 -0800

On Sun, Jan 30, 2011 at 11:27:06PM -0500, Wesley Eddy wrote:
> 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.

After I saw John's mail eariler today, I had a late look at this
document.  I don't support it for publication at this time, though
that may not mean anything after Last Call.

My concerns can be summed up in Section 5 and Section 7.   Here's
Section 5, Conclusions, in its entirety:

	The document addresses the fact that terminating TCP connections
	stuck in the persist condition does not violate RFC 1122 or RFC
	793.  It also suggests that TCP must not abort any connection
	until explicitly requested by the application or the operating
	system to do so.  The potential implementation guidelines of the
	request and the action are documented in Section 7, and the
	details of mitigating the DoS attack are left to the
	implementer.

That seems to say that the document says nothing at all, until the last
sentence.  The authors address the fact that an ESTABLISHED connection
with a zero window doesn't violate any standards and that such
connections shouldn't be spontaneously aborted by the TCP protocol
engine.  That's true, but not news.

Then there's that last muddy sentence; I can't quite follow what it's
getting, but it points me to a substantive section that follows the
Conclusions Section (!) describing an API:

	The above interface allows applications to inform TCP that when
	the local connection stays in persist condition it can be
	aborted after a set time.

That text describes an API that instructs the TCP engine to do exactly
what the conclusions (and the RFCs) tell me is non-conformant: abort a
valid connection.

It seems to me that the right way to describe the interface in Section 7
is to say that it lets the application tell the OS about the
application's preferences for releasing resources if they get scarce.
"The above interface allows applications to inform *the* *Operating*
*System*..." I think that makes the section compliant with the RFCs
cited in the Conclusions, but I think it stops being an IETF document at
that point.

This may be water under the bridge now, but John made me curious and I
figured I'd chime in.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

---

From: Fernando Gont <[email-masked]>
Date: Wed, 02 Feb 2011 02:41:48 -0300

Hi, Anantha,

On 31/01/2011 10:48 p.m., Anantha Ramaiah (ananth) wrote:

> Well, the best way to address this is to write a separate document which
> addresses these issues and proposes solutions to the same. This is
> definitely beyond of the current document which is a simple
> clarification. The API is part of the clarification.

FWIW, all these issues (including netkill, Naphta, etc.) are discussed
in draft-ietf-tcpm-tcp-security.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ted Faber <[email-masked]>
Date: Wed, 2 Feb 2011 09:22:38 -0800

> what the conclusions (and the RFCs) tell me is non-conformant: abort a

Some private mail to me indicated that I do need to split the hair
that's inherent in that description: namely that the new interface
proposed in this informational document is really just a way for an
application to abort a TCP connection.  I disagree.

But, you know what?  That's not my problem at all.  I apologize for
wasting the authors' and the WG's time picking nits when I have a more
fundamental objection and should have just said it.

My problem is that the document is not clear enough.

If the authors and the WG want to say that TCP connections can get stuck
in a zero-window state and that can chew up enough resources to DoS the
endpoint, that's great.  If they want to also say that the authors have
had success with an OS interface that allows the OS to preferentially
abort connections in that state, I'm all for it.  Content is not really
the source of my objections.

This text does not clearly lay that out at all.  If you read through the
intro there is no indication that there's a mitigation to be proposed,
and there's only that confusing sentence in the conclusions that points
to "potential implementation guidelines of the request and action" in a
section buried after the Acknowledgements.

I think that only people who were involved with this discussion will be
able to tell what we're talking about.  That "we" is intentional: this
is a WG document.

For the record: I think that the idea here is fine, assuming that I
correctly summarized it above.  This presentation is unclear enough that
I don't think we should publish it as written.

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 09:49:04 -0800

Hi, Ted (et al.),

My view is that this doc was supposed to say (and I thought said):

- connections can get stuck

- users and/or the OS (on behalf of users as a group) can *always* abort 
connections to protect resources

The latter appears to be the point of needing this doc. I.e., that a TCP 
connection is not "protected" as a resource once initiated; the OS can 
always reclaim it.

I never thought we needed an RFC to say that. IMO, the OS aborting the 
connection for these reasons is basically just using the existing RFC 
793 interface as a proxy for the user, and there's no ambiguity.

The rest of the issue is an implementation issue that (I agree with Ted) 
should not be in an RFC. But I've made that point before.

Joe

On 2/2/2011 9:22 AM, Ted Faber wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Wed, 2 Feb 2011 10:22:43 -0800

I will pick nits with you, just for fun. :-)  (Avert your eyes, draft
authors.)

On Wed, Feb 02, 2011 at 09:49:04AM -0800, Joe Touch wrote:
> I never thought we needed an RFC to say that.

Any protocol standard that claims the right to make resource decisions
on behalf of the OS is pretty well doomed, and I don't think 793 or 1122
make any such claims.

So, yeah, we agree that the RFCs are OK.

>                                               IMO, the OS aborting the 

And heeeeeeeeere's the nit:

The OS doesn't need to do any such thing.  A purist (and I think I'm
talking to one :-)) would argue that there is no OS/TCP interface
specified by the IETF, nor should there be.  The OS simply reclaims the
resources allocated to the TCP connection using whatever internal
interface it has.  That may look like an abort or it may be less
sophisticated.  For example, the OS may use the internal interface of
killing the process holding the most open TCP connections.

As long as the reclaimed connection(s) go(es) into the CLOSED state, the
TCP protocol engine will DTRT, and no one cares how they got there.  A
Good Thing, IMHO.

> should not be in an RFC. But I've made that point before.

While there's no need to standardize the interface they propose, I don't
see a problem with saying that this is an interface that the authors
have used and liked.

Couldn't hurt, might help.  But it needs to be clear, or it only stirs
up nit-pickers.

Uh, stirring up nit-pickers could hurt, so I guess I'm wrong... :-)

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 10:45:41 -0800

Hi, Ted,

Overall, I think we agree. two points, however:

> So, yeah, we agree that the RFCs are OK.

We do, but I think consensus in the WG is that not everyone does, which 
is why the WG has decided it's useful here to say "the OS always had the 
right to do this".

(I personally don't think it's necessary, but understand the WG see it 
this way)

...
> Couldn't hurt, might help.  But it needs to be clear, or it only stirs

Agreed.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 2 Feb 2011 11:13:14 -0800

Ted,
   Some responses inline :- 

And a question at the end, which is probably the one that matters for
moving forward.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Ted Faber
> Sent: Wednesday, February 02, 2011 9:23 AM
> To: Wesley Eddy
> Cc: [email-masked]
> Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-persist
> 
> application to abort a TCP connection. 

That's actually the point. More so, we also state that it is left to the
implementers to design a better API if they wish to do so.

> I disagree.
> If the authors and the WG want to say that TCP connections can get
> stuck in a zero-window state and that can chew up enough resources to
> DoS the endpoint, that's great.  If they want to also say that the
> authors have had success with an OS interface that allows the OS to
> preferentially abort connections in that state, I'm all for it.
> Content is not really the source of my objections.

Ok.

> 
> This text does not clearly lay that out at all.  If you read through
> the intro there is no indication that there's a mitigation to be
> proposed, and there's only that confusing sentence in the conclusions
> that points to "potential implementation guidelines of the request and
> action" in a section buried after the Acknowledgements.
> 

I'll have to dig up the emails, but the current content (which includes
pushing things to the appendix)) is all in response to the feedback
received from the WG.

> correctly summarized it above.  This presentation is unclear enough
> that I don't think we should publish it as written.

Any suggestions for a better looking layout? 

Thanks,
-Anantha

<snip>

---

From: Ted Faber <[email-masked]>
Date: Wed, 2 Feb 2011 11:31:16 -0800

> pushing things to the appendix)) is all in response to the feedback

If the authors intend Section 7 to be an appendix, I suggest calling it
Appendix 1, for starters.

> Any suggestions for a better looking layout? 

I think I was unclear again.  I'm not looking for a better looking
layout.  The text of the draft needs to be clearer.

When I said content wasn't my problem, I meant that the ideas that the
WG has converged on (as I understand and summarized them in my message
you quoted above) are fine with me.

The words in the document are unclear to the point that people who have
not been part of the WG will not, IMHO, understand what we are talking
about at all.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 02 Feb 2011 18:03:10 -0800

Ted,

If I am reading you right, these are the changes you are suggesting.

    * Clarify in the introduction that connections that get stuck in
      zero-window state can chew up enough resources to put the end
      point in a DoS condition.
    * Add a statement in the introduction section that talks about the
      implementation guideline later in the document.
    * Change the last sentence in Section 5 to say that Section 7 talks
      about the implementation guideline.
    * Change Section 7 to say Appendix 1.

Anything else?

If you can suggest particular text to any of the items let me know.

Thanks.

On 2/2/11 11:31 AM, Ted Faber wrote:
> http://www.isi.edu/~faber <http://www.isi.edu/%7Efaber>           PGP: 
> http://www.isi.edu/~faber/pubkeys.asc 
> <http://www.isi.edu/%7Efaber/pubkeys.asc>
> <http://www.isi.edu/%7Efaber/FAQ.html#SIG>
>

-- mj