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:[email protected]] > Sent: Montag, 18. August 2014 23:35 > To: Jacob Appelbaum; Scheffenegger, Richard > Cc: Wesley Eddy; Christian Grothoff; [email protected]; tcpm > ([email protected]); 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 <[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
