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

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

[Eric Dumazet]

Windows XP platforms, with RFC1323 enabled, send a SYN packet with NULL tsval.

12:56:56.989615 IP 192.168.4.20.3554 > 192.168.20.110.ssh: S 2907491202:2907491202(0) win 64512 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>

linux tcp stack correctly implements RFC1323 and ignores this timestamp option, sending
a SYN+ACK answer without timestamp option.

I was wondering what could happen if I patch linux to accept this RFC violation, in
hope to get timestamps on TCP flows to customers (slow and congestioned links, but long living tcp sessions)

I got :

12:58:01.266978 IP 192.168.4.20.3579 > 192.168.20.110.ssh: S 1532083461:1532083461(0) win 64512 <mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
12:58:01.267015 IP 192.168.20.110.ssh > 192.168.4.20.3579: S 3467339386:3467339386(0) ack 1532083462 win 5792 <mss 1460,nop,nop,timestamp 4294950269 0,nop,wscale 6>
12:58:01.268968 IP 192.168.4.20.3579 > 192.168.20.110.ssh: . ack 1 win 64512 <nop,nop,timestamp 60498 4294950269>
12:58:01.276664 IP 192.168.20.110.ssh > 192.168.4.20.3579: P 1:24(23) ack 1 win 91 <nop,nop,timestamp 4294950279 60498>
12:58:01.288914 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 1:29(28) ack 24 win 64489 <nop,nop,timestamp 60498 4294950279>
12:58:01.288966 IP 192.168.20.110.ssh > 192.168.4.20.3579: . ack 29 win 91 <nop,nop,timestamp 4294950291 60498>
12:58:01.289266 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 29:541(512) ack 24 win 64489 <nop,nop,timestamp 60498 4294950279>
12:58:01.289278 IP 192.168.20.110.ssh > 192.168.4.20.3579: . ack 541 win 108 <nop,nop,timestamp 4294950292 60498>
12:58:01.289283 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 541:645(104) ack 24 win 64489 <nop,nop,timestamp 60498 4294950279>
12:58:01.289290 IP 192.168.20.110.ssh > 192.168.4.20.3579: . ack 645 win 108 <nop,nop,timestamp 4294950292 60498>
12:58:01.290007 IP 192.168.20.110.ssh > 192.168.4.20.3579: P 24:664(640) ack 645 win 108 <nop,nop,timestamp 4294950292 60498>
12:58:01.294770 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 645:661(16) ack 664 win 63849 <nop,nop,timestamp 60498 4294950292>
12:58:01.297546 IP 192.168.20.110.ssh > 192.168.4.20.3579: P 664:944(280) ack 661 win 108 <nop,nop,timestamp 4294950300 60498>
12:58:01.331144 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 661:933(272) ack 944 win 63569 <nop,nop,timestamp 60499 4294950300>
12:58:01.350655 IP 192.168.20.110.ssh > 192.168.4.20.3579: P 944:1536(592) ack 933 win 124 <nop,nop,timestamp 4294950353 60499>
12:58:01.384974 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 933:949(16) ack 1536 win 64512 <nop,nop,timestamp 60499 4294950353>
12:58:01.385002 IP 192.168.4.20.3579 > 192.168.20.110.ssh: P 949:1001(52) ack 1536 win 64512 <nop,nop,timestamp 60499 4294950353>


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 ?

Thanks a lot

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index cf74c41..4a55854 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1226,15 +1226,6 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	if (want_cookie && !tmp_opt.saw_tstamp)
 		tcp_clear_options(&tmp_opt);
 
-	if (tmp_opt.saw_tstamp && !tmp_opt.rcv_tsval) {
-		/* Some OSes (unknown ones, but I see them on web server, which
-		 * contains information interesting only for windows'
-		 * users) do not send their stamp in SYN. It is easy case.
-		 * We simply do not advertise TS support.
-		 */
-		tmp_opt.saw_tstamp = 0;
-		tmp_opt.tstamp_ok  = 0;
-	}
 	tmp_opt.tstamp_ok = tmp_opt.saw_tstamp;
 
 	tcp_openreq_init(req, &tmp_opt, skb);

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

[David Miller]

From: Eric Dumazet <dada1@cosmosbay.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.

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

[Eric Dumazet]

David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.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.

ts_ecn ? You meant tsval ?

OK, here is a patch against net-next-2.6 with a Changelog and Signoff then.

Thank you

[PATCH] tcp: allow timestamps even if SYN packet has tsval=0

Some systems send SYN packets with apparently wrong RFC1323 timestamp
option values [timestamp tsval=0 tsecr=0].
It might be for security reasons (http://www.secuobs.com/plugs/25220.shtml )

Linux TCP stack ignores this option and sends back a SYN+ACK packet
without timestamp option, thus many TCP flows cannot use timestamps
and lose some benefit of RFC1323.

Other operating systems seem to not care about initial tsval value, and let
tcp flows to negotiate timestamp option.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
---

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index cf74c41..4a55854 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1226,15 +1226,6 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
 	if (want_cookie && !tmp_opt.saw_tstamp)
 		tcp_clear_options(&tmp_opt);
 
-	if (tmp_opt.saw_tstamp && !tmp_opt.rcv_tsval) {
-		/* Some OSes (unknown ones, but I see them on web server, which
-		 * contains information interesting only for windows'
-		 * users) do not send their stamp in SYN. It is easy case.
-		 * We simply do not advertise TS support.
-		 */
-		tmp_opt.saw_tstamp = 0;
-		tmp_opt.tstamp_ok  = 0;
-	}
 	tmp_opt.tstamp_ok = tmp_opt.saw_tstamp;
 
 	tcp_openreq_init(req, &tmp_opt, skb);

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

[David Miller]

From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 11 Mar 2009 16:00:02 +0100

> [PATCH] tcp: allow timestamps even if SYN packet has tsval=0
> 
> Some systems send SYN packets with apparently wrong RFC1323 timestamp
> option values [timestamp tsval=0 tsecr=0].
> It might be for security reasons (http://www.secuobs.com/plugs/25220.shtml )
> 
> Linux TCP stack ignores this option and sends back a SYN+ACK packet
> without timestamp option, thus many TCP flows cannot use timestamps
> and lose some benefit of RFC1323.
> 
> Other operating systems seem to not care about initial tsval value, and let
> tcp flows to negotiate timestamp option.
> 
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

And amusingly even Linux didn't care for ipv6 TCP sockets ;-)

Applied to net-next-2.6, thanks Eric.

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

[Ilpo Järvinen]

On Wed, 11 Mar 2009, David Miller wrote:

> From: Eric Dumazet <dada1@cosmosbay.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.

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

[David Miller]

From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET)

> On Wed, 11 Mar 2009, David Miller wrote:
> 
> > From: Eric Dumazet <dada1@cosmosbay.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 :-)

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

[Ilpo Järvinen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1628 bytes --]

On Fri, 13 Mar 2009, David Miller wrote:

> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET)
> 
> > On Wed, 11 Mar 2009, David Miller wrote:
> > 
> > > From: Eric Dumazet <dada1@cosmosbay.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.

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

[Eric Dumazet]

Ilpo Järvinen a écrit :
> On Fri, 13 Mar 2009, David Miller wrote:
> 
>> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
>> Date: Thu, 12 Mar 2009 09:26:20 +0200 (EET)
>>
>>> On Wed, 11 Mar 2009, David Miller wrote:
>>>
>>>> From: Eric Dumazet <dada1@cosmosbay.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