netdev - Re: TCP socket receives strange packet

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: <20141014164144.GG28432@Paaschs-MacBook-Pro.local>
Date:	Tue, 14 Oct 2014 09:41:44 -0700
From:	Christoph Paasch <christoph.paasch@...il.com>
To:	John Heffner <johnwheffner@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	"Yurij M. Plotnikov" <Yurij.Plotnikov@...etlabs.ru>,
	Netdev <netdev@...r.kernel.org>,
	"Alexandra N. Kossovsky" <Alexandra.Kossovsky@...etlabs.ru>
Subject: Re: TCP socket receives strange packet

Hello,

On 14/10/14 - 11:40:44, John Heffner wrote:
> On Tue, Oct 14, 2014 at 11:00 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > On Tue, 2014-10-14 at 18:09 +0400, Yurij M. Plotnikov wrote:
> >> Connected TCP socket receives packet without timestamps option which
> >> exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.
> >>
> >> tcpdump output description: The host has address 10.208.10.1 (server)
> >> and the peer host has address 10.208.10.2 (client).
> >>
> >> Establishing connection: Timestamps option exists in SYN, SYNACK and ACK
> >> (packets 1, 2 and 3 in attached file), so accepted socket should receive
> >> packets only with timestamps option.
> >
> > Can you point the RFC paragraph stating so ?
> >
> > I have wondering if this behavior was correct some time ago, and could
> > not find a definitive answer.
> >
> > RFC 1323 4.2.1 seems to suggest it is valid to accept a segment without
> > TS.
> >
> > R1) If there is a Timestamps option in the arriving segment...
> >
> >
> >  There is no : Else drop the segment.
> 
> 
> I can't think of a good reason to drop unless you're trying to use the
> timestamp fields as extra security against off-path injection attacks.
>   (It doesn't currently help much for that.)

there was a long discussion whether for the updated version of RFC1323 (now
published as RFC 7323) a segment must be dropped if it does not contain a
timestamp. The rationale (defended by Joe Touch) was that it must be there to
protect against wrapped sequence numbers while others argued that mandating
a drop might result in stalling connections if (for one reason or another) a
host sends a segment without TS (or a middlebox removed it).

The RFC now says that a host SHOULD drop segments without timestamps.



Cheers,
Christoph

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