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

Joe Touch <> Fri, 02 May 2014 23:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96A771A6FDE; Fri, 2 May 2014 16:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2cz9yaHBh29H; Fri, 2 May 2014 16:59:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D01B1A6F63; Fri, 2 May 2014 16:59:00 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s42Nw4IT016849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 16:58:04 -0700 (PDT)
Message-ID: <>
Date: Fri, 02 May 2014 16:58:06 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; 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 23:59:02 -0000

On 5/2/2014 4:15 PM, Tom Herbert wrote:
>> I think your objection may be that you don't think we can assume that
>> zero-checksum packets arrive at VXLAN, because of how RFC1122 is worded.
> No, I expect zero checksums will be the common case.

I meant that you don't think that this common case will be correctly 

>> However, RFC768 permits zero-checksum packets as valid and useful to the
>> upper layer, so I interpret RFC 1122 as saying "the app might be able to
>> configure UDP to discard zero-checksum packets", but if it doesn't, those
>> packets already will end up at the application.
> My interpretation of the VXLAN draft precludes the possibility of an
> implementation being able to reject received zero-checksums even as a
> configuration option, or even for select senders.

Agreed - as writte, it cannot reject those packets merely because thye 
have a zero checksum -

   "When a packet
    is received with a UDP checksum of zero, it MUST be accepted for
    decapsulation. "

(note that I have no position as to whether this is good or bad; VXLAN 
could decide to reject such packets if that's what the WG decides).

> So if we receive a
> zero checksum from a sender that we know has not disabled checksums,
> per the draft we need to accept even though we know this is a
> corrupted packet.

I don't know how you can make this claim.

You don't know it's a corrupted packet - esp. because it's highly 
unlikely that the checksum would be zero'd solely by corruption. What 
you know - at best - is that the source decided to send a zero-checksum 

A sender that transmits zero checksums does so deliberately (on an 
ongoing basis). It does so when it believes that another layer will 
check for packet corruption, or when packet corruption isn't important.

> This may not break the standard, but it doesn't seem
> robust either. Is my interpretation correct?

VXLAN can make whatever decision you want; you can decide to accept 
zero-sum packets for further processing, to reject them, or to decide on 
a per-endpoint basis given other knowledge of the endpoint. All 
behaviors are compliant with current standards.

What you cannot do is accept a packet with a non-zero checksum that is 
invalid. Those should never be sent to VXLAN; they MUST be silently 
dropped by UDP. That's where this discussion originated.

As to robustness, IMO, the best would be to send packets with UDP 
checksums, so you drop corrupt packets as early as possible. If you 
don't want to incur the cost of checking (which is often in offload 
engines anyway), then you'd be relying on the upper layer (VXLAN layer) 
to check for errors.

However, I don't see that here - what I see is an ethernet header but 
that doesn't protect the E2E of the UDP packet, and that's not good enough.

> My core concern in all of this is still whether the vni in VXLAN in
> being adequately protected against corruption (this would apply to
> other encapsulation protocols that carry vni also). The integrity of
> the vni is paramount in supporting the isolation requirements of
> network virtualization.

Then what you want is to require VXLAN to MUST send non-zero UDP 
checksums. At that point, saying "VXLAN receiver MUST discard 
zero-checksums" is fine, and both statements are compliant with existing 

Alternately, if you allow - or encourage - zero-checksum UDP, then you 
want to add a checksum of some kind to the VXLAN header.

But again, you're talking about the zero-checksum case, not the non-zero 
case where this all started.