On Fri, Jul 29, 2016 at 12:44 PM, Jesse Gross <[email protected]> wrote: > >> On Jul 29, 2016, at 12:17 PM, Fabio Maino <[email protected]> wrote: >> >> On 7/29/16 11:45 AM, Tom Herbert wrote: >>> On Jul 29, 2016 11:12 AM, "Fabio Maino" <[email protected]> wrote: >>> > >>> > On 7/27/16 1:43 PM, Tom Herbert wrote: >>> >> >>> >> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino <[email protected]> wrote: >>> >>> >>> >>> On 7/27/16 12:27 PM, Tom Herbert wrote: >>> >>>> >>> >>>> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino <[email protected]> wrote: >>> >>>>> >>> >>>>> On 7/27/16 10:53 AM, Tom Herbert wrote: >>> >>>>>> >>> >>>>>> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci >>> >>>>>> <[email protected]> >>> >>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) >>> >>>>>>>> <[email protected]> >>> >>>>>>>> wrote: >>> >>>>>>>>> >>> >>>>>>>>> On 7/26/16 12:08 PM, Dino Farinacci wrote: >>> >>>>>>>>>>> >>> >>>>>>>>>>> Having VXLAN as an Independent Stream RFC gives a document to be >>> >>>>>>>>>>> used >>> >>>>>>>>>>> to >>> >>>>>>>>>>> innovate from. I believe that was the intent of VXLAN-GPE - to >>> >>>>>>>>>>> provide the ability >>> >>>>>>>>>>> for needed extensions. >>> >>>>>>>>>> >>> >>>>>>>>>> The only new feature the VXLAN-GPE brings to the table is a way >>> >>>>>>>>>> to >>> >>>>>>>>>> identify that NSH is being encapsulated. >>> >>>>>>>>> >>> >>>>>>>>> or any other shim header, NSH just happens to be one. >>> >>>>>>>> >>> >>>>>>>> Precisely. GPE addresses the limitation associated with VXLAN, >>> >>>>>>>> namely >>> >>>>>>>> the lack of multi-protocol support. As we've seen on the list, >>> >>>>>>>> other >>> >>>>>>>> protocols have come up: MPLS for example. >>> >>>>>>> >>> >>>>>>> This is technically not true. As long as you are willing to spend 14 >>> >>>>>>> bytes on a MAC header, then anything with an ethertype can be >>> >>>>>>> encapsulated >>> >>>>>>> with VXLAN. >>> >>>>>>> >>> >>>>>>> And I have working code that encapsulates both IPv4 and IPv6 in >>> >>>>>>> VXLAN >>> >>>>>>> with ethertypes 0x0800 and 0x86dd, respectively. >>> >>>>>>> >>> >>>>>>>> There are some other technical benefits as well: version and OAM. >>> >>>>>> >>> >>>>>> As do Geneve and GUE. But this thread is not about touting the >>> >>>>>> features of these protocols, it is about the technical objections to >>> >>>>>> them. My major objections (from the list I posted) to VXLAN-GPE is >>> >>>>>> that it has no extensibility and offers no security of the VNI. These >>> >>>>>> are showstoppers in my deployment. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Tom, >>> >>>>> >>> >>>>> extensibility is achieved via shim header: >>> >>>>> >>> >>>>> - if you want to carry end to end metadata you can define the >>> >>>>> appropriate >>> >>>>> shim header >>> >>>>> >>> >>>>> - If you want to protect the integrity of the VNI, you can include an >>> >>>>> HMAC >>> >>>>> of the VNI in the shim header >>> >>>>> >>> >>>> Please point me to the specification where this shim header with the >>> >>>> HMAC is described and add a reference to it in the security >>> >>>> considerations section of the VXLAN-GPE draft. >>> >>> >>> >>> >>> >>> Hi Tom, >>> >>> there are a lot of use cases that can be addressed with shim headers, >>> >>> and >>> >>> each solution may look fairly different depending on the requirements. >>> >>> >>> >> The security option including the specific header format is described >>> >> in draft-herbert-gue-extensions. You can use the same data format. >>> >> >>> >>> Can you point me to an nvo3 specification of what are the requirements >>> >>> that >>> >>> need to be addressed to provide VNI integrity protection? If the >>> >>> requirements are the same you used for GUE, the shim header could use an >>> >>> encoding similar to the GUE security option. >>> >>> >>> >> Section 6.2 of draft-ietf-nvo3-security-requirements describes the >>> >> dataplane requirements. The most important requirement of nvo3 is to >>> >> maintain strict isolation between tenant virtual networks. The problem >>> >> is exacerbated in UDP encapsulation since any non privileged >>> >> application can send a UDP packet to any port thereby making it easier >>> >> to inject packets into a virtual network than in a non-UDP based encap >>> >> protocol like nvgre. In our large scale network we need strong >>> >> mechanisms to guarantee this isolation; Ethernet CRC and network >>> >> mechanisms like firewalls or address spoofing are not sufficient for >>> >> multi-tenant nv security. >>> > >>> > >>> > Tom, >>> > I went back and re-read the draft. Requirement 10, that is the one that >>> > seems relevant here, is not a MUST. From that standpoint VXLAN-GPE does >>> > comply with that draft. >>> > >>> > I don't want to argue that there are use cases where authenticaton of the >>> > VNI might be useful, but certainly there are others where it isn't. >>> > Otherwise the WG would have settled for a MUST there. >>> > >>> > In the design of VXLAN-GPE we have choosen to not burden the cost of ALL >>> > the implementations with a mandatory authentication field. However, >>> > thanks to VXLAN-GPE flexibility and extensibility, this function can be >>> > added via shim header. >>> > >>> > >>> >> >>> >>> Lacking the requirement document, I'm sure we can add a paragraph in the >>> >>> security section that describes how it can be done. >>> >>> >>> >> Please be specific in that. If you just say "use NSH" that is not >>> >> helpful at all to your potential implementors or users. If we were to >>> >> implement security we need to know the exact bits that are set in the >>> >> packet. >>> >> >>> >> Tom >>> > >>> > >>> > >>> > That should not go in the VXLAN-GPE draft. All that draft needs to >>> > specify is that there might be a following shim header. The VXLAN-GPE >>> > draft does that today. >>> > >>> > if I read your comment right, you seem to agree that it can be done. Is >>> > this your MAJOR objection to VXLAN-GPE? If we were to specify such a >>> > draft, would that change your opinion in supporting VXLAN-GPE for WG >>> > adoption? >>> > >>> My major objections are lack of security and extensibility. The counter >>> argument seems to be use a shim header for security or extensions, but >>> there has never be any specifics offered (I have asked several times now >>> how to implement a 64 bit security cookie in VXLAN-GPE). Also the security >>> considerations section in the draft provides no useful guidance. >>> >>> In my data center if we are going to commit to using a protocol for the >>> long term (like if we buy into HW support), I need to believe it is >>> adaptable to face changing security risks and new technologies. I know how >>> to extend GUE and in fact we have useful extensions defined. I believe I >>> would know how to extend Geneve, although I still wish there were some >>> standard TLVs spec'ed. However, I don't know how extend VXLAN-GPE. I can't >>> afford to find out two years from now that I need switch protocols because >>> we can't adapt the running protocol. This is particularly true in data >>> center security, the demands for strong security mechanisms will only be >>> increasing-- I need a protocol that can deal with that... >>> >>> This is all just my opinion of course :-) >>> >> >> I think that the point at hand here is that the AD is pushing the WG to have >> a discussion on which encapsulations should be selected for standard track. >> What should guide that decision are the requirements emerging from the set >> of documents that are adopted by the WG. >> >> As I said in the previous message, IMO VXLAN-GPE does address the security >> requirements as expressed in draft-ietf-nvo3-security-requirements. I note >> that you have not objected to that point. >> >> Also, I pointed to NSH as ONE example of how VXLAN-GPE can be extended using >> a shim header. NSH implements SFC and metadata transport. Looking at what >> NSH + VXLAN-GPE achieves, it makes fairly hard to maintain that VXLAN-GPE is >> not extensible. Extensibility is achieved via layering. It might not be the >> same way extensibility is achieved by the other contenders, but it's a >> fairly established way to design protocols. >> >> I think this should answer the objections to security and extensibility for >> the purpose of the selection of an nvo3 encapsulation. > > The issue with shim headers is that introducing a new one breaks the ability > of existing implementations to parse the packet. There are a lot of use cases > where just being able to get to the packet data is hugely useful - a NIC > steering incoming frames to a VM shouldn’t need to be modified for every use > case. Even simple examples like tcpdump/Wireshark benefit from this - it’s > really useful to be able to generally get a look at a packet even if it > doesn’t understand everything. With both Geneve and GUE this is possible but > not with the design that you are describing with VXLAN-GPE. > > What you are describing is essentially the same as IPv6 extension headers vs. > IPv4 options. Anecdotally, I’ve seen a lot more bugs in implementations of > IPv6 extension headers even in very common cases. The reason is that with > IPv6, it’s necessary to traverse different shim headers, which themselves > have different locations of next protocol field is, etc. At least with IPv4, > getting to the data is very simple and consistent. > > To make this very concrete: I know that there a number of NIC vendors that > have implemented support for VXLAN-GPE offloading already. If a shim header > was introduced to add VNI security as you are describing, these offloads > would suddenly become useless. That does not seem like a very good definition > of extensibility to me.
+1. I'd also point out that header chains most likely are harder to parser than TLVs (as in the IPv6 EH vs. IPv4 options), so this a counter argument to the objection that Geneve with TLVs would have more processing complexity than VXLAN-GPE+NSH. Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
