Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team

Sami Boutros <> Thu, 16 February 2017 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 968051294F8; Thu, 16 Feb 2017 10:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lRAE8HJJFJM7; Thu, 16 Feb 2017 10:12:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 982CA1294F5; Thu, 16 Feb 2017 10:12:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=30TbGRvy4JVKxeFgOjJDpJ9SwpYkSbo1wWmQsXMwLO0=; b=f9RWF3eoUsoJ80Wd2bEnjrpqpx53F64siJjyx+l2L2fBSdml9FX4ETfBvjGh5qpsyve7nDuXcfozTHZZg/5Oys6LtfxK+perjIxwtHUB3hSCatNVDfMz8n4VJO7c9DNnH7TGFPuk1wP7qlkOKPHgak5bgKbEErFQxIRZ/Qwd0Qg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 18:12:14 +0000
Received: from ([]) by ([]) with mapi id 15.01.0919.011; Thu, 16 Feb 2017 18:12:13 +0000
From: Sami Boutros <>
To: Tom Herbert <>
Thread-Topic: [nvo3-dt-encap] [nvo3] Encap draft published by design team
Thread-Index: AQHSgxQJtXs78HeFw0KWUNBaH5/Q/KFp18cAgADZ74CAAMJpAA==
Date: Thu, 16 Feb 2017 18:12:13 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 7379596d-3d63-4c81-51af-08d456975575
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3013;
x-microsoft-exchange-diagnostics: 1; CY4PR05MB3013; 7:+/JlQOcCDn6+FzzfIGvlHjHNliI/ODT5qHf3bSkQVNauRO/jjTIiv68CDvtMT5lW+g9jPhhbEXNMVztTIQL+4rQihw24bIrkd9BRxgqx+sw58QFlfU1U2CCpOsDaDe2FSzmkSIYxARlpTqbAz4mhTdVUJS/pKRn4T2f0a8NLcDXzn/mrdzCzOwz8VGh/63cqXjCrwrUCMdFDfjhnrmfFjVU7oQW/SmbOdAqtVfJBLaCkAFqfrMMVRaNwYotQB82UK0bzpk81qQc7Ra2ET1xCPB839mXjBZRS9mrR4opbV9Jbu6zstvWkHOwdi7ndEsKlsnI0SkTr/3klZRu/MpnZ7g==; 20:HaWVX+G6n5BF/v4a0ujTYAY3d+BSCdBvcTUo3v92+0Wig472Mwv/APYWx+kcchhepG3H2eTCUzJFfOCPHoR29CL2bOYta15j47+Cf4k00NvmwokNvWLwAiMzVTy5/+gltVEwYKEhQjwwg0Vt+8Qh2/ulPeQwSyD/IIb0ap0M6rs=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(61668805478150)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR05MB3013; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3013;
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377454003)(199003)(189002)(54906002)(6916009)(97736004)(3660700001)(66066001)(5660300001)(106116001)(6512007)(7736002)(77096006)(106356001)(3846002)(6246003)(305945005)(8676002)(229853002)(38730400002)(102836003)(105586002)(110136004)(25786008)(6486002)(6116002)(53936002)(6436002)(81156014)(76176999)(36756003)(81166006)(99286003)(4326007)(82746002)(230783001)(2950100002)(122556002)(8936002)(50986999)(2900100001)(92566002)(101416001)(33656002)(83716003)(189998001)(93886004)(54356999)(39060400002)(6506006)(3280700002)(86362001)(2906002)(389900003)(68736007)(53546006)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3013;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 18:12:13.7653 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3013
Archived-At: <>
Cc: Sam Aldrin <>, "" <>, "" <>, "" <>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 18:12:20 -0000

On 2/15/17, 2:36 PM, "Tom Herbert" <> wrote:

>On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros <> wrote:
>> Hi Tom,
>>>The Security Considerations section needs content. First and foremost,
>>>in a multi-tenant data center ensuring strict isolation between
>>>different tenants traffic seems fundamental and the mechanisms for
>>>doing that should be explicit in the description of an encapsulation.
>>>Bear in mind that when we use UDP for encapsulation there is typically
>>>nothing in a host to prevent an unprivileged application from spoofing
>>>well formed nvo3 packets and sending them to arbitrary destinations
>>>(this is harder to do with other protocols such as TCP or GRE). A
>>>24-bit VNI is not sufficient to provide any guarantee of virtual
>>>network isolation.
>> Can you please elaborate more on why 24- bit is not sufficient to provide network isolation?
>1) From a security standpoint small identifiers are easily guessable
>by an attacker and does not allow much entropy, a single bit flip in
>the VNI could result in mis-delivery of a packet to the wrong tenant.
>Mis-delivery due to corruption is why the UDP checksum is important to
>enable, but even that is too weak to guarantee isolation-- this one
>reason why we defined header security in GUE.
>2) I don't believe that 24-bit identifiers scale to large deployments.
>It is quite possible that a large provider may have upwards of 1M
>tenants and sub-tenants that need identifiers. If we take into account
>that these may have hierarchical allocation, flag bits (e.g. trusted
>vs. not trusted tenant), and a strong desire to avoid ever having to
>renumber networks-- 24 bits starts to look small and even 32 bits
>might not be enough. I really wish the design time provided more of an
>analysis on the scaling properties of 24 bit VNI instead of just
>saying VXLAN and Geneve already have that size so it must be okay.

We discussed mandating UDP checksum and having Security extensions to secure 
both the tunnel header and payload for security and integrity. 
We can add the above text in the security considerations.

We saw value in keeping the VNI as part of the tunnel header given 
the existing implementations being able to identify the service quickly.

As well, we discussed having more than 24 bit VNI via using extensions.

>> We have the section 6.2.2 on security and integrity that we borrowed the text you supplied for it’s content.
>> We can refer in the security considerations to the 6.2.2 section? Is this what you are looking for?
>Section 6.2.2 only describes a problem from a rather high level about
>how it _might_ be solved in Geneve not how it is _actually_ solved.
>This is indicative of the most of the draft I think. There are a lot
>of "cans" and "possibilities" in the draft but very few concrete
>statements on what the protocol does already and how it performs in
>the real world. For instance, in the absence of any actual TLVs being
>defined and implemented how can we _really_ know what the operational
>characteristics are? How can we know how these are implemented in HW
>or even if it is feasible,  how the C-bit might help, rather error
>handling and corner cases are actually covered, how is this going to
>withstand DOS attack, or even if the primary technical concern with
>Geneve can be addressed? The current answers to these questions seem
>to be based only on speculation which doesn't inspire confidence in
>those answers for me.

In the security section you provided text for, we talked about the 
possibility of authenticating the tunnel header and payload via extensions 
to address concern of spoofing VNI and payload security.
If you think we need to beef the text more to discuss how C bit could help?
Or how can we withstand DOS attack? Please suggest some text?

However, wouldn’t discussing a solution such as (1) defining TLV(s) and (2) 
Exact operational characteristics be out of scope of this draft?

>If the decision is to pursue Geneve for standardization, I really hope
>that the chairs and ADs quickly prioritize defining and implementing
>some critical TLVs. If this is deferred any longer I think these will
>die on the vine in the same way that IP options became implicitly
>deprecated even before they were even used.