On Mon, Aug 18, 2014, at 02:50 PM, Jacob Appelbaum wrote:
> On 8/15/14, Scheffenegger, Richard <[email protected]> wrote:
> > I just learned about an individual submission, which is probably of
> > interest not only to the members of these two WGs;
> >
> > http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00
>
> > There seem to be at least two or three major issues that compromise
> > either the working and stability of TCP, or work against the
> > intended "stealthieness" of this modification (making it easy for an
> > attacker to identify such sessions, provided he is able to actively
> > interfere with segments in transit (ie. cause certain segments to be
> > dropped).
>
> Could you expand on these thoughts a bit?
>
> > Nevertheless, it might be beneficial to discuss the generic idea in
> > a wider forum, among brighter minds than me.

Let's look at Richard's concerns:

> compromise either the working and stability of TCP

This RFC only modifies the calculation of the SQN number in order to get
port-knockable services. Every other host between just continues to see
the SQN as a random number as it did before. Unless between hops were to
modify the packet's timestamps, this will be completely backwards
compatible.

> work against the intended "stealthieness" of this modification (making
> it easy for an attacker to identify such sessions, provided he is able
> to actively interfere with segments in transit

This is not about hiding from big brother who is listening on the wire.
This is about minimising your visible footprint to the wider internet.
It's on par to your server's firewall dropping all incoming connections
unless you have the shared secret. But with this RFC, you don't need to
know the source IP address before hand.

I think it's a great idea. Nice work.

Alfie

-- 
  Alfie John
  [email protected]

_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to