On 3/27/14, 4:25 PM, Tom Herbert wrote:
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.
Somewhat, but I imagine that the SAs would most likely between
physical machines (not per vni) in which case a corrupted vni is still
a problem.
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?
Inside, next header for ESP is 0x4 or 0x29.
I see, not exactly the way IPsec uses ESP, but I understand what you're
trying to do.
In our deployments we have used IPsec tunnel mode there, that introduces
some redundancy, but allows to reuse quite a few pieces of existing
implementations.
If you have a "transport independent" version of ESP you could apply
that transformation right after the network virtualization header, and
protect the metadata together with the payload. Using an authenticated
encryption mode with support for Additional Authenticated Data you could
selectively provide integrity protection or confidentiality+integrity
protection to different portions of the metadata.
Fabio
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
