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

From: Daniel Migault <[email-masked]>
Date: Tue, 26 Nov 2019 16:05:03 -0500

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.

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. 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. 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. 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. 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.

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.

Yours,
Daniel

On Thu, Oct 24, 2019 at 2:42 PM The IESG <[email-masked]> 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
> [email-masked] mailing lists by 2019-11-07. Exceptionally, comments
> may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 27 Nov 2019 18:39:45 +0530

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=
[email-masked]> 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)

> 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
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

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Nov 2019 15:45:33 +0000

Hi Sam,

Thanks for the feed backs. See my responses.

Yours,
Daniel

From: Sam Aldrin <[email-masked]>
Sent: Wednesday, November 27, 2019 8:10 AM
To: Daniel Migault <[email-masked]>
Cc: [email-masked]; Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; NVO3 <[email-masked]>; [email-masked]
Subject: Re: [Last-Call] Last Call: <draft-ietf-nvo3-geneve-14.txt> (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard

Hi Daniel,

On Wed, Nov 27, 2019, 2:35 AM Daniel Migault <daniel.migault=[email-masked]<mailto:[email-masked]>> 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).

<mglt > I agree with you this has been exposed / discussed in session and on the mailing list. I also agree that the WG did not shared my concerns. However it is hard for me to evaluate if the reason is that my concerns were not valid or because the security was under-represented. In any case, I have not been convinced my concerns did not applied and I am not in a position I can say I understand the design choice, that is a reasonable choice.

Early version of the “geneve security requirement” pointed out some complexity/flaws associated to the  transit devices. While some concerns raised are reflected in the current document, this work has not yet been completed yet and security of NVE-to-NVE communications in conjunction of transit device still remain unclear to me at that time.

From all discussions, in my perspective, transit devices should not be mentioned as they raise concerns – at least to me. That said, I would probably not have raised any concerns if they were described in the appendix in an non normative section, if necessary.
</mglt>

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.

<mglt>I understand your comment as I am assuming any NVE-to-NVE sessions have a transit device. If I interpreter correctly your comment, this is not what I intended to say. Instead, I am saying that transit devices when they exist are placed on path of a NVE-to-NVE communication. If this is not correct, than I understand transit devices would be out of scope of the nvo3 architecture.</mglt>

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.

<mglt>I understand your comment as any administrator has a full control of NVEs and transit devices. In other words, because we are in a controlled environment, the information a transit device is on path is known. The problem however, appears to me similar as the core of the problem is the interaction between the transit devices and the security layer used to secure NVE-to-NVE communications. -- It basically moves the problem from securing communication that do not have on-path transit devices to configuring the network with transit devices out of the path of NVE-to-NVE communications that needs to be secured. In any case, securing these NVE-to-NVE communications will result in disabling the transit devices functions which represents, unless this transit devices functions are useless, a major operational change. The perspective of this change is likely to result in not securing the NVE-to-NVE communication.</mglt>

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.
<mglt>If the arch RFC is 8014, I do not see any transit devices, thought I may have missed them in the document or consider an inappropriate document </mglt>

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.

<mglt>As mentioned above the problem is related to the interaction between transit device and end-to-end security protocols, not the way these are deployed. </mglt>

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.

<mglt> As mentioned above, the problem is due to interactions between DTLS and transit devices. </mglt>

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.

<mglt> This comment seems to indicate a commitment that security will be addressed the security concerns. The history of security in this working group is relatively bad. “nvo3 security requirements” [1] is an abandoned wg document since 2016  and the “geneve security requirements” [2] did not pass the call for adoption. As a result, a commitment related to security seems to me unrealistic for now. </mglt>

[1] https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07
[2] https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
[3] https://mailarchive.ietf.org/arch/msg/nvo3/AfwANpWA3sfH_TMVuQp0GhWWOOw

Cheers
Sam

Yours,
Daniel

On Thu, Oct 24, 2019 at 2:42 PM The IESG <[email-masked]<mailto:[email-masked]>> wrote:

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
[email-masked]<mailto:[email-masked]> mailing lists by 2019-11-07. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

_______________________________________________
IETF-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-announce
--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 28 Nov 2019 02:02:15 -0800

Hi Daniel,

Please find my responses inline.

-sam

On Wed, Nov 27, 2019 at 7:45 AM Daniel Migault <[email-masked]>
wrote:

> *From:* Sam Aldrin <[email-masked]>
> *Sent:* Wednesday, November 27, 2019 8:10 AM
> *To:* Daniel Migault <[email-masked]>
> *Cc:* [email-masked]; Bocci, Matthew (Nokia - GB) <
> [email-masked]>; [email-masked]; NVO3 <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Last-Call] Last Call: <draft-ietf-nvo3-geneve-14.txt>
> (Geneve: Generic Network Virtualization Encapsulation) to Proposed Standard
>
>
>
> Hi Daniel,
>
>
>
> folks at the mic (refer to meeting minutes).
>
>
>
> <mglt > I agree with you this has been exposed / discussed in session and
> on the mailing list. I also agree that the WG did not shared my concerns.
> However it is hard for me to evaluate if the reason is that my concerns
> were not valid or because the security was under-represented. In any case,
> I have not been convinced my concerns did not applied and I am not in a
> position I can say I understand the design choice, that is a reasonable
> choice.
>
%sam - Sure everyone has personal choice, which not necessary should be the
right one.

>
>
> Early version of the “geneve security requirement” pointed out some
> complexity/flaws associated to the  transit devices. While some concerns
> raised are reflected in the current document, this work has not yet been
> completed yet and security of NVE-to-NVE communications in conjunction of
> transit device still remain unclear to me at that time.
>
%sam - Referencing personal drafts cannot lead us to logical conclusion. If
there is an architecture requirement specified in the RFC 8014 or Framework
RFC 7365, and Geneve draft is contrary to that, we should discuss. I don't
see any of that thus far.

>
>
> From all discussions, in my perspective, transit devices should not be
> mentioned as they raise concerns – at least to me. That said, I would
> probably not have raised any concerns if they were described in the
> appendix in an non normative section, if necessary.
>
%sam - I would say, please refer to the early discussions of Arch and
Framework. Transit devices was explicitly not part of it. Bringing that up
is a new arch requirement and framework, which should follow the IETF due
process i.e. submit a requirement and associated drafts and discuss. From
my personal point view, we are discussing some assumptions, which were
neither documented or discussed/agreed upon.

> <mglt>I understand your comment as I am assuming any NVE-to-NVE sessions
> have a transit device. If I interpreter correctly your comment, this is not
> what I intended to say. Instead, I am saying that transit devices when they
> exist are placed on path of a NVE-to-NVE communication. If this is not
> correct, than I understand transit devices would be out of scope of the
> nvo3 architecture.</mglt>
>
%sam - What is 'placed'? There is no explicit placement or signalling about
transit devices. Yes, transit devices are out of scope. RFC8014.

> 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.
>
>
>
> <mglt>I understand your comment as any administrator has a full control of
> NVEs and transit devices. In other words, because we are in a controlled
> environment, the information a transit device is on path is known.
>
%sam - What kind of information are you referring to and how does it relate
to data plane protocol? Please add references for the same.

> The problem however, appears to me similar as the core of the problem is
> the interaction between the transit devices and the security layer used to
> secure NVE-to-NVE communications. -- It basically moves the problem from
> securing communication that do not have on-path transit devices to
> configuring the network with transit devices out of the path of NVE-to-NVE
> communications that needs to be secured. In any case, securing these
> NVE-to-NVE communications will result in disabling the transit devices
> functions which represents, unless this transit devices functions are
> useless, a major operational change. The perspective of this change is
> likely to result in not securing the NVE-to-NVE communication.</mglt>
>
%sam - I disagree to your thinking. Instead of ratholing into design
choices, which I'd leave it as deployment scenarios, please point me to the
clear requirement , be in RFC or WG draft. Limiting the discussion to
agreed architecture, would make more sense to reach logical conclusion.

> %sam - Having hard time to parse your point. Are you asking transit
devices to be 'non-bypassing'? If so, why is not a new architecture
proposal/requirement? What exact usefulness you want the transit devices to
be?

> <mglt>If the arch RFC is 8014, I do not see any transit devices, thought I
> may have missed them in the document or consider an inappropriate document
> </mglt>
>
%sam - inappropriate for who?

> <mglt>As mentioned above the problem is related to the interaction between
> transit device and end-to-end security protocols, not the way these are
> deployed. </mglt>
>
%sam - Again, I am not able to understand your concern. From the way I
look, you want transit devices to peek into header or whatever and
participate in some action. By definition, we call that device as NVE.

> and transit devices. </mglt>
%sam - Looks like, transit device definition of yours is actually NVE.

> <mglt> This comment seems to indicate a commitment that security will be
> addressed the security concerns. The history of security in this working
> group is relatively bad.
>
%sam - This is systemic problem in IETF and not just NVo3.

“nvo3 security requirements” [1] is an abandoned wg document since 2016
>  and the “geneve security requirements” [2] did not pass the call for
> adoption. As a result, a commitment related to security seems to me
> unrealistic for now. </mglt>
>
>
>
> [2]
> https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
>