On 2/15/17, 2:36 PM, "Tom Herbert" <[email protected]> wrote:
>On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros <[email protected]> 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.
Agreed,
Sami
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
