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

Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 05 December 2019 02:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: nvo3@ietf.org
Delivered-To: nvo3@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BDC120058; Wed, 4 Dec 2019 18:03:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157551143635.11168.5900992134750052817.idtracker@ietfa.amsl.com>
Date: Wed, 04 Dec 2019 18:03:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/hzecTM4MvhX2LRqONAKx47EW-LQ>
Subject: [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
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 02:03:56 -0000

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.