> On Jul 29, 2016, at 4:39 PM, Fabio Maino <[email protected]> wrote: > > On 7/29/16 12:44 PM, Jesse Gross 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. > > That approach forces your customers to pay upfront for the cost of buffering > metadata that their devices don't know how to handle, and/or they may never > use. To implement a new feature, you'll need buffers AND logic. > > Even if you allocate buffer in advance (before the feature is specified), > you'll have to spin a new version of the HW to add the logic that addresses > that new feature. > > In this sense VXLAN-GPE allows an implementor to be sensible in allocating > resources, by using only the buffer space that is actually needed by that > specific implementation. > > I suspect that the result of the pressure of cost on implementations will be > such that, some HW implementations of Geneve, may implement only the basic > functions, restricting to very few, if any, support for variable length > options. Packets with unknown options will be eventually punted to the slow > path, and vendors will claim support for the protocol. > > This is not very different from how an unknown shim header will be handled. > Flexibility and HW implementations might be a bit of a unicorn…
I think that you are making some specific assumptions about the types of implementations here. In particular, you are assuming that the only device class is a fixed-function switching ASIC. The comments don’t really apply to software, NICs, or even the more programmable switching ASICs that are starting to come out. In that specific situation, I agree that it doesn’t make sense to include elements of an implementation that can’t be usefully deployed. However, in cases where the device would need to be respun to include new logic, I doubt that anyone would prematurely include vestigal pieces that would drive up the cost. They would simply implement the support as necessary and the cost would reflect what the device is capable of doing. This is similar to VXLAN-GPE in that regard. However, I don’t believe that networks consist exclusively of fixed switching ASICs. As I mentioned before, there are many other components that can take advantage of extensibility. I don’t see that it is necessary to deny them those benefits even if some devices may need to be incrementally respun. > >> >> 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. > > This is actually a good example for the counter argument: many vendors > couldn't justify the cost of supporting IPv4 option in the fast path, and > packet with IP options, in many implementations, were punted to the slow > path. This quickly drove developers to abandon use of IP options in their > applications, as it was almost a guarantee to send their flows in the slow > path. Some time too much flexibility is bad (especially when cost is an > issue). > > For IPv6 extension headers, use cases will determine (are determining) which > ones are worth the extra cost in the fast path and vendors will act > accordingly. Fittest options will survive… Yes, I certainly agree that vendors will act according to the needs that they see in the market. I think it’s been said a number of times in the working group that extensibility is a “use it or lose it” type of thing. Since IP options didn’t have immediate important uses when it was first being implemented, there was little sense in handling them. In contrast, TCP options are alive and well these days because there are good uses for them. I know that TCP is generally implemented in software instead of hardware but I can assure you the desire to take shortcuts is plenty strong in the software industry. In the specific case of Geneve, I gave some information about some of the implementations I’ve personally seen and their capabilities a while back (https://mailarchive.ietf.org/arch/msg/nvo3/HTSXROpKwman1Bd4fAlmmfZF_P8). Since options are the core reason for Geneve existing (it’s the main thing that separates it from VXLAN), there’s been much more awareness that it is important and useful to implement them. >> >> 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. > > > Similarly to those vendors that might have implemented Geneve in the fast > path, and want to add support for a new optional extension. With the > difference that their customers will have paid already for the cost of extra > buffering even in the first release that had no support for that new option. In the specific example that I gave (NICs), that is not really true. As new Geneve options are introduced the existing cards will continue to work (GUE also has this property). This is because these offloads are primarily operating on the payload while the option logic is handled in the host CPU. For server-based tunnel termination this ability to continue to offload as the protocol evolves is a significant benefit. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
