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

[Tom Herbert <[e-mail]>]

On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros <[e-mail]> 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