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

Tom Herbert <therbert@google.com> Wed, 30 April 2014 20: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 E7AB11A097C for <tofoo@ietfa.amsl.com>; Wed, 30 Apr 2014 13:01:47 -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=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 HsI3fznsegDZ for <tofoo@ietfa.amsl.com>; Wed, 30 Apr 2014 13:01:46 -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 22DA81A0973 for <tofoo@ietf.org>; Wed, 30 Apr 2014 13:01:46 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id lx4so2494463iec.10 for <tofoo@ietf.org>; Wed, 30 Apr 2014 13:01:43 -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=OvvAgJtMTYsET9j3NrBtGcBT+Y1biWRM30GShKrO7i8=; b=Egp7ccrTWXLLD49Rkn09ivY89FqenZH4IKDxCkMk8rgDgBHD0AOubbfN4Z2atAcmtR nTtgeHypmarmYeK1EblAsrQRYs2LOSN2eiHXkqz+/c00KMJd//1YSJvTsiOqq5o1J67V bRjntZ52SHkW1UOXAQY4acda0YuI/OgJ+nQum0KRtoRBBKQk+erFcr01z7rLcxpXriNu jLlI9vjJOmBklezvA0E2GOmLDJis/4f6QtcnJBRkFh90p6WwkiCa6cxKxsp1dZTo0nGC ZSmOsWRRkvBrQEkvfF5/kZt6652vH24nPB62X/D91cqTZzh9Zixp4lK44mUKmfjYxwUW MhfQ==
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=OvvAgJtMTYsET9j3NrBtGcBT+Y1biWRM30GShKrO7i8=; b=MlDe6/bgTG16zFYHm2Jje9khorssn0NfVupvJMbgK1rf3Ki8TxXR9ijT9/Qbm1ehFR INqQfyB1y3kvz8Agu5aJrVzbKLdI5o/ddxZcaErF1bgINm20oNyQVBHSmwqTCG4BTI8l SGRiiwk8Lo/1FaWez9nolct5cCWMG0YOplqnEEspAsrO9X2nMwTVVBUwdDg49X70thg5 BGPidLQ9iJJbmo3hHyYF/FLhmtpUHMm8REwIaKnkMvJzyIAGz6Zq8advdoYQcU8YauzN 97Rc2w4GMW5lAVdazfMy4vAG/QyudOMoppote0DarpgZrcZMPECf4Tn3xbIv0sLBnPT0 MWhw==
X-Gm-Message-State: ALoCoQn8qAy++B2M7Ll4jAUg3jtrW7qNrlmrVwvpB71wknlLCzv6GxyNtOJZITbPBR3W20ndfNNpkEPCN6vdedlh2cJZULF733tc5EzIwO0eVchmqhXTHoZX1xoiX8GULcig6haM+aPMTC6ofQJuiQxsHj4mQPlCto73DN+8UoCvUyK5NbTkFg9GyKe5aVjZHrS/JTD7bRbX
MIME-Version: 1.0
X-Received: by 10.42.62.196 with SMTP id z4mr6091488ich.49.1398888097028; Wed, 30 Apr 2014 13:01:37 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Wed, 30 Apr 2014 13:01:36 -0700 (PDT)
In-Reply-To: <CAC8QAccqYygAZrX=P1S7Av4KXtU82RWANv=BAaKjYm=hDH0hAA@mail.gmail.com>
References: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com> <CAC8QAccqYygAZrX=P1S7Av4KXtU82RWANv=BAaKjYm=hDH0hAA@mail.gmail.com>
Date: Wed, 30 Apr 2014 13:01:36 -0700
Message-ID: <CA+mtBx9YfBtizy+a1Wi+z5isYQ7AtLm_Hevx7U66U8HS8u_6LQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: sarikaya@ieee.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/tCF37shA2J2HUGMhAawb1EECZw0
Cc: "tofoo@ietf.org" <tofoo@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, mallik_mahalingam@yahoo.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: Wed, 30 Apr 2014 20:01:48 -0000

On Wed, Apr 30, 2014 at 12:46 PM, Behcet Sarikaya
<sarikaya2012@gmail.com> wrote:
> This is what VXLAN draft says:
>
> The UDP checksum field SHOULD be transmitted as zero.  When a packet
>    is received with a UDP checksum of zero, it MUST be accepted for
>    decapsulation.  Optionally, if the encapsulating endpoint includes a
>    non-zero UDP checksum, it MUST be correctly calculated across the
>    entire packet including the IP header, UDP header, VXLAN header and
>    encapsulated MAC frame.  When a decapsulating endpoint receives a
>    packet with a non-zero checksum it MAY choose to verify the checksum
>
> value.  If it chooses to perform such verification, and the
>    verification fails, the packet MUST be dropped.  If the
>    decapsulating destination chooses not to perform the verification,
>    or performs it successfully, the packet MUST be accepted for
>    decapsulation.
>
> What is wrong with it?
>
This makes the verification of (a non-zero) UDP checksum optional,
which as I pointed out seems contrary to established UDP standard. If
the verification isn't done then the MUST to drop packets with an
invalid checksum is moot. Also, there really should be no reason that
VXLAN needs to define a custom use of UDP checksum. The UDP checksum
is either computed across the UDP payload which should be clear in
VXLAN, or may be zero per using zero checksum in tunneling guidelines.
These should hold for all foo/UDP.

Tom

> Behcet
>
>
> On Wed, Apr 30, 2014 at 2: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
>
>