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

Tom Herbert <therbert@google.com> Thu, 01 May 2014 01:48 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 07AA11A09BB for <tofoo@ietfa.amsl.com>; Wed, 30 Apr 2014 18:48:18 -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 rBqSFs5BzLAI for <tofoo@ietfa.amsl.com>; Wed, 30 Apr 2014 18:48:16 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E23041A09B5 for <tofoo@ietf.org>; Wed, 30 Apr 2014 18:48:15 -0700 (PDT)
Received: by mail-ig0-f171.google.com with SMTP id c1so2745740igq.4 for <tofoo@ietf.org>; Wed, 30 Apr 2014 18:48:13 -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=o2TR9O46i5gLuZtzbyefWxdwSIdOh006zjHf1gYKWi8=; b=e87pFTrdyMQikOKldduQ4S2P809gZArxjGXuO40v4sklWcd0VLn+V7NIzwLusyQYZd BzOS+NHm2C7c9UCHGFbuHljX8knYlLR3G5IOrqTyhTuXCq35TvIxGJN7w+ifV/9Tk5rR RQ3kF8J5Tv+E2LCGqfXICEDVpnxjpo6o1CUOo8L05SexBw/qchOmc5JQZdO/0WArB7CJ E+5yf7IXz1FPzPn2/RcV3BR0Jm+bv256yft95k8/H14CXGwa4JCPmvElsIQhSgsASJ2G glU2ikhGmPsejZKVgn6N5TYDyZj3k7dVEJdiv9odvCOxah/UrD60Ny24VjzSbUso/fqc PN/A==
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=o2TR9O46i5gLuZtzbyefWxdwSIdOh006zjHf1gYKWi8=; b=GZkQRjC6mcj6/bkvCA0ZpvBZ3toHhuMh6SEN/iApexfKDgJiqoVG4XZRriIYooqPRa ZHWgqisk3fZdPemkmzStMHPQnu9YxlckQ/MndaYWD2uBhScs6MlKqedQqmZS2E57u9B/ oHOixKN+Djxudm56Hwv1kr8j650r1nmPbFyi2Bsbk0pxA5Ux8GE0YHiptmnOx2wDOInp clEooG1RQ17D6HPQ7Wnx+TcKT/OTdPqy13M1SwOzyCwdOpnP/5oIiXb+VjsoIqM4ZGGI n0EkU5khJdn5ovBZq+Q0DBMQ1mNmhwLzgAHIJAcX/xEb1TY4qewdcnY6wOBGD6t4hjyF zj0Q==
X-Gm-Message-State: ALoCoQnl9pMzH+JxbOAhJjogXUZvUI6pzQmw08N7KBUENpjjBlakcuvYLvLJynaJpXIN0Pw2VUH2
MIME-Version: 1.0
X-Received: by 10.43.90.202 with SMTP id bj10mr7348649icc.48.1398908893629; Wed, 30 Apr 2014 18:48:13 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Wed, 30 Apr 2014 18:48:13 -0700 (PDT)
In-Reply-To: <CF86DC33.F39B6%kreeger@cisco.com>
References: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com> <CF86DC33.F39B6%kreeger@cisco.com>
Date: Wed, 30 Apr 2014 18:48:13 -0700
Message-ID: <CA+mtBx9E=NopE=Evm1u7air4_R_eCUM6WvaOW+mw7m6LDGemDw@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
Content-Type: multipart/alternative; boundary=bcaec5186f0aadb28304f84cdbde
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/QQNO7S7PZmldV-Y_D1d0KUY9MIQ
Cc: "tofoo@ietf.org" <tofoo@ietf.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 01:48:18 -0000

On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger)
<kreeger@cisco.com>wrote;wrote:

> Hi Tom,
>
> I'll give you my perspective on why I feel the behavior described in the
> VXLAN draft is a good thing.  First, it is my assumption that some
> implementations (e.g. many hardware implementations), will not implement
> checksum generation, nor checksum validation.  I believe this is an
> implementation reality.  If implementations are required to check a
> non-zero checksum, but can't actually do it, what alternatives do they
> have?


Barring that the implementations you're referring to only implement IPv6,
these implementations must be already be doing checksum validation for IPv4
header-- so the checksum logic must have been implemented and I'm not sure
the argument that this HW can't calculate the UDP csum would have much
merit. A specific example implementation would be nice here, for instance
in the case that the stack decapsulates the checksum can always be done in
SW if verification is not provided by the device.

Also, as I pointed out, the UDP checksum is *not* useless in VXLAN. In an
L3 routed network there is nothing that protects the vni from corruption
expect possibly the UDP checksum. Without any additional security
mechanisms is VXLAN header (like a cookie), the only way I could deploy
VXLAN is with checksums enabled. So in my opinion, the draft should be
encouraging use of UDP checksums instead of discouraging them.

Thanks,
Tom



> One is to drop all packets with a non-zero checksum (because one
> might be invalid and even one invalid one slipping through would be
> unacceptable).  Another alternative is to accept all checksum values.  The
> second option greatly enhances interoperability with implementations that
> choose to generate a checksum and implementations that cannot validate the
> checksum.  It allows a mixed environment where "better" implementations
> (that can validate) can interoperate with "inferior" implementations that
> are unable to validate the checksum.



>
>
BTW, VXLAN is not the only tunneling protocol to specify this behavior.
> LISP (RFC 6830), specifies exactly the same behavior.
>
 - Larry
>
> On 4/30/14 12:01 PM, "Tom Herbert" <therbert@google.com> wrote:
>
> >Hi,
> >
> >I noticed that the VXLAN draft allows an implementation to potentially
> >ignore a non-zero invalid UDP checksum.
> >
> >From: http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-09
> >
> >"When a decapsulating endpoint receives a packet with a non-zero
> >checksum it MAY choose to verify the checksum"
> >
> >However, from RFC 1122:
> >
> >"If a UDP datagram is received with a checksum that is non-zero and
> >invalid, UDP MUST silently discard the datagram."
> >
> >It doesn't seem like 1122 allows checksum verification to be optional,
> >so these would seem to be a conflict. Presumably, ignoring the RX csum
> >is included for performance but since the sender can already send zero
> >checksums in UDP (they are optional in IPv4 and allowed for IPv6
> >tunnels in RFC 6935) I'm not sure this is necessary. Besides that, the
> >UDP checksum is potentially the only thing that protection of the vni
> >against corruption end to end so allowing a receiver to ignore a bad
> >checksum seems very risky.
> >
> >As a comparison, RFC 3931 (L2TP) has the following wording:
> >
> >"Thus, UDP checksums MAY be disabled in order to reduce the associated
> >packet processing burden at the L2TP endpoints."
> >
> >This is somewhat ambiguous, but seems like the correct interpretation
> >should be that zero checksums may be sent with L2TP/UDP, but on
> >receive non-zero checksums should still be validated.
> >
> >Are these interpretations correct? Is there there a need to clarify
> >the requirement for UDP tunnel protocols and checksums?
> >
> >Thanks,
> >Tom
> >
> >_______________________________________________
> >Tofoo mailing list
> >Tofoo@ietf.org
> >https://www.ietf.org/mailman/listinfo/tofoo
>
>