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 12:29:09 -0800 (PST)

----- Original Message ----
> From: Joe Touch <[email-masked]>
> To: MURALI BASHYAM <[email-masked]>
> Cc: David Borman <[email-masked]>; Anantha Ramaiah <[email-masked]>; TCP Maintenance and Minor Extensions WG <[email-masked]>
> Sent: Sunday, December 2, 2007 12:15:37 PM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> 
> MURALI BASHYAM wrote:
> ...
> > Can you think of WHY this shouldn't be done in TCP, with the
> go-ahead
> 
 from the application via a socket
> > option and/or globally by the adminstrator? 
> 
> That would be an implementation decision, which is fine.
> 
> However, I don't agree that any of this needs to be explained further.
> RFCs are not substitute for undergraduate background in OS and socket
> programming techniques.
> 
> > I've asked this question quite a few times, and i've not received
> a
> 
 satisfactory answer from the list so far, i've heard responses 
> >   a) that it is too risky for TCP to do this,
> >   b) that it's a flawed application that's causing this, 
> >   c) that the OS has failed its responsibility to manage resources, 
> > 
> > None of these are convincing,
> 
> We understand that none of this is convincing you. I don't think you
> appreciate that it is you who have not convinced us yet that this
> is
> 
 NOT
> one of the above.
> 
> > when we all agree that it's a protocol vulnerability being
> exploited
> 
 by the attacker. 
> 
> We never agreed to that; in fact, many of us feel that this is a
> protocol feature that you have shown an artificial attack against which
> is not necessarily more of a vulnerability than many other attacks
> against other TCP features.

Explain to me specifically and clearly what the INDEFINITE wait in that ZWP state buys for the protocol or the application. Emphasis on the word INDEFINITE, i.e your arguments cannot relying on using a finite value to limit that duration. We know what its fallouts are. Where is the justification for making it INDEFINITE? The document doesn't give me enough justification for why it made that decision.

Murali

> 
> In short, you have not shown a problem that needs to be fixed in
> TCP
> 
 yet.
> Joe

      ____________________________________________________________________________________
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: David Borman <[email-masked]>
Date: Sun, 2 Dec 2007 15:40:46 -0600

...
> Explain to me specifically and clearly what the INDEFINITE wait in  
> that ZWP state buys for the protocol or the application. Emphasis on  
> the word INDEFINITE, i.e your arguments cannot relying on using a  
> finite value to limit that duration. We know what its fallouts are.  
> Where is the justification for making it INDEFINITE? The document  
> doesn't give me enough justification for why it made that decision.

It's called robustness; that's what it buys you.  As long as a TCP  
session is up and responding, TCP does not abort it.  And an  
indefinite wait doesn't mean it'll never end, it just means you don't  
know *when* it is going to end.
			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Sun, 02 Dec 2007 21:56:27 -0800

MURALI BASHYAM wrote:
...
> that ZWP state buys for the protocol or the application. Emphasis on the
> word INDEFINITE, i.e your arguments cannot relying on using a finite
> value to limit that duration. We know what its fallouts are. Where is
> the justification for making it INDEFINITE? The document doesn't give me
> enough justification for why it made that decision.

We've explained the reason for indefinite ZWP multiple times. To repeat
it here, TCP is allowed - explicitly - to permit the receiving
application to stall the transfer of data until its application is ready
to receive it. There is no limit on how long that can take; that has
been already described as a *feature* of TCP on this list.

You may disagree with this reason. However, the burden of proof of why
this is NOT appropriate is on you, since the above is how TCP is already
designed, and it is you who consider this an issue.

joe