netdev - Re: [PATCH net] tcp: add proper TS val into RST packets

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]

Message-ID: <1443041578.29850.137.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 23 Sep 2015 13:52:58 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yuchung Cheng <ycheng@...gle.com>
Cc:	Neal Cardwell <ncardwell@...gle.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] tcp: add proper TS val into RST packets

On Wed, 2015-09-23 at 13:36 -0700, Yuchung Cheng wrote:
> On Wed, Sep 23, 2015 at 1:30 PM, Neal Cardwell <ncardwell@...gle.com> wrote:
> >
> > On Wed, Sep 23, 2015 at 4:19 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > > From: Eric Dumazet <edumazet@...gle.com>
> > >
> > > RST packets sent on behalf of TCP connections with TS option (RFC 7323
> > > TCP timestamps) have incorrect TS val (set to 0), but correct TS ecr.
> > >
> > > A > B: Flags [S], seq 0, win 65535, options [mss 1000,nop,nop,TS val 100 ecr 0], length 0
> > > B > A: Flags [S.], seq 2444755794, ack 1, win 28960, options [mss 1460,nop,nop,TS val 7264344 ecr 100], length 0
> > > A > B: Flags [.], ack 1, win 65535, options [nop,nop,TS val 110 ecr 7264344], length 0
> > >
> > > B > A: Flags [R.], seq 1, ack 1, win 28960, options [nop,nop,TS val 0 ecr 110], length 0
> > >
> > > We need to call skb_mstamp_get() to get proper TS val,
> > > derived from skb->skb_mstamp
> > >
> > > Note that RFC 1323 was advocating to not send TS option in RST segment,
> > > but RFC 7323 recommends the opposite :
> > >
> > >   Once TSopt has been successfully negotiated, that is both <SYN> and
> > >   <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
> > >   segment for the duration of the connection, and SHOULD be sent in an
> > >   <RST> segment (see Section 5.2 for details)
> Nice comment. I think it's worth adding why we choose not to follow
> RFC7323 sec 5.2 recommendation on setting TSval to 0?

We revert to prior behavior. This is a bug fix, as it clearly was not
even considered in 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")

In 5 years, if/when all TCP stack are RFC 7323 ready, we might consider
to decide to send TS val = 0

Problem with RFC is they suppose both senders and receivers are ready
and support new recommendations.

Linux always sent TSopt in its RST packets, and apparently it works
well.

It is premature to send TS val = 0 we believe.


--
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