Hi Hagen, Actually, the initiator (sender) of a session could roll the dice multiple times (select different ISNs), until the hashed TSopt fulfills the PAWS requirement of being larger than the last TSopt sent in the previous session to that host/port/4-tuple...
Would require a bit more state within that host, but would be manageable (using the system uptime really always was a kludge IMHO ). To paraphrase: TSecr SHOULD be zero on SYN, (even though some implementations didn't adhere to this), and MUST NOT be interpreted when ACK is not set. In my opinion, the only reason to not use the TSopt/TSecr combination would be to have this steganographic property to mislead a more advanced adversary that can sniff traffic in between two third parties. Richard Scheffenegger > -----Original Message----- > From: Hagen Paul Pfeifer [mailto:[email protected]] > Sent: Mittwoch, 20. August 2014 14:03 > To: Scheffenegger, Richard > Cc: Christian Grothoff; Jacob Appelbaum; [email protected]; > [email protected]; tcpm ([email protected]); Joe Touch > Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG > > On 20 August 2014 13:23, Scheffenegger, Richard <[email protected]> wrote: > > > 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. > > Sounds better then messing with the ISN. One show stopper still > exists: the TSval is required to strong monotonicity increasing for PAWS > protection. To lower the barrier one more time: why not just use TSecr? > > This relax just nearly all headaches and 32 bits are still enough for this > mechanism?! > > Hagen _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
