Re: [PATCH] TCP: Add support for TCP Stealth

[Daniel Borkmann <dborkman@redhat.com>]

On 01/01/2015 04:32 PM, Christian Grothoff wrote:
...
> That approach is highly vulnerable to timing attacks, and doesn't answer
> how TCP clients without special capabilities could set the ISN correctly
> either. Playing with raw sockets is the kind of geeky hack that is

Right, for client/server side you'd need to have the capabilities and
then drop them later, which would make that approach less convenient
for user space applications (despite not having to have a port knocking
uapi in the TCP core itself). For the server, you might get away with a
central daemon spawning sockets via IPC, but for the unprivileged
client to e.g., let it set it's own ISN via setsockopt(2) would be a
bad idea.

> unlikely to give us the combination of usability and security required
> to significantly reduce the ongoing large-scale compromise of network
> equipment by spy agencies.

Out of curiosity, when you say you want to significantly reduce the
large-scale compromise of services by hiding ports, how do you solve
i) the pre-shared key distribution issue you need for your approach
(are you mostly targeting administrators for accessing their companies
router/firewall management interfaces?), and ii) the broad adoption of
this setsockopt(2) in applications? I think for ii) it would be great
not having to change and recompile every possible client _and_ server
application if they don't have the change upstreamed in their project.
It feels like a property that goes beyond the scope of a specific,
individual application, put differently, what about an additional
central configuration interface? Other than that, is there a plan for
key rotations in other words, to have a grace period for a key
transition as peers might not have synced clocks?