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

[Christian Grothoff <[e-mail]>]

On 08/20/2014 01:23 PM, Scheffenegger, Richard wrote:
> Jacob, Christian,
> 
> To add some constructive discussion points:
> 
> 
> As the editor of RFC7323 (soon to be released), which is the update
> to 1323, and the discussion I looked at over at
> http://thread.gmane.org/gmane.linux.network/294386 and of course
> here, I was wondering if you might have it backwards...
> 
> 
> I have not seen a convincing enough argument, that running a fixed
> ISN for a 4-tuple is really safe. (And yes, re-use of a 4-tuple
> should be rare, but it can happen).
> 
> 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?

> 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.

> So, I could not help myself from wondering, if you haven't got your
> fields backwards....
> 
> If you want undetectable knocking, which authenticates a particular
> user, why not transport that hash as TSval (or optionally, the
> unused/empty TSecr; however, that would be detectable to someone with
> a sniffer, as early Win95 is not really that common any more). That
> would leave TCP ISN alone  - and as a true core component, arguing
> for a modification there has to come with very good arguments. Also,
> it would serve to randomize the TSval - as ISN is supposed to be
> choosen randomly - thus help close another indirect exploit vector.

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).

> And as you already stated that connections across Meddleboxes (those
> that tweak around with ISN or TSval) are out of scope and may fail,
> you don't really reduce the population of sessions that could benefit
> from this.

Based on our experiments, it would reduce it only slightly (within the
margin of error of our experiments), so yes, that maybe acceptable.

> 
> Finally, as TSopt is optional, modifications there have a much lower
> bar for acceptance, compared to a modification like the ISN; a server
> implementing the scheme would still be free to silently discard TCP
> SYNs without TSOpt, or the wrong TSval / TSecr... (As you could
> instruct your firewall to block empty, non-related RSTs).
> 
> Finally, the combination of TSval/TSecr would yield 64 bits, btw. But
> only on the SYN...

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.

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.

Happy hacking!

Christian