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?
Thanks,
Fabio
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
