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.
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.
Lacking the requirement document, I'm sure we can add a paragraph in the
security section that describes how it can be done.
I'll be happy to work on whatever can move the WG out of this impasse.
Fabio
Thanks,
Tom
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
