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

"Larry Kreeger (kreeger)" <kreeger@cisco.com> Thu, 01 May 2014 00:13 UTC

Return-Path: <kreeger@cisco.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 EE0D51A0A02; Wed, 30 Apr 2014 17:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 98TVa88P01Nc; Wed, 30 Apr 2014 17:13:16 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB891A0984; Wed, 30 Apr 2014 17:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2885; q=dns/txt; s=iport; t=1398903195; x=1400112795; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9jMcDv+9MQyCcGpvmDfL/Ti1h85xzEWHlIpfr+T28vM=; b=m6hF2lOvUDxS6+l7o5r212bDBvP/5cHrToYeZqpuTjVYs8nQ02byLDbh 1qHkJm+JvGuSBEKte+vTHe6fuof4u0p03kYd3999e+bjAELEX1jv395jp 6zF9aipVzxTav3wbPx4vtzMsuujzwyCG4p6TrtUWPu7/h/J1GTKuXYpml w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAOOQYVOtJA2B/2dsb2JhbABZgwZPV70Phz6BIRZ0giUBAQEEAQEBNzQbAgEIDgchECcLJQIEARKIQQ3JfReOWIQ5BIRYA5BYg3SBPJEvgzGBayQc
X-IronPort-AV: E=Sophos;i="4.97,961,1389744000"; d="scan'208";a="321614466"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 01 May 2014 00:13:14 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s410DEPU023128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 00:13:14 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 19:13:13 -0500
From: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
To: Tom Herbert <therbert@google.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "tofoo@ietf.org" <tofoo@ietf.org>, "mallik_mahalingam@yahoo.com" <mallik_mahalingam@yahoo.com>, "ddutt.ietf@hobbesdutt.com" <ddutt.ietf@hobbesdutt.com>
Thread-Topic: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums
Thread-Index: AQHPZKbjNYPI8b/6TUi7fhWXO3OBYJsquXGA
Date: Thu, 01 May 2014 00:13:13 +0000
Message-ID: <CF86DC33.F39B6%kreeger@cisco.com>
References: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com>
In-Reply-To: <CA+mtBx8+OyN5UUsL-sS1AuPF69p6=T3kw4Mq-BogjQhEF-Cpsw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [10.155.166.41]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32D635A284E12A4AB14FF7E9364698EA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/jvt2729j3ULAo4CdBH_XRr-Y0Vo
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 00:13:18 -0000

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?  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