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

[Alfie John <[e-mail]>]

On Tue, Aug 19, 2014, at 12:07 AM, Scheffenegger, Richard wrote:
> my concern is with the use of a static ISN for each 4-tuple; this
> significantly increases the chance of a  collision between sessions
> (ie. when the sender terminates a sluggish earlier session, some
> segments of that last session will very likely be in-window for a
> session that was started a short time later).
>
> (I understand that an application could use some crude time-based
> salt, to address this concern. But that would mean application/socket
> level modifications; and additional failure modes - like Kerberos has
> with the 5 min time window).
>
> Of course, the ephemeral source ports (the remaining 3 fields of the 4
> tuple will again be static for a given service) will provide some
> protection, as each different source port will have a different ISN.

Yeah, unless the client is using a fixed source port for whatever
reason, the source port should uniquely identify connections. Maybe this
wouldn't be useful from a high-traffic NAT as source port reuse is a
possibility, but apart from that I'm still all for this.

> OTOH, detection of this knocking scheme will be rather easy by passive
> means - currently the probability to two identical ISNs between two
> different sessions for the same 4-tuple (IP + ports) will be around
> 2^-32; with this, it is 1; and the number of ephemeral ports is
> limited so observing a protected web server will be rather straight
> forwards.
>
> Which probably will flag such a service as a primary target for those
> adversaries this scheme is supposed to protect against.
>
> Or am I missing something?

I don't think you're understanding it's main use case. Just like
with vanilla port knocking, it would completely transparent to
someone listening on the wire. But this isn't what it would be used
for. It's purpose is to protect services from the common script
kiddie, but the NSA.

e.g. I wish to setup a web server on my home machine protected by a
     password. The only user is me, but I don't know where I will be
     connecting from so I can't firewall because I don't know my source
     IP address. If this RFC were in place, port 80 would only be
     available to me since I know the shared secret.

     Sure anyone listening on the wire can see that I've got a service
     listening on port 80, but my main concern are the script kiddies
     who try to find open services and then hammer my home server with
     common exploits. This RFC completely protects my web server from
     the script kiddies without me having to setup port knocking (off-
     topic, but port knocking can sometimes be a pain).

Alfie

-- 
  Alfie John
  [e-mail]