Tom,
I think we're back to where this conversation started: definition of use
cases.
Why the vni authentication tag you're proposing couldn't be part of a
metadata header? The network may be able and willing to use the vni for
routing, but won't certainly be able to use the vni authentication tag
whose key is known only to the endpoints. Those kind of questions will
drive the design. I think it's hard to ask implementations to bear the
cost of metadata that may or may not be used without articulating for
which use cases the metadata will be used.
Also, I'm not saying that all the use cases can be addressed by existing
mechanisms, but I suspect that some are. You'll be looking at payload
confidentiality, as another security use case. I guess it would be a
good idea to look at IPsec (or maybe MACsec for a L2 overlay) for that
one, and not reinvent the whole shebang at network virtualization
layer... or maybe not. One way to find out is to articulate the use case.
Fabio
On 3/25/14, 11:59 AM, Tom Herbert wrote:
That's a great write up. Thanks especially for the appendix that articulates
very well the motivations that are driving the effort of using the
optimization provided by current NICs.
I think the design of the protocol would benefit from a better separation of
the network virtualization layer and the metadata layer. It would allow each
implementation (at the end host or in the network) to implement
independently part of the specification, and will eventually help with
adoption. I think with a better layering you could also take advantage of
other well established features (such as security, for example) that you may
want to reuse, rather than reinvent.
I think you're viewing the meta-data as being a discrete idempotent
pieces of data which are not intrinsic to network virtualization. This
true is some cases, but not in all cases. For example, my first need
for meta-data is for providing integrity and authentication of the
vni. Isolation is a hard requirement in network virtualization, and it
follows that the we need protocols to guarantee that. As I already
pointed out, we cannot rely on the network to be error free nor always
provide adequate security. So I believe that some sort of security
bits are pretty much mandatory to protect the vni in every
encapsulated packet. This becomes inseparable from the vni since the
end host cannot accept the packet without the data to verify the vni.
By the way in GUE, the vni is itself just "meta data", GUE is a
general encapsulation protocol which is not virtualization specific--
this will allow us to use a common encapsulation for different use
cases.
Packet security is also important and this is a case where we do want
to use well established mechanisms (like IPsec). This was an important
consideration in GUE: how can we use security like IPsec but still
allow visibility to the encapsulation data for consumption by devices
in the network.
After security, the next challenge will likely be congestion control.
We need congestion control which can be applied to third party traffic
to bring it into conformance with CC in the native network.
Theoretically, we can insert a DCCP header after GUE, but that seems
like a lot of overkill. This may be a case where additional meta data
is justified.
Tom
Fabio
Thanks,
Tom
Regards,
Fabio
A.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
