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

["Scheffenegger, Richard" <[e-mail]>]

Hi Alfie,

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.


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?



Richard Scheffenegger


> -----Original Message-----
> From: Alfie John [mailto:[e-mail]]
> Sent: Montag, 18. August 2014 23:35
> To: Jacob Appelbaum; Scheffenegger, Richard
> Cc: Wesley Eddy; Christian Grothoff; [e-mail]; tcpm
> ([e-mail]); Joe Touch
> Subject: Re: [tcpinc] TCP Stealth - possible interest to the WG
> 
> On Mon, Aug 18, 2014, at 02:50 PM, Jacob Appelbaum wrote:
> > On 8/15/14, Scheffenegger, Richard <[e-mail]> 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
>   [e-mail]