Re: [Last-Call] Last Call: <draft-ietf-nvo3-geneve-14.txt> (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard

Daniel Migault <> Tue, 26 November 2019 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF4D6120AD8; Tue, 26 Nov 2019 13:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HxJg8TBbzAVg; Tue, 26 Nov 2019 13:05:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 245FC120AD4; Tue, 26 Nov 2019 13:05:16 -0800 (PST)
Received: by with SMTP id y13so1371074vsd.9; Tue, 26 Nov 2019 13:05:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jy/CTGga+Xx5Mj53fN4DkajS0h6Hb0/8d8wSUDqd6TU=; b=TPwzKDGgwjseMzHXnASEHSTRgdjMRULzj+wjVgNGK3EytSSIsBrrJLyuRZcqaapy7p jBpHvi7IxI6+7rQDJ1pX+J0IK7parWj7N55qLVCmnHhojAfvjdoqq39G3JPMz1Pqp8nJ zN86Gief0N1TGG6SU6XSnkCzG+aQCdD8hPeSCz6xrdUEnQkfx5bH/WmNXXso8IMK75JN Q2DQE94OErkoDw3ImWRolKMACk/l3wgfjKzDpczmjWNgK8RWcclPFYVjrW+7atYCin7a zC/MwagjYAyPNPezr7b7GokhLBOtj1kbnWDNIK24oBYWZ7PkixTzX5fnxzcGPyc3ilDh 2YFA==
X-Gm-Message-State: APjAAAV8HToUmKWwumiHpREfF96deDE/Okw7PDzFFP3oB0W4qR/ydJz7 HIua/0GUsTF98hNM7CuzA8LZNVBnncSEKpq1DMrH0N1Wv1A=
X-Google-Smtp-Source: APXvYqza3sz5pWQHhMLjILPvh96LWLijmXI6nNvAtVGrY2FwG/q6CbaC1l1POt5d9SmsgyuAvzNlGlZDmbypyCA9ZkI=
X-Received: by 2002:a67:d504:: with SMTP id l4mr2131338vsj.180.1574802314865; Tue, 26 Nov 2019 13:05:14 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Tue, 26 Nov 2019 16:05:03 -0500
Message-ID: <>
Cc: "Bocci, Matthew (Nokia - GB)" <>,, NVO3 <>,
Content-Type: multipart/alternative; boundary="00000000000091b23d0598463c23"
Archived-At: <>
Subject: Re: [Last-Call] Last Call: <draft-ietf-nvo3-geneve-14.txt> (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Nov 2019 21:05:18 -0000


I do have some architecture concerns regarding the Geneve specification. My
concerns have already been raised to the WG but I have not been convinced
these have been resolved. I am not claiming that I am not wrong nor that I
am not on the rough but for more transparency, I prefer reiterating my

In my opinion, the transit devices that are not part of the generic NVO3
architecture RFC8014 should not be part of the Geneve specification as they
do raise - at least to me - significant concerns.

Transit devices are placed on-path of a session established between end
points (NVE) which results in a three parties communication. The absence of
explicit signaling between the the NVE and the transit device contradicts
of rfc8558 - though mostly focused on TCP. The consequence I am concerned
is, in my opinion, that the presence of transit devices will slow down or
prevent securing NVE-to-NVE communications. Typically, the document
recommends securing the NVE-to-NVE communication with DTLS or IPsec which
results in "bypassing" the transit devices. While the draft specifies the
transit devices should not block an encrypted communication, my concern is
that encrypting communications makes transit devices useless. In that
sense, a NVE that is not aware that no transit devices are on its path will
not secure the NVE-to-NVE communication. As a result, my understanding is
that with DTLS/IPsec: either the transit devices constitute a major
obstacle to the deployment of securing NVE-to-NVE communications or transit
devices have been designed to be useless.

Note that communication security does not necessarily needs to be performed
by DTLS or IPsec, and that securing at the overlay
layer could accommodate the transit device. However, there has been no
consensus on the security requirements yet, so in my opinion it is
premature to rely on such mechanisms.


On Thu, Oct 24, 2019 at 2:42 PM The IESG <> wrote:

> The IESG has received a request from the Network Virtualization Overlays WG
> (nvo3) to consider the following document: - 'Geneve: Generic Network
> Virtualization Encapsulation'
>   <draft-ietf-nvo3-geneve-14.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2019-11-07. Exceptionally, comments
> may
> be sent to instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
> Abstract
>    Network virtualization involves the cooperation of devices with a
>    wide variety of capabilities such as software and hardware tunnel
>    endpoints, transit fabrics, and centralized control clusters.  As a
>    result of their role in tying together different elements in the
>    system, the requirements on tunnels are influenced by all of these
>    components.  Flexibility is therefore the most important aspect of a
>    tunnel protocol if it is to keep pace with the evolution of the
>    system.  This document describes Geneve, an encapsulation protocol
>    designed to recognize and accommodate these changing capabilities and
>    needs.
> The file can be obtained via
> IESG discussion can be tracked via
> The following IPR Declarations may be related to this I-D:
> _______________________________________________
> IETF-Announce mailing list