On 3/26/14, 5:23 PM, Tom Herbert wrote:
On Wed, Mar 26, 2014 at 4:44 PM, Fabio Maino <[email protected]> wrote:
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.
I think my use case is pretty clear, we need the ability to validate a
vni before receiving at an end host. As you point out, this security
information only has meaning to end points, not to routing. I'm not
sure what "part of a metadata header" actually means, if this is a
reference to SFC, an actual example of how this could be accomplished
would be quite helpful!
that's not how SFC is defined today, because it's trying to address
another use case.
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.
We need the ability to encrypt and authenticate packets sent on the
overlay network. A secondary concern is keeping the virtualization
data (e.g. vni) in clear text so we can still route based on it in the
network.
One interesting aspect is that when the inner payload is IPsec
encrypted, the integrity of the vni becomes less critical. It's not
addressing all use cases, but in many it helps.
By the way, I'm not sure I understand where's the inner IP header in the
picture below. Inside or outside the ESP payload?
Fabio
Here is the text from GUE which describes a way to accomplish
this using IPsec:
"
We expect that GUE may be used to encapsulate IPsec packets. This
allows the benefits of deriving a flow hash for the inner,
potentially encrypted, packet. In this case the protocol stack may
be:
+-----------------------------+
| |
| UDP/IP header |
| |
|-------------------------------|
| |
| GUE Header |
| |
|-------------------------------|
| |
| ESP/AH/private security |
| |
|-------------------------------|
| |
| Encapsulated packet |
| |
+-------------------------------+
Note that the security does not cover the GUE header (does not
authenticate it for instance). The GUE security field may be used to
provide authentication or integrity of the GUE header.
"
Tom
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
