Re: [nvo3] Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

"Ganga, Ilango S" <ilango.s.ganga@intel.com> Thu, 05 December 2019 08:39 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 F32F81200F5; Thu, 5 Dec 2019 00:39:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 PN4wGiG_U51Y; Thu, 5 Dec 2019 00:39:01 -0800 (PST)
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 EF6FA1200F1; Thu, 5 Dec 2019 00:39:00 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2019 00:39:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,280,1571727600"; d="scan'208";a="209075891"
Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga008.fm.intel.com with ESMTP; 05 Dec 2019 00:39:00 -0800
Received: from orsmsx116.amr.corp.intel.com ([169.254.7.11]) by ORSMSX108.amr.corp.intel.com ([169.254.2.82]) with mapi id 14.03.0439.000; Thu, 5 Dec 2019 00:39:00 -0800
From: "Ganga, Ilango S" <ilango.s.ganga@intel.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-nvo3-geneve@ietf.org" <draft-ietf-nvo3-geneve@ietf.org>, Matthew Bocci <matthew.bocci@nokia.com>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
Thread-Index: AQHVqxBFVRTdVAkXcUm8xF2OnvitCaerNu9g
Date: Thu, 05 Dec 2019 08:38:59 +0000
Message-ID: <C5A274B25007804B800CB5B289727E3590683352@ORSMSX116.amr.corp.intel.com>
References: <157551143635.11168.5900992134750052817.idtracker@ietfa.amsl.com>
In-Reply-To: <157551143635.11168.5900992134750052817.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGQ5YTk4NmQtMWE4Ny00MmU1LThlZDYtZWIwYTJkNjNmMjVlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiamtQdEUwSEg3bWVIdXRnVzhldEpQc1MzS3l2YVBKbkxLUTNBd1JLOXNjUHNaVGRrTUM5cnE1R09pWmJ1TGVFNiJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.22.254.139]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/toCR0NW8WFLMVlK3X_9b2qFKjok>
Subject: Re: [nvo3] Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
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, 05 Dec 2019 08:39:03 -0000

Thanks for your review and comments.

Several of the comments from reviewers came in in the last hours before the Telechat.  We will review the comments and try to respond to each one of these as soon as we can in a day or two.

Thanks,
Ilango


-----Original Message-----
From: Roman Danyliw via Datatracker <noreply@ietf.org> 
Sent: Wednesday, December 4, 2019 6:04 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nvo3-geneve@ietf.org; Matthew Bocci <matthew.bocci@nokia.com>; nvo3-chairs@ietf.org; matthew.bocci@nokia.com; nvo3@ietf.org
Subject: Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-nvo3-geneve-14: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) The threat model assumed by geneve appears to be expressed in conflicting ways.  Section 4.1 notes that RFC8085’s definition of “controlled environment”
applies.  However,

- Section 6 notes “When crossing an untrusted link, such as the public Internet, …”

- Section 6.1 notes “Geneve data traffic between tenant systems across such separated networks should be protected from threats when traversing public networks. Any Geneve overlay data leaving the data center network beyond the operator's security domain SHOULD be secured by encryption mechanisms such as IPsec or other VPN mechanisms to protect the communications between the NVEs when they are geographically separated over untrusted network links.”

The advice provided in Section 6.x is sound.  Nevertheless, it doesn’t appear to describe a “controlled environment”.

(2) Section 6.  Per “Compromised tunnel endpoints may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants”, couldn’t compromised transit devices do the same?

(3) Section 6.1.  Similar to what is discussed in Section 6.2 (for integrity), please refer to the impact of a compromised node on confidentiality.  For example (not verbatim) “A compromised network node or a transit device within a data center may passively monitor Geneve packet data between NVEs; or route traffic for further inspection.”

(4) Section 6.1.  Per “Due to the nature of multi-tenancy in such environments, a tenant system may expect data confidentiality to ensure its packet data is not tampered with (active attack) in transit or a target of unauthorized monitoring (passive attack).”, please provide additional precision on the confidentiality. It is only relative to other tenants, but not from the provider (who can engage in tampering and passive monitoring).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the transit device which is only permitted to inspect the geneve traffic isn’t clear, especially if end-to-end security is applied.  RFC7365 didn’t provide insight into this architectural element.