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

Tom Herbert <therbert@google.com> Thu, 01 May 2014 15:18 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 A47931A6F74 for <tofoo@ietfa.amsl.com>; Thu, 1 May 2014 08:18:10 -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=unavailable
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 oRj6yzJ-MVqN for <tofoo@ietfa.amsl.com>; Thu, 1 May 2014 08:18:07 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 88A701A08E9 for <tofoo@ietf.org>; Thu, 1 May 2014 08:18:07 -0700 (PDT)
Received: by mail-ig0-f181.google.com with SMTP id h18so604497igc.2 for <tofoo@ietf.org>; Thu, 01 May 2014 08:18:04 -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=ybJDw+Nc38no8RFVLnrHBpqObEc7ybLf9CZueAAuppw=; b=MTXu3oDzW9B7e1qp2xLnFLYp99HUH0qjx+vH3cGwtTXrOW7i21x/v8VtML3wV9ZfSl qgj3CDE+N6Rjh1A+GWE76mD3yo3sBX68n/ZlCyYOFJmEuGuGkxmmDmgEw04KXy8nPRtp p2XJCAhyjMZVgYnMOWe64gXq95KNmNtXXJYNTgTAY79DNU6lZHfj3gY+3UZDbgtXODom tq64oN5naU3f2/wP16kx6K5uPNSIqUKUNHPVXfK+ptlX0Y+HBOVw5VfKcYa9nYAHaqBm Ms7cfZngtDftX7tLndPGGX9xo5+3tiSob1lwYkAQueIiOV3HgSHHga7yek19i0N0m1Hi pt9Q==
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=ybJDw+Nc38no8RFVLnrHBpqObEc7ybLf9CZueAAuppw=; b=diVx3FLkHDWK/6xwLicX2QT6CADreBWZ03TphlWUJCBL7iJXu6peve/HF5Xmqs9O47 dWtBIRjAbTn3w0lsZOY+zCykYEDfQUQWYyJ6KDTjB9M9cm6RFLIaSG+D1myVoDgYnl/G QD5PDf4J7oA6GJtbc6KJVTUQOvfo0qoY9oZpBUvUXx/ohIlM26KE+ixWkGpBPu/P9EpC nI93FeAotLwy3HuYAalXhYvn86wfUbxxa6+B3n8du2m4Jt5P4MCmbGpPBJmUUily9eas XNe01LfGE006zJYPK1ICchKDq8FJLR26wzWlxmkFHHFMevY5qyX0a2TT+Y+FMEEzlcPT 0Q1A==
X-Gm-Message-State: ALoCoQk22RhTzCDK8oJ2OmkHw1MWaLUyjHIsXLJG2Nq7vUcV1Dv20H0ItXASbWksv90xfnYXNqUn
MIME-Version: 1.0
X-Received: by 10.42.62.196 with SMTP id z4mr10416428ich.49.1398957484670; Thu, 01 May 2014 08:18:04 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Thu, 1 May 2014 08:18:04 -0700 (PDT)
In-Reply-To: <663894c8432a40f6ada92247831f7a2d@AM3PR03MB612.eurprd03.prod.outlook.com>
References: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com> <CF86DC33.F39B6%kreeger@cisco.com> <CA+mtBx9E=NopE=Evm1u7air4_R_eCUM6WvaOW+mw7m6LDGemDw@mail.gmail.com> <663894c8432a40f6ada92247831f7a2d@AM3PR03MB612.eurprd03.prod.outlook.com>
Date: Thu, 1 May 2014 08:18:04 -0700
Message-ID: <CA+mtBx-KWtpLREmgT_s+yARmmB7zJ2Q1J4Uo2O4Xm_ajgwP8Kg@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Content-Type: multipart/alternative; boundary=90e6ba614a76ee1f9f04f8582b3e
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/BfYlMpYTsuUgjRwYo57fNVHgPus
Cc: "tofoo@ietf.org" <tofoo@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "Larry Kreeger \(kreeger\)" <kreeger@cisco.com>, "mallik_mahalingam@yahoo.com" <mallik_mahalingam@yahoo.com>, "ddutt.ietf@hobbesdutt.com" <ddutt.ietf@hobbesdutt.com>
Subject: Re: [Tofoo] [nvo3] 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 15:18:10 -0000

On Thu, May 1, 2014 at 1:10 AM, Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

>  Tom, Larry and all,
>
> I do not want to argue for or against UDP checksums in VXVLAN .
>
> Just want to point that ability of HW to check/generate the IPv4 checksums
> does not, IMHO and FWIW, that the same HW can easily do UDP checksums.
>
>
>
> AFAIK, IPv4 forwarding HW in most cases has access to a  relatively small
> part at the beginning of the packet. This is enough to deal with  the IPv4
> header but is not enough to compute UDP checksums – because these include
> the entire packet payload.
>
>
>
Thanks Sasha, this is a good point. Similar concerns have been mentioned
about the difficulty of switches to process packets with IP options. The
solutions there were to split into a fast and slow data path based on the
presence of options, or some implementations probably just dropped packets
with options.   In either case protocol conformance is maintained and there
was no need to change IP protocol. I'd suggest a similar approach can be
done where zero checksum value in a UDP packet takes an expedited data path.

Also, this discussion really seems to be specific to switch HW. I think
you'd be hard pressed to find a NIC that does not provide L4 checksum
offload. Retrofitting those NICs to provide checksum for encapsulation
(really a matter of supporting >1 csums in a packet) should mostly be an
API issue and even then most of the complexity in on TX side not RX.


>  This does not mean that HW-assisted computation of UDP ckechsums is not
> possible – only that it would be rthogonal to HW-assisted computation of
> IPv4 header checksums.
>
> My 2c,
>
>        Sasha
>
> Email: Alexander.Vainshtein@ecitele.com
>
> Mobile: 054-9266302
>
>
>
> *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Tom Herbert
> *Sent:* Thursday, May 01, 2014 4:48 AM
> *To:* Larry Kreeger (kreeger)
> *Cc:* tofoo@ietf.org; nvo3@ietf.org; mallik_mahalingam@yahoo.com;
> ddutt.ietf@hobbesdutt.com
> *Subject:* Re: [nvo3] [Tofoo] VXLAN (UDP tunnel protocols) and non-zero
> checksums
>
>
>
>
>
>
>
> On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger) <
> kreeger@cisco.com> 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
>
>
>