From nobody Fri Apr 11 14:06:25 2014 Return-Path: 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 5CE9B1A022E for ; Fri, 11 Apr 2014 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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.272, SPF_PASS=-0.001] autolearn=no 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 AfGLveA6E2Pa for ; Fri, 11 Apr 2014 14:06:23 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53B1A01DF for ; Fri, 11 Apr 2014 14:06:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id as1so6015772iec.31 for ; Fri, 11 Apr 2014 14:06:21 -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 :content-type; bh=T4at5gCvE3nAuxdwfuWxaiQJaIoxGAJArr97S93+bpc=; b=cyfB2SE06bkxJZgV+B8jMf03B1dZl2UrwXppibR9nGNF8alQvKNX2aAv7auQdCFDVM g/j78ZoCj3a3g/kdLB8Anxgv5hSaufg4UTNCb7+gcwLAjCyjHOVEvhlW4i9gdjuT5Iyo HW1WY4hifKALMPOwvmyhReqJI18IXD8qWJk1kN9xNe8TRrL6xikGV9VHoWZr0DiDoN9M iwdX4o+vwt5VhJuCoJEdPCZKQ17aPlKxeFJNY51+pxO+tMFs6whz4Qr3jBzK7j4GbbtH LfuOh8nKkuXnGlgkj6i3VQNpQQ6jFO4R1lZYuukvkAPXOncdFSqUaasRyE7yuPRtkuZq +Muw== 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:content-type; bh=T4at5gCvE3nAuxdwfuWxaiQJaIoxGAJArr97S93+bpc=; b=lBy0JOp9EcPq2d569wj69nNnL5ZQScM1GX/nEbAHnJ6535teDqfk48DuLK4YfRPphR PbVHPrLNzpL2e0AkXAibvyIlP9BYp71OsPjtaZoUYn/VGdTDNXq2zL14GMq7JvR8uD8Y 2rynjNrYuwjylMTPejyQP8Z2iYAEX044u1b4PvSyhiV93z+Ov7x1cXqnUG2dt7qtIFwf hIqAUcS3jZtrtPCK1lynALsjer2fgi6rXsh0c/WKnVbYYxvpid37vVEiH/YL/NWu3V5d F/xIATUm3TFVGs2NwH/iD7mtXtZlw3jSM/w2VfEeYAZD5C0rzhk8/ZEjFckGT4Fg+hXP 5b4A== X-Gm-Message-State: ALoCoQnTJTCSn8aLr1i/L2GNAduglfVABmAApalReBAPN96QdsEX9Rx5cb3AI4rMXQ6MOGSP5w9m7VKPah6mQ8Q9k90oEZidivz9e+ibHJ/rrtDBpItBAVbtV1pAB+7vXjRrW1lKU/6J8SnlsBA9cj+l9uwRakqv28E7F9liXI6KPDAqL11gqkEMoPDb9TbkjaA1BKS8fknl MIME-Version: 1.0 X-Received: by 10.50.136.229 with SMTP id qd5mr6251024igb.48.1397250381594; Fri, 11 Apr 2014 14:06:21 -0700 (PDT) Received: by 10.64.148.98 with HTTP; Fri, 11 Apr 2014 14:06:21 -0700 (PDT) In-Reply-To: <20140304190242.14859.65050.idtracker@ietfa.amsl.com> References: <20140304190242.14859.65050.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 14:06:21 -0700 Message-ID: From: Tom Herbert To: tofoo@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/jGWfSzugXb71NnNfhB8zLHo2mQU Subject: [Tofoo] Fwd: New Version Notification for draft-herbert-gue-01.txt 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:06:24 -0000 Posting to brand new tofoo list for discussion! ---------- Forwarded message ---------- From: Date: Tue, Mar 4, 2014 at 11:02 AM Subject: New Version Notification for draft-herbert-gue-01.txt To: Tom Herbert A new version of I-D, draft-herbert-gue-01.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-gue Revision: 01 Title: Generic UDP Encapsulation Document date: 2014-03-05 Group: Individual Submission Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-herbert-gue-01.txt Status: https://datatracker.ietf.org/doc/draft-herbert-gue/ Htmlized: http://tools.ietf.org/html/draft-herbert-gue-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-herbert-gue-01 Abstract: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of arbitrary IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such tunnels and overlay networks, can be constructed. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Apr 11 16:53:04 2014 Return-Path: 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 1180D1A02B6 for ; Fri, 11 Apr 2014 16:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] 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 AyO9G3faIGRd for ; Fri, 11 Apr 2014 16:53:02 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0137D1A027D for ; Fri, 11 Apr 2014 16:53:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3BNqRGr009395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Apr 2014 16:52:27 -0700 (PDT) Message-ID: <5348803B.8050102@isi.edu> Date: Fri, 11 Apr 2014 16:52:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tofoo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/146U9umJd44VXPt3snCVqlFmFog Subject: [Tofoo] some existing drafts 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 23:53:03 -0000 Hi, all, There are at least two documents that might be useful to consider in this discussion: http://tools.ietf.org/html/draft-ietf-intarea-tunnels-01 This doc began in 2010 at the request of several ADs during meetings in the Philadelphia IETF, and remains an INTAREA WG item. Given recent interest, Mark and I are currently updating the doc. Input to this doc would be useful; this is intended to be the INTAREA's summary of IP tunnel practices. http://tools.ietf.org/html/draft-bonica-intarea-gre-mtu-04 which addresses the specific issue of MTU interactions There are certainly a lot of other existing documents to consider. Joe From nobody Tue Apr 15 12:00:25 2014 Return-Path: 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 DDF311A06A1 for ; Tue, 15 Apr 2014 12:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 fIAeWblGmu6H for ; Tue, 15 Apr 2014 12:00:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 499E91A0642 for ; Tue, 15 Apr 2014 12:00:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFR15899; Tue, 15 Apr 2014 19:00:14 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 19:58:54 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 20:00:13 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 12:00:02 -0700 From: Lucy yong To: "tofoo@ietf.org" Thread-Topic: use of UDP in tunneling foo over IP Thread-Index: AQHPWNznn0+ZMVBexkCjCPZIfOowrw== Date: Tue, 15 Apr 2014 19:00:02 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4536FDE0@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/kAkgP-ml10Nolo3p_8j2lQVHysY Subject: [Tofoo] use of UDP in tunneling foo over IP 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 19:00:23 -0000 SG9wZSB0byBzdGltdWxhdGUgc29tZSBkaXNjdXNzaW9ucy4NCg0KVGhlIGRlbWFuZCBmb3IgdXNp bmcgdHVubmVscyBpbiBkYXRhIGNlbnRlcnMgYW5kIGFjcm9zcyB0aGUgSW50ZXJuZXQgaXMgaW5j cmVhc2luZyBkdWUgdG8gbmV0d29yayB2aXJ0dWFsaXphdGlvbi4gVURQIGJhc2VkIHR1bm5lbCBt ZWNoYW5pc20gaXMgZGVzaXJhYmxlIGZvciBzdWNoIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gYXBw bGljYXRpb25zIGJlY2F1c2UgVURQIGhhcyB0aGUgZGVtdWx0aXBsZXggY2FwYWJpbGl0eSAobmVl ZCBhdCBlZ3Jlc3MpIGFuZCBwb3RlbnRpYWwgZmxvdyBlbnRyb3B5IGNhcGFiaWxpdHkgKHVzZWQg YnkgdW5kZXJsYXkgbmV0d29yaykuIFNvIHRoZSBhcHByb2FjaCBicmluZ3MgbGVhc3QgY29tbW9u IGRlbm9taW5hdG9yIGJldHdlZW4gTlYgb3ZlcmxheSBhbmQgdW5kZXJsYXkgbmV0d29ya3MsIHdo aWNoIG1lZXRzIHRoZSBrZXkgcmVxdWlyZW1lbnQgb2YgTlZPLCBpLmUuIGRlY291cGxlIG92ZXJs YXkgbmV0d29ya2luZyBhbmQgdW5kZXJsYXkgbmV0d29yay4NCg0KVGhlIGNvbnNlcXVlbmNlIG9m IHRoaXMgYXBwcm9hY2ggaXMgdGhhdCBOVk8gdHJhZmZpYyB3aWxsIGJlIHRyZWF0ZWQgYXMgVURQ IHRyYWZmaWMgaW4gdW5kZXJsYXkgSVAgbmV0d29ya3MuIEluIG90aGVyIHdvcmRzLCB0aGVzZSBO Vk8gYXBwbGljYXRpb25zIHdpbGwgYmUgdHJlYXRlZCBhcyBVRFAgYXBwbGljYXRpb25zIGluIHVu ZGVybGF5IElQIG5ldHdvcmsuIFJGQzUwNTQgaGFzIHNwZWNpZmllZCB0aGUgcnVsZXMgZm9yIGEg VURQIGFwcGxpY2F0aW9uIHRvIGZvbGxvdyBpbiBvcmRlciB0byBtYWtlIEludGVybmV0IHdvcmsg d2VsbC4gTm93IHRoZSBxdWVzdGlvbiBpcyBpZiB0aGVzZSBuZXcgVURQIHR1bm5lbCBtZXRob2Rz IGZvciBOViBzaG91bGQgZm9sbG93IHRoZSBleGFjdCBzYW1lIHJ1bGUgb3Igbm90Lg0KDQpZZXMs IGlmIHRoZSBVRFAgdHVubmVsIG92ZXIgSW50ZXJuZXQsIGl0IG5lZWRzIHRvIGZvbGxvdyB0aGUg cnVsZXMgc3BlY2lmaWVkIGluIFJGQzUwNTQ7IGJ1dCBpZiB0aGUgVURQIHR1bm5lbCBpcyB1c2Vk IHdpdGhpbiBkYXRhIGNlbnRlcnMgb3Igc2VydmljZSBwcm92aWRlciBuZXR3b3JrcywgdGhlIHJ1 bGVzIHNwZWNpZmllZCBpbiBSRkM1MDU0IG1heSBiZSBvdmVya2lsbC4gVGh1cywgaXQgaXMgbmVj ZXNzYXJ5IHRvIGRpZmZlcmVudGlhdGUgdGhlIHR3byBlbnZpcm9ubWVudHMgYW5kIGhhdmUgYSBw cm9wZXIgc2V0IG9mIHJ1bGVzIGZvciB0aGUgbGF0dGVyIGNhc2UuIA0KDQpTaW5jZSBSRkM1MDU0 IG9ubHkgc3BlY2lmaWVzIHRoZSBydWxlcywgcGVvcGxlIHdhbnQgYSBzb2x1dGlvbiBleGFtcGxl IGluIHRoZSB0dW5uZWwgbWVjaGFuaXNtIHdoZW4gYSBydWxlIGFwcGxpZXMuIEZvciBleGFtcGxl LCBjb25nZXN0aW9uIGNvbnRyb2wgc29sdXRpb24gZXhhbXBsZSB3aGVuIGl0IGlzIG5lY2Vzc2Fy eS4NCg0KT25lIGtleSBmZWF0dXJlIGluIE5WTyBpcyB0aGUgYWJpbGl0eSB0byBleHByZXNzIG92 ZXJsYXkgdHJhZmZpYyBmbG93IGVudHJvcHkgdG8gdW5kZXJsYXkgbmV0d29ya3MuIFVEUCB0dW5u ZWwgYWNoaWV2ZXMgdGhpcyB3aXRob3V0IGEgY2hhbmdlIGluIHVuZGVybGF5IG5ldHdvcmtzLCB3 aGljaCBpcyBncmVhdCBiZW5lZmljaWFsLiBIb3dldmVyIElQdjYgaGVhZGVyIGhhcyBhIGZsb3cg bGFiZWwgZmllbGQgZm9yIGhvc3QgdG8gZXhwcmVzcyBmbG93IGVudHJvcHkgYW5kIFJGQzY0Mzgg c3BlY2lmaWVzIGhvdyB0byB1c2UgaXQgaW4gSVB2NiBuZXR3b3Jrczsgc29tZSBmb28gb3ZlciBJ UCBjb3VsZCB1c2UgdGhlIGZsb3cgbGFiZWwgaWYgdW5kZXJsYXkgbmV0d29yayBpcyBJUHY2IGlu c3RlYWQgb2YgZm9vLWluLXVkcCBvdmVyIElQLCB3aGljaCB3aWxsIGJlIHNpbXBsZXIgdGhlIHJ1 bGVzIGJlY2F1c2UgSVB2NiBoYXMgc29tZSBkaWZmZXJlbnQgc2VtYW50aWNzIGFuZCBtZWNoYW5p c20gdGhhdCByZXN1bHQgaW4gZGlmZmVyZW50IHJ1bGVzIGZyb20gSVB2NCBzdWNoIGFzIGNoZWNr c3VtLiBHcmUtaW4tdWRwIGFuZCBtcGxzLWluLXVkcCBhcmUgdW5kZXIgdGhpcyBjYXRlZ29yeS4g SG93ZXZlciwgaWYgYW4gTlZPIGFwcGxpY2F0aW9uIGlzIGEgbmV3IG92ZXJsYXkgYXBwbGljYXRp b24gc3VjaCBhcyBMSVNQIGFuZCBWWExBTiBhbmQgbmVlZHMgdG8gZGlzdGluZ3Vpc2ggZnJvbSBo b3N0IGFwcGxpY2F0aW9ucywgaXQgc3RpbGwgbmVlZHMgVURQIHR1bm5lbCBpbiBJUHY2IHVuZGVy bGF5IG5ldHdvcmsuIFRodXMsIHRyYW5zcG9ydCBhcmVhIHBlb3BsZSBsaWtlIHRvIHNlZSBhIHNv bHV0aW9uIGV4YW1wbGUgdG8gbWVldCB0aGUgcnVsZXMgaW4gYm90aCBJUHY0IGFuZCBJUHY2IHVu ZGVybGF5IG5ldHdvcmsuDQoNCg0KUmVnYXJkcywNCkx1Y3kgICAgIA0KICANCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYtQW5ub3VuY2UgW21haWx0bzppZXRmLWFubm91 bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVRGIFNlY3JldGFyaWF0DQpTZW50 OiBUaHVyc2RheSwgQXByaWwgMTAsIDIwMTQgMTI6MDQgUE0NClRvOiBJRVRGIEFubm91bmNlbWVu dCBMaXN0DQpDYzogbWxzLmlldGZAZ21haWwuY29tOyB0b2Zvb0BpZXRmLm9yZw0KU3ViamVjdDog TmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IFRvZm9vIC0tIERpc2N1c3Npb24gbGlzdCBmb3IgVHVu bmVsaW5nIG92ZXIgRm9vICh3aXRoKWluIElQIG5ldHdvcmtzIChUT0ZPTykNCg0KQSBuZXcgSUVU RiBub24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuDQoNCkxpc3Qg YWRkcmVzczogdG9mb29AaWV0Zi5vcmcNCkFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi90b2Zvby8NClRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90b2Zvbw0KDQpQdXJwb3NlOiANCg0KVHVubmVsaW5nIGRhdGEgYWNy b3NzIElQLWJhc2VkIG5ldHdvcmtzIGNhbiB1c2UgYSB2YXJpZXR5IG9mIGV4aXN0aW5nIGVuY2Fw c3VsYXRpb24gc2NoZW1lcywgc3VjaCBhcywgR1JFIFtSRkMyNzg0XSwgSVAtaW4tSVAgW1JGQzIw MDNdIGFuZCBJUHNlYyB0dW5uZWxzIFtSRkM0MzAxXSBvciBwcm9wb3NlZCBlbmNhcHN1bGF0aW9u IHNjaGVtZXMgdGhhdCBhcmUgYmFzZWQgb24gY2FycnlpbmcgdHJhZmZpYyBvdmVyIFVEUC4gDQpU aGUgZGVtYW5kIGZvciB1c2luZyB0dW5uZWxzIGluIGRhdGEgY2VudGVycyBhbmQgYWNyb3NzIHRo ZSBJbnRlcm5ldCBpcyBpbmNyZWFzaW5nIGFsc28gZHVlIHRvIG5ldHdvcmsgdmlydHVhbGl6YXRp b24uIA0KQSBudW1iZXIgb2Yga25vd24gaXNzdWVzIGhhdmUgYmVlbiByYWlzZWQgYXJvdW5kIHVz aW5nIHR1bm5lbHMsIGRpc2N1c3Npb25zIGFib3V0IGFwcGxpY2FiaWxpdHkgb2YgdGhlc2UgaXNz dWVzIGFyZSBvbmdvaW5nIGFuZCBhIG51bWJlciBvZiBzb2x1dGlvbnMgdG8gY29wZSB3aXRoLCBm b3IgaW5zdGFuY2UsIGNvbmdlc3Rpb24gY29udHJvbCBvciBjb25nZXN0aW9uIGNvbnRyb2wgc2Vu c2l0aXZpdHksIGFyZSBiZWluZyBkaXNjdXNzZWQuIA0KVGhlIGludGVudGlvbiBvZiB0aGlzIGxp c3QgaXMgdG8gYnJpbmcgdG9nZXRoZXIgdHVubmVsIHByb3RvY29sIGRlc2lnbmVycy9pbXBsZW1l bnRlcnMsIG5ldHdvcmsgb3BlcmF0b3JzLCBhbmQgdGhlIGRpZmZlcmVudCBhcmVhcyBpbiB0aGUg SUVURiB0byBkaXNjdXNzIHRoZSB3YXlzIGZvcndhcmQuDQoNCkZvciBhZGRpdGlvbmFsIGluZm9y bWF0aW9uLCBwbGVhc2UgY29udGFjdCB0aGUgbGlzdCBhZG1pbmlzdHJhdG9ycy4NCg0K From nobody Tue Apr 15 14:57:19 2014 Return-Path: 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 951341A07A2 for ; Tue, 15 Apr 2014 14:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 WaRgRAy2xpHR for ; Tue, 15 Apr 2014 14:57:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2561A0783 for ; Tue, 15 Apr 2014 14:57:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDD40939; Tue, 15 Apr 2014 21:57:07 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 22:55:33 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 22:57:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 14:56:55 -0700 From: Lucy yong To: Lucy yong , "tofoo@ietf.org" Thread-Topic: use of UDP in tunneling foo over IP Thread-Index: AQHPVN7tn0+ZMVBexkCjCPZIfOowr5sS7cJwgABUooA= Date: Tue, 15 Apr 2014 21:56:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4536FEEC@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.152.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/Kg5ecbW7tFSKoal6-IS0A8uPnFk Subject: Re: [Tofoo] use of UDP in tunneling foo over IP 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:57:17 -0000 T25lIGNvcnJlY3Rpb24gb24gcHJldmlvdXMgbWFpbC4gSXQgc2hvdWxkIGJlIFJGQzU0MDUgKG5v dCA1MDU0KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTHVjeSB5b25nIA0K U2VudDogVHVlc2RheSwgQXByaWwgMTUsIDIwMTQgMjowNCBQTQ0KVG86ICd0b2Zvb0BpZXRmLm9y ZycNClN1YmplY3Q6IHVzZSBvZiBVRFAgaW4gdHVubmVsaW5nIGZvbyBvdmVyIElQDQoNCkhvcGUg dG8gc3RpbXVsYXRlIHNvbWUgZGlzY3Vzc2lvbnMuDQoNClRoZSBkZW1hbmQgZm9yIHVzaW5nIHR1 bm5lbHMgaW4gZGF0YSBjZW50ZXJzIGFuZCBhY3Jvc3MgdGhlIEludGVybmV0IGlzIGluY3JlYXNp bmcgZHVlIHRvIG5ldHdvcmsgdmlydHVhbGl6YXRpb24uIFVEUCBiYXNlZCB0dW5uZWwgbWVjaGFu aXNtIGlzIGRlc2lyYWJsZSBmb3Igc3VjaCBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIGFwcGxpY2F0 aW9ucyBiZWNhdXNlIFVEUCBoYXMgdGhlIGRlbXVsdGlwbGV4IGNhcGFiaWxpdHkgKG5lZWQgYXQg ZWdyZXNzKSBhbmQgcG90ZW50aWFsIGZsb3cgZW50cm9weSBjYXBhYmlsaXR5ICh1c2VkIGJ5IHVu ZGVybGF5IG5ldHdvcmspLiBTbyB0aGUgYXBwcm9hY2ggYnJpbmdzIGxlYXN0IGNvbW1vbiBkZW5v bWluYXRvciBiZXR3ZWVuIE5WIG92ZXJsYXkgYW5kIHVuZGVybGF5IG5ldHdvcmtzLCB3aGljaCBt ZWV0cyB0aGUga2V5IHJlcXVpcmVtZW50IG9mIE5WTywgaS5lLiBkZWNvdXBsZSBvdmVybGF5IG5l dHdvcmtpbmcgYW5kIHVuZGVybGF5IG5ldHdvcmsuDQoNClRoZSBjb25zZXF1ZW5jZSBvZiB0aGlz IGFwcHJvYWNoIGlzIHRoYXQgTlZPIHRyYWZmaWMgd2lsbCBiZSB0cmVhdGVkIGFzIFVEUCB0cmFm ZmljIGluIHVuZGVybGF5IElQIG5ldHdvcmtzLiBJbiBvdGhlciB3b3JkcywgdGhlc2UgTlZPIGFw cGxpY2F0aW9ucyB3aWxsIGJlIHRyZWF0ZWQgYXMgVURQIGFwcGxpY2F0aW9ucyBpbiB1bmRlcmxh eSBJUCBuZXR3b3JrLiBSRkM1MDU0IGhhcyBzcGVjaWZpZWQgdGhlIHJ1bGVzIGZvciBhIFVEUCBh cHBsaWNhdGlvbiB0byBmb2xsb3cgaW4gb3JkZXIgdG8gbWFrZSBJbnRlcm5ldCB3b3JrIHdlbGwu IE5vdyB0aGUgcXVlc3Rpb24gaXMgaWYgdGhlc2UgbmV3IFVEUCB0dW5uZWwgbWV0aG9kcyBmb3Ig TlYgc2hvdWxkIGZvbGxvdyB0aGUgZXhhY3Qgc2FtZSBydWxlIG9yIG5vdC4NCg0KWWVzLCBpZiB0 aGUgVURQIHR1bm5lbCBvdmVyIEludGVybmV0LCBpdCBuZWVkcyB0byBmb2xsb3cgdGhlIHJ1bGVz IHNwZWNpZmllZCBpbiBSRkM1MDU0OyBidXQgaWYgdGhlIFVEUCB0dW5uZWwgaXMgdXNlZCB3aXRo aW4gZGF0YSBjZW50ZXJzIG9yIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MsIHRoZSBydWxlcyBz cGVjaWZpZWQgaW4gUkZDNTA1NCBtYXkgYmUgb3ZlcmtpbGwuIFRodXMsIGl0IGlzIG5lY2Vzc2Fy eSB0byBkaWZmZXJlbnRpYXRlIHRoZSB0d28gZW52aXJvbm1lbnRzIGFuZCBoYXZlIGEgcHJvcGVy IHNldCBvZiBydWxlcyBmb3IgdGhlIGxhdHRlciBjYXNlLiANCg0KU2luY2UgUkZDNTA1NCBvbmx5 IHNwZWNpZmllcyB0aGUgcnVsZXMsIHBlb3BsZSB3YW50IGEgc29sdXRpb24gZXhhbXBsZSBpbiB0 aGUgdHVubmVsIG1lY2hhbmlzbSB3aGVuIGEgcnVsZSBhcHBsaWVzLiBGb3IgZXhhbXBsZSwgY29u Z2VzdGlvbiBjb250cm9sIHNvbHV0aW9uIGV4YW1wbGUgd2hlbiBpdCBpcyBuZWNlc3NhcnkuDQoN Ck9uZSBrZXkgZmVhdHVyZSBpbiBOVk8gaXMgdGhlIGFiaWxpdHkgdG8gZXhwcmVzcyBvdmVybGF5 IHRyYWZmaWMgZmxvdyBlbnRyb3B5IHRvIHVuZGVybGF5IG5ldHdvcmtzLiBVRFAgdHVubmVsIGFj aGlldmVzIHRoaXMgd2l0aG91dCBhIGNoYW5nZSBpbiB1bmRlcmxheSBuZXR3b3Jrcywgd2hpY2gg aXMgZ3JlYXQgYmVuZWZpY2lhbC4gSG93ZXZlciBJUHY2IGhlYWRlciBoYXMgYSBmbG93IGxhYmVs IGZpZWxkIGZvciBob3N0IHRvIGV4cHJlc3MgZmxvdyBlbnRyb3B5IGFuZCBSRkM2NDM4IHNwZWNp ZmllcyBob3cgdG8gdXNlIGl0IGluIElQdjYgbmV0d29ya3M7IHNvbWUgZm9vIG92ZXIgSVAgY291 bGQgdXNlIHRoZSBmbG93IGxhYmVsIGlmIHVuZGVybGF5IG5ldHdvcmsgaXMgSVB2NiBpbnN0ZWFk IG9mIGZvby1pbi11ZHAgb3ZlciBJUCwgd2hpY2ggd2lsbCBiZSBzaW1wbGVyIHRoZSBydWxlcyBi ZWNhdXNlIElQdjYgaGFzIHNvbWUgZGlmZmVyZW50IHNlbWFudGljcyBhbmQgbWVjaGFuaXNtIHRo YXQgcmVzdWx0IGluIGRpZmZlcmVudCBydWxlcyBmcm9tIElQdjQgc3VjaCBhcyBjaGVja3N1bS4g R3JlLWluLXVkcCBhbmQgbXBscy1pbi11ZHAgYXJlIHVuZGVyIHRoaXMgY2F0ZWdvcnkuIEhvd2V2 ZXIsIGlmIGFuIE5WTyBhcHBsaWNhdGlvbiBpcyBhIG5ldyBvdmVybGF5IGFwcGxpY2F0aW9uIHN1 Y2ggYXMgTElTUCBhbmQgVlhMQU4gYW5kIG5lZWRzIHRvIGRpc3Rpbmd1aXNoIGZyb20gaG9zdCBh cHBsaWNhdGlvbnMsIGl0IHN0aWxsIG5lZWRzIFVEUCB0dW5uZWwgaW4gSVB2NiB1bmRlcmxheSBu ZXR3b3JrLiBUaHVzLCB0cmFuc3BvcnQgYXJlYSBwZW9wbGUgbGlrZSB0byBzZWUgYSBzb2x1dGlv biBleGFtcGxlIHRvIG1lZXQgdGhlIHJ1bGVzIGluIGJvdGggSVB2NCBhbmQgSVB2NiB1bmRlcmxh eSBuZXR3b3JrLg0KDQoNClJlZ2FyZHMsDQpMdWN5ICAgICANCiAgDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KU2VudDogVGh1 cnNkYXksIEFwcmlsIDEwLCAyMDE0IDEyOjA0IFBNDQpUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlz dA0KQ2M6IG1scy5pZXRmQGdtYWlsLmNvbTsgdG9mb29AaWV0Zi5vcmcNClN1YmplY3Q6IE5ldyBO b24tV0cgTWFpbGluZyBMaXN0OiBUb2ZvbyAtLSBEaXNjdXNzaW9uIGxpc3QgZm9yIFR1bm5lbGlu ZyBvdmVyIEZvbyAod2l0aClpbiBJUCBuZXR3b3JrcyAoVE9GT08pDQoNCkEgbmV3IElFVEYgbm9u LXdvcmtpbmcgZ3JvdXAgZW1haWwgbGlzdCBoYXMgYmVlbiBjcmVhdGVkLg0KDQpMaXN0IGFkZHJl c3M6IHRvZm9vQGlldGYub3JnDQpBcmNoaXZlOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvdG9mb28vDQpUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdG9mb28NCg0KUHVycG9zZTogDQoNClR1bm5lbGluZyBkYXRhIGFjcm9zcyBJ UC1iYXNlZCBuZXR3b3JrcyBjYW4gdXNlIGEgdmFyaWV0eSBvZiBleGlzdGluZyBlbmNhcHN1bGF0 aW9uIHNjaGVtZXMsIHN1Y2ggYXMsIEdSRSBbUkZDMjc4NF0sIElQLWluLUlQIFtSRkMyMDAzXSBh bmQgSVBzZWMgdHVubmVscyBbUkZDNDMwMV0gb3IgcHJvcG9zZWQgZW5jYXBzdWxhdGlvbiBzY2hl bWVzIHRoYXQgYXJlIGJhc2VkIG9uIGNhcnJ5aW5nIHRyYWZmaWMgb3ZlciBVRFAuIA0KVGhlIGRl bWFuZCBmb3IgdXNpbmcgdHVubmVscyBpbiBkYXRhIGNlbnRlcnMgYW5kIGFjcm9zcyB0aGUgSW50 ZXJuZXQgaXMgaW5jcmVhc2luZyBhbHNvIGR1ZSB0byBuZXR3b3JrIHZpcnR1YWxpemF0aW9uLiAN CkEgbnVtYmVyIG9mIGtub3duIGlzc3VlcyBoYXZlIGJlZW4gcmFpc2VkIGFyb3VuZCB1c2luZyB0 dW5uZWxzLCBkaXNjdXNzaW9ucyBhYm91dCBhcHBsaWNhYmlsaXR5IG9mIHRoZXNlIGlzc3VlcyBh cmUgb25nb2luZyBhbmQgYSBudW1iZXIgb2Ygc29sdXRpb25zIHRvIGNvcGUgd2l0aCwgZm9yIGlu c3RhbmNlLCBjb25nZXN0aW9uIGNvbnRyb2wgb3IgY29uZ2VzdGlvbiBjb250cm9sIHNlbnNpdGl2 aXR5LCBhcmUgYmVpbmcgZGlzY3Vzc2VkLiANClRoZSBpbnRlbnRpb24gb2YgdGhpcyBsaXN0IGlz IHRvIGJyaW5nIHRvZ2V0aGVyIHR1bm5lbCBwcm90b2NvbCBkZXNpZ25lcnMvaW1wbGVtZW50ZXJz LCBuZXR3b3JrIG9wZXJhdG9ycywgYW5kIHRoZSBkaWZmZXJlbnQgYXJlYXMgaW4gdGhlIElFVEYg dG8gZGlzY3VzcyB0aGUgd2F5cyBmb3J3YXJkLg0KDQpGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlv biwgcGxlYXNlIGNvbnRhY3QgdGhlIGxpc3QgYWRtaW5pc3RyYXRvcnMuDQoNCg== From nobody Tue Apr 15 16:15:38 2014 Return-Path: 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 DF7D01A0076 for ; Tue, 15 Apr 2014 16:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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.272, SPF_PASS=-0.001] autolearn=no 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 p08Y2O2iCGsS for ; Tue, 15 Apr 2014 16:15:33 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEC1A0073 for ; Tue, 15 Apr 2014 16:15:32 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id to1so9919179ieb.0 for ; Tue, 15 Apr 2014 16:15:29 -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:content-transfer-encoding; bh=DTA0nvK8mfhpcIhLOhQbgBSv49WjcUvoOx/5vJsjakE=; b=DhllkJO15szrIzyqn+6ajxTamloeKCUq/g2EsRhG+yHMIwIBtCYQesLtKHgxE5uPhb TUwNf/wtFJDDPQW0rHlbp5qCUZkx/ikU9hp9OPxQgCw8bNupWtHrqvQLJQRwQRe5BYgJ KEczCC6PjQs7i91Ukwdi6wLWgtJ6YkPA3168cVArYk3p9L9LZAT7cC/9MYAa2ALO+SjK SNcn+xohneFuTlCc0Dgo8N/KUTK+bwAtGj3lyCUPZARXQyReue07h9F1Vyv/2odgMBmU LPmkm0EvmSuGrD+j4gheufbZ9lqQ/490K81QGPPofN+s61qLg7OPS0JnruAPQVE9veDg DwzA== 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 :content-transfer-encoding; bh=DTA0nvK8mfhpcIhLOhQbgBSv49WjcUvoOx/5vJsjakE=; b=l6ZqkipY9856TpZ7lgTan5d89jrKOUkGwWtkGFd0dcNCzuLWAWbCBe8NfpY2YL95RS aoeVqSJBrCaOimB11RBRIOzQQEaqnM2HosmqTI5UlkEesPQFX5Jn501DRcB0g+nhDdfa 34/suYK+J1gK54I3mp86KPSfA2Ds/5i2Ml9X2AMk/mlxLoPI8FzeKfgovpd9XHVXQTxy j1if8BD8kbB8QaGcxsJXRxbJ/pRsWa0EnOrxOxojtMZSjWFtx8xSTYNSS7pztROOdz6Y xZFSWoT2SdWp1prrVRQYA7Hq8hAWv5ptRNOxUeItSiqFenD0bpQiXzx8QtU7W8PAbQRN bkuQ== X-Gm-Message-State: ALoCoQkiSeJwzz+8yLuh7xYQ9G6HzjrZ8wjnjdGiF3FvK0tfUQituMk/pCIO6ijIHk+XG+1JUuxzbtBSaViAeWBFo6S1rMBIdNcLrdvlpzib8txLc2OSAXl8zIHNAZym4o9hs2ieUYlLT8ykmu/QFYeGL/Agfwd/YZVyYRlE7Jrq3Dp85CZjLx3DfIX0u8i/VE3WQyFYgCYK MIME-Version: 1.0 X-Received: by 10.50.25.67 with SMTP id a3mr6523668igg.28.1397603729103; Tue, 15 Apr 2014 16:15:29 -0700 (PDT) Received: by 10.64.148.98 with HTTP; Tue, 15 Apr 2014 16:15:29 -0700 (PDT) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4536FDE0@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4536FDE0@dfweml701-chm.china.huawei.com> Date: Tue, 15 Apr 2014 16:15:29 -0700 Message-ID: From: Tom Herbert To: Lucy yong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/wSEtXx7VgTx2bqg_aibV_pjEj3A Cc: "tofoo@ietf.org" Subject: Re: [Tofoo] use of UDP in tunneling foo over IP 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 23:15:35 -0000 Hi Lucy, Response in line... On Tue, Apr 15, 2014 at 12:00 PM, Lucy yong wrote: > Hope to stimulate some discussions. > > The demand for using tunnels in data centers and across the Internet is i= ncreasing due to network virtualization. UDP based tunnel mechanism is desi= rable for such network virtualization applications because UDP has the demu= ltiplex capability (need at egress) and potential flow entropy capability (= used by underlay network). So the approach brings least common denominator = between NV overlay and underlay networks, which meets the key requirement o= f NVO, i.e. decouple overlay networking and underlay network. > > The consequence of this approach is that NVO traffic will be treated as U= DP traffic in underlay IP networks. In other words, these NVO applications = will be treated as UDP applications in underlay IP network. RFC5054 has spe= cified the rules for a UDP application to follow in order to make Internet = work well. Now the question is if these new UDP tunnel methods for NV shoul= d follow the exact same rule or not. > > Yes, if the UDP tunnel over Internet, it needs to follow the rules specif= ied in RFC5054; but if the UDP tunnel is used within data centers or servic= e provider networks, the rules specified in RFC5054 may be overkill. Thus, = it is necessary to differentiate the two environments and have a proper set= of rules for the latter case. > I think the relevant question is can we define standard "data center" protocols which have different properties and optimizations than "Internet" protocols. There might be some justification for latitude here (in my opinion the requirement that all encapsulation protocols need to inter-operate with NAT is awfully restrictive), but as a prerequisite I think you would need a clear definition of "use within a data center" or a "data center protocol". For instance, if packets are going over private links between two sites can they still be considered to be within a data center? Also, would this imply that data center networks must meet certain requirements to be candidates for using a data center protocol? Would a low error rate be required such that things to make UDP checksum unnecessary as a standard? To what extent can we assume security of the protocol provided by the DC network? Is in order delivery guaranteed so we don't have to worry about OOO? Can the upper protocol layers be trusted to do congestion control correctly (in case of NV answer is clearly no to that)? Requirements to use L2 or L3? Thanks, Tom > Since RFC5054 only specifies the rules, people want a solution example in= the tunnel mechanism when a rule applies. For example, congestion control = solution example when it is necessary. > > One key feature in NVO is the ability to express overlay traffic flow ent= ropy to underlay networks. UDP tunnel achieves this without a change in und= erlay networks, which is great beneficial. However IPv6 header has a flow l= abel field for host to express flow entropy and RFC6438 specifies how to us= e it in IPv6 networks; some foo over IP could use the flow label if underla= y network is IPv6 instead of foo-in-udp over IP, which will be simpler the = rules because IPv6 has some different semantics and mechanism that result i= n different rules from IPv4 such as checksum. Gre-in-udp and mpls-in-udp ar= e under this category. However, if an NVO application is a new overlay appl= ication such as LISP and VXLAN and needs to distinguish from host applicati= ons, it still needs UDP tunnel in IPv6 underlay network. Thus, transport ar= ea people like to see a solution example to meet the rules in both IPv4 and= IPv6 underlay network. > > > Regards, > Lucy > > > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of = IETF Secretariat > Sent: Thursday, April 10, 2014 12:04 PM > To: IETF Announcement List > Cc: mls.ietf@gmail.com; tofoo@ietf.org > Subject: New Non-WG Mailing List: Tofoo -- Discussion list for Tunneling = over Foo (with)in IP networks (TOFOO) > > A new IETF non-working group email list has been created. > > List address: tofoo@ietf.org > Archive: http://www.ietf.org/mail-archive/web/tofoo/ > To subscribe: https://www.ietf.org/mailman/listinfo/tofoo > > Purpose: > > Tunneling data across IP-based networks can use a variety of existing enc= apsulation schemes, such as, GRE [RFC2784], IP-in-IP [RFC2003] and IPsec tu= nnels [RFC4301] or proposed encapsulation schemes that are based on carryin= g traffic over UDP. > The demand for using tunnels in data centers and across the Internet is i= ncreasing also due to network virtualization. > A number of known issues have been raised around using tunnels, discussio= ns about applicability of these issues are ongoing and a number of solution= s to cope with, for instance, congestion control or congestion control sens= itivity, are being discussed. > The intention of this list is to bring together tunnel protocol designers= /implementers, network operators, and the different areas in the IETF to di= scuss the ways forward. > > For additional information, please contact the list administrators. > > _______________________________________________ > Tofoo mailing list > Tofoo@ietf.org > https://www.ietf.org/mailman/listinfo/tofoo From nobody Wed Apr 16 07:44:10 2014 Return-Path: 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 EE67F1A01CF for ; Wed, 16 Apr 2014 07:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 G9fd5hdLlFot for ; Wed, 16 Apr 2014 07:44:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 712B31A0132 for ; Wed, 16 Apr 2014 07:43:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFS12657; Wed, 16 Apr 2014 14:43:55 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 15:42:18 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Apr 2014 15:43:54 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml703-chm.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0158.001; Wed, 16 Apr 2014 07:43:47 -0700 From: Lucy yong To: Tom Herbert Thread-Topic: [Tofoo] use of UDP in tunneling foo over IP Thread-Index: AQHPWNznn0+ZMVBexkCjCPZIfOowr5sTxM2AgACE6BA= Date: Wed, 16 Apr 2014 14:43:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4537107B@dfweml701-chm.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D4536FDE0@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/jLpDXZ_dhiA_BA7I7lfwtdUt3-o Cc: "tofoo@ietf.org" Subject: Re: [Tofoo] use of UDP in tunneling foo over IP 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:44:06 -0000 SGkgVG9tLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBiZWxvdy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dGhlcmJlcnRAZ29vZ2xlLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNSwgMjAxNCA2OjE1IFBNDQpUbzogTHVjeSB5b25nDQpD YzogdG9mb29AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVG9mb29dIHVzZSBvZiBVRFAgaW4gdHVu bmVsaW5nIGZvbyBvdmVyIElQDQoNCkhpIEx1Y3ksDQoNClJlc3BvbnNlIGluIGxpbmUuLi4NCg0K T24gVHVlLCBBcHIgMTUsIDIwMTQgYXQgMTI6MDAgUE0sIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1 YXdlaS5jb20+IHdyb3RlOg0KPiBIb3BlIHRvIHN0aW11bGF0ZSBzb21lIGRpc2N1c3Npb25zLg0K Pg0KPiBUaGUgZGVtYW5kIGZvciB1c2luZyB0dW5uZWxzIGluIGRhdGEgY2VudGVycyBhbmQgYWNy b3NzIHRoZSBJbnRlcm5ldCBpcyBpbmNyZWFzaW5nIGR1ZSB0byBuZXR3b3JrIHZpcnR1YWxpemF0 aW9uLiBVRFAgYmFzZWQgdHVubmVsIG1lY2hhbmlzbSBpcyBkZXNpcmFibGUgZm9yIHN1Y2ggbmV0 d29yayB2aXJ0dWFsaXphdGlvbiBhcHBsaWNhdGlvbnMgYmVjYXVzZSBVRFAgaGFzIHRoZSBkZW11 bHRpcGxleCBjYXBhYmlsaXR5IChuZWVkIGF0IGVncmVzcykgYW5kIHBvdGVudGlhbCBmbG93IGVu dHJvcHkgY2FwYWJpbGl0eSAodXNlZCBieSB1bmRlcmxheSBuZXR3b3JrKS4gU28gdGhlIGFwcHJv YWNoIGJyaW5ncyBsZWFzdCBjb21tb24gZGVub21pbmF0b3IgYmV0d2VlbiBOViBvdmVybGF5IGFu ZCB1bmRlcmxheSBuZXR3b3Jrcywgd2hpY2ggbWVldHMgdGhlIGtleSByZXF1aXJlbWVudCBvZiBO Vk8sIGkuZS4gZGVjb3VwbGUgb3ZlcmxheSBuZXR3b3JraW5nIGFuZCB1bmRlcmxheSBuZXR3b3Jr Lg0KPg0KPiBUaGUgY29uc2VxdWVuY2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IE5WTyB0cmFm ZmljIHdpbGwgYmUgdHJlYXRlZCBhcyBVRFAgdHJhZmZpYyBpbiB1bmRlcmxheSBJUCBuZXR3b3Jr cy4gSW4gb3RoZXIgd29yZHMsIHRoZXNlIE5WTyBhcHBsaWNhdGlvbnMgd2lsbCBiZSB0cmVhdGVk IGFzIFVEUCBhcHBsaWNhdGlvbnMgaW4gdW5kZXJsYXkgSVAgbmV0d29yay4gUkZDNTA1NCBoYXMg c3BlY2lmaWVkIHRoZSBydWxlcyBmb3IgYSBVRFAgYXBwbGljYXRpb24gdG8gZm9sbG93IGluIG9y ZGVyIHRvIG1ha2UgSW50ZXJuZXQgd29yayB3ZWxsLiBOb3cgdGhlIHF1ZXN0aW9uIGlzIGlmIHRo ZXNlIG5ldyBVRFAgdHVubmVsIG1ldGhvZHMgZm9yIE5WIHNob3VsZCBmb2xsb3cgdGhlIGV4YWN0 IHNhbWUgcnVsZSBvciBub3QuDQo+DQo+IFllcywgaWYgdGhlIFVEUCB0dW5uZWwgb3ZlciBJbnRl cm5ldCwgaXQgbmVlZHMgdG8gZm9sbG93IHRoZSBydWxlcyBzcGVjaWZpZWQgaW4gUkZDNTA1NDsg YnV0IGlmIHRoZSBVRFAgdHVubmVsIGlzIHVzZWQgd2l0aGluIGRhdGEgY2VudGVycyBvciBzZXJ2 aWNlIHByb3ZpZGVyIG5ldHdvcmtzLCB0aGUgcnVsZXMgc3BlY2lmaWVkIGluIFJGQzUwNTQgbWF5 IGJlIG92ZXJraWxsLiBUaHVzLCBpdCBpcyBuZWNlc3NhcnkgdG8gZGlmZmVyZW50aWF0ZSB0aGUg dHdvIGVudmlyb25tZW50cyBhbmQgaGF2ZSBhIHByb3BlciBzZXQgb2YgcnVsZXMgZm9yIHRoZSBs YXR0ZXIgY2FzZS4NCj4NCkkgdGhpbmsgdGhlIHJlbGV2YW50IHF1ZXN0aW9uIGlzIGNhbiB3ZSBk ZWZpbmUgc3RhbmRhcmQgImRhdGEgY2VudGVyIg0KcHJvdG9jb2xzIHdoaWNoIGhhdmUgZGlmZmVy ZW50IHByb3BlcnRpZXMgYW5kIG9wdGltaXphdGlvbnMgdGhhbiAiSW50ZXJuZXQiIHByb3RvY29s cy4gDQpbTHVjeV0gVGhpcyBpcyBhIGdvb2Qgd2F5IHRvIHB1dC4gQSBiaXQgY2hhbmdlIGlzOiAi ZGF0YSBjZW50ZXIiIC0+ICJkYXRhIGNlbnRlcnMgYW5kIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29y a3MiLg0KIFRoZXJlIG1pZ2h0IGJlIHNvbWUganVzdGlmaWNhdGlvbiBmb3IgbGF0aXR1ZGUgaGVy ZSAoaW4gbXkgb3BpbmlvbiB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhbGwgZW5jYXBzdWxhdGlvbiBw cm90b2NvbHMgbmVlZCB0byBpbnRlci1vcGVyYXRlIHdpdGggTkFUIGlzIGF3ZnVsbHkgcmVzdHJp Y3RpdmUpLCBidXQgYXMgYSBwcmVyZXF1aXNpdGUgSSB0aGluayB5b3Ugd291bGQgbmVlZCBhIGNs ZWFyIGRlZmluaXRpb24gb2YgInVzZSB3aXRoaW4gYSBkYXRhIGNlbnRlciIgb3IgYSAiZGF0YSBj ZW50ZXIgcHJvdG9jb2wiLg0KW0x1Y3ldIEFncmVlLiBOZWVkIHRoZSByaWdodCB0ZXJtcyBoZXJl Lg0KIEZvciBpbnN0YW5jZSwgaWYgcGFja2V0cyBhcmUgZ29pbmcgb3ZlciBwcml2YXRlIGxpbmtz IGJldHdlZW4gdHdvIHNpdGVzIGNhbiB0aGV5IHN0aWxsIGJlIGNvbnNpZGVyZWQgdG8gYmUgd2l0 aGluIGEgZGF0YSBjZW50ZXI/IEFsc28sIHdvdWxkIHRoaXMgaW1wbHkgdGhhdCBkYXRhIGNlbnRl ciBuZXR3b3JrcyBtdXN0IG1lZXQgY2VydGFpbiByZXF1aXJlbWVudHMgdG8gYmUgY2FuZGlkYXRl cyBmb3IgdXNpbmcgYSBkYXRhIGNlbnRlciBwcm90b2NvbD8gV291bGQgYSBsb3cgZXJyb3IgcmF0 ZSBiZSByZXF1aXJlZCBzdWNoIHRoYXQgdGhpbmdzIHRvIG1ha2UgVURQIGNoZWNrc3VtIHVubmVj ZXNzYXJ5IGFzIGEgc3RhbmRhcmQ/IFRvIHdoYXQgZXh0ZW50IGNhbiB3ZSBhc3N1bWUgc2VjdXJp dHkgb2YgdGhlIHByb3RvY29sIHByb3ZpZGVkIGJ5IHRoZSBEQyBuZXR3b3JrPyBJcyBpbiBvcmRl ciBkZWxpdmVyeSBndWFyYW50ZWVkIHNvIHdlIGRvbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgT09P PyBDYW4gdGhlIHVwcGVyIHByb3RvY29sIGxheWVycyBiZSB0cnVzdGVkIHRvIGRvIGNvbmdlc3Rp b24gY29udHJvbCBjb3JyZWN0bHkgKGluIGNhc2Ugb2YgTlYgYW5zd2VyIGlzIGNsZWFybHkgbm8g dG8gdGhhdCk/DQpSZXF1aXJlbWVudHMgdG8gdXNlIEwyIG9yIEwzPw0KW0x1Y3ldIHlvdSByYWlz ZSBhIGxvdCBvZiBnb29kIHF1ZXN0aW9ucyB0aGF0IG5lZWQgdG8gYmUgY29uc2lkZXJlZCBhbmQg YWRkcmVzc2VkIGluIE5WTyB0ZWNobm9sb2d5LiBFYWNoIHNvbHV0aW9uIGhhcyBwcm9zIGFuZCBj b25zLiBUaGUgbWF0dGVyIGlzIHdoaWNoIGhhcyB0aGUgYmV0dGVyIG9wdGltaXphdGlvbiBmb3Ig Y3VycmVudCByZWFsaXR5IGFuZCBwb3RlbnRpYWwgY2FwYWJpbGl0eSB0byBldm9sdmUuIA0KDQpU aGFua3MsDQpMdWN5DQoNClRoYW5rcywNClRvbQ0KDQo+IFNpbmNlIFJGQzUwNTQgb25seSBzcGVj aWZpZXMgdGhlIHJ1bGVzLCBwZW9wbGUgd2FudCBhIHNvbHV0aW9uIGV4YW1wbGUgaW4gdGhlIHR1 bm5lbCBtZWNoYW5pc20gd2hlbiBhIHJ1bGUgYXBwbGllcy4gRm9yIGV4YW1wbGUsIGNvbmdlc3Rp b24gY29udHJvbCBzb2x1dGlvbiBleGFtcGxlIHdoZW4gaXQgaXMgbmVjZXNzYXJ5Lg0KPg0KPiBP bmUga2V5IGZlYXR1cmUgaW4gTlZPIGlzIHRoZSBhYmlsaXR5IHRvIGV4cHJlc3Mgb3ZlcmxheSB0 cmFmZmljIGZsb3cgZW50cm9weSB0byB1bmRlcmxheSBuZXR3b3Jrcy4gVURQIHR1bm5lbCBhY2hp ZXZlcyB0aGlzIHdpdGhvdXQgYSBjaGFuZ2UgaW4gdW5kZXJsYXkgbmV0d29ya3MsIHdoaWNoIGlz IGdyZWF0IGJlbmVmaWNpYWwuIEhvd2V2ZXIgSVB2NiBoZWFkZXIgaGFzIGEgZmxvdyBsYWJlbCBm aWVsZCBmb3IgaG9zdCB0byBleHByZXNzIGZsb3cgZW50cm9weSBhbmQgUkZDNjQzOCBzcGVjaWZp ZXMgaG93IHRvIHVzZSBpdCBpbiBJUHY2IG5ldHdvcmtzOyBzb21lIGZvbyBvdmVyIElQIGNvdWxk IHVzZSB0aGUgZmxvdyBsYWJlbCBpZiB1bmRlcmxheSBuZXR3b3JrIGlzIElQdjYgaW5zdGVhZCBv ZiBmb28taW4tdWRwIG92ZXIgSVAsIHdoaWNoIHdpbGwgYmUgc2ltcGxlciB0aGUgcnVsZXMgYmVj YXVzZSBJUHY2IGhhcyBzb21lIGRpZmZlcmVudCBzZW1hbnRpY3MgYW5kIG1lY2hhbmlzbSB0aGF0 IHJlc3VsdCBpbiBkaWZmZXJlbnQgcnVsZXMgZnJvbSBJUHY0IHN1Y2ggYXMgY2hlY2tzdW0uIEdy ZS1pbi11ZHAgYW5kIG1wbHMtaW4tdWRwIGFyZSB1bmRlciB0aGlzIGNhdGVnb3J5LiBIb3dldmVy LCBpZiBhbiBOVk8gYXBwbGljYXRpb24gaXMgYSBuZXcgb3ZlcmxheSBhcHBsaWNhdGlvbiBzdWNo IGFzIExJU1AgYW5kIFZYTEFOIGFuZCBuZWVkcyB0byBkaXN0aW5ndWlzaCBmcm9tIGhvc3QgYXBw bGljYXRpb25zLCBpdCBzdGlsbCBuZWVkcyBVRFAgdHVubmVsIGluIElQdjYgdW5kZXJsYXkgbmV0 d29yay4gVGh1cywgdHJhbnNwb3J0IGFyZWEgcGVvcGxlIGxpa2UgdG8gc2VlIGEgc29sdXRpb24g ZXhhbXBsZSB0byBtZWV0IHRoZSBydWxlcyBpbiBib3RoIElQdjQgYW5kIElQdjYgdW5kZXJsYXkg bmV0d29yay4NCj4NCj4NCj4gUmVnYXJkcywNCj4gTHVjeQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJRVRGLUFubm91bmNlIFttYWlsdG86aWV0Zi1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+IE9mIElFVEYgU2VjcmV0YXJpYXQNCj4g U2VudDogVGh1cnNkYXksIEFwcmlsIDEwLCAyMDE0IDEyOjA0IFBNDQo+IFRvOiBJRVRGIEFubm91 bmNlbWVudCBMaXN0DQo+IENjOiBtbHMuaWV0ZkBnbWFpbC5jb207IHRvZm9vQGlldGYub3JnDQo+ IFN1YmplY3Q6IE5ldyBOb24tV0cgTWFpbGluZyBMaXN0OiBUb2ZvbyAtLSBEaXNjdXNzaW9uIGxp c3QgZm9yIA0KPiBUdW5uZWxpbmcgb3ZlciBGb28gKHdpdGgpaW4gSVAgbmV0d29ya3MgKFRPRk9P KQ0KPg0KPiBBIG5ldyBJRVRGIG5vbi13b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4g Y3JlYXRlZC4NCj4NCj4gTGlzdCBhZGRyZXNzOiB0b2Zvb0BpZXRmLm9yZw0KPiBBcmNoaXZlOiBo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdG9mb28vDQo+IFRvIHN1YnNjcmli ZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90b2Zvbw0KPg0KPiBQdXJw b3NlOg0KPg0KPiBUdW5uZWxpbmcgZGF0YSBhY3Jvc3MgSVAtYmFzZWQgbmV0d29ya3MgY2FuIHVz ZSBhIHZhcmlldHkgb2YgZXhpc3RpbmcgZW5jYXBzdWxhdGlvbiBzY2hlbWVzLCBzdWNoIGFzLCBH UkUgW1JGQzI3ODRdLCBJUC1pbi1JUCBbUkZDMjAwM10gYW5kIElQc2VjIHR1bm5lbHMgW1JGQzQz MDFdIG9yIHByb3Bvc2VkIGVuY2Fwc3VsYXRpb24gc2NoZW1lcyB0aGF0IGFyZSBiYXNlZCBvbiBj YXJyeWluZyB0cmFmZmljIG92ZXIgVURQLg0KPiBUaGUgZGVtYW5kIGZvciB1c2luZyB0dW5uZWxz IGluIGRhdGEgY2VudGVycyBhbmQgYWNyb3NzIHRoZSBJbnRlcm5ldCBpcyBpbmNyZWFzaW5nIGFs c28gZHVlIHRvIG5ldHdvcmsgdmlydHVhbGl6YXRpb24uDQo+IEEgbnVtYmVyIG9mIGtub3duIGlz c3VlcyBoYXZlIGJlZW4gcmFpc2VkIGFyb3VuZCB1c2luZyB0dW5uZWxzLCBkaXNjdXNzaW9ucyBh Ym91dCBhcHBsaWNhYmlsaXR5IG9mIHRoZXNlIGlzc3VlcyBhcmUgb25nb2luZyBhbmQgYSBudW1i ZXIgb2Ygc29sdXRpb25zIHRvIGNvcGUgd2l0aCwgZm9yIGluc3RhbmNlLCBjb25nZXN0aW9uIGNv bnRyb2wgb3IgY29uZ2VzdGlvbiBjb250cm9sIHNlbnNpdGl2aXR5LCBhcmUgYmVpbmcgZGlzY3Vz c2VkLg0KPiBUaGUgaW50ZW50aW9uIG9mIHRoaXMgbGlzdCBpcyB0byBicmluZyB0b2dldGhlciB0 dW5uZWwgcHJvdG9jb2wgZGVzaWduZXJzL2ltcGxlbWVudGVycywgbmV0d29yayBvcGVyYXRvcnMs IGFuZCB0aGUgZGlmZmVyZW50IGFyZWFzIGluIHRoZSBJRVRGIHRvIGRpc2N1c3MgdGhlIHdheXMg Zm9yd2FyZC4NCj4NCj4gRm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250YWN0 IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBUb2ZvbyBtYWlsaW5nIGxpc3QNCj4gVG9mb29AaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90b2Zvbw0K From nobody Wed Apr 30 12:02:32 2014 Return-Path: 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 A3B811A8891 for ; Wed, 30 Apr 2014 12:02:30 -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=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 u5bRe9-OWHaB for ; Wed, 30 Apr 2014 12:02:24 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id EE82E1A8882 for ; Wed, 30 Apr 2014 12:01:53 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id h3so2277895igd.10 for ; Wed, 30 Apr 2014 12:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HNzHEgPtX+QvKxclLSbjfzhLKbx6Xb6eH4QrSBwW6S0=; b=Gb2yuBWb5wxfr6s7+qj65PUIUIq6Debo8rbQPA+vEXrauMz7K/EUouSZJyVpBZ2a4f cx4oJ0qJ0XoZkjsF/mejDkqmbYkrJqU9mU6IswxdpTlCv4ig+z5GN+KLXYVzO8JvT8s7 HueL3vHayXU4dXZp/Hcc5qYJJeReFVNXqHtae/M1x/5wum736QOMyTTBaODwHiN5rMwy q0sgkacvTtPp3zQXTG7JQdSr6xCB+qF0sMUFuOKBgE+qUUQcd70gua1jVObyR7mgsrW6 92p775x8iYMQn0J0PpgLAaXj0vFPsvES/274dMiBMsjjXXwu3BIoF5xBwoY5qC6A3mpk 46xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=HNzHEgPtX+QvKxclLSbjfzhLKbx6Xb6eH4QrSBwW6S0=; b=IkDXmpMT1fPHG7FteI5/Z3/fWojOuauFGSZlvWbGXB0LQKDoyug+IES4Alv0lniSaz aSMGZrfK2Tlg8mcm042RLkwYvA2NkbhYAU4POJbYz9bZcpoyNiZEuThQRcctKI0JN/0g 1MgtEZbh1lOOJPQBdKBvDXAqW93L7CYu3uFCLCCs9BJn8Ix+mbNd0NuQTLMxm52IKwPM sSPZUdm+zrdNpC4Q/uEWJB59ZlUgDZ/F5hxo2Dn1fsONgrXDjAZBiAuM3PXDMgdkqvDg GYGUwxHoLiWmySqT+5sV4hwHyuzq2+zhxw04KzunEYclbtl/z9SRyL7Rne7x/MRcIB7t 5/7Q== X-Gm-Message-State: ALoCoQnyPvPGE7xjovKCEXRPHP/FCUsAmBLrJ1EjgjG0jU22n94OHK0eUOjzyg76/T6FRjssR5x4Z2dBQqPBOUZRPuPVCAtu8RiGiPPqyPia39LPWUCJESMUWhdeEvLm6yqCBl3dPNYI0rdyGhLMj+Ujh1Uy5R30qh3VTBfw3HOzx6F182JqOXVdPyyjvIPWNlJuyFrC65Es MIME-Version: 1.0 X-Received: by 10.43.151.7 with SMTP id kq7mr3846051icc.78.1398884512154; Wed, 30 Apr 2014 12:01:52 -0700 (PDT) Received: by 10.64.148.98 with HTTP; Wed, 30 Apr 2014 12:01:52 -0700 (PDT) Date: Wed, 30 Apr 2014 12:01:52 -0700 Message-ID: From: Tom Herbert To: "nvo3@ietf.org" , "tofoo@ietf.org" , mallik_mahalingam@yahoo.com, ddutt.ietf@hobbesdutt.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/qoYGVp-hPdhg9cXdwe4HugwvIrs Subject: [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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:02:30 -0000 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 From nobody Wed Apr 30 12:15:59 2014 Return-Path: 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 20D251A0956; Wed, 30 Apr 2014 12:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B1Gn1RvBvyRM; Wed, 30 Apr 2014 12:15:53 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3A1A094A; Wed, 30 Apr 2014 12:15:53 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 2E2092B454D; Wed, 30 Apr 2014 20:15:51 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 648442B43B3; Wed, 30 Apr 2014 20:15:49 +0100 (BST) Message-ID: <53614BE5.2040203@erg.abdn.ac.uk> Date: Wed, 30 Apr 2014 20:15:49 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tom Herbert , "nvo3@ietf.org" , "tofoo@ietf.org" , mallik_mahalingam@yahoo.com, ddutt.ietf@hobbesdutt.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/kckc2AH-hejKxnLiKNtwL4p-kUg Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums X-BeenThere: tofoo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:15:56 -0000 This idea of simply ignoring the checksum value was dicussed and rejected in the analysis described in rfc6936. Appendix A2.6 describes the reasons why this was not recommended. Gorry On 30/04/2014 20:01, Tom Herbert 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 > From nobody Wed Apr 30 12:46:55 2014 Return-Path: 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 7553A1A099B; Wed, 30 Apr 2014 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 GmVcEdXJFp_F; Wed, 30 Apr 2014 12:46:50 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 584A21A097C; Wed, 30 Apr 2014 12:46:50 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr17so1614198lab.31 for ; Wed, 30 Apr 2014 12:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m8xM+daoLLmDandhwEroLzGZH43/Kc+u3Hoj1SFJRPA=; b=ebMC0wQwopDLq1A0OlcwossTdvqJHBPRFFfL5a/2UXI6sMiwpJqP+B3vHd+wKGjY86 ntpUFzA6EyX6N0pJzTkltKDVT1/4qJ/WgAyoWPLVA7P6ZH0t1LaNcT/5UL8JO+0AwGjL q2EHnCbO4n9VwDdaruiCFQU3++fqvXNZXOEX7WV98H1L0qEspQE3Uc7laOBRjRkLL/CC BVrauAPembQ3DI7GYXRcE7w1tFQ7bcA6YEzh2xPXqTdXAlFQN/EtDCFGfs+xhzacz0nM HlfS0rWdl3uyEBfQqXGeE/Mm2YguWS7hBCd1aD6QGpEZV4boqzxny368U7aONU61iKRj 3rCA== MIME-Version: 1.0 X-Received: by 10.152.121.72 with SMTP id li8mr2488810lab.45.1398887208075; Wed, 30 Apr 2014 12:46:48 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 30 Apr 2014 12:46:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 14:46:48 -0500 Message-ID: From: Behcet Sarikaya To: Tom Herbert Content-Type: multipart/alternative; boundary=089e01176b3b1e48fa04f847cf77 Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/7yEWrwlCGWQhglmCpN5FkO65hjo Cc: "tofoo@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 Reply-To: sarikaya@ieee.org List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:46:52 -0000 --089e01176b3b1e48fa04f847cf77 Content-Type: text/plain; charset=UTF-8 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? Behcet On Wed, Apr 30, 2014 at 2:01 PM, Tom Herbert 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 > --089e01176b3b1e48fa04f847cf77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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?

Behcet
=


On Wed, Apr 3= 0, 2014 at 2:01 PM, Tom Herbert <therbert@google.com> wrot= e:
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-d= cops-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,<= br> 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<= br> 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
h= ttps://www.ietf.org/mailman/listinfo/tofoo

--089e01176b3b1e48fa04f847cf77-- From nobody Wed Apr 30 13:01:51 2014 Return-Path: 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 ; 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 ; 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 ; Wed, 30 Apr 2014 13:01:46 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so2494463iec.10 for ; 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: References: Date: Wed, 30 Apr 2014 13:01:36 -0700 Message-ID: From: Tom Herbert 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" , "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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:01:48 -0000 On Wed, Apr 30, 2014 at 12:46 PM, Behcet Sarikaya 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 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 > > From nobody Wed Apr 30 14:23:50 2014 Return-Path: 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 614681A09BC; Wed, 30 Apr 2014 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 69MImUSR5w6o; Wed, 30 Apr 2014 14:23:37 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8B76A1A08B5; Wed, 30 Apr 2014 14:23:30 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id l4so1655341lbv.4 for ; Wed, 30 Apr 2014 14:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3I4TlrbYQsMbxjTroZmrdiobgKhqP0A9ixYUgVfOang=; b=Q37fC1W2vDWxwZ9mDOz35v8C+/MR350w1eqlFJBcZcgJnIv8Xuy5ao0E6CTmUKeRPM Us3MxNGNVau7jtzumCJPp59Qg97UrDg0ICBARC/KWlCv29cQTfA6wHpa64JvWGApOxUK vvOw8dHcTsROUOqP7mSZdrgVQR+q/vxKYaq2KeDqn0FgzqWcdDY/z9HBUqd2nmndkaWr mYRXu3/HAKS9+DMa6M2Q4xbqKMr2R+VcPBEI3Z92X3z1U3Z/RxunJqgiyVSZYz//I2cM oYxOZLRghIGpu9vqmDidv9VJZuYOdN6miqPps/E6f1UUC+jBfsFSijBuDVH2chnWVHyV KRzg== MIME-Version: 1.0 X-Received: by 10.112.164.98 with SMTP id yp2mr4254792lbb.29.1398893008244; Wed, 30 Apr 2014 14:23:28 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Wed, 30 Apr 2014 14:23:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 16:23:28 -0500 Message-ID: From: Behcet Sarikaya To: Tom Herbert Content-Type: multipart/alternative; boundary=001a11c33c6ed5dd2704f849289d Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/SQKnICIx1-l4DCmyTxBJ227xWEc Cc: "tofoo@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 Reply-To: sarikaya@ieee.org List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 21:23:39 -0000 --001a11c33c6ed5dd2704f849289d Content-Type: text/plain; charset=UTF-8 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? Behcet On Wed, Apr 30, 2014 at 3:01 PM, Tom Herbert wrote: > On Wed, Apr 30, 2014 at 12:46 PM, Behcet Sarikaya > 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 > 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 > > > > > --001a11c33c6ed5dd2704f849289d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is what VXLAN says on tunneled traffic:

<= pre class=3D"">Tunneled traffic over the IP network can be secured with tra= ditional 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?

Behcet


On Wed, Apr 30, 2014 at 3:01 PM, Tom = Herbert <therbert@google.com> wrote:
On Wed, Apr 30, 2014 at 12:4= 6 PM, Behcet Sarikaya
<sarikaya2012@gmail.com>= ; wrote:
> This is what VXLAN draft says:
>
> The UDP checksum field SHOULD be transmitted as zero. =C2=A0When a pac= ket
> =C2=A0 =C2=A0is received with a UDP checksum of zero, it MUST be accep= ted for
> =C2=A0 =C2=A0decapsulation. =C2=A0Optionally, if the encapsulating end= point includes a
> =C2=A0 =C2=A0non-zero UDP checksum, it MUST be correctly calculated ac= ross the
> =C2=A0 =C2=A0entire packet including the IP header, UDP header, VXLAN = header and
> =C2=A0 =C2=A0encapsulated MAC frame. =C2=A0When a decapsulating endpoi= nt receives a
> =C2=A0 =C2=A0packet with a non-zero checksum it MAY choose to verify t= he checksum
>
> value. =C2=A0If it chooses to perform such verification, and the
> =C2=A0 =C2=A0verification fails, the packet MUST be dropped. =C2=A0If = the
> =C2=A0 =C2=A0decapsulating destination chooses not to perform the veri= fication,
> =C2=A0 =C2=A0or performs it successfully, the packet MUST be accepted = for
> =C2=A0 =C2=A0decapsulation.
>
> 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 potenti= ally
>> ignore a non-zero invalid UDP checksum.
>>
>> From: http://tools.ietf.org/html/draft-mahaling= am-dutt-dcops-vxlan-09
>>
>> "When a decapsulating endpoint receives a packet with a non-z= ero
>> checksum it MAY choose to verify the checksum"
>>
>> However, from RFC 1122:
>>
>> "If a UDP datagram is received with a checksum that is non-ze= ro and
>> invalid, UDP MUST silently discard the datagram."
>>
>> It doesn't seem like 1122 allows checksum verification to be o= ptional,
>> 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 t= hat, 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 b= ad
>> 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 a= ssociated
>> packet processing burden at the L2TP endpoints."
>>
>> This is somewhat ambiguous, but seems like the correct interpretat= ion
>> 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 clarif= y
>> the requirement for UDP tunnel protocols and checksums?
>>
>> Thanks,
>> Tom
>>
>> _______________________________________________
>> Tofoo mailing list
>> Tofoo@ietf.org
>> https://www.ietf.org/mailman/listinfo/tofoo
>
>

--001a11c33c6ed5dd2704f849289d-- From nobody Wed Apr 30 17:13:20 2014 Return-Path: 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)" To: Tom Herbert , "nvo3@ietf.org" , "tofoo@ietf.org" , "mallik_mahalingam@yahoo.com" , "ddutt.ietf@hobbesdutt.com" Thread-Topic: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums Thread-Index: AQHPZKbjNYPI8b/6TUi7fhWXO3OBYJsquXGA Date: Thu, 1 May 2014 00:13:13 +0000 Message-ID: References: In-Reply-To: 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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 From nobody Wed Apr 30 18:48:18 2014 Return-Path: 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 ; 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 ; 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 ; Wed, 30 Apr 2014 18:48:15 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so2745740igq.4 for ; 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: References: Date: Wed, 30 Apr 2014 18:48:13 -0700 Message-ID: From: Tom Herbert To: "Larry Kreeger (kreeger)" Content-Type: multipart/alternative; boundary=bcaec5186f0aadb28304f84cdbde Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/QQNO7S7PZmldV-Y_D1d0KUY9MIQ Cc: "tofoo@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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:48:18 -0000 --bcaec5186f0aadb28304f84cdbde Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger) 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" 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 > > --bcaec5186f0aadb28304f84cdbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



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 th= e
VXLAN draft is a good thing. =C2=A0First, it is my assumption that some
implementations (e.g. many hardware implementations), will not implement checksum generation, nor checksum validation. =C2=A0I believe this is an implementation reality. =C2=A0If implementations are required to check a non-zero checksum, but can't actually do it, what alternatives do they<= br> have?

Barring that the implementations you&= #39;re referring to only implement IPv6, these implementations must be alre= ady be doing checksum validation for IPv4 header-- so the checksum logic mu= st 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 imp= lementation would be nice here, for instance in the case that the stack dec= apsulates the checksum can always be done in SW if verification is not prov= ided by the device.

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

Thanks,
Tom

=C2=A0
One is to drop all packets with a non-ze= ro checksum (because one
might be invalid and even one invalid one slipping through would be
unacceptable). =C2=A0Another alternative is to accept all checksum values. = =C2=A0The
second option greatly enhances interoperability with implementations that choose to generate a checksum and implementations that cannot validate the<= br> checksum. =C2=A0It allows a mixed environment where "better" impl= ementations
(that can validate) can interoperate with "inferior" implementati= ons that
are unable to validate the checksum.
=C2=A0
=C2=A0
BTW, VXLAN is not the only tunneling protocol to specify this behavior.
LISP (RFC 6830), specifies exactly the same behavior.=C2=A0
=C2=A0- 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<= br> >ignore a non-zero invalid UDP checksum.
>
>From: http://tools.ietf.org/html/draft-mahalingam-du= tt-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 an= d
>invalid, UDP MUST silently discard the datagram."
>
>It doesn't seem like 1122 allows checksum verification to be option= al,
>so these would seem to be a conflict. Presumably, ignoring the RX csum<= br> >is included for performance but since the sender can already send zero<= br> >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 associ= ated
>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


--bcaec5186f0aadb28304f84cdbde-- From nobody Wed Apr 30 18:54:40 2014 Return-Path: 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 4DF071A09B2; Wed, 30 Apr 2014 18:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Bc9qLovHTusk; Wed, 30 Apr 2014 18:54:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B91A09C1; Wed, 30 Apr 2014 18:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14045; q=dns/txt; s=iport; t=1398909274; x=1400118874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=scw1Ksa+LHqHrHtYkK+XP3nbgnu7oRJLBIuB6DkTdis=; b=ldDR73jW9G8VbUAUFSAGzRrCISHXg7plJDlZw21/ZYFcWkETI6jDKWbL EGITCmnnB3wq485+gkhpPeU/7EqntTrXGwvhlmZjUMy8yBmiJCRFIilEL doOaR3otV3pev6pEqOfnVddfzukyvTdsgv584MKpSqd9UpyrWBYkAgeLa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFANSoYVOtJA2L/2dsb2JhbABZgkJET1ese45WgUIBhz2BIBZ0giUBAQEEAQEBZAcLEAIBCA4DAwECKAcnCxMBCQgCBA4FiC0DEQ3JdheMOoIGDQQHhDkEhFgDApBWggmBa4E8i1WFWoMxgWskHA X-IronPort-AV: E=Sophos;i="4.97,962,1389744000"; d="scan'208,217";a="321425443" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 01 May 2014 01:54:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s411sXv5032758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 May 2014 01:54:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 20:54:33 -0500 From: "Larry Kreeger (kreeger)" To: Tom Herbert Thread-Topic: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums Thread-Index: AQHPZKbjNYPI8b/6TUi7fhWXO3OBYJsquXGAgACP5oD//4xngA== Date: Thu, 1 May 2014 01:54:32 +0000 Message-ID: References: In-Reply-To: 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: multipart/alternative; boundary="_000_CF86F645F3CBBkreegerciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/33UUnkUjwSk5WF7984yUSBjEQxk Cc: "tofoo@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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:54:38 -0000 --_000_CF86F645F3CBBkreegerciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See inline, marked with LK>. - Larry From: Tom Herbert > Date: Wednesday, April 30, 2014 6:48 PM To: Larry Kreeger > Cc: "nvo3@ietf.org" >, "tofoo@ietf.org" >, "mallik_mahalingam@yahoo.com" >, Dines= h Dutt > Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums On Wed, Apr 30, 2014 at 5:13 PM, Larry Kreeger (kreeger) > 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, t= hese 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 meri= t. A specific example implementation would be nice here, for instance in th= e case that the stack decapsulates the checksum can always be done in SW if= verification is not provided by the device. LK> I am referring to switching ASIC implementations. There is no software= nor traditional UDP stack involved. Also, as I pointed out, the UDP checksum is *not* useless in VXLAN. In an L= 3 routed network there is nothing that protects the vni from corruption exp= ect possibly the UDP checksum. Without any additional security mechanisms i= s VXLAN header (like a cookie), the only way I could deploy VXLAN is with c= hecksums enabled. So in my opinion, the draft should be encouraging use of = UDP checksums instead of discouraging them. LK> Neither I nor the VXLAN draft claims that UDP checksums are useless, ho= wever I think it is an exaggeration to say "nothing" protects the VNI from = corruption when the packet is being carried over Ethernet with a robust CRC= 32 protecting it. 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" > 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 --_000_CF86F645F3CBBkreegerciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
See inline, marked with LK>. - Larry

From: Tom Herbert <therbert@google.com>
Date: Wednesday, April 30, 2014 6:4= 8 PM
To: Larry Kreeger <kreeger@cisco.com>
Cc: "nvo3@ietf.org" <nvo3@i= etf.org>, "tofoo@ietf.org= " <tofoo@ietf.org>, "= mallik_mahalingam@yahoo.com<= /a>" <mallik_mahalingam@yahoo= .com>, Dinesh Dutt <= ddutt.ietf@hobbesdutt.com>
Subject: Re: [Tofoo] VXLAN (UDP tun= nel 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 IP= v6, 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 implement= ation would be nice here, for instance in the case that the stack decapsula= tes the checksum can always be done in SW if verification is not provided b= y the device.

LK> I am referring to switching ASIC implementations.  There i= s no software nor traditional UDP stack involved.

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 corruptio= n expect possibly the UDP checksum. Without any additional security mechani= sms is VXLAN header (like a cookie), the only way I could deploy VXLAN is with checksums enabled. So in my opin= ion, the draft should be encouraging use of UDP checksums instead of discou= raging them.

LK> Neither I nor the VXLAN draft claims that UDP checksums are use= less, however I think it is an exaggeration to say "nothing" prot= ects the VNI from corruption when the packet is being carried over Ethernet= with a robust CRC32 protecting it.

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<= br> checksum.  It allows a mixed environment where "better" impl= ementations
(that can validate) can interoperate with "inferior" implementati= ons 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<= br> >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 an= d
>invalid, UDP MUST silently discard the datagram."
>
>It doesn't seem like 1122 allows checksum verification to be optional,<= br> >so these would seem to be a conflict. Presumably, ignoring the RX csum<= br> >is included for performance but since the sender can already send zero<= br> >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<= br> >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 associ= ated
>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


 --_000_CF86F645F3CBBkreegerciscocom_-- From nobody Wed Apr 30 20:14:41 2014 Return-Path: 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 883181A085A for ; Wed, 30 Apr 2014 20:14:33 -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 H69N1thV66ry for ; Wed, 30 Apr 2014 20:14:29 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF21A0839 for ; Wed, 30 Apr 2014 20:14:28 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so3012766iec.9 for ; Wed, 30 Apr 2014 20:14:26 -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=NXNOp+3mYb5Ed2P07Mtgp8UUZZiBNYHCPDX3arqUUKM=; b=GsjyVrqB0ynE9wm1xix22ktYhKhT9e3LC2N/1/dH07tmX0EtXp+n99oE5RiokYgIIi Hv4OsEOOpb2N7b2574D6Pc9gKtYjWzupI7F0JO8oz/3y50m3YZOigbDHJ5qOkkDHbQCN EKA9ZVqhAojE/vCkgQ2N91nhq4SxuQi3VEdogFVfoZVqlBwibXAXTgtiV+M3Da1qZOJY NBqGOg5rjg5RoiQGatwSeyB6s5DHBxKskj3SwMei4zKDF2X+IR91rlYkDqkCpzbIzrTv aev/9OJhEL0HzNvcjPVnXs2xxpx5gDkfvlvzsj3jRlVjiYylqG5MoaRHk7q5qA6yqNnR PXDw== 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=NXNOp+3mYb5Ed2P07Mtgp8UUZZiBNYHCPDX3arqUUKM=; b=d/j46oDBKLVzFmyNPiHUSHTvfoFhc2N1FXf8uZT0Bxcki4raERbzWnwS9DWFby06e2 bLMqeXfRPe595gac3s40YtE+Xx9v1POgPaKpf1673QylnFgIwW7aWGDisyM0tjz9e9SM /0YgFQCI/n6d0XZFhBG/WzVvvFG5Fq6C394JYmSFkUjlyt8hju/uhyW0JkPKr+8tPJTb OkhQ0O3Ndw8swHlEgRHTpJLtvKCuiHL1BKYDr/hV/WVvRzsG0uwDkjTt/3CMUrqRcI4m j7Du2uPDYNXMihTL/xsyMPnIBzS3dD9MpqY/bqWsZWYcu+AvxaJ9UwkBfXi9z/+o5eXZ qqjQ== X-Gm-Message-State: ALoCoQmFZsDs/8RHjld470upYIpX4O/nVUuCNH+cbUzVVMrmTJPTxNumnSJVFOARbNjR+BVj0aGG MIME-Version: 1.0 X-Received: by 10.50.109.130 with SMTP id hs2mr209969igb.29.1398914066806; Wed, 30 Apr 2014 20:14:26 -0700 (PDT) Received: by 10.64.148.98 with HTTP; Wed, 30 Apr 2014 20:14:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 20:14:26 -0700 Message-ID: From: Tom Herbert To: "Larry Kreeger (kreeger)" Content-Type: multipart/alternative; boundary=089e0111bc9a06139004f84e10c5 Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/AP6m4S3brwxLnY3TMJb3RrMmOjk Cc: "tofoo@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\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 03:14:33 -0000 --089e0111bc9a06139004f84e10c5 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 6:54 PM, Larry Kreeger (kreeger) wrote: > See inline, marked with LK>. - Larry > > From: Tom Herbert > Date: Wednesday, April 30, 2014 6:48 PM > To: Larry Kreeger > Cc: "nvo3@ietf.org" , "tofoo@ietf.org" , " > mallik_mahalingam@yahoo.com" , Dinesh Dutt < > ddutt.ietf@hobbesdutt.com> > Subject: Re: [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. > > LK> I am referring to switching ASIC implementations. There is no > software nor traditional UDP stack involved. > > Are these implementations also ignoring IPv4 header checksum then? > 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. > > LK> Neither I nor the VXLAN draft claims that UDP checksums are useless, > however I think it is an exaggeration to say "nothing" protects the VNI > from corruption when the packet is being carried over Ethernet with a > robust CRC32 protecting it. > > Assuming we are using Ethernet (I don't believe this can be a requirement either) this only provides hop to hop protection, not end to end. I don't have a completely error free network and checksum errors while low, are non-zero. Sending a packet to the wrong VM is fundamentally bad and could be quite costly, so for me UDP checksums would be the minimum requirement. This would need to apply to the case where the protocol is switched also. In any case, the requirements and constraints for when it's acceptable to ignore non-zero checksums for UDP should be specified in a more general way if is being allowed. Maybe an addendum to RFC 6935? Tom 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" 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 >> >> > --089e0111bc9a06139004f84e10c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 30, 2014 at 6:54 PM, Larry Kreeger (kreeger) <kreeger= @cisco.com> wrote:
See inline, marked with LK>. - Larry

From: Tom Herbert <therbert@google.com>
Date: Wednesday, April 30, 2014 6:4= 8 PM
To: Larry Kreeger <kreeger@cisco.com>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "tofoo@ietf.org" <tofoo@ietf.org>, "mallik_mahali= ngam@yahoo.com" <malli= k_mahalingam@yahoo.com>, Dinesh Dutt <ddutt.ietf@hobbesdutt.com>
Subject: Re: [Tofoo] VXLAN (UDP tun= nel 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 th= e
VXLAN draft is a good thing. =C2=A0First, it is my assumption that some
implementations (e.g. many hardware implementations), will not implement checksum generation, nor checksum validation. =C2=A0I believe this is an implementation reality. =C2=A0If implementations are required to check a non-zero checksum, but can't actually do it, what alternatives do they<= br> have?

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

LK> I am referring to switching ASIC implementations. =C2=A0There i= s no software nor traditional UDP stack involved.

Are these implementations also ignoring IPv4 header checksum then?
=C2=A0
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 corruptio= n expect possibly the UDP checksum. Without any additional security mechani= sms is VXLAN header (like a cookie), the only way I could deploy VXLAN is with checksums enabled. So in my opin= ion, the draft should be encouraging use of UDP checksums instead of discou= raging them.

LK> Neither I nor the VXLAN draft claims that UDP checksums a= re useless, however I think it is an exaggeration to say "nothing"= ; protects the VNI from corruption when the packet is being carried over Et= hernet with a robust CRC32 protecting it.

Assuming we are using Ethernet (I don't believe this can b= e a requirement either) this only provides hop to hop protection, not end t= o end. I don't have a completely error free network and checksum errors= while low, are non-zero. Sending a packet to the wrong VM is fundamentally= bad and could be quite costly, =C2=A0so for me UDP checksums would be the = minimum requirement. This would need to apply to the case where the protoco= l is switched also.

In any case, the requirements and constraints for when = it's acceptable to ignore non-zero checksums for UDP should be specifie= d in a more general way if is being allowed. =C2=A0Maybe an addendum to RFC= 6935?

Tom

=
Thanks,
Tom

=C2=A0
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). =C2=A0Another alternative is to accept all checksum values. = =C2=A0The
second option greatly enhances interoperability with implementations that choose to generate a checksum and implementations that cannot validate the<= br> checksum. =C2=A0It allows a mixed environment where "better" impl= ementations
(that can validate) can interoperate with "inferior" implementati= ons that
are unable to validate the checksum.
=C2=A0
=C2=A0
BTW, VXLAN is not the only tunneling protocol to specify this behavior.
LISP (RFC 6830), specifies exactly the same behavior.=C2=A0
=C2=A0- 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<= br> >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 an= d
>invalid, UDP MUST silently discard the datagram."
>
>It doesn't seem like 1122 allows checksum verification to be option= al,
>so these would seem to be a conflict. Presumably, ignoring the RX csum<= br> >is included for performance but since the sender can already send zero<= br> >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 associ= ated
>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<= br> >https://www.ietf.org/mailman/listinfo/tofoo

--089e0111bc9a06139004f84e10c5--