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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ