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] [day] [month] [year] [list]

Date:	Sat, 14 Mar 2009 10:31:03 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC] tcp: allow timestamps even if SYN packet has tsval=0

Ilpo Järvinen a écrit :
> 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.
> 

If you believe this could cause unable-to-connect problem, we must revert the patch,
or implement your work-around :)

Thanks

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html