Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

From: MURALI BASHYAM <[email-masked]>
Date: Sun, 2 Dec 2007 13:31:13 -0800 (PST)

----- Original Message ----
> From: David Borman <[email-masked]>
> To: MURALI BASHYAM <[email-masked]>
> Cc: TCP Maintenance and Minor Extensions WG <[email-masked]>; Joe Touch <[email-masked]>; Mark Allman <[email-masked]>
> Sent: Thursday, November 29, 2007 9:09:29 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
> 
> 
> On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
> ...
> > The second aspect is the ability of the application to explicitly  
> > cause the TCP connection
> > to leave the ZWP state at the specified time independent of  
> > available resources. There are
> > applications where having this level of control over the TCP  
> > connection makes sense (web, game servers).
> > But aborting this connection with trigger from TCP or OS or  
> > application is a protocol violation, i don't buy the fact
> > that if the OS does it, it's not a violation, that's what i was  
> > referring to as pure wordplay.
> 
> Fine.  Call it wordplay.  There's nothing wrong with that, because
> you
> 
  
> *have* to get the words right.  You have to be crisp on the protocol  
> definition.  The implementation can blur the boundaries, but the  
> protocol definition can't.   The aborting of a connection (whether in  
> persist or any other state) when the other side is alive and  
> responding has to be done by the application.  TCP should not be
> doing
> 
  
> that without direct instructions from the application.  Whether that  
> is done directly by the application by using the existing abort or  
> user timeout interface, or whether a new interface is defined to
> allow
> 
  
> the application tells the OS to run a timer and abort the connection  
> when the timer goes off, it is still being done under the direction
> of
> 
  
> the application.
> 
> 
> > A protocol is a contract between the sender and receiver here, and  
> > the contract defines the wire
> > behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any other  
> RFCs that are applicable.  It is more than just the wire behavior.
> 
> 
> > I care about the wire behaviour of the
> > connection, and if i observe the behaviour of the connection in the  
> > ZWP state prior to this change, i see
> > ACKs and probes exchanged infinitely. With this change (no matter  
> > who does it, OS, app, TCP), i see
> > ACKs and probes being exchanged for some time, followed by a RST  
> > segment to abort the connection.
> >
> > Do you agree that if we do the latter without changing the wording  
> > of RFC1122, it's a protocol
> > violation?
> > My claim all along has been that it is.
> 
> There already exists two mechanisms for the application to abort a  
> connection, directly with the abort interface, or indirectly with the  
> user timeout on the send interface, and you will get the same wire  
> behavior, a connection in persist state gets aborted.
> 
> The only protocol problem here is to have TCP abort a connection in  
> ZWP state without the application having first explicitly asked for  
> that to happen.  And if you need a new interface to provide that  
> functionality, then that will be a change to the TCP protocol.
> 
> The OS freeing up resources when they run out by doing things like  
> aborting connections is not a protocol violation, because it isn't
> TCP
> 
  
> making that decision.  Take that to the extreme, and you'd be arguing  
> that the system crashing is a TCP protocol violation, and that's just  
> silly.
> 
> >
> >
> > If we agree that it's a violation, then it's a standards track  
> > nature of draft.
> 
> If it changes TCP, in this case adding a new User/TCP interface, then  
> it should be on the standards track.

I agree with your suggestions, a new User/TCP interface is needed to enable the ZWP timer specificially, 
and  have TCP inform the app to ensure  that we limit the duration of the connection in the ZWP state. 
It's upto the application to enable the timer and take the abort action when the timer expires. But TCP will have to take abort action in the scenario where the application has already closed the connection.

A separate document (informational) can be written to describe how the application can use the new interface, and also discuss the DoS implications of the ZWP state and provide recommendations on a solution and what it needs to accomplish. 

Ted, Mark : What do you think?

Murali

>             -David Borman

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Dec 2007 09:44:51 -0800

MURALI BASHYAM wrote:
...
> I agree with your suggestions, a new User/TCP interface is needed to
> enable the ZWP timer specificially, and  have TCP inform the app to
> ensure  that we limit the duration of the connection in the ZWP
> state. It's upto the application to enable the timer and take the
> abort action when the timer expires. But TCP will have to take abort
> action in the scenario where the application has already closed the
> connection.
> 
> A separate document (informational) can be written to describe how
> the application can use the new interface, and also discuss the DoS
> implications of the ZWP state and provide recommendations on a
> solution and what it needs to accomplish.

It might be more useful to write a single document. That doc should
focus on the first item above - convincing the WG to agree this is a
"violation" or requires a TCP-level solution. It would also explain why
considering this a DOS attack that needs to be prevented is useful.

Ultimately, *IF* we agree to change TCP, then that doc would be expanded
to include the TCP interface changes and application use example. It
should also include solutions that do not change the TCP interface,
since it would be unlikely this would be a required immediate change
even if it were to go forward.

Joe