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