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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Feb 2016 20:20:50 +0000
From:	Edward Cree <ecree@...arflare.com>
To:	David Miller <davem@...emloft.net>
CC:	<rick.jones2@....com>, <tom@...bertland.com>, <jesse@...nel.org>,
	<aduyck@...antis.com>, <netdev@...r.kernel.org>,
	<alexander.duyck@...il.com>
Subject: Re: [net-next PATCH 0/2] GENEVE/VXLAN: Enable outer Tx checksum by
 default

On 23/02/16 18:08, David Miller wrote:
> From: Edward Cree <ecree@...arflare.com>
> Date: Tue, 23 Feb 2016 17:38:28 +0000
>
>> "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.
> Just a reminder that a very long time ago we tried setting the IP ID
> field to zero for DF packets, and this broke SLHC because that expects
> a monotonically increasing IP ID field.
If I'm reading it right, Linux's SLHC implementation can cope [1] with
unchanging IP IDs (or IDs that do something other than increment), which it
encodes with the NEW_I bit.  RFC1144 supports this, remarking "note that it
may be zero or negative" (§3.2.3) of the ID delta.  So VJ implementations that
can't handle it really are buggy, not just exhibiting a difference of opinion.

So it seems like the problem case is where some sort of SLIP gateway lies
between a Linux system (say, a webserver sending with TSO) and a buggy client;
in that case, even if the client can't be fixed it seems like the gateway
could be (either to send NEW_I or just lie about the incoming IP IDs and claim
they're incrementing - the latter is entirely safe for a DF packet).

[ I really hope we can figure out a way not to change IP IDs, because I think
an inverted version of Tom's generic TSO could also work as a generic h/w GRO
accelerator.  In its simplest form, the hardware just remembers the previous
packet, then gives us the length of the common prefix.  If that ends four bytes
into a TCP header, then the packet is a candidate for GRO; otherwise not.  I
haven't worked out all the details yet, but it's clear that non-constant IP IDs
would cause problems.  (If it's only the innermost IP ID that's changing, we
can probably still cope, but the performance gain will be less and the
implementation could start to get ugly.) ]

--
-Ed

[1] http://lxr.free-electrons.com/source/drivers/net/slip/slhc.c#L425