Re: [nvo3] Review of draft-ietf-nvo3-geneve-13

"Ganga, Ilango S" <ilango.s.ganga@intel.com> Thu, 25 July 2019 21:18 UTC

Return-Path: <ilango.s.ganga@intel.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F7E1201F2 for <nvo3@ietfa.amsl.com>; Thu, 25 Jul 2019 14:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zaX-I-Yz7moD for <nvo3@ietfa.amsl.com>; Thu, 25 Jul 2019 14:18:38 -0700 (PDT)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8881201F1 for <nvo3@ietf.org>; Thu, 25 Jul 2019 14:18:38 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2019 14:18:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.64,308,1559545200"; d="scan'208,217";a="161100662"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga007.jf.intel.com with ESMTP; 25 Jul 2019 14:18:37 -0700
Received: from orsmsx125.amr.corp.intel.com (10.22.240.125) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 14:18:37 -0700
Received: from orsmsx116.amr.corp.intel.com ([169.254.7.85]) by ORSMSX125.amr.corp.intel.com ([169.254.3.92]) with mapi id 14.03.0439.000; Thu, 25 Jul 2019 14:18:37 -0700
From: "Ganga, Ilango S" <ilango.s.ganga@intel.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: [nvo3] Review of draft-ietf-nvo3-geneve-13
Thread-Index: AQHVMQ5zXCwv34AAQUmjH7hujLmoc6bb8bPQ
Date: Thu, 25 Jul 2019 21:18:36 +0000
Message-ID: <C5A274B25007804B800CB5B289727E35905C4AA0@ORSMSX116.amr.corp.intel.com>
References: <CAHbuEH66JZd1KOi5_mL8nzdTZ7WjSsOQP8a3B+oSwA6wNnfDKw@mail.gmail.com>
In-Reply-To: <CAHbuEH66JZd1KOi5_mL8nzdTZ7WjSsOQP8a3B+oSwA6wNnfDKw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTc5YWE4NjgtZWFiNy00MDNjLWE2NDctODdkYzlkNDgxZjliIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieUlrS2pYRnZrZmZ2Z0NMTFl4TEFOWDB4dWhSN2FJbGhWMnFrOGliTXlqWjBKWVwvS09admNLVm5QMDlmOEgyQnkifQ==
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: multipart/alternative; boundary="_000_C5A274B25007804B800CB5B289727E35905C4AA0ORSMSX116amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/7JMxkcvm9SmjwPboIzibGjFbBec>
Subject: Re: [nvo3] Review of draft-ietf-nvo3-geneve-13
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 21:18:41 -0000

Hello Kathleen,

Thanks for your review of draft-ietf-nvo3-geneve-13.  We could provide additional clarification in section 4.3 to address your comment. Please let us know if this satisfies your comment.

Current text in Section 4.3, first paragraph:

   In order to provide integrity of Geneve headers, options and payload,

   for example to avoid mis-delivery of payload to different tenant

   systems in case of data corruption, outer UDP checksum SHOULD be used

   with Geneve when transported over IPv4.  An operator MAY choose to

   disable UDP checksum and use zero checksum if Geneve packet integrity

   is provided by other data integrity mechanisms such as IPsec or

   additional checksums or if one of the conditions in Section 4.3.1<https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a,

   b, c are met.

Proposed text to 4.3 that we believe would address your comments:


   In order to provide integrity of Geneve headers, options and payload,

   for example to avoid mis-delivery of payload to different tenant

   systems in case of data corruption, outer UDP checksum SHOULD be used

   with Geneve when transported over IPv4. "The UDP checksum provides a statistical guarantee that a payload was not corrupted in transit. These integrity checks are not strong from a coding or cryptographic perspective and are not designed to detect physical-layer errors or malicious modification of the datagram (see RFC 8085 section 3.4). In deployments where such a risk exists, an operator SHOULD use additional data integrity mechanisms such as offered by IPSec (see Section 6.2)."



   An operator MAY choose to

   disable UDP checksum and use zero checksum if Geneve packet integrity

   is provided by other data integrity mechanisms such as IPsec or

   additional checksums or if one of the conditions in Section 4.3.1<https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a,

   b, c are met.

Thanks,
Ilango


From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Tuesday, July 2, 2019 12:43 PM
To: nvo3@ietf.org
Subject: [nvo3] Review of draft-ietf-nvo3-geneve-13

Hello,

I just read through draft-ietf-nvo3-geneve, sorry I am out-of-cycle in the review process, but it looks like it has not started IETF last call yet.  I have what's really just a nit and request for a little more text.

Section 4.3.1

The value of the UDP checksum is overstated.  The text should note that corruption is still possible as this is a checksum and not a hash with low collision rates.  Corruption happens and goes undetected in normal operations today.

The security considerations section does address the recommendation to use IPsec, but making the connection on the UDP checksum being inadequate could be helpful.

Reality:

The way this is written, I suspect there really are no plans to use IPsec with GENEVE, are there?  The MUST statements around not altering traffic can only be achieved with IPsec, so if the intent is really to enforce the early MUST statements in the document, sooner mention of IPsec would be good.  If this is more for detecting corruption (and not having that be 100% or close) that should be clear up front.

I'm just envisioning use cases where the virtual path is set differently to the physical path for expected operations to route through desired security functions, then an attacker alters checksums to avoid detection of these changes.

Thanks and sorry for a late review!

--

Best regards,
Kathleen