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

Tom Herbert <tom@herbertland.com> Wed, 15 February 2017 22:36 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: nvo3-dt-encap@ietfa.amsl.com
Delivered-To: nvo3-dt-encap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24112987B for <nvo3-dt-encap@ietfa.amsl.com>; Wed, 15 Feb 2017 14:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 6jwdddGkgIcb for <nvo3-dt-encap@ietfa.amsl.com>; Wed, 15 Feb 2017 14:36:24 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC69C1298A6 for <nvo3-dt-encap@ietf.org>; Wed, 15 Feb 2017 14:36:24 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id w20so398807qtb.1 for <nvo3-dt-encap@ietf.org>; Wed, 15 Feb 2017 14:36:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RobsL+8BBG+Jcq23Rht2/80ivM+s772NqkkuO/3OvAE=; b=txZbwXPcPyd4rsmIxWOFPKTYXtTpxlMQFgnQHGtlE4WDuMBp+fLymWT0DLSDzTG1zD tYISYsNWuUL1s5FqLWPxMpzClTaL70nahafu3/OXgYxmTpnP/Dp7DveBarUrYLVB9J9C OXslw88yuI2Fg6YeTozC0OPmjBUy+fMOk62uYvbCkbOM6zzJH8cL5z12NtauSciI2GzN qU20pDCIFci61fnsiHutTr+lfGLpQirbIXRhHoI5TfVq1GEA43r1FjgeR2wVUYwgPV87 LkzYWQCEcgbNbp+5VQFxEpNPLmKQAA2dH9yU9Mh2p2lBtGun/xzNRPkCLT/kuz/uXQw5 4m9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RobsL+8BBG+Jcq23Rht2/80ivM+s772NqkkuO/3OvAE=; b=Abu1f1B4hgBdFq8xnOroog7XgF0sN5kQfF1X7FOvYm9bFhsvhKFZ1cLL2xTds2GkR9 cN0IOhSFe5/7GGAWI2YJgUzESJkZ6cxh52FKEB2y/CI8vhMvZ7lg9sO6qwbDNzThu07Y 2s4RwAnyfYKanoFG3nLUBVeicxbQNL13lsZD6v/d/DGsxxCj5GTcEKEc6KKX/j+ozH/q 26ihyzUdp4IDBQsUb2W7NVYJDLEQGcjuh4sj/BFHMhlk+gbg3bJ2N5RwDzAmtZ/RmYPf Hg94HeTGbvTr04fJ6clAyxnexa/y4A2o4CpxxAYV8qVQjGAcpQF0PUTtKb0eWhbsfli6 yVtw==
X-Gm-Message-State: AMke39kYePPX+kt3HF9Nhxi7OCnB0o5jCrwtvAE1/vdeJC0Bzn0iAc3EtlZZ0A6DD2VBgCdQ4lGHEkJueRdczQ==
X-Received: by 10.200.40.113 with SMTP id 46mr33263300qtr.167.1487198183728; Wed, 15 Feb 2017 14:36:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.43.227 with HTTP; Wed, 15 Feb 2017 14:36:23 -0800 (PST)
In-Reply-To: <F80D14D0-57B0-4768-9405-4AF99526E439@vmware.com>
References: <CA+C0YO0yz4KBe=w+EXHVBA=XWErRAtTzdCNsca7h-BjJ2Bwdxg@mail.gmail.com> <CALx6S37AeS8QEtm1SJsFe9dAnEoCdPZodPJyr7jfYxxEnM040g@mail.gmail.com> <F80D14D0-57B0-4768-9405-4AF99526E439@vmware.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 15 Feb 2017 14:36:23 -0800
Message-ID: <CALx6S35eYxWXCK3TsESedJ8g3zQDWHYyyJXObAJ4VMnC9Q1aQQ@mail.gmail.com>
To: Sami Boutros <sboutros@vmware.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3-dt-encap/063Wx1mtmeccEGMhNNv6ZbzPGsM>
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "nvo3-dt-encap@ietf.org" <nvo3-dt-encap@ietf.org>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>
Subject: Re: [nvo3-dt-encap] [nvo3] Encap draft published by design team
X-BeenThere: nvo3-dt-encap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Private mailing list for internal NVO3 Encapsulation Design Team discussions <nvo3-dt-encap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3-dt-encap/>
List-Post: <mailto:nvo3-dt-encap@ietf.org>
List-Help: <mailto:nvo3-dt-encap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3-dt-encap>, <mailto:nvo3-dt-encap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 22:36:26 -0000

On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros <sboutros@vmware.com> 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 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.

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.

Tom



>
> Thanks,
>
> Sami
>>
>>Tom