On 8/1/16 4:21 PM, Alia Atlas wrote:
On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert <t...@herbertland.com
<mailto:t...@herbertland.com>> wrote:
On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino <fma...@cisco.com
<mailto:fma...@cisco.com>> wrote:
> On 7/29/16 6:38 PM, Jesse Gross wrote:
>>>
>>> On Jul 29, 2016, at 4:39 PM, Fabio Maino <fma...@cisco.com
<mailto:fma...@cisco.com>> wrote:
>>>
>>> On 7/29/16 12:44 PM, Jesse Gross wrote:
>>>>>
>>>>> On Jul 29, 2016, at 12:17 PM, Fabio Maino <fma...@cisco.com
<mailto:fma...@cisco.com>> wrote:
>>>>>
>>>>> On 7/29/16 11:45 AM, Tom Herbert wrote:
>>>>>>
>>>>>> On Jul 29, 2016 11:12 AM, "Fabio Maino" <fma...@cisco.com
<mailto:fma...@cisco.com>> wrote:
>>>>>>>
>>>>>>> On 7/27/16 1:43 PM, Tom Herbert wrote:
>>>>>>>>
>>>>>>>> On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino
<fma...@cisco.com <mailto:fma...@cisco.com>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 7/27/16 12:27 PM, Tom Herbert wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino
<fma...@cisco.com <mailto:fma...@cisco.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 7/27/16 10:53 AM, Tom Herbert wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci
>>>>>>>>>>>> <farina...@gmail.com <mailto:farina...@gmail.com>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino)
>>>>>>>>>>>>>> <fma...@cisco.com <mailto:fma...@cisco.com>>
>>>>>>>>>>>>>> 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.
>>>>
>>>> The issue with shim headers is that introducing a new one
breaks the
>>>> ability of existing implementations to parse the packet.
There are a lot of
>>>> use cases where just being able to get to the packet data is
hugely useful -
>>>> a NIC steering incoming frames to a VM shouldn’t need to be
modified for
>>>> every use case. Even simple examples like tcpdump/Wireshark
benefit from
>>>> this - it’s really useful to be able to generally get a look
at a packet
>>>> even if it doesn’t understand everything. With both Geneve
and GUE this is
>>>> possible but not with the design that you are describing with
VXLAN-GPE.
>>>
>>> That approach forces your customers to pay upfront for the cost of
>>> buffering metadata that their devices don't know how to
handle, and/or they
>>> may never use. To implement a new feature, you'll need buffers
AND logic.
>>>
>>> Even if you allocate buffer in advance (before the feature is
specified),
>>> you'll have to spin a new version of the HW to add the logic
that addresses
>>> that new feature.
>>>
>>> In this sense VXLAN-GPE allows an implementor to be sensible in
>>> allocating resources, by using only the buffer space that is
actually needed
>>> by that specific implementation.
>>>
>>> I suspect that the result of the pressure of cost on
implementations will
>>> be such that, some HW implementations of Geneve, may implement
only the
>>> basic functions, restricting to very few, if any, support for
variable
>>> length options. Packets with unknown options will be
eventually punted to
>>> the slow path, and vendors will claim support for the protocol.
>>>
>>> This is not very different from how an unknown shim header will be
>>> handled. Flexibility and HW implementations might be a bit of
a unicorn…
>>
>> I think that you are making some specific assumptions about the
types of
>> implementations here. In particular, you are assuming that the
only device
>> class is a fixed-function switching ASIC. The comments don’t
really apply to
>> software, NICs, or even the more programmable switching ASICs
that are
>> starting to come out.
>>
>> In that specific situation, I agree that it doesn’t make sense
to include
>> elements of an implementation that can’t be usefully deployed.
However, in
>> cases where the device would need to be respun to include new
logic, I doubt
>> that anyone would prematurely include vestigal pieces that
would drive up
>> the cost. They would simply implement the support as necessary
and the cost
>> would reflect what the device is capable of doing. This is
similar to
>> VXLAN-GPE in that regard.
>>
>> However, I don’t believe that networks consist exclusively of fixed
>> switching ASICs. As I mentioned before, there are many other
components that
>> can take advantage of extensibility. I don’t see that it is
necessary to
>> deny them those benefits even if some devices may need to be
incrementally
>> respun.
>
>
> This diverse base of implementation platforms is, IMO, what
makes hard to
> select a single encap for the nvo3 use case. A feature of the
protocol that
> might be a benefit for one platform, introduces significant
> costs/disadvantages when deployed in another one.
>
Can you give a specific example of a feature that demonstrates this?
With regards to extensibility I am not seeing why using NSH has lower
costs or fewer disadvantages to deploy compared to flag-fields in GUE
or even TLVs in Geneve...
[Alia] Do recall that the question is around significant technical
concerns that
must be addressed. It isn't whether one approach is "better" or
"easier" for a
particular deployment scenario as compared to another.
The major concern comes from selecting a single MUST implement
encapsulation that has the option to include hundreds of bytes of
unstructured, variable length metadata. Such a feature is fairly
unfriendly to implement in fixed switching ASICs.
Considerations on implementability of an approach is, in my opinion, a
very significant technical concern in selecting a standard.
Fabio
Regards,
Alia
Tom
> Fabio
>
>
>
>>
>>>> What you are describing is essentially the same as IPv6 extension
>>>> headers vs. IPv4 options. Anecdotally, I’ve seen a lot more
bugs in
>>>> implementations of IPv6 extension headers even in very common
cases. The
>>>> reason is that with IPv6, it’s necessary to traverse
different shim headers,
>>>> which themselves have different locations of next protocol
field is, etc. At
>>>> least with IPv4, getting to the data is very simple and
consistent.
>>>
>>> This is actually a good example for the counter argument: many
vendors
>>> couldn't justify the cost of supporting IPv4 option in the
fast path, and
>>> packet with IP options, in many implementations, were punted
to the slow
>>> path. This quickly drove developers to abandon use of IP
options in their
>>> applications, as it was almost a guarantee to send their flows
in the slow
>>> path. Some time too much flexibility is bad (especially when
cost is an
>>> issue).
>>>
>>> For IPv6 extension headers, use cases will determine (are
determining)
>>> which ones are worth the extra cost in the fast path and
vendors will act
>>> accordingly. Fittest options will survive…
>>
>> Yes, I certainly agree that vendors will act according to the
needs that
>> they see in the market. I think it’s been said a number of
times in the
>> working group that extensibility is a “use it or lose it” type
of thing.
>> Since IP options didn’t have immediate important uses when it
was first
>> being implemented, there was little sense in handling them. In
contrast, TCP
>> options are alive and well these days because there are good
uses for them.
>> I know that TCP is generally implemented in software instead of
hardware but
>> I can assure you the desire to take shortcuts is plenty strong
in the
>> software industry.
>>
>> In the specific case of Geneve, I gave some information about
some of the
>> implementations I’ve personally seen and their capabilities a
while back
>>
(https://mailarchive.ietf.org/arch/msg/nvo3/HTSXROpKwman1Bd4fAlmmfZF_P8).
>> Since options are the core reason for Geneve existing (it’s the
main thing
>> that separates it from VXLAN), there’s been much more awareness
that it is
>> important and useful to implement them.
>>
>>>> To make this very concrete: I know that there a number of NIC
vendors
>>>> that have implemented support for VXLAN-GPE offloading
already. If a shim
>>>> header was introduced to add VNI security as you are
describing, these
>>>> offloads would suddenly become useless. That does not seem
like a very good
>>>> definition of extensibility to me.
>>>
>>>
>>> Similarly to those vendors that might have implemented Geneve
in the fast
>>> path, and want to add support for a new optional extension.
With the
>>> difference that their customers will have paid already for the
cost of extra
>>> buffering even in the first release that had no support for
that new option.
>>
>> In the specific example that I gave (NICs), that is not really
true. As
>> new Geneve options are introduced the existing cards will
continue to work
>> (GUE also has this property). This is because these offloads
are primarily
>> operating on the payload while the option logic is handled in
the host CPU.
>> For server-based tunnel termination this ability to continue to
offload as
>> the protocol evolves is a significant benefit.
>
>
>
_______________________________________________
nvo3 mailing list
nvo3@ietf.org <mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
