On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino <[email protected]> wrote: > On 8/1/16 4:21 PM, Alia Atlas wrote: > > > > On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert <[email protected]> wrote: >> >> On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino <[email protected]> wrote: >> > On 7/29/16 6:38 PM, Jesse Gross wrote: >> >>> >> >>> 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. >> > >> > >> > This diverse base of implementation platforms is, IMO, what makes hard >> > to >> > select a single encap for the nvo3 use case. A feature of the protocol >> > that >> > might be a benefit for one platform, introduces significant >> > costs/disadvantages when deployed in another one. >> > >> Can you give a specific example of a feature that demonstrates this? >> With regards to extensibility I am not seeing why using NSH has lower >> costs or fewer disadvantages to deploy compared to flag-fields in GUE >> or even TLVs in Geneve... >> > > [Alia] Do recall that the question is around significant technical concerns > that > must be addressed. It isn't whether one approach is "better" or "easier" > for a > particular deployment scenario as compared to another. > > > The major concern comes from selecting a single MUST implement encapsulation > that has the option to include hundreds of bytes of unstructured, variable > length metadata. Such a feature is fairly unfriendly to implement in fixed > switching ASICs. > This is where I think there is confusion on the "HW implementability" arguments that are being made. VXLAN-GPE is a fixed length header and that is perfectly amenable to switching ASICs-- but so is GUE and Geneve without any options present (they all resolve to a simple fixed length 8 byte headers that can no doubt be implemented in switching ASICs with equal ease). But, if you take into account processing options for extensibility which would be TLVs in Geneve, flag-fields in GUE, and NSH with VXLAN-GPE as you suggested-- then GUE is the most friendly to HW (parsing is amenable to implement by TCAM for instance), and Geneve is likely easier to process since TLVs in one protocol header is more straightforward for processing a header chain (e.g. IP options vs. ext. hdrs. experience).
Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
