Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG

[Christian Grothoff <[e-mail]>]

On 08/19/2014 08:59 PM, Hagen Paul Pfeifer wrote:
> On 19 August 2014 20:27, Christian Grothoff <[e-mail]> wrote:
> 
>> You clearly also deliberately missunderstand the difference between
>> design / specification / mechanism, and the reality of an implementation.
> 
> No, I don't. But you are right, we should talk about implementation issues.
> 
>> Prove is a strong word.  Now, I would not mind if the standard included
>> some strong wording on using a random TSval in combination with TCP
>> Stealth by default.  But, as was pointed out, due to some NATs messing
>> with TSvals, we decided to keep it optional, as opposed to mandatory.
>> But I think that is a point I would be open to discuss, as it is really
>> a trade-off.
> 
> TSvals *are* optional, you propose TCP stealth should depend on an
> "optional option"? 

What I said is that if possible, clients should use TCP stealth in
combination with this optional option. As it is an option, we did not
make it mandatory, but I think it is totally acceptable to recommend
using the option.

> I clearly see problems here because they can be
> filtered, disabled or simple the limited option space is exhausted by
> other options.

We do have a measurement study on this in Julian's master's thesis. Yes,
it does happen, but it is uncommon.

> What about PAWS? What about ISN duplicates and how are
> these handled (and differentiated)?

We discuss TCP SYN retransmissions in the draft.