netdev - Re: [RFC] tcp: allow timestamps even if SYN packet has tsval=0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 14 Mar 2009 10:22:12 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	dada1@...mosbay.com, Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: allow timestamps even if SYN packet has tsval=0

On Fri, 13 Mar 2009, David Miller wrote:

> From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET)
> 
> > On Wed, 11 Mar 2009, David Miller wrote:
> > 
> > > From: Eric Dumazet <dada1@...mosbay.com>
> > > Date: Wed, 11 Mar 2009 13:17:54 +0100
> > > 
> > > > So apparently WindowsXP sends a NULL tsval in SYN packet, then
> > > > subsequent packets get a real value (60498) in this case.
> > > > 
> > > > This seems to work on other OS as well, so is the following patch
> > > > considered evil ?  Do we have security concerns or only risking
> > > > windows client to have slightly wrong rtt estimation at the begining
> > > > of the tcp session ?
> > > 
> > > I think we'll have to accept this.
> > > 
> > > I don't see other systems blocking initial ts_ecn values of
> > > zero like we do.
> > 
> > What about the fact that PAWS could bite us leaving us a hung connection 
> > if timestamp changes too much when we get the first ACK? Though I doubt 
> > you can get windows to run long enough for this to become a problem if 
> > they always start from zero... ;-)
> 
> I really don't think it's a real issue, and Windows XP should be happy
> we're willing to try timestamps at all with it :-)

Right. Would it ever become a problem it would certainly possible to 
collect the first real timestamp and discard the bogus zero. We just need 
to be aware on this if some report about unable-to-connect appears once
the change gets larger exposure in wild.

There could be other broken things such as firewalls zeroing it in SYNs 
so the end host might not necessarily even be xp.

-- 
 i.