netdev - Re: [net-next PATCH 0/2] GENEVE/VXLAN: Enable outer Tx checksum by default

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: <56CC9914.5010506@solarflare.com>
Date:	Tue, 23 Feb 2016 17:38:28 +0000
From:	Edward Cree <ecree@...arflare.com>
To:	Rick Jones <rick.jones2@....com>, Tom Herbert <tom@...bertland.com>
CC:	Jesse Gross <jesse@...nel.org>, Alex Duyck <aduyck@...antis.com>,
	"Linux Kernel Network Developers" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Alexander Duyck <alexander.duyck@...il.com>
Subject: Re: [net-next PATCH 0/2] GENEVE/VXLAN: Enable outer Tx checksum by
 default

On 23/02/16 17:20, Rick Jones wrote:
> On 02/23/2016 08:47 AM, Tom Herbert wrote:
>> Right, GRO should probably not coalesce packets with non-zero IP
>> identifiers due to the loss of information. Besides that, RFC6848 says
>> the IP identifier should only be set for fragmentation anyway so there
>> shouldn't be any issue and really no need for HW TSO (or LRO) to
>> support that.
>
> You sure that is RFC 6848 "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)" ?
PossiblyRFC 6864 "Updated Specification of the IPv4 ID Field".
> In whichever RFC that may be, is it a SHOULD or a MUST, and just how many "other" stacks might be setting a non-zero IP ID on fragments with DF set?
"The IPv4 ID field MUST NOT be used for purposes other than fragmentation
 and reassembly."(§4.1)
"Originating sources MAY set the IPv4 ID field of atomic datagrams to any
 value."(§4.1)
"All devices that examine IPv4 headers MUST ignore the IPv4 ID field of
 atomic datagrams."(§4.1)
Atomic datagrams are defined by "(DF==1)&&(MF==0)&&(frag_offset==0)" (§4).

So it's OK to coalesce packets with different identifiers, as long as they
have DFset (and aren't fragmented already).  Also, the RFC takes pains to
point out that it "does not reserve any IPv4 ID values, including 0, as
distinguished" (§4.1), so one cannot rely on the ID always being zero.
--
-Ed