netdev - Re: [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload

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: <5693F3FD.4030804@solarflare.com>
Date:	Mon, 11 Jan 2016 18:27:09 +0000
From:	Edward Cree <ecree@...arflare.com>
To:	Tom Herbert <tom@...bertland.com>, Jesse Gross <jesse@...nel.org>
CC:	Alexander Duyck <alexander.duyck@...il.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	<linux-net-drivers@...arflare.com>
Subject: Re: [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload

On 11/01/16 17:55, Tom Herbert wrote:
> On Mon, Jan 11, 2016 at 9:24 AM, Jesse Gross <jesse@...nel.org> wrote:
>> It's hard to say what other types of endpoints might do if they
>> receive a VXLAN packet with a checksum set and, of course, there are
>> other protocols that don't specify that received UDP checksums can be
>> ignored.
>>
> RFC1122 is very clear on the subject of UDP checksums:
>
> "If a UDP datagram is received with a checksum that is non- zero and
> invalid, UDP MUST silently discard the datagram."
>
> So if a VXLAN receiver accepts a UDP packet without checking a
> non-zero UDP checksum for validity they are breaking the UDP protocol.
> If they blow up because they don't expect to receive non-zero
> checksums that is entirely their problem.
More to the point, RFC7348 says that if the outer checksum isvalid, the
 receiver MUST accept it.
"If the decapsulating destination chooses not to perform the verification,
 or performs it successfully, the packet MUST be accepted for decapsulation."
Therefore, if they blow up because they don't expect to receive non-zero
 checksums, they're not compliant with the spec.
On the other hand, there is always 'be conservative in what you emit'... how
 far should you go to interoperate with broken implementations.
On the gripping hand, I suspect RFC7348 only recommends against outer csums
 in the first place because the authors believed it was expensive.

-ed