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 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
