Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums

Joe Touch <> Fri, 02 May 2014 22:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 801141A0957; Fri, 2 May 2014 15:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EKJU97U_t1ix; Fri, 2 May 2014 15:26:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F1081A6FE3; Fri, 2 May 2014 15:26:02 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s42MPA0Y028420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 15:25:10 -0700 (PDT)
Message-ID: <>
Date: Fri, 02 May 2014 15:25:10 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Tom Herbert <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>,, "" <>, "" <>, "" <>
Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 May 2014 22:26:05 -0000

On 5/2/2014 2:34 PM, Tom Herbert wrote:
>            VXLAN draft also breaks this by making accepting packets with
>         zero checksums a MUST.
>     That's not "breaking" anything; VXLAN is - to UDP - an application.
> Perhaps not, but making it a MUST in the encapsulation protocol
> definition to always accept UDP packets with zero checksums seems a bit
> austere. For instance, if I know within my deployment that all senders
> are configured to use checksums, then receiving a packet with zero
> checksum should be considered an invalid packet.

Sorry if I'm missing something here - this started with the following, 
from draft-mahalingam-dutt-dcops-vxlan-09, which focuses on the non-zero 
checksum case:

"When a decapsulating endpoint receives a packet with a non-zero
checksum it MAY choose to verify the checksum"

The point is that this is NOT an option. If the UDP checksum is nonzero, 
it MUST be validated.

(this isn't open to interpretation; if you want to have VXLAN accept 
non-zero checksums that are invalid, then you are not compliant with 
what few standards the Internet has)


When the UDP checksum is zero, RFC1122 says that:
	- an app MAY optionally be able to configure a system
	to accept zero-checksum UDP packets up or discard them

It would be a bad idea for VXLAN to assume that this configuration is 
available. However, that leaves only two cases:

	1) if accept/discard of zero-checksum IS available, then
	VXLAN would configure it to accept

	2) if accept/discard of zero-checksum is NOT available,
	then UDP *MUST* pass the zero-checksum packets to VXLAN.
	It's up to VXLAN to decide how to handle them - and it's
	OK to require VXLAN to MUST accept them (i.e., to treat
	them the same way as a valid non-zero checksum)

When you have a stronger validation mechanism, I see no reason to drop 
packets with zero checksums for that reason alone - however, VXLAN 
really needs to say that *it* will do that drop if necessary, not to 
assume that UDP can be configured to do so.