On 7/29/16 11:45 AM, Tom Herbert wrote:
On Jul 29, 2016 11:12 AM, "Fabio Maino" <[email protected]
<mailto:[email protected]>> wrote:
>
> On 7/27/16 1:43 PM, Tom Herbert wrote:
>>
>> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino <[email protected]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
<[email protected] <mailto:[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?
>
My major objections are lack of security and extensibility. The
counter argument seems to be use a shim header for security or
extensions, but there has never be any specifics offered (I have asked
several times now how to implement a 64 bit security cookie in
VXLAN-GPE). Also the security considerations section in the draft
provides no useful guidance.
In my data center if we are going to commit to using a protocol for
the long term (like if we buy into HW support), I need to believe it
is adaptable to face changing security risks and new technologies. I
know how to extend GUE and in fact we have useful extensions defined.
I believe I would know how to extend Geneve, although I still wish
there were some standard TLVs spec'ed. However, I don't know how
extend VXLAN-GPE. I can't afford to find out two years from now that I
need switch protocols because we can't adapt the running protocol.
This is particularly true in data center security, the demands for
strong security mechanisms will only be increasing-- I need a protocol
that can deal with that...
This is all just my opinion of course :-)
I think that the point at hand here is that the AD is pushing the WG to
have a discussion on which encapsulations should be selected for
standard track. What should guide that decision are the requirements
emerging from the set of documents that are adopted by the WG.
As I said in the previous message, IMO VXLAN-GPE does address the
security requirements as expressed in
draft-ietf-nvo3-security-requirements. I note that you have not objected
to that point.
Also, I pointed to NSH as ONE example of how VXLAN-GPE can be extended
using a shim header. NSH implements SFC and metadata transport. Looking
at what NSH + VXLAN-GPE achieves, it makes fairly hard to maintain that
VXLAN-GPE is not extensible. Extensibility is achieved via layering. It
might not be the same way extensibility is achieved by the other
contenders, but it's a fairly established way to design protocols.
I think this should answer the objections to security and extensibility
for the purpose of the selection of an nvo3 encapsulation.
We can certainly have side conversations on how to address particular
functions of particular use cases using VXLAN-GPE, but IMO it won't add
much to the selection process that the AD is pushing for.
Fabio
Tom
>
> Thanks,
>
> Fabio
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
