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] [day] [month] [year] [list]

Message-ID: <CALx6S37xyVHBzBG7uwatqj3je_0X=c=mTen_=R0G4f4+RTzNmA@mail.gmail.com>
Date:	Mon, 11 Jan 2016 10:43:16 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Edward Cree <ecree@...arflare.com>
Cc:	Jesse Gross <jesse@...nel.org>,
	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 Mon, Jan 11, 2016 at 10:27 AM, Edward Cree <ecree@...arflare.com> wrote:
> 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.

But the only way to know if a checksum is valid is to actually do the
computation. :-)

> "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.
>
Right, I've probably mentioned it at least ten times in nvo3 that we
usually get *better* performance by enabling the outer checksums due
to use of checksum offload. The reason Cisco doesn't want payload
checksums is because switch hardware typically doesn't support it, but
this doesn't justify changing fundamental UDP requirements for their
purposes. Making enabling of transmitting UDP checksums per tunnel is
sufficient to allow interoperability with such devices.

> -ed