netdev - Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

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]

Message-ID: <57002B05.8070005@hpe.com>
Date:	Sat, 2 Apr 2016 13:26:45 -0700
From:	Rick Jones <rick.jones2@....com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	alexander.duyck@...il.com, aduyck@...antis.com,
	herbert@...dor.apana.org.au, tom@...bertland.com, jesse@...nel.org,
	edumazet@...gle.com, netdev@...r.kernel.org
Subject: Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On 04/01/2016 07:21 PM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote:
>> From: Alexander Duyck <alexander.duyck@...il.com>
>> Date: Fri, 1 Apr 2016 12:58:41 -0700
>>
>>> RFC 6864 is pretty explicit about this, IPv4 ID used only for
>>> fragmentation.  https://tools.ietf.org/html/rfc6864#section-4.1
>>>
>>> The goal with this change is to try and keep most of the existing
>>> behavior in tact without violating this rule?  I would think the
>>> sequence number should give you the ability to infer a drop in the
>>> case of TCP.  In the case of UDP tunnels we are now getting a bit more
>>> data since we were ignoring the outer IP header ID before.
>>
>> When retransmits happen, the sequence numbers are the same.  But you
>> can then use the IP ID to see exactly what happened.  You can even
>> tell if multiple retransmits got reordered.
>>
>> Eric's use case is extremely useful, and flat out eliminates ambiguity
>> when analyzing TCP traces.
>
> Yes, our team (including Van Jacobson ;) ) would be sad to not have
> sequential IP ID (but then we don't have them for IPv6 ;) )

Your team would not be the only one sad to see that go away.

rick jones

> Since the cost of generating them is pretty small (inet->inet_id
> counter), we probably should keep them in linux. Their usage will phase
> out as IPv6 wins the Internet war...
>
>