Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

Actually recomposing the VXLAN/LISP splitting was another design goal of 
VXLAN-GPE. A VXLAN-GPE implementation can share most of its code with a 
LISP implementation, contributing to the reduction of test and 
implementation cost.


Fabio


On 8/5/16 9:21 AM, Jesse Gross wrote:

On Aug 5, 2016, at 8:01 AM, Dino Farinacci  wrote:


In addition, while you are trying to optimize for one particular implementation 
and architecture, the long term results of these decisions tend to impact many 
more platforms than the original one. For example, VXLAN was derived from LISP 
with the same goals as you are describing here. However, I suspect that many of 
the platforms that now implement VXLAN never had LISP support in the first 
place. These implementations must now carry the historical baggage so from a 
global perspective this did not turn out to be an optimization after all.

In practice, there really isn’t historical baggage. And if you build something 
to last 10 years and think it won’t change, having options in the header is 
good.

I think that if you look at the header layout for VXLAN-GPE (as a further evolution 
from LISP->VXLAN->VXLAN-GPE) without knowing the historical context, most 
people would find it a bit odd. In particular, I’ve heard numerous people ask why the 
‘I’ bit must be set in VXLAN. These types of issues cause confusion, introduce 
undefined error states into the protocol, and waste bits in the header. You can argue 
about whether carrying this legacy forward was a worthwhile tradeoff but it’s clear 
that there is historical baggage.


But changing to a different protocol all together and having different options 
in one protocol IS exactly the same result. THERE ARE CHANGES for the vendor 
and the deployer.

I don’t agree that the impact from all changes is the same. After all, the 
stated reason for extending existing header formats is to reduce test and 
implementation cost. To me, the best way to achieve this is to have a protocol 
that has a well defined structure that enables incremental extensions while 
sharing core functionality. In the immediate term this might be a bigger change 
but over the long term, I believe that it will result in less complexity, and 
yes, less cost.



___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Jesse Gross]

> On Aug 5, 2016, at 8:01 AM, Dino Farinacci  wrote:
> 
>> In addition, while you are trying to optimize for one particular 
>> implementation and architecture, the long term results of these decisions 
>> tend to impact many more platforms than the original one. For example, VXLAN 
>> was derived from LISP with the same goals as you are describing here. 
>> However, I suspect that many of the platforms that now implement VXLAN never 
>> had LISP support in the first place. These implementations must now carry 
>> the historical baggage so from a global perspective this did not turn out to 
>> be an optimization after all.
> 
> In practice, there really isn’t historical baggage. And if you build 
> something to last 10 years and think it won’t change, having options in the 
> header is good. 

I think that if you look at the header layout for VXLAN-GPE (as a further 
evolution from LISP->VXLAN->VXLAN-GPE) without knowing the historical context, 
most people would find it a bit odd. In particular, I’ve heard numerous people 
ask why the ‘I’ bit must be set in VXLAN. These types of issues cause 
confusion, introduce undefined error states into the protocol, and waste bits 
in the header. You can argue about whether carrying this legacy forward was a 
worthwhile tradeoff but it’s clear that there is historical baggage.

> But changing to a different protocol all together and having different 
> options in one protocol IS exactly the same result. THERE ARE CHANGES for the 
> vendor and the deployer.

I don’t agree that the impact from all changes is the same. After all, the 
stated reason for extending existing header formats is to reduce test and 
implementation cost. To me, the best way to achieve this is to have a protocol 
that has a well defined structure that enables incremental extensions while 
sharing core functionality. In the immediate term this might be a bigger change 
but over the long term, I believe that it will result in less complexity, and 
yes, less cost.
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Tom Herbert]

> Tom,
> it's more than just infeasibility that should be considered as part of the
> technical evaluation, but also the cost/complexity associated with
> implementations.
>
> Encapsulations are not implemented in a vacuum, but compete with other
> features for resources available in a given platform. VXLAN-GPE was designed
> to be a superset of VXLAN. VXLAN happens to exist as a legacy encapsulation
> and will likely be around for quite some time. An implementation of
> VXLAN-GPE makes a more efficient use of resources on platforms that need
> also to support VXLAN (that to my knowledge are a very significant chunk of
> the implementations out there). This is particularly true for
> fixed-functions ASICs, but I think it stands true for other platforms as
> well when you consider the cost/complexity of verification and testing.
>

Fabio,

GUE is based on GRE which is one of the world's most mature and
deployed encapsulation protocols. GRE is the only protocol we've found
with variable length headers that is commonly processed by both switch
and NIC hardware. We would have used GRE for our deployment but its
extensibility is too limited.

> Then there's the cost/complexity associated with the transport of metadata.
> I think that a parser for a fixed length portion of a header with an ordered
> set of metadata can be implemented with less cost/complexity than a parser
> for a variable length header where metadata can appear in any order. This is
> particularly evident in fixed-function ASICs. IMO, a mandatory to implement
> encapsulation, shouldn't force implementations to deal with variable length
> unordered sets of metadata.
>
Options in GUE are will ordered, it does not have the combinatoric
complexity associated with TLVs. draft-herbert-gue-extensions shows
the GUE header with all the currently proposed fundament encapsulation
options:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   |Source port|  Destination port  | \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
   |   Length  |  Checksum | /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |Ver|C|   Hlen  |  Proto/ctype  |V|SEC|K|F|T|R|   Rsvd Flags|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |VNID (optional)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~  Security (optional)  ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Checksum (optional) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   + Fragmentation (optional)  +
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Payload transform (optional |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Remote checksum offload (optional)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~   Private fields (optional)   ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that for any combination of options (indicated by set flags)
there is only _one_ possible ordering. So the total number of possible
unique packet formats is 2^N where N is number of option bits. The
number variants of the GUE header is thus 128. To contrast, if these
options were in TLVs the number of possible orderings of the TLVs is
greater than 10,000-- this is the combinatoric nature of TLVs. 128
combinations is small enough that it is feasible to implementing
option parsing with parallel HW techniques (like a TCAM as an
example).

Another important field in the GUE header is Hlen. This provides two
important features:

1) It puts a hard limit on the amount of header that can be used for
options. This is important because a lot of HW implementation can only
load the first N bytes of a packet into their cache for parsing. The
limit also presents the possibility of DOS attack where an attacker
fills up a whole packet with dummy headers like can happen with IPv6
extension headers.
2) The Hlen provides a means for middleboxes to skip over the options
so that it can parse the payload. 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Dino Farinacci]

> In addition, while you are trying to optimize for one particular 
> implementation and architecture, the long term results of these decisions 
> tend to impact many more platforms than the original one. For example, VXLAN 
> was derived from LISP with the same goals as you are describing here. 
> However, I suspect that many of the platforms that now implement VXLAN never 
> had LISP support in the first place. These implementations must now carry the 
> historical baggage so from a global perspective this did not turn out to be 
> an optimization after all.

In practice, there really isn’t historical baggage. And if you build something 
to last 10 years and think it won’t change, having options in the header is 
good. 

But changing to a different protocol all together and having different options 
in one protocol IS exactly the same result. THERE ARE CHANGES for the vendor 
and the deployer.

Dino

___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Jesse Gross]

> On Aug 4, 2016, at 5:53 PM, Fabio Maino  wrote:
> Tom,
> it's more than just infeasibility that should be considered as part of the 
> technical evaluation, but also the cost/complexity associated with 
> implementations.
> 
> Encapsulations are not implemented in a vacuum, but compete with other 
> features for resources available in a given platform. VXLAN-GPE was designed 
> to be a superset of VXLAN. VXLAN happens to exist as a legacy encapsulation 
> and will likely be around for quite some time. An implementation of VXLAN-GPE 
> makes a more efficient use of resources on platforms that need also to 
> support VXLAN (that to my knowledge are a very significant chunk of the 
> implementations out there). This is particularly true for fixed-functions 
> ASICs, but I think it stands true for other platforms as well when you 
> consider the cost/complexity of verification and testing.
> 
> Then there's the cost/complexity associated with the transport of metadata. I 
> think that a parser for a fixed length portion of a header with an ordered 
> set of metadata can be implemented with less cost/complexity than a parser 
> for a variable length header where metadata can appear in any order. This is 
> particularly evident in fixed-function ASICs. IMO, a mandatory to implement 
> encapsulation, shouldn't force implementations to deal with variable length 
> unordered sets of metadata.

The problem is, as you say, this particular encapsulation isn’t implemented in 
a vacuum. Given the number of variations and extensions that already exist for 
VXLAN, I think it’s pretty safe to say that things will continue to evolve. 
Going down the path that you are proposing here would almost certainly mean 
having several different protocols in the future with different interpretations 
and possibly lengths. It’s not obvious to me that this is preferable to having 
a single, extensible protocol from an implementation complexity or testing 
point of view.

In addition, while you are trying to optimize for one particular implementation 
and architecture, the long term results of these decisions tend to impact many 
more platforms than the original one. For example, VXLAN was derived from LISP 
with the same goals as you are describing here. However, I suspect that many of 
the platforms that now implement VXLAN never had LISP support in the first 
place. These implementations must now carry the historical baggage so from a 
global perspective this did not turn out to be an optimization after all.
___
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

On 8/3/16 4:34 PM, Tom Herbert wrote:

On Wed, Aug 3, 2016 at 3:54 PM, Fabio Maino  wrote:

On 8/3/16 3:38 PM, Tom Herbert wrote:

On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino  wrote:

On 8/1/16 4:21 PM, Alia Atlas wrote:



On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert  wrote:

On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino  wrote:

On 7/29/16 6:38 PM, Jesse Gross wrote:

On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:

On 7/29/16 12:44 PM, Jesse Gross wrote:

On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:

On 7/29/16 11:45 AM, Tom Herbert wrote:

On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:

On 7/27/16 1:43 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino 
wrote:

On 7/27/16 12:27 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino

wrote:

On 7/27/16 10:53 AM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci

wrote:

On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)

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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Tom Herbert]

On Wed, Aug 3, 2016 at 3:54 PM, Fabio Maino  wrote:
> On 8/3/16 3:38 PM, Tom Herbert wrote:
>>
>> On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino  wrote:
>>>
>>> On 8/1/16 4:21 PM, Alia Atlas wrote:
>>>
>>>
>>>
>>> On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert  wrote:

 On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino  wrote:
>
> On 7/29/16 6:38 PM, Jesse Gross wrote:
>>>
>>> On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:
>>>
>>> On 7/29/16 12:44 PM, Jesse Gross wrote:
>
> On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
>
> On 7/29/16 11:45 AM, Tom Herbert wrote:
>>
>> On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
>>>
>>> On 7/27/16 1:43 PM, Tom Herbert wrote:

 On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino 
 wrote:
>
> On 7/27/16 12:27 PM, Tom Herbert wrote:
>>
>> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino
>> 
>> wrote:
>>>
>>> On 7/27/16 10:53 AM, Tom Herbert wrote:

 On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
 
 wrote:
>>
>> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
>> 
>> 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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Tom Herbert]

On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino  wrote:
> On 8/1/16 4:21 PM, Alia Atlas wrote:
>
>
>
> On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert  wrote:
>>
>> On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino  wrote:
>> > On 7/29/16 6:38 PM, Jesse Gross wrote:
>> >>>
>> >>> On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:
>> >>>
>> >>> On 7/29/16 12:44 PM, Jesse Gross wrote:
>> >
>> > On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
>> >
>> > On 7/29/16 11:45 AM, Tom Herbert wrote:
>> >>
>> >> On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
>> >>>
>> >>> On 7/27/16 1:43 PM, Tom Herbert wrote:
>> 
>>  On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino 
>>  wrote:
>> >
>> > On 7/27/16 12:27 PM, Tom Herbert wrote:
>> >>
>> >> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino
>> >> 
>> >> wrote:
>> >>>
>> >>> On 7/27/16 10:53 AM, Tom Herbert wrote:
>> 
>>  On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
>>  
>>  wrote:
>> >>
>> >> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
>> >> 
>> >> 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

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

On 8/1/16 4:21 PM, Alia Atlas wrote:



On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert > wrote:


On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino > wrote:
> On 7/29/16 6:38 PM, Jesse Gross wrote:
>>>
>>> On Jul 29, 2016, at 4:39 PM, Fabio Maino > wrote:
>>>
>>> On 7/29/16 12:44 PM, Jesse Gross wrote:
>
> On Jul 29, 2016, at 12:17 PM, Fabio Maino > wrote:
>
> On 7/29/16 11:45 AM, Tom Herbert wrote:
>>
>> On Jul 29, 2016 11:12 AM, "Fabio Maino" > wrote:
>>>
>>> On 7/27/16 1:43 PM, Tom Herbert wrote:

 On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino
>
 wrote:
>
> On 7/27/16 12:27 PM, Tom Herbert wrote:
>>
>> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino
>
>> wrote:
>>>
>>> On 7/27/16 10:53 AM, Tom Herbert wrote:

 On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
 >
 wrote:
>>
>> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
>> >
>> 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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Alia Atlas]

On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert  wrote:

> On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino  wrote:
> > On 7/29/16 6:38 PM, Jesse Gross wrote:
> >>>
> >>> On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:
> >>>
> >>> On 7/29/16 12:44 PM, Jesse Gross wrote:
> >
> > On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
> >
> > On 7/29/16 11:45 AM, Tom Herbert wrote:
> >>
> >> On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
> >>>
> >>> On 7/27/16 1:43 PM, Tom Herbert wrote:
> 
>  On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino 
>  wrote:
> >
> > On 7/27/16 12:27 PM, Tom Herbert wrote:
> >>
> >> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  >
> >> wrote:
> >>>
> >>> On 7/27/16 10:53 AM, Tom Herbert wrote:
> 
>  On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
>  
>  wrote:
> >>
> >> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
> >> 
> >> 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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

On 7/29/16 6:38 PM, Jesse Gross wrote:

On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:

On 7/29/16 12:44 PM, Jesse Gross wrote:

On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:

On 7/29/16 11:45 AM, Tom Herbert wrote:

On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:

On 7/27/16 1:43 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:

On 7/27/16 12:27 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:

On 7/27/16 10:53 AM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
wrote:

On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
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. 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Jesse Gross]

> On Jul 29, 2016, at 4:39 PM, Fabio Maino  wrote:
> 
> On 7/29/16 12:44 PM, Jesse Gross wrote:
>>> On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
>>> 
>>> On 7/29/16 11:45 AM, Tom Herbert wrote:
 On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
> On 7/27/16 1:43 PM, Tom Herbert wrote:
>> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:
>>> On 7/27/16 12:27 PM, Tom Herbert wrote:
 On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:
> On 7/27/16 10:53 AM, Tom Herbert wrote:
>> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
>> 
>> wrote:
 On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
 
 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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

On 7/29/16 12:44 PM, Jesse Gross wrote:

On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:

On 7/29/16 11:45 AM, Tom Herbert wrote:

On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:

On 7/27/16 1:43 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:

On 7/27/16 12:27 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:

On 7/27/16 10:53 AM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
wrote:

On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Tom Herbert]

On Fri, Jul 29, 2016 at 12:44 PM, Jesse Gross  wrote:
>
>> On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
>>
>> On 7/29/16 11:45 AM, Tom Herbert wrote:
>>> On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
>>> >
>>> > On 7/27/16 1:43 PM, Tom Herbert wrote:
>>> >>
>>> >> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:
>>> >>>
>>> >>> On 7/27/16 12:27 PM, Tom Herbert wrote:
>>> 
>>>  On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:
>>> >
>>> > On 7/27/16 10:53 AM, Tom Herbert wrote:
>>> >>
>>> >> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
>>> >> 
>>> >> wrote:
>>> 
>>>  On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
>>>  
>>>  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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Jesse Gross]

> On Jul 29, 2016, at 12:17 PM, Fabio Maino  wrote:
> 
> On 7/29/16 11:45 AM, Tom Herbert wrote:
>> On Jul 29, 2016 11:12 AM, "Fabio Maino"  wrote:
>> >
>> > On 7/27/16 1:43 PM, Tom Herbert wrote:
>> >>
>> >> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:
>> >>>
>> >>> On 7/27/16 12:27 PM, Tom Herbert wrote:
>> 
>>  On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:
>> >
>> > On 7/27/16 10:53 AM, Tom Herbert wrote:
>> >>
>> >> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
>> >> wrote:
>> 
>>  On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
>>  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 

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

[Fabio Maino]

On 7/27/16 1:43 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino  wrote:

On 7/27/16 12:27 PM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino  wrote:

On 7/27/16 10:53 AM, Tom Herbert wrote:

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci 
wrote:

On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) 
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
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3