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

Tom Herbert <therbert@google.com> Fri, 02 May 2014 22:34 UTC

Return-Path: <therbert@google.com>
X-Original-To: tofoo@ietfa.amsl.com
Delivered-To: tofoo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA81A6FDE for <tofoo@ietfa.amsl.com>; Fri, 2 May 2014 15:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
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=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKZcThf69M3Z for <tofoo@ietfa.amsl.com>; Fri, 2 May 2014 15:34:12 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id DEF9E1A0957 for <tofoo@ietf.org>; Fri, 2 May 2014 15:34:11 -0700 (PDT)
Received: by mail-ig0-f182.google.com with SMTP id uy17so925384igb.3 for <tofoo@ietf.org>; Fri, 02 May 2014 15:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Mla9aodA+3AvstUHbKyml78ldvof/p+sMYRVZX/z/Y=; b=HrgJUb8TddU1Jouo+zJbO0rHxVsViHSAFmRvP8UGpS+TLbo1sTejFYUuqqtRaybcLP mnMefdzSXLubMogYrSpfKHiLgTmNWG3omhTAcgVr8tlNZ+x1XnS9NvQ7mUWZ1Lw1TskU WozP7NchbJFhRpVe9ifYg9J9fwGhtsRN1wdnL3YB65zJKE39SORXxFzmj6F6mZ/o9zeP gDPRLIkwbGw1oHJcOM/Z+mX9CFQDTpgT3/luAcw9vjcJh2mbS2A30Rsb8oq9DbWmaAFo m2U9gD2vtHKBo5uJfyNKad/QhfaE6EPljLkLyAVvROV66/29AHrK2L2Rb5rp69tXmc4k faWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Mla9aodA+3AvstUHbKyml78ldvof/p+sMYRVZX/z/Y=; b=G2t/GpYWYJH1PPRmEiexKwJrMpoR23io8ID3c7HWfw60wQTkW1DxGg+5d0ZhsTyw4b 0lD+V3pGJpasjrWE8DI6Duj3zFjZqzt4Enl2Y5LbCWewWKRC8u8X9tVeETcymZdfNyDa onNrUtEO0XumTrQI8P4gBbOZ0ye49VnUPAOwDysGv14NxMyx+TOhU/ALvCsif6y/pwPV D7En6fwzGeKU99gRRGYGaXG0DmBzvK4JhK27hz23OA0cl5Uge2iNGzEn6Dq6MK68vdjQ d9FGszgsySRsna9wajyTpsS/1zEZTOCbdTElwdDWlSKI/ZXAAXgLWoeyIOaIivMrnUr2 FwWw==
X-Gm-Message-State: ALoCoQlVylys3dyVZyc7Dc7jIFuw8TM7sa7rjNixZTGBIYvirawbpMu6WgtZRD3t1sDR00wVLLts
MIME-Version: 1.0
X-Received: by 10.50.25.201 with SMTP id e9mr8119604igg.28.1399070049367; Fri, 02 May 2014 15:34:09 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Fri, 2 May 2014 15:34:09 -0700 (PDT)
In-Reply-To: <53641B46.5000200@isi.edu>
References: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com> <CAC8QAccqYygAZrX=P1S7Av4KXtU82RWANv=BAaKjYm=hDH0hAA@mail.gmail.com> <CA+mtBx9YfBtizy+a1Wi+z5isYQ7AtLm_Hevx7U66U8HS8u_6LQ@mail.gmail.com> <CAC8QAcdXLbdVw3FYcdqSg163_w76ThYXuK3M9-vvw_wx5d52_Q@mail.gmail.com> <5362ACA5.1030102@isi.edu> <CAC8QAcfi=CEc_a43R1ZgidtmdjGL2G4C_+PPj-uDCMkZ+aheuw@mail.gmail.com> <5362AFBB.6080008@isi.edu> <CA+mtBx8G6kBzOiKP2r7W3i1JV43A8feg8Xqbo6t1Kfhj3jwpJA@mail.gmail.com> <5362B7E4.8060809@isi.edu> <CA+mtBx8hLyvQ+3Bs9cFjGPV0dWtK+TDO+J6Mg_gLtgxHECiCRw@mail.gmail.com> <53641B46.5000200@isi.edu>
Date: Fri, 2 May 2014 15:34:09 -0700
Message-ID: <CA+mtBx-3on5jyEteRnNLAb6Pv5n6y2UkHUdKCnbmJDMk6yrKFQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/tESU0khchGIj8P0F7i8SoH7l_AY
Cc: "tofoo@ietf.org" <tofoo@ietf.org>, sarikaya@ieee.org, "nvo3@ietf.org" <nvo3@ietf.org>, "mallik_mahalingam@yahoo.com" <mallik_mahalingam@yahoo.com>, "ddutt.ietf@hobbesdutt.com" <ddutt.ietf@hobbesdutt.com>
Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums
X-BeenThere: tofoo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <tofoo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tofoo>, <mailto:tofoo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tofoo/>
List-Post: <mailto:tofoo@ietf.org>
List-Help: <mailto:tofoo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tofoo>, <mailto:tofoo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 22:34:13 -0000

On Fri, May 2, 2014 at 3:25 PM, Joe Touch <touch@isi.edu>; wrote:
>
>
>
> 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)
>
I am referring to:

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

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