Jacob, Christian, To add some constructive discussion points:
As the editor of RFC7323 (soon to be released), which is the update to 1323, and the discussion I looked at over at http://thread.gmane.org/gmane.linux.network/294386 and of course here, I was wondering if you might have it backwards... I have not seen a convincing enough argument, that running a fixed ISN for a 4-tuple is really safe. (And yes, re-use of a 4-tuple should be rare, but it can happen). Also, you want to add some additional "randomness" by adding the TSval into the hash, if available. However, TSval is not random, it's in most implementations a pretty accurate uptime indicator (that this in itself is a bad idea, is known for a long time. That it would make sense to randomize the TSval in the same way as the ISN is now much more prominently stated in RFC7323). So, I could not help myself from wondering, if you haven't got your fields backwards.... If you want undetectable knocking, which authenticates a particular user, why not transport that hash as TSval (or optionally, the unused/empty TSecr; however, that would be detectable to someone with a sniffer, as early Win95 is not really that common any more). That would leave TCP ISN alone - and as a true core component, arguing for a modification there has to come with very good arguments. Also, it would serve to randomize the TSval - as ISN is supposed to be choosen randomly - thus help close another indirect exploit vector. And as you already stated that connections across Meddleboxes (those that tweak around with ISN or TSval) are out of scope and may fail, you don't really reduce the population of sessions that could benefit from this. Finally, as TSopt is optional, modifications there have a much lower bar for acceptance, compared to a modification like the ISN; a server implementing the scheme would still be free to silently discard TCP SYNs without TSOpt, or the wrong TSval / TSecr... (As you could instruct your firewall to block empty, non-related RSTs). Finally, the combination of TSval/TSecr would yield 64 bits, btw. But only on the SYN... Richard Scheffenegger > -----Original Message----- > From: Christian Grothoff [mailto:[email protected]] > Sent: Dienstag, 19. August 2014 21:04 > To: Hagen Paul Pfeifer > Cc: Jacob Appelbaum; [email protected]; Scheffenegger, Richard; > [email protected]; tcpm ([email protected]); Joe Touch > Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG > > On 08/19/2014 08:59 PM, Hagen Paul Pfeifer wrote: > > On 19 August 2014 20:27, Christian Grothoff <[email protected]> > wrote: > > > >> You clearly also deliberately missunderstand the difference between > >> design / specification / mechanism, and the reality of an > implementation. > > > > No, I don't. But you are right, we should talk about implementation > issues. > > > >> Prove is a strong word. Now, I would not mind if the standard included > >> some strong wording on using a random TSval in combination with TCP > >> Stealth by default. But, as was pointed out, due to some NATs messing > >> with TSvals, we decided to keep it optional, as opposed to mandatory. > >> But I think that is a point I would be open to discuss, as it is really > >> a trade-off. > > > > TSvals *are* optional, you propose TCP stealth should depend on an > > "optional option"? > > What I said is that if possible, clients should use TCP stealth in > combination with this optional option. As it is an option, we did not > make it mandatory, but I think it is totally acceptable to recommend > using the option. > > > I clearly see problems here because they can be > > filtered, disabled or simple the limited option space is exhausted by > > other options. > > We do have a measurement study on this in Julian's master's thesis. Yes, > it does happen, but it is uncommon. > > > What about PAWS? What about ISN duplicates and how are > > these handled (and differentiated)? > > We discuss TCP SYN retransmissions in the draft. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
