Subject: [nvo3] Poll for adoption of draft-mglt-nvo3-geneve-security-requirements-06

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Apr 2019 14:38:23 +0000

This email begins a second two-week poll for adoption of draft-mglt-nvo3-geneve-security-requirements-06 in the NVO3 working group.

Please review the draft and send any comments to the NVO3 list.

Please also indicate whether you support adoption of the draft as an NVO3 working group document.

Note that supporting working group adoption indicates that you think the draft is headed in the right direction and represents a piece of work that the working group should take on and progress. It does not have to be technically perfect at this stage.

This poll closes on Wednesday 24th April 2019.

Regards
Matthew and Sam

---

From: Daniel Migault <[email-masked]>
Date: Fri, 12 Apr 2019 07:44:05 -0400

As a co-author, I am supporting the adoption of the draft.
Yours,
Daniel

On Wed, Apr 10, 2019 at 10:38 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> This email begins a second two-week poll for adoption of
> draft-mglt-nvo3-geneve-security-requirements-06 in the NVO3 working group.
>
>
>
> Note that supporting working group adoption indicates that you think the
> draft is headed in the right direction and represents a piece of work that
> the working group should take on and progress. It does not have to be
> technically perfect at this stage.
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Apr 2019 14:23:54 +0200

Dear Matthew, Sam, et al.,
I've read the draft and support its adoption by the WG. It addresses the
much-needed problem of providing L3 overlay security when using the Geneve
protocol, is well-written. I believe the work is well-timed and is in the
scope of the WG charter.

Regards,
Greg

---

From: "T. Sridhar" <[email-masked]>
Date: Thu, 18 Apr 2019 06:40:48 +0000

There is already another working group draft on NVO3 security (https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07) which would be a good place to include information about Geneve specific security requirements. This draft has not been updated in a while but includes content which is broadly applicable to NVO3 including NVE-NVE data plane (i.e. Geneve)  communication.

My vote is for the draft-mglt-nvo3-geneve-security-requirements authors to include relevant sections of their draft in the existing nv03-security-requirements draft instead of the WG adopting another draft related to security.

Section 6.2 of draft-ietf-nvo3-security-requirements  is the section which can be enhanced to include information about Geneve security since it already details several areas common to both the drafts.  I would also suggest not using the current categorization of draft-mglt-nvo3-geneve-security-requirements (SEC-OP and SEC-GEN – see below) when including text from draft-mglt-nvo3-geneve-security-requirements  into draft-nvo3-security-requirements

SEC-OP: requirements to evaluate a given deployment of Geneve overlay. Such requirements are intended to Geneve overlay provider to evaluate a given deployment.

SEC-GEN: requirements a security mechanism need to fulfill to secure any deployment of Geneve overlay deployment

In summary, I don’t support the adoption of this draft as a new WG document – we should add relevant content from here into the existing security requirements draft and continue to progress that.

Thanks,

Sridhar

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wednesday, April 10, 2019 at 7:38 AM
To: "[email-masked]" <[email-masked]>
Subject: [nvo3] Poll for adoption of draft-mglt-nvo3-geneve-security-requirements-06

Regards
Matthew and Sam

---

From: Daniel Migault <[email-masked]>
Date: Tue, 23 Apr 2019 13:47:49 -0400

Hi T. Sridhar,

Thanks for the feedbacks.

My reading of your feedback, is that you are supporting a security
analysis for Geneve, however, you would have prefered it to be part of a
document
expired since 2016 dealing another topic written by a different team of
co-authors. You are correct that is not what happened and since then,
you comment might be interpreted like a support for adopting the document.

As far as I understand, you do not have technical concerns. That reality
could have been otherwise might not be sufficient to oppose adoption of
a document. If there ever have been any technical concerns, we would
be pleased to heard them clearly.  I believe raising them would be more
 appropriated for a call for adoption -- as well as helpful for the
co-authors
of the document.

Note also that we checked the Geneve security document was aligned with
the more generic recommendations of NVO3. It has been decided by the WG
and the chairs to include the relevant NVO3 recommendations that apply
to Geneve in the current document rather than building on top of the
NVO3 requirements.

Note also that the notation SEC-OP/SEC-GEN have been proposed as a way to
address the WG concerns:
* How to evaluate a Geneve deployment is secure
* What are the requirements for a Geneve Security mechanisms to secure
Geneve deployments.
Are you suggesting after adoption, these two questions should be provided
in two
different documents ?

Yours,
Daniel

On Thu, Apr 18, 2019 at 2:41 AM T. Sridhar <tsridhar=
[email-masked]> wrote:

>
>
> There is already another working group draft on NVO3 security (
> https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07)
> which would be a good place to include information about Geneve specific
> security requirements. This draft has not been updated in a while but
> includes content which is broadly applicable to NVO3 including NVE-NVE data
> plane (i.e. Geneve)  communication.
>
>
>
> My vote is for the draft-mglt-nvo3-geneve-security-requirements authors to
> include relevant sections of their draft in the existing
> nv03-security-requirements draft instead of the WG adopting another draft
> related to security.
>
>
>
> Section 6.2 of draft-ietf-nvo3-security-requirements  is the section which
> can be enhanced to include information about Geneve security since it
> already details several areas common to both the drafts.  I would also
> suggest not using the current categorization of
> draft-mglt-nvo3-geneve-security-requirements (SEC-OP and SEC-GEN – see
> below) when including text from
> draft-mglt-nvo3-geneve-security-requirements  into
> draft-nvo3-security-requirements
>
>
>
> SEC-OP: requirements to evaluate a given deployment of Geneve overlay.
> Such requirements are intended to Geneve overlay provider to evaluate a
> given deployment.
>
>
>
> In summary, I don’t support the adoption of this draft as a new WG
> document – we should add relevant content from here into the existing
> security requirements draft and continue to progress that.
>
>
>
> Thanks,
>
> Sridhar
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>
> *Date: *Wednesday, April 10, 2019 at 7:38 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[nvo3] Poll for adoption of
> draft-mglt-nvo3-geneve-security-requirements-06
>
>
>

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Wed, 24 Apr 2019 23:56:52 +0000

Hello WG Chair, Authors and WG,

I reviewed the new version of the draft. The document still has not addressed many of the comments raised on the previous versions of the draft. This version still makes certain assumptions on the functionality of transit devices that is not consistent with Geneve architecture.

It is not about technical perfection, the architectural issue and the assumption of the threat model due to this effect needs to be addressed before the adoption of this draft as WG document.

The document calls for undue requirements and prescriptive of NVE implementations and solutions that are either not necessary nor practical for deployments (details below). Some of the requirements are optimizations that are not absolute requirements for securing overlays.

We need to first baseline on a threat model as applicable to Geneve and in general overlays in NVO3.  How are such threats being addressed by other encapsulations protocols like IP-in-IP, GRE, UDP encapsulation protocols like GRE-in-UDP, MPLS-in-UDP, etc.,    Apply those learnings and focus on addressing  specific threats applicable to Geneve deployment models instead over-specifying or gratuitous requirements and prescribing solutions. Many of these issues need to be addressed by the document.

Hence, I do not support the adoption of the draft in its current form.

Please see below for list of comments on the current draft:

General comments related to the draft:
SEC-OP vs SEC-GEN requirements. There was lengthy discussion in NVO3 WG meeting on should we have SEC-OP and SEC-GEN requirements, should we include SEC-OP, how to get feedback from operators, should this be in a single document or multiple separate documents etc., There was no consensus on this issue. Hence we still need to revisit this issue.  There was supposed to be mailing list discussion on this topic.  However, I did not see such discussion.
https://datatracker.ietf.org/meeting/103/materials/minutes-103-nvo3-00

I-D.ietf-nvo3-security-requirements document. There is a reference to this document from the geneve security requirements draft. There is good amount of information, including the threat model, that is defined in the NVO3-secuirty-requirements document, and data plane and control plane requirements are also defined.  We need to deicide as to what do we do with respect to the NVO3 security requirements document, and how do we pull in the information into this draft or other option is to revive the already adopted NVO3 WG document.

In general we need some serious discussion on the mailing list on the direction defining the threat model and direction we should take in defining the requirements.

Specific comments related to Requirements:

SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by
default encrypt the inner payload. A Geneve overlay provider MAY
disable this capability for example when encryption is performed
by the Tenant System and that level of confidentiality is believed
to be sufficient. In order to provide additional protection to
traffic already encrypted by the Tenant the Geneve network
operator MAY partially encrypt the clear part of the inner
payload.

SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.

SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the
capability authenticate the inner payload when encryption is not
provided. A Geneve overlay provider MAY disable this capability
for example when this is performed by the Tenant System and that
level of integrity is believed to be sufficient. In order to
provide additional protection to traffic already protected by the
Tenant the Geneve network operator MAY partially protect the
unprotected part of the inner payload.

Partial encryption (SEC-OP-1 and SEC-GEN2) is an optimization (as had been indicated in a comment on the previous version of this draft) and should not be a requirement.  The traffic between NVE pairs should be secured and operator may have a policy to encrypt the traffic irrespective of the any security mechanisms employed by the Tenant Systems Also an NVE may handle traffic from multiple TSes and hence the service provider may enable encryption between NVE pairs. So partial encryption or selective encryption should not be a requirement.

SEC-OP-3: A secure deployment of a Geneve overlay MUST evaluate
the risk associated to traffic pattern recognition. When a risk
has been identified, traffic pattern recognition MUST be addressed
with padding policies as well as generation of dummy packets.

SEC-GEN-6: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.

SEC-GEN-7: Geneve security mechanism MUST provide the ability to
send dummy packets.

SEC-OP-3 and SEC-GEN-6: The requirements document should stay with stating requirements and not prescribe a solution(s). This comment was already submitted in the previous version of the document.  “traffic pattern recognition MUST be addressed with padding policies as well as generation of dummy packets”  This is an undue requirement on NVE implementations which is not necessary and should not be in the requirements.  Need to clearly explain what additional security risk is caused because Geneve encapsulation vs standard IP transport and why such a requirement is mandatory. Any such risk can be mitigated by existing security mechanisms for communication between NVEs.

SEC-GEN-1: Geneve security mechanism MUST provide the capability
to encrypt the inner payload.

Define the threat model where only the inner payload should be selectively encrypted. The requirements should be to address a specific threat model. Not all deployments need encryption.

SEC-GEN-3: Geneve security mechanism MUST provide means to encrypt
a single or a set of zero, one or multiple Geneve Options while
leave other Geneve Options in clear. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option in clear, while
encrypting the others.

SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header (excluding Geneve Options).
Reversely, a Geneve security mechanism MUST be able to leave in
clear Geneve Header information (Geneve Options excluded) while
encrypting the other.

SEC-GEN-5: Geneve security mechanisms MUST provide the ability to
provide confidentiality protection between multiple nodes, i.e.
multiple transit devices and a NVE.

SEC-GEN-3,4 and SEC-GEN-5,6,7: All these SEC-GEN requirements (for partial encryption) are optimizations which should not be part of requirements especially with “MUST” mandates. The main objective of requirements is for protecting the traffic between the NVEs (privacy/integrity/confidentiality). Applying partial encryption is more of an optimization than to mitigate any specific threat especially when other existing mechanisms are available to protect communications between NVEs.  Specify the use cases where options need to selectively encrypted. What is the threat model and why such partial encryption of options is required.  So adding requirements for partial headers/payload/options could not be considered as a security requirement to address a security threat, hence these requirements must not be included.

SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate
the risk associated to a change of the Geneve Outer Header, Geneve
Header (excluding Geneve Options) and Geneve Option. When a risk
analysis concludes that the risk is too high, this piece of
information MUST be authenticated.

SEC-OP-6: A secure deployment of a Geneve overlay SHOULD
authenticate communications between NVE to protect the Geneve
Overlay infrastructure as well as the Tenants System’s
communications (Geneve Packet). A Geneve overlay provider MAY
disable authentication of the inner packet and delegates it to the
Tenant Systems when communications between Tenant’s System is
secured. This is NOT RECOMMENDED. Instead, it is RECOMMENDED
that mechanisms binds the inner payload to the Geneve Header. To
prevent injection between virtualized network, it is strongly RECOMMENDED that at least the Geneve Header without Geneve Options
is authenticated.

What specific risk does the operator see based on the threat model and what piece of information should be authenticated, why this should be selectively authenticated as called for in these requirements? Can you specify the usage model for these requirements.

SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT
process data prior authentication. If that is not possible, the
Geneve overlay provider SHOULD evaluate its impact.

This is too generic, what should the operator do with this requirement,  “…SHOUD evaluate its impact”?

SEC-GEN-8: Geneve security mechanism MUST provide the capability
to authenticate the inner payload.

SEC-GEN-9: Geneve security mechanism SHOULD provide the capability
to partially authenticate the inner payload header.

SEC-GEN-10: Geneve security mechanism MUST provide the capability
to authenticate a single or a set of options while leave other
Geneve Option unauthenticated. Reversely, a Geneve security
mechanism MUST be able to leave a Geneve option unauthenticated,
while encrypting the others.

SEC-GEN-11: Geneve security mechanism MUST provide means to
authenticate the information of Geneve Header (Geneve Option
excluded). Reversely, a Geneve security mechanism MUST be able to
leave unauthenticated Geneve header information (Geneve Options
excluded) while authenticating the other.

What is the threat model and what is use case that is driving the partial encryption or authentication of options?

SEC-GEN-13: Geneve Security mechanism MUST provide means for a
transit device to authenticate data prior it is being processed.

This requirement is not consistent with Geneve architecture, hence remove this requirement.

SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate
the communications subject to replay attacks. Communications that
are subject to this attacks MUST be authenticated with an anti
replay mechanism. Note that when partial authentication is
provided, the part not covered by the authentication remains a
surface of attack. It is strongly RECOMMENDED that the Geneve
Header is authenticated with anti replay protection

What is the threat model and use case that calls for partial authentication. Same comments as partial encryption applies to this comment as well.

SEC-OP-9: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and
authentication associated to each flow between NVEs.

SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define
distinct material for each flow. The cryptographic depends on the
nature of the flow (multicast, unicast) as well as on the security
mechanism enabled to protect the flow.

SEC-GEN-15: A Geneve security mechanism MUST be managed via
security policies associated for each traffic flow to be
protected. Geneve overlay provider MUST be able to configure NVEs
with different security policies for different flows. A flow MUST
be identified at minimum by the Geneve virtual network identifier
and the inner IP and transport headers, and optionally additional
fields which define a flow (e.g., inner IP DSCP, IPv6 flow id,
Geneve options)

It is not clear as to what threat is being addressed by requiring flow level granularity.  If communication between NVE to NVE need be encrypted/authenticated, then, at a minimum, security policy should be applied for the traffic between, for example, NVE A to NVE B or NVE A to NVE C, etc.  Any granularity beyond that is not a requirement to address any threat. This is undue burden on NVEs, not needed to address specific threat or define the threat model.   Hence remove flow level granularity requirement.

SEC-GEN-17: A Geneve security mechanisms, when multicast is used,
packets,MUST be able to assign distinct cryptographic group keys
to protect the multicast packets exchanged among the NVEs within
different multicast groups. Upon receiving a data packet, an
egress Geneve NVE MUST be able to verify whether the packet is

sent from a proper ingress NVE which is authorized to forward that
packet.

Need to define the threat model for multicast, define multicast,  most deployments multicast is implemented using multiple unicast. So the requirement does not apply to such deployments.

8. Appendix

I suggest to remove the entire Appendix from the document. Let us first agree on the requirements before we get into mapping different solutions to meet the requirements.

Thanks,

Ilango

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, April 10, 2019 7:38 AM
To: NVO3 <[email-masked]>
Subject: [nvo3] Poll for adoption of draft-mglt-nvo3-geneve-security-requirements-06

Regards
Matthew and Sam

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Apr 2019 17:04:33 -0400

Hi,

In my opinion most concerns raised are irrelevant. While the requirements
are derived from the threat model, it seems this section has been ignored.
I am addressing them all in line and further discussion may happen after
the document is adopted. I agree that further discussion should happen on
the mailing list, but I do not think we can be blamed for not requesting
these discussion to happen. In any case, adoption does not mean that no
changes will be possible.

I have a big concern regarding the following comment and would like further
clarifications, though this could happen after adoption as well.

> <mglt>My reading of your comment is that you are mandating that transit
devices are not expected to be able to authenticate the data they process.
Could you clarify your concern as well you clarify where the inconsistency
is? Text from the geneve architecture would be welcome. My understanding is
that the requirement that transit device authenticate the option they
process has been stated at the mic by David at the mic during the Prague
meeting. As a result, I am very confused by that concern. Of course if that
is inconsistent with the Geneve architecture, such requirement will be
removed. .</mglt>

Yours,
Daniel

On Wed, Apr 24, 2019 at 7:57 PM Ganga, Ilango S <[email-masked]>
wrote:

> I reviewed the new version of the draft. The document still has not
> addressed many of the comments raised on the previous versions of the
> draft. This version still makes certain assumptions on the functionality of
> transit devices that is not consistent with Geneve architecture.
>
>
>
> It is not about technical perfection, the architectural issue and the
> assumption of the threat model due to this effect needs to be addressed
> before the adoption of this draft as WG document.
>
>
>
> The document calls for undue requirements and prescriptive of NVE
> implementations and solutions that are either not necessary nor practical
> for deployments (details below). Some of the requirements are optimizations
> that are not absolute requirements for securing overlays.
>
>
>
> We need to first baseline on a threat model as applicable to Geneve and in
> general overlays in NVO3.  How are such threats being addressed by other
> encapsulations protocols like IP-in-IP, GRE, UDP encapsulation protocols
> like GRE-in-UDP, MPLS-in-UDP, etc.,    Apply those learnings and focus on
> addressing  specific threats applicable to Geneve deployment models instead
> over-specifying or gratuitous requirements and prescribing solutions. Many
> of these issues need to be addressed by the document.
>
>
>
<mglt>My understanding of your comment is that you are missing a threat
model for geneve and NVO3 as well as a section on how many of these
protocol are addressing these threats. The draft focuses on geneve and
Section 4 of the draft describes the threat model for geneve. From the
threat model security requirements are derived. My understanding is that
comparison on how other protocol address the security is part of the
solution space which is out of scope of the current document. </mglt>

> SEC-OP vs SEC-GEN requirements. There was lengthy discussion in NVO3 WG
> meeting on should we have SEC-OP and SEC-GEN requirements, should we
> include SEC-OP, how to get feedback from operators, should this be in a
> single document or multiple separate documents etc., There was no consensus
> on this issue. Hence we still need to revisit this issue.  There was
> supposed to be mailing list discussion on this topic.  However, I did not
> see such discussion.
>
<mglt>If I understand correctly your comment, you would like a discussion
on how to deal with the SEC-GEN, SEC-OP requirements. The question was do
we want to have SEC-OP in that document or in another one. I am happy to do
what the WG wants. Nothing prevents this to be done after adoption. </mglt>

> I-D.ietf-nvo3-security-requirements document. There is a reference to this
> document from the geneve security requirements draft. There is good amount
> of information, including the threat model, that is defined in the
> NVO3-secuirty-requirements document, and data plane and control plane
> requirements are also defined.  We need to deicide as to what do we do with
> respect to the NVO3 security requirements document, and how do we pull in
> the information into this draft or other option is to revive the already
> adopted NVO3 WG document.
>
>
>
<mglt>Again, this is out of scope of that call for adoption. The current
document deals with Geneve, not nvo3 in general. Adoption of the geneve
security requirement do not prevent nvo3 security requirements to be
revived. This has been already discussed in session and is not a topic we
are ignoring. </mglt>

> In general we need some serious discussion on the mailing list on the
> direction defining the threat model and direction we should take in
> defining the requirements.
>
>
>
<mglt>My vision is that we have made all possible effort to get these
discussions, through an issue tracker, a mailing list conference calls. We
also have been responsive to concerned we got. You are correct that not
being responsive does not help and we are happy to have those discussions
on the mailing list. I do not believe that prevents adoption of the
document.</mglt>

> Partial encryption (SEC-OP-1 and SEC-GEN2) is an optimization (as had been
> indicated in a comment on the previous version of this draft) and should
> not be a requirement.  The traffic between NVE pairs should be secured and
> operator may have a policy to encrypt the traffic irrespective of the any
> security mechanisms employed by the Tenant Systems Also an NVE may handle
> traffic from multiple TSes and hence the service provider may enable
> encryption between NVE pairs. So partial encryption or selective encryption
> should not be a requirement.
>
>
<mglt>Your comment seems to say these requirements prevent a NVE to encrypt
the traffic irrespective to the TSs. This is wrong and SHOULD makes this
requirement non blocking. The appendix provides  also two examples of DTLS
and IPsec that do not have this capability and such requirement does not
block IPsec nor TLS to be used. In addition, the same requirement is in the
nvo3 security requirement. As result, your concern does not seem relevant.
</mglt>

> SEC-OP-3 and SEC-GEN-6: The requirements document should stay with stating
> requirements and not prescribe a solution(s). This comment was already
> submitted in the previous version of the document.  “traffic pattern
> recognition MUST be addressed with padding policies as well as generation
> of dummy packets”  This is an undue requirement on NVE implementations
> which is not necessary and should not be in the requirements.  Need to
> clearly explain what additional security risk is caused because Geneve
> encapsulation vs standard IP transport and why such a requirement is
> mandatory. Any such risk can be mitigated by existing security mechanisms
> for communication between NVEs.
>
>
>
<mglt>Your comment seems to indicate we are prescribing solutions or
preventing existing solution to be re-used. In addition, you indicate a
threat model should be provided. I do not think that is correct. I do not
think we are mentioning any solution, nor prescribing any. Then
requirements are based on threat models provided in section 4. I do not see
any comments regarding threat model, thus I assume you agree with it.
 Appendix section illustrates that IPsec fulfil SEC-GEN-6, so existing
mechanisms can be re-used. Your concern, up to my understanding does not
seem relevant. Please lt us know how section 4 (threat model) as well as
the appendix can be clarified, if needed.</mglt>

> Define the threat model where only the inner payload should be selectively
> encrypted. The requirements should be to address a specific threat model.
> Not all deployments need encryption.
>
>
>
<mglt>You are reading the word "only" but I don't. On the other hand, you
do not see the threat model section but I do. The requirement addresses
traffic sniffing (this is the title of the section), in which case
authentication provides no protection. Your concern is not relevant.</mglt>

> SEC-GEN-3,4 and SEC-GEN-5,6,7: All these SEC-GEN requirements (for partial encryption) are optimizations which should not be part of requirements especially with “MUST” mandates.
>
> The main objective of requirements is for protecting the traffic between the NVEs (privacy/integrity/confidentiality). Applying partial encryption is more of an optimization than to mitigate any specific threat especially when other existing mechanisms are available to protect communications between NVEs.  Specify the use cases where options need to selectively encrypted. What is the threat model and why such partial encryption of options is required.  So adding requirements for partial headers/payload/options could not be considered as a security requirement to address a security threat, hence these requirements must not be included.
>
>
>
> <mglt>You seem to indicate that the requirement are not based on a threat
model. The requirement does not come from an optimization perspective. Such
requirements comes from the presence of transit nodes. The exact same
requirement have been mentioned at the mic by David Black during the Prague
meeting. I agreed, none objected. It you want transit device to coexist
with a security mechanism this is a necessary requirement. Otherwise you
will have to chose between transit device OR security. This is exactly what
makes transit devices not OPTIONNAL. IPv6 and IPsec handle transit devices,
in a clean way, but Genev is not willing to learn from this. Your concern
and this discussion is out of scope of the document but in the scope of the
Geneve specification.     </mglt>

> What specific risk does the operator see based on the threat model and what piece of information should be authenticated,
>
> why this should be selectively authenticated as called for in these requirements? Can you specify the usage model for these requirements.
>
> <mglt> The threat model and risks are described in section 4.
Authentication of Options or metadata is not something new. The threat
model of protecting the NVI is to prevent packets to be steered in the
wrong network. Unless I am not understanding your comment, I believe it is
irrelevant here. Maybe it could be handled in clarifying the threat model,
but that is not something your seem to have concern with. </mglt>

>  <mglt>The operator needs to ensure authentication is performed prior the
data is processed. I do not see how to clarify the purpose.
 This requirement comes from the transit devices, and the purpose is to
avoid option being for example processed by a transit device and
authenticated by the NVE.  </mglt>

> <mglt>see section 4 for the threat model.</mglt>

> <mglt>My reading of your comment is that you are mandating that transit
devices are not expected to process the data they process. Could clarify
your concern as well you clarify where the inconsistency is? Text from the
geneve architecture would be welcome. The requirement that transit device
authenticate the option they process has been stated at the mic by David at
the mic during the Prague meeting. As a result, I am very confused. Of
course if that is inconsistent with the Geneve architecture, such
requirement will be removed. But further discussion is needed, and being
unresponsive will not help.</mglt>

> <mglt> same response. please read the threat model section. The concern is
</mglt>

> It is not clear as to what threat is being addressed by requiring flow level granularity.  If communication between NVE to NVE need be encrypted/authenticated, then, at a minimum, security policy should be applied for the traffic between, for example, NVE A to NVE B or NVE A to NVE C, etc.
>
>

> Any granularity beyond that is not a requirement to address any threat. This is undue burden on NVEs, not needed to address specific threat or define the threat model.   Hence remove flow level granularity requirement.
>
> <mglt>This needs further discussion in the working group to what level of
granularity we want. The discussion can happen after adoption.</mglt>

> <mglt>My reading of your comment is that as multicast can be replaced by
multiple unicast, the requirement should be removed. The document is
focused on Geneve which may use multicast, not to replace multicast. The
nvo3 security requirement document got similar requirements. I believe your
concern is irrelevant to the document. </mglt>

> <mglt>I believe that the appendix is illustrating the requirements and as
such is useful to understand the requirements as well as how to read them.
Ithe appendix was completed based on the comments received from the secdir
reviewer of the geneve document.  Of course the requirement needs to be
agreed on. However, I believe that lots of your concerns could have been
avoided if this section has been read, so I strongly believe it is a useful
section. </mglt>

>
>
> Thanks,
>
> Ilango
>
>
>
>
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Bocci, Matthew
> (Nokia - GB)
> *Sent:* Wednesday, April 10, 2019 7:38 AM
> *To:* NVO3 <[email-masked]>
> *Subject:* [nvo3] Poll for adoption of