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

[Christian Grothoff <[e-mail]>]

On 08/19/2014 07:20 PM, Scheffenegger, Richard wrote:
> Hi Hagen,
> 
>> Anyway, I am little bit ambivalent regarding this ID. It may help
>> in some situations and reduce the attack vector. Any effort to
>> improve the security should be reviewed! I mean if there are no
>> negative impacts: why not? ;-)
> 
> I'm reluctant to conclude that there are no negative impacts.
> 
> As an example, think of a lightweight http server running this on a
> server, an legimtate client (knowing the secret) running on a similar
> leightweight client without TSopt and only very few ephemeral ports.
> 
> For each http session, the very same ISN will be re-used for every
> identical source port.

No, that is nonsense, you are constructing a pretty narrow scenario.
First of all, with integrity protection, the client can include the
first N bytes of the HTTP header in what is hashed into the ISN, so
different URLs would created different ISNs.

Furthermore, even without integrity protection, the client should
use the TCP timestamp option, which will add another 32-bits of
entropy to the hash, making each new request have a very much random
ISN.

Finally, I question that it is realistic that a client will
1) create SO MANY connections to an administrative service
   (sign of BAD application-level protocol design) that
   the number of available ephemeral source ports is exceeded
   before connections can be properly timed out;
2) not be able to enable TSopt
3) not be able to use integrity protections

You need _all_ of these.   And note that using TCP Stealth is supposed
to be an option that applications can enable, not something every server
has to require for every TCP client. So if the above scenario really
is what happens, just don't use it.

> In that enviornment the chances for a delayed packet to corrupt a
> TCP
stream are non-negligible any more... ( the inverse of the number of
ephemeral source ports available).

Btw, isn't a proper TCP implementation supposed to not re-use ephemeral
ports for a sufficiently long time out to ensure this cannot happen,
regardless of ISN collision possibilities?  After all, the ISN almost
doesn't matter here, as the connection might have been used to transfer
4 GB and then _every_ ISN may cause this problem.  So I think you are
considering the case of a very, very broken TCP client implementation.

> Also, the client will have to do a fall-back SYN without TSopt, if an
> intermediate meddlebox modifies the TSopt in any way; and across
> normalizers (also not completely uncommon) the scheme breaks down.
> But then, those meddleboxes shouldn't really be messing around to
> begin with... :)

Exactly.

> 
> I guess what I'm saying is that if some randomness (high order bits)
> could be maintained even when the 4-tuples are identical, that would
> at least address this concern (such sessions would still be
> detectable, by checking if the low order bits are identical; unless
> there is some clever way to randomly distribute the hash-bits and
> random bits, perhaps also based on a (different?) hash of the
> 4-tuple...

Look, with TSval and optionally hashing in the content, you do have
already two good ways to increase entropy.  A third way would be if the
application-logic decides to change the secret after each successful
connection (one-time secrets), which for _some_ scenarios with only one
legitimate user of the TCP server is also realistic.

Happy hacking!

Christian