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...
Tom > Fabio > > > >> >>>> 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
