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

Tom Herbert <therbert@google.com> Thu, 01 May 2014 21:01 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 1F2B21A7032 for <tofoo@ietfa.amsl.com>; Thu, 1 May 2014 14:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 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, HTML_MESSAGE=0.001, 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 FkvXyMvOajDX for <tofoo@ietfa.amsl.com>; Thu, 1 May 2014 14:00:59 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 901061A0971 for <tofoo@ietf.org>; Thu, 1 May 2014 14:00:59 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id lx4so4125895iec.38 for <tofoo@ietf.org>; Thu, 01 May 2014 14:00:57 -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=Mev6aRfGmzP6qIdAXdjQk8l5UMKMyhWLGc1C+JsNkLg=; b=juAN037mNkOFJgWn6YMKq7F7E23EFXz/jQLdt1mWmQKQ9kmGPc24t5d2qLrIU2iz7Y CX+GbH+EEjYjUh4TMmhO7I90ljk5zbuHh4ecJhrCKz4uX+QmPNo/c11CrcUudjUvE13J PRmaeOeqJ0Ajtdg3mdPb23H8WVHVtpW6DodvLQR7I8xbMLZISVA5aCojW3uVydIqn1J9 Qf9HB/1JEnAOdR1/ty79mBYqz4z1sklwbJVt3u8SKOyLWHH+SaZEm1iEEz7Lffug1hb2 E4unIR8CxTnaCPy5gtGC9zLT80GpacW7ZTbEyxDo98EReFhYPSo0nZbyPLDIKcY5QtL+ pM5g==
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=Mev6aRfGmzP6qIdAXdjQk8l5UMKMyhWLGc1C+JsNkLg=; b=Uae4WrLtosnJ26v83CRIn+Sa1AgB8MSqLyYJKuuxD1N54ueQbx1E+hpm/CftLjjzKy KmAiaFsdnyAg/JWbdLz3roL4Ipg5g5ZxDzDmLCMIXhZypLrYw3Hf7YlzIBwPZi2H+JTm +KF76zju6WA5xwN8UN/RaXZQFhEcbeAlR+OEnTjxFGyO9IBJUN9/RrCm5bAGjnRc2PhW IqI33QxjyNhe0ERg7lD6gfFcbXk/zNcQL6uDRkU4K/4CYw/DRbxntq14Q9Yc9P/pF8nR rC52+wrAl19IuAZqtmMq2QWoQlb6LRjvx497DwEPO9WRWi4YRgj0dCUnpWHTaRBc9kqZ H1Zw==
X-Gm-Message-State: ALoCoQlBJe0EP59uBWCDc+naNhWzHIpD5/GL6oxKh9hmLsWCuPI/obeXkeBORDsLBxiF2uCe5HPm
MIME-Version: 1.0
X-Received: by 10.50.143.34 with SMTP id sb2mr5942196igb.48.1398978049737; Thu, 01 May 2014 14:00:49 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Thu, 1 May 2014 14:00:49 -0700 (PDT)
In-Reply-To: <5362AFBB.6080008@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>
Date: Thu, 01 May 2014 14:00:49 -0700
Message-ID: <CA+mtBx8G6kBzOiKP2r7W3i1JV43A8feg8Xqbo6t1Kfhj3jwpJA@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="001a1135effeb4238904f85cf50f"
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/4rSXyMO4Sm9qO-n3NC20INk6qJA
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: Thu, 01 May 2014 21:01:01 -0000

On Thu, May 1, 2014 at 1:34 PM, Joe Touch <touch@isi.edu> wrote:

>
>
> On 5/1/2014 1:30 PM, Behcet Sarikaya wrote:
>
>>
>>
>>
>> On Thu, May 1, 2014 at 3:20 PM, Joe Touch <touch@isi.edu
>> <mailto:touch@isi.edu>> wrote:
>>
>>
>>
>>     On 4/30/2014 2:23 PM, Behcet Sarikaya wrote:
>>
>>         Here is what VXLAN says on tunneled traffic:
>>
>>         Tunneled traffic over the IP network can be secured with
>> traditional
>>              security mechanisms like IPsec that authenticate and
>> optionally
>>              encrypt VXLAN traffic. This will, of course, need to be
>>         coupled with
>>              an authentication infrastructure for authorized endpoints
>>         to obtain
>>              and distribute credentials.
>>
>>         Based on this, UDP checksum text seems to be consistent, no?
>>
>>
>>     No; the UDP checksum is not for authetication. It is an error check.
>>
>>     The only party that can decide to make the UDP checksum optional
>>     when using IPv4 is the source - by inserting zero.
>>
>>     It's not the receiver's choice to ignore that checksum if it's not
>>     zero. That's where this doc breaks the current standards.
>>
>> The important point in the above text that I quoted was encryption being
>> optional not about authentication.
>> So checksum would be zero if the payload is encrypted and non-zero if it
>> is not not and both cases are possible.
>>
>
> Receiver processing is simple:
>
>         - if the checksum is zero, ignore
>
>         - if the checksum is NOT zero, it MUST match
>
> This is true with caveat that an implementation MAY ignore a zero
checksum, not MUST ignore a zero checksum. This is specified in RFC1122.
 VXLAN draft also breaks this by making accepting packets with zero
checksums a MUST. From a practical perspective, if the UDP checksum were
the only thing I had to protect the vni I would want the capability to drop
packets received with zero checksums in my deployment.

Tom

No other part of the packet needs to be examined. If the *sender* wants to
> have the receiver ignore the checksum, it inserts zero. If not, the
> receiver MUST process and validate it.
>
> Joe
>