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