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

MURALI BASHYAM wrote:
...
>>> 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.

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

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

Attachment: signature.asc