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

Tom Herbert <> Sat, 03 May 2014 01:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CE35A1A7026 for <>; Fri, 2 May 2014 18:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lg-fFgLOqAbi for <>; Fri, 2 May 2014 18:47:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::235]) by (Postfix) with ESMTP id 6800D1A6F53 for <>; Fri, 2 May 2014 18:47:38 -0700 (PDT)
Received: by with SMTP id y20so5883442ier.40 for <>; Fri, 02 May 2014 18:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=75oSHPLqV7nFIplY6Q805mVkf9AtBqQraw7clOgbVRo=; b=MfiM3tox7JHOCQWfOfeYbY1x6VG4TvyuLAx/j++Ml/1rouYexaZxAZECUlQtalrkNr xxrusCNYFClONnQNPoKCIAQpnIGbKQWcYBA5qSqis8TI/H5OeEy6mjtzCZqABV4JfgXP QrgxZR6avP3Y+gt1mkGGGkJESniyD1yxLUDNoQJSbiDc5LSQ5sXg8ky2AcohQcoH2MV+ JPs885yw35/qOVUwU5B/YGWLk1ThO4+UZuAlaxestTU3jfCg6uuR4W7NvHRGzvBKy7MZ kbA1bRZIehCTzp/XbT9QpJFzWG/ySX424fEpovh3HIPHVmb9SiHANw4TXmRpVwBCJCDK HiSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=75oSHPLqV7nFIplY6Q805mVkf9AtBqQraw7clOgbVRo=; b=EDJhWBA1cMaWRHfBwFToHvRLlsEvjdfMQln5taCQiNRg6osJMnFoejhyFJ6qHja/KC CzC6mD8JDxmBraMoAVZmjbaEj3MGHLGwYQC9tEEK0J5NuOGKB6ltZyeIw/UdE6rrNQAW kfASU11rBHOYk2A16Jlwt6ECG33qBR5zHtNVgXRh7RNYF8Chepxw6nXU7tWi9Ax7IFAd Ts3BgweEzCkQRwcUSEUgVGG8Wowu4gFbk94DmhF78RZovDvAdMAKfKMWM/fZPdzlabx4 9QVhMlquiNNv76qK2iE7vwqzTDLB9zFaNu4LskoF0EA0qXF/WvshgviarHpBnl/1Ops0 q0NA==
X-Gm-Message-State: ALoCoQmmnpubD3QemVwMXjB8f5hVD2/waFCRC/i3YOX4KE0G0ZlIII9+F2LhZqxy8aUoHttvh//C
MIME-Version: 1.0
X-Received: by with SMTP id e9mr8746869igg.28.1399081655877; Fri, 02 May 2014 18:47:35 -0700 (PDT)
Received: by with HTTP; Fri, 2 May 2014 18:47:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Fri, 2 May 2014 18:47:35 -0700
Message-ID: <>
From: Tom Herbert <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
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: Sat, 03 May 2014 01:47:40 -0000

> 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 packet.
Factually, I only know that I received a packet with checksum of zero,
not that one want sent. If I have external information that says the
sender has not disabled checksums then something must have gone awry.
This is not just the rare case of corrupted checksum value, but
unfortunately zero is the likely value if the sender is not properly
setting the checksum. Since the checksum is always zeroed in the
packet before computation, there are many opportunities for bugs in
drivers, stacks, and HW where the checksum is not actually written
correctly (especially possible in presence of TSO and checksum offload
in NICs)-- in this case packets may be sent incorrectly with a
checksum of zero. This condition could be difficult to detect since
everything might otherwise appear okay. I would take this into
consideration when contemplating use of zero checksums.

> 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 standards.
> 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.
> Joe