Subject: Re: [tcpm] TCP persist state issue.

From: "John Heffner" <[email-masked]>
Date: Tue, 1 Jul 2008 22:09:02 -0700

On Mon, Jun 30, 2008 at 10:44 PM, Anantha Ramaiah (ananth)
<[email-masked]> wrote:
>> You can find the copy of the first draft at :
>> http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt.
>> Comments welcome.

As with the previous draft, I think the greatest weakness of this one
is that it focuses so much on the persist state.  The conclusion
states, "The document addresses the fact that terminating TCP
connections stuck in the persist condition does not violate any RFC."
But isn't this statement also true without the condition that
connections are "stuck" in persist?  That is, terminating a connection
at any time is allowed, regardless of its state (see RFC 793, section
3.8, the ABORT command).

And again, I think the persist state has fairly little to do with the
more general DoS issue.  Consider the following: a client that,
instead of shrinking its window to zero, simply stops ACKing after
sending the request, or a client that slowly acks one byte at a time.
Both have the same effect on the server, are fairly straightforward,
and neither advertise a zero window.

  -John
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 2 Jul 2008 07:54:07 -0700

Hi John,
   Thanks for your comments, Pl see inline. 

> -----Original Message-----
> From: John Heffner [mailto:[email-masked]] 
> Sent: Tuesday, July 01, 2008 10:09 PM
> To: Anantha Ramaiah (ananth)
> Cc: TCP Maintenance and Minor Extensions WG
> Subject: Re: [tcpm] TCP persist state issue.
> 
> As with the previous draft, I think the greatest weakness of 
> this one is that it focuses so much on the persist state.  
> The conclusion states, "The document addresses the fact that 
> terminating TCP connections stuck in the persist condition 
> does not violate any RFC."
> connections are "stuck" in persist?  That is, terminating a 
> connection at any time is allowed, regardless of its state 
> (see RFC 793, section 3.8, the ABORT command).

Correct. The whole point of writing this draft is that there is
confusion w.r.t RFC 1122 verbiage which needed clarification. Atleast
there was some consensus to that. 
It focuses on persist state because that is where the clarification is
needed. Atleast that is the reading which was gathered after 60+ email
exchanges last time.

> 
> And again, I think the persist state has fairly little to do 
> with the more general DoS issue.  Consider the following: a 
> client that, instead of shrinking its window to zero, simply 
> stops ACKing after sending the request, or a client that 

This will cause retransmissions from the server and eventually the
connection would timeout.

> slowly acks one byte at a time.
> Both have the same effect on the server, are fairly 
> straightforward, and neither advertise a zero window.

Slowly acking "one( or n << MSS) byte at a time" OR "ACK division
attack"  has other side effects too.. Like purposefully increase cwnd is
covered by ABC draft. 

Again, the purpose of this document is not about various scenarios and
solutions , it is written as an informational draft to clarifiy RFC 1122
verbiage w.r.t persist state. 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jul 2008 08:21:15 -0700

Anantha Ramaiah (ananth) wrote:
...
> confusion w.r.t RFC 1122 verbiage which needed clarification. 
...
> verbiage w.r.t persist state.

As Informational, it would not have that effect on a Standard. If this 
is intended to redefine behavior, it needs to be standards track.

I don't think highlighting a response in this case is needed at all, 
since, as John pointed out, the behavior is already permitted by 793.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 2 Jul 2008 08:35:34 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Wednesday, July 02, 2008 8:21 AM
> > solutions , it is written as an informational draft to clarifiy RFC 
> > 1122 verbiage w.r.t persist state.
> 
> As Informational, it would not have that effect on a 
> Standard. If this is intended to redefine behavior, it needs 
> to be standards track.
> 
> I don't think highlighting a response in this case is needed 
> at all, since, as John pointed out, the behavior is already 
> permitted by 793.

Combining the above two statements, it appears that : "there is nothing
to change in the standard since RFC 793 permits it". RFC 1122 is
supposed to act as clarification for RFC 793 in many cases, which says "
A TCP MAY
   keep it's offered receive window closed indefinitely.  As long as the
   receiving TCP continues to send acknowledgments in response to the
   probe segments, the sending TCP MUST allow the connection to stay
   open.  The RFC goes on to say that it is important to remember that
   ACK (acknowledgement) segments that contain no data are not reliably
   transmitted by TCP.  Therefore zero window probing SHOULD be
   supported to prevent a connection from hanging forever if ACK
   segments that re-opens the window is lost.......

So, the thinking was to have a clarification draft which combines the
sentiments of RFC 793 and RFC 1122 and also the current issue's
relationship to DoS.

Well, I am not arguing agaianst your viewpoint, but trying to justify
why this draft was written in the first place. I can post a summary of
email exchanges and "conclusions" arrived after those email exchanges,
if that helps.

Thanks,
-Anantha