On Wed, Aug 3, 2016 at 3:54 PM, Fabio Maino <[email protected]> wrote: > On 8/3/16 3:38 PM, Tom Herbert wrote: >> >> 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). > > > The amount of buffering required, and the number and ordering of options > makes a difference as well. TCAM adds to the cost and is a resource > contended by other functions in the ASIC. Given that the HW needs to be > re-spun anyway to process new features the flexibility of the protocol > itself doesn't make much of a difference. > Fabio,
Sorry if it seems like I'm being contentious, but I really would like to understand the what your concerns are. Your statement was "Considerations on implementability of an approach is, in my opinion, a very significant technical concern in selecting a standard.". Yes I agree, infeasibility in implementation would be a valid technical objection. But as Matthew as stated in the original email thread "Please be as concrete and detailed as possible as to your technical objection.". I would infer that you're objecting that to Geneve and GUE because they are less implementable in HW than VXLAN-GPE. If that is indeed your technical objection to those protocols, can you provide a concrete and detailed explanation why you consider VXLAN-GPE to be more implementable in HW? Thanks, Tom > Fabio > > > >> >> Tom > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
