Re: [nvo3] [Last-Call] Last Call: <draft-ietf-nvo3-geneve-14.txt> (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard

Hi Daniel,

Speaking as individual with chair hat off.

I'll let authors detail more responses. See
 inline for my comments.

On Wed, Nov 27, 2019, 2:35 AM Daniel Migault <daniel.migault=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> I do have some architecture concerns regarding the Geneve specification.
> My concerns have already been raised to the WG but I have not been
> convinced these have been resolved. I am not claiming that I am not wrong
> nor that I am not on the rough but for more transparency, I prefer
> reiterating my concern.
>
These were discussed at the mic and I personally think the concerns were
not valid or valid ones were already addressed. Neither does the WG shared
the concerns you are expressing, reading from the comments from authors and
folks at the mic (refer to meeting minutes)

>
> In my opinion, the transit devices that are not part of the generic NVO3
> architecture RFC8014 should not be part of the Geneve specification as they
> do raise - at least to me - significant concerns.
>
> Transit devices are placed on-path of a session established between end
> points (NVE) which results in a three parties communication.
>
You are assuming the requirement here, when there is none.

The absence of explicit signaling between the the NVE and the transit
> device contradicts of rfc8558 - though mostly focused on TCP. The
> consequence I am concerned is, in my opinion, that the presence of transit
> devices will slow down or prevent securing NVE-to-NVE communications.
>
Says who?. Speaking with deployment experience of overlay network, what you
mention is hypothesis. This is not how things work. Transit device is not
in the mix when overlay dataplane is setup.

Typically, the document recommends securing the NVE-to-NVE communication
> with DTLS or IPsec which results in "bypassing" the transit devices. While
> the draft specifies the transit devices should not block an encrypted
> communication, my concern is that encrypting communications makes transit
> devices useless.
>
It is intended and as per arch RFC.

In that sense, a NVE that is not aware that no transit devices are on its
> path will not secure the NVE-to-NVE communication.
>
Please do not make assumptions. Real deployment do not go by assumption.
Security of the traffic is by design and not because of transit device or
whether NVE has that info. You are introducing totally non-existent
requirement of NVEs being aware of transit devices. In my deployment,
traffic is secured, based on how we set up overlays, not because it has to
transit or not. That is outside the scope of dataplane.

As a result, my understanding is that with DTLS/IPsec: either the transit
> devices constitute a major obstacle to the deployment of securing
> NVE-to-NVE communications or transit devices have been designed to be
> useless.
>
Your assumption is wrong and not true.

>
> Note that communication security does not necessarily needs to be
> performed by DTLS or IPsec, and that securing at the overlay
> layer could accommodate the transit device. However, there has been no
> consensus on the security requirements yet, so in my opinion it is
> premature to rely on such mechanisms.
>
I would advise the authors of requirements draft (if there exists one)
publish and start building consensus with the WG, if certain new arch for
overlays has to be undertaken. Based on the adopted arch/rfc, the geneve
draft is inline with the arch.

Cheers
Sam

>
> Yours,
> Daniel
>
>
> On Thu, Oct 24, 2019 at 2:42 PM The IESG <iesg-secretary@ietf.org> wrote:
>
>>
>> The IESG has received a request from the Network Virtualization Overlays
>> WG
>> (nvo3) to consider the following document: - 'Geneve: Generic Network
>> Virtualization Encapsulation'
>>   <draft-ietf-nvo3-geneve-14.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> last-call@ietf.org mailing lists by 2019-11-07. Exceptionally, comments
>> may
>> be sent to iesg@ietf.org instead. In either case, please retain the
>> beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    Network virtualization involves the cooperation of devices with a
>>    wide variety of capabilities such as software and hardware tunnel
>>    endpoints, transit fabrics, and centralized control clusters.  As a
>>    result of their role in tying together different elements in the
>>    system, the requirements on tunnels are influenced by all of these
>>    components.  Flexibility is therefore the most important aspect of a
>>    tunnel protocol if it is to keep pace with the evolution of the
>>    system.  This document describes Geneve, an encapsulation protocol
>>    designed to recognize and accommodate these changing capabilities and
>>    needs.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ballot/
>>
>> The following IPR Declarations may be related to this I-D:
>>
>>    https://datatracker.ietf.org/ipr/2424/
>>    https://datatracker.ietf.org/ipr/2423/
>>
>>
>>
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>