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

["Scheffenegger, Richard" <[e-mail]>]

Hi Christian,

> > Also, you want to add some additional "randomness" by adding the TSval
> > into the hash, if available.
> 
> We do that, did you even read the draft?


I did, but my wording was unfortunate; Let me rephrase: The use of TSopt is optional in your draft. Why not make it mandatory?


> 
> > However, TSval is not random, it's in most implementations a pretty
> > accurate uptime indicator (that this in itself is a bad idea, is known
> > for a long time. That it would make sense to randomize the TSval in
> > the same way as the ISN is now much more prominently stated in
> > RFC7323).
> 
> We do agree that the TSval should be randomized.
> > 
> Right now, TSval is rarely chosen at random by implementations (see our
> measurement study in Julian's thesis).  So putting the authenticator into
> the TSval would have provided an easy distinguisher, which we wanted to
> avoid.  However, I would in principle support _also_ using the TSval, that
> way we could get 64 bits.  But, as said before, this is a trade-off with
> respect to how many middleboxes will work, as some fiddle with TSval but
> not the ISN (and vice versa).

Well, OpenBSD does proper randomization; also, when someone follows RFC7323, proper randomization of TSval should become the norm over time... And as you mentioned earlier, full protection against someone able to both sniff and selectively drop packets is not intended, if I read the draft correctly.

 
> Right, but the SYN is what matters most IMO.  We could use 32 bits of the
> ISN for the content integrity protector, and another 32 bits of the
> timestamp for the authenticator part, that would be fine.  But, as I said,
> the problem is that this means that handshakes doing so would stand out
> from current traffic.  So really this is a bit of a trade-off between
> passive detection of the knock in the current environment and getting a
> few more bits of security.

Nothing really prevents you from mandating a SYN+TSOPT as basis for TCP Stealth. When putting the authenticator into TSval (with ISN as additional bits of randomness), all those sessions don't look any different from an OpenBSD box connecting - except for some passive TCP option fingerprinting perhaps. But again, all you want to do is not react to SYNs from people that can not observe and meddle with functioning sessions between two third parties...


> Another issue maybe that some current OSes don't use TSval at all, so I
> figured just changing the ISN calculation might be the more conservative
> suggestion, but again, this is clearly a trade-off and if IETF decided to
> instead to ISN+TSval or even just TSval, I would still consider this a big
> progress.

I'd be in full support for your proposal, when ISN is kept unmodified, and the authenticator bits put into TSval or TSecr of a SYN. Again, putting bits in TSecr would make your traffic stand out, not that those implementations that were broken in that respect, have vanished.

Best regards,
   Richard