[nvo3] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

[Ganga, Ilango S]

Hello Authors,

Thanks for the revised draft. I reviewed the security requirements document, and here is a list of comments. To summarize, this version has not addressed many of the concerns raised in the previous version of the draft. This version still makes certain assumptions on the functionality of transit devices that is not consistent with the Geneve architecture. One of the key concerns is the requirements 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. Please see below for detailed comments. Also, I would like to thank T. Sridhar for his thorough review and contributions.

List of comments on draft-mglt-nvo3-geneve-security-requirements-04:


1. Section 2: The second paragraph assumes overlay cloud service provider may be different from Cloud service provider. While this may be a possibility, most common use cases should be outlined in this paragraph and in the list of scenarios in the last paragraph of this section. For example data center operator or cloud service provider hosts tenant systems and provides virtual network as a service. The underlay infrastructure including servers and data center network are managed by the same service provider. The last paragraph of this section should identify which provider manages the NVE and orchestrates tenant systems.



2. Section 2: Not all data centers environments have all the risks/threats highlighted in this document. In certain data center environments operated by a cloud provider or a private enterprise, where certain risks highlighted in this document may not be applicable. Hence one or more of the requirements identified in this document may not be applicable to those use cases and the data center operator may do a risk assessment and choose to deploy solutions with subset of requirements that are relevant for their application(s). So the document should make this clear upfront in section 2. So provide examples outlining the type of risk and illustrate which requirement is applicable to such scenario.


On the other hand, the

definition of a security mechanisms that enables to secure any

Geneve deployment requires the design of a Geneve specific

mechanism.


3. Section 2: Paragraph beginning with SEC-OP: We need a single set of requirements with MUST/SHOULD/MAY and not separate requirements into what is needed to “evaluate a given deployment”. I do not agree with the statement “On the other hand 
 to secure any Geneve deployment” – it assumes that there should be a Geneve specific security mechanism, which is not the case with other tunneling schemes – where they work with other parts of the stack to realize security.



SEC-GEN: requirements a security mechanism need to fulfill to

secure any deployment of Geneve overlay deployment. Such

mechanism may require the design of a specific solution.


4. Section 2: Paragraph beginning with SEC-GEN: We should remove references to new protocols or design of a specific solution. There is no rationale for a new protocol design while existing mechanisms would suffice.



5. Section 4: Suggest to make this document self-contained, we don’t know the status of the other document. Just we can state that “securing control plane is not in scope of this document”.



6. Section 4.1 - paragraph beginning with “Avoiding” – this is a very generic statement and imposes a requirement that is not needed (“..typically making leaked data unusable..”). Also please identify which is the rogue element described in this paragraph. For example, is this an NVE or a forwarding element in the underlay?



7. Section 4.2 – “Rogue element on path of TS traffic” Identify with respect to Figure 1 where is the rogue element is located. For example in server system where a TS is directly connected to an NVE this may not be applicable, and hence are the requirements associated with this case. Also as per section 5, the Network connecting TSes and NVEs are out of scope and also an attacker controlling the underlying network device is out of scope.


Selectively providing integrity / authentication, confidentiality /

encryption of only portions of the Geneve packet is in scope. This

will be the case if the Tenant Systems uses security protocol to

protect its communications.


8. Section 5. Selectively protecting portions of the Geneve packet, because tenant is already protecting the packet is more of an optimization and not an essential requirement as the security can be provide by protecting the entire Geneve packet for example using IPsec. Also an NVE may service multiple tenant systems and may have a policy to protect all packets from tenant systems irrespective of whether a tenant systems uses other mechanism at the payload level.


A secure deployment of a Geneve overlay must fulfill the requirement

below:


9. Section 5.1 “A secure deployment of Geneve must fulfill the requirements below”. Not all scenarios need to meet all of these requirements. Leading each paragraph with a blanket statement like this may imply, if some of these requirements are not used or enabled (by the operator based on their risk evaluation) then it is not a secure deployment. This is not accurate, specifically state the conditions of the risk and when such a requirement is applicable for risk mitigation, instead of using blanket statement for each requirement.



10. Section 5.1 - First paragraph: Scenarios described in this first paragraph were, for example a “passive network observer manipulating two VMs on the same host” or “controlling network activity of other VMs on the same host” are not specific to Geneve, so should be out of scope. So remove these scenarios or state that these are out of scope.



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.



o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability

to partially encrypt the inner payload header.



11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that all traffic should be encrypted. An operator may evaluate the risk and may enable encryption to mitigate such risk, remove “default” requirement. Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of an optimization that should not be mandated and should not be a requirement.



12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this requirement. So need to clearly state under the conditions under which this MUST requirement is applicable. For example an operator may do risk assessment and based on the analysis needed may enable this to mitigate the risk. Mandating Geneve security mechanism must fulfill the following requirements is not applicable to all scenarios.



13. Section 5.1 - paragraph beginning with “The Geneve Header and Geneve Options”: Making a distinction about options that need to be read by transit devices and “other” options may only be accessed by the tunnel end point is not a valid description. Options are only intended for endpoints – transit devices MAY interpret them.


o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate

the information associated to the leakage of the Geneve Outer

Header, Geneve Header and Geneve Option. When those information

are likely to carry sensitive information. they MUST NOT be

transmit in clear text.


14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry sensitive information..” is high level. We already say that it is possible to configure whether the network virtualization layer should also encrypt in addition to the TS level encryption, that should address such a risk. Hence this requirement is not necessary.


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


15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the communication between NVEs



o SEC-GEN-3: Geneve security mechanism MUST provide the capability

to encrypt a single or a set of options while leave other Geneve

Option in clear. Reversely, a Geneve security mechanism MUST be

able to leave a Geneve option in clear, while encrypting the

others.



o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt

the information of Geneve Header. Reversely, a Geneve security

mechanism MUST be able to leave in clear header information while

encrypting the other.



o SEC-GEN-5: Geneve security mechanism MUST provide the ability to

pad a Geneve packet.



o SEC-GEN-6: Geneve security mechanism MUST provide the ability to

send dummy packets.



16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN requirements (for partial encryption) are optimizations which should not be part of requirements especially with “MUST” mandates. Also see previous comment for SEC-GEN-5, 6. 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 threat especially when other existing mechanisms are available to protect communications between NVEs. So adding requirements for partial headers/payload could not be considered as a security requirement to address a security threat, hence these requirements should not be included.



The Geneve architecture

considers transit devices that MAY process some Geneve Option without

affecting the Geneve packet. These transit device MAY Authenticate

the Geneve packet as part of the Geneve packet processing but MAY

also process other Geneve options. As a result, integrity protection

and authentication SHOULD be performed by transit device, prior to

any processing.


17. Section 5.2 “Transit devices may process Geneve Options” Geneve headers (including options) are generated and terminated by NVEs. So if NVE to NVE communication is secured end to end (e.g. IPsec), then the options are not visible to transit devices. This is no different than ECMP routers not having access to inner header information when traffic is encrypted. So the intent is not for creating authentication or encryption of partial header (option) information with transit devices along the path. So remove this paragraph or state that transit devices don’t have access to the bits or if the tunnel transport communication is secured.



o SEC-OP-4: 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. To prevent injection between

virtualized network, it is strongly RECOMMENDED that at least the

Geneve Header is authenticated.



18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment of a Geneve overlay SHOULD authenticate communications between NVE
” is good enough to fulfill the security objective. The other statements are optimizations and not needed to satisfy security objective, hence the following sentences can removed, “A Geneve overlay provider MAY disable..” and “This is not “NOT RECOMMENDED”.



o SEC-GEN-8: Geneve Security mechanism MUST provide means for a

tunnel endpoint (NVE) to authenticate data prior it is being

processed. A tunnel endpoint (NVE) MUST be able to authenticate

at least:



* the Geneve Header and a subset of Geneve Options



* the Geneve Header, a subset of Geneve options and the Geneve

inner payload



* the Geneve Header, a subset of Geneve options and the Geneve

inner payload or the portion of the inner payload in case the

Tenant's System provides some authentication mechanism.


o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a

transit device to authenticate the Geneve Option prior processing

it. Authentication MAY concern the whole Geneve packet, but MAY

be limited to the Geneve Option.


19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations and should not be specified as requirements. Authentication of end points is the only requirement that we should look at, which is already captured in first statement of SEC-OP4. Partial authentication of headers etc., is an optimization and not essential to secure the communication between NVEs. Also SEC-GEN-9 specification of transit node behavior is not needed, and hence to be removed (also see comment 17).



More

specifically, a rogue source NVE will still be able to redirect the

traffic in clear text before protecting ( and encrypting the packet).

A rogue destination NVE will still be able to redirect the traffic in

clear text after decrypting the Geneve packets. The same occurs with

a rogue transit that is in charge of encrypting and decrypting a

Geneve Option, Geneve Option or any information.


20. Section 5.3 First paragraph: In general securing nodes, NVEs and transit devices should be beyond the scope of securing Geneve transport. Securing such devices is not specific to Geneve. So the operator should use other best practices for securing those devices and establish trust between those devices and NVAs.



o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate

the flows subject to replay attacks. Flows 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 both authenticated

with anti replay protection.



21. Section 5.4 – Reproducing earlier comment from the list on previous version of this draft: “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. “ Hence remove SEC-OP-6.



o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the

security policies that associates the encryption, and

authentication associated to each flow between NVEs.



o SEC-OP-8: 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.



o SEC-GEN-11: 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).





22. Section 5.5 – Same comment as above applies to this section SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level granularity to be removed. These are prescribing implementations and undue burden on NVEs that are not needed to secure communication between NVEs.


o SEC-GEN-13: 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.



23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist for multicasting tenant traffic. For example, implementations my use multiple unicast tunnels to achieve this objective. So mandating MUST requirement for specific multicast mechanism is not necessary. An operator may decide based on their environment as to what multicast mechanism is applicable to the deployment. Hence MUST requirement should be removed.



24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2 as we should not get into implementation details when discussing requirements.

/End of Comments/

Thanks,
Ilango


From: nvo3 [mailto:nvo3-***@ietf.org] On Behalf Of Daniel Migault
Sent: Friday, October 12, 2018 2:22 PM
To: ***@ietf.org
Subject: [nvo3] Fwd: [Curdle] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

Hi,

Please find below an update of the security requirements. I believe the document reflects the feed backs and comments we received during the meetings as well the clarification of the transit device.

Any feed back is appreciated!
Yours,
Daniel

-----Original Message-----
From: internet-***@ietf.org<mailto:internet-***@ietf.org> <internet-***@ietf.org<mailto:internet-***@ietf.org>>
Sent: Friday, October 12, 2018 5:14 PM
To: Sami Boutros <***@vmware.com<mailto:***@vmware.com>>; Dan Wings <***@vmware.com<mailto:***@vmware.com>>; Dan Wing <***@vmware.com<mailto:***@vmware.com>>; Daniel Migault <***@ericsson.com<mailto:***@ericsson.com>>; Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>>
Subject: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt


A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
URL: https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
Status: https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
Htmlized: https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04

Abstract:
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).

The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Curdle mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/curdle

[Daniel Migault]

Hi Illango,

Please see my responses inline. In most cases I believe the current text
addresses the concerns you raised. In other cases, I addressed them with
additional text. The current version of the draft is available here:
https://github.com/mglt/draft-mglt-nvo3-geneve-security-requirements/blob/master/draft-mglt-nvo3-geneve-security-requirements.mkd

A few comments needs further discussion on the mailing list, but should
not raised any issues.

There one comment I think needs more clarifications on the Geneve
specifications.

As a general comment, I am wondering if the concerns have not been
raised due to a different interpretation of what matching the
requirements means. I believe the illustration of TLS, IPsec in the
appendix sections are good illustrations of how to read them.

In a nutshell, the draft provides two kinds of requirements:
* SEC-OP: provides security requirements to check whether a Geneve
deployment is secure or not.
* intended for operators
* security mechanisms are not specified and could be anything
* conditional to some deployment specifities, risk analysis and in some
case may not be applicable

* SEC-GEN: provides security requirements for Geneve security mechanism to
secure any deployment
* The mechanism needs to be defined (not necessarily a new mechanism)
* The mechanism needs to fit ANY Geneve deployment (compatible with the
Geneve architecture /protocol)

The way requirements have been written is that a Geneve deployment
(resp. Geneve Security Mechanism) passes SEC-OP (resp. SEC-GEN) as long
as there is no conflict.
* In some case the requirement does not apply which does not raises any
conflict

However, in my view there is still one major concern related to the Geneve
architecture that needs to be clarified.

Yours,
Daniel

From: Ganga, Ilango S <***@intel.com>
Sent: Thursday, October 25, 2018 10:13 PM
To: Daniel Migault <***@ericsson.com>; ***@ietf.org
Subject: RE: [nvo3] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt

Hello Authors,

Thanks for the revised draft. I reviewed the security requirements
document, and here is a list of comments. To summarize, this version has
not addressed many of the concerns raised in the previous version of the
draft. This version still makes certain assumptions on the functionality of
transit devices that is not consistent with the Geneve architecture. One of
the key concerns is the requirements 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. Please see below for detailed comments. Also, I would
like to thank T. Sridhar for his thorough review and contributions.

List of comments on draft-mglt-nvo3-geneve-security-requirements-04:

1. Section 2: The second paragraph assumes overlay cloud service
provider may be different from Cloud service provider. While this may be a
possibility, most common use cases should be outlined in this paragraph and
in the list of scenarios in the last paragraph of this section. For example
data center operator or cloud service provider hosts tenant systems and
provides virtual network as a service. The underlay infrastructure
including servers and data center network are managed by the same service
provider. The last paragraph of this section should identify which provider
manages the NVE and orchestrates tenant systems.

<mglt>
The second paragraph of section 2 is the text below:
"""
The underlay infrastructure on which the multi-tenancy overlay
networks are hosted, can be owned and provided by an underlay
provider who may be different from the overlay cloud provider.
"""

The last paragraph of this section is the text below:
"""
Given the different relations between Tenant, Geneve Overlay Provider
and Infrastructure Provider, this document aims providing
requirements to ensure: 1. The Geneve Overlay Provider delivers
tenant payload traffic (Geneve inner payload) and ensuring privacy
and integrity. 2. The Geneve Overlay Provider provides the
necessary means to prevent injection or redirection of the Tenant
traffic from a rogue node in the Geneve overlay network or a rogue
node from the infrastructure. 3. The Geneve Overlay Provider can
rely on the Geneve overlay in term of robustness and reliability of
the signaling associated to the Geneve packets (Geneve tunnel header,
Geneve header and Geneve options) in order to appropriately manage
its overlay.
"""

If I understand correctly, the comment says that the most common use
case- a Cloud Provider providing the virtual network as a service -
should be listed. I am inclined to think that use cases popularity is
out of the scope of a security analysis.

This document elaborates a model to perform a security analysis. The
model defines roles and relations between them as specified in the
Geneve architecture document. That a specific combination is
popular/common or not should not impact the security analysis.
Typically, while the most common use case of today is likely to evolve
over time, the security analysis must not. As a result, considering use
cases here seems to me out of scope of the document.

As a side note, basing the security analysis on specific use cases is
likely to create security vulnerabilities for deployment that do not
exactly match the considered *most* common use case. As a result, this
will limit drastically the usage of the protocol to a specific use case,
which is probably not what we are looking for.

Do we agree that use cases and security analysis are orthogonal, or do
you believe we should still add some considerations of the use cases ?

</mglt>

2. Section 2: Not all data centers environments have all the
risks/threats highlighted in this document. In certain data center
environments operated by a cloud provider or a private enterprise, where
certain risks highlighted in this document may not be applicable. Hence one
or more of the requirements identified in this document may not be
applicable to those use cases and the data center operator may do a risk
assessment and choose to deploy solutions with subset of requirements that
are relevant for their application(s). So the document should make this
clear upfront in section 2. So provide examples outlining the type of risk
and illustrate which requirement is applicable to such scenario.

<mglt>
If I understand correctly, the comment says that section 2 should state
that deployment has different threats and risks so specific deployment
may only consider a subset of the requirements.

I believe the current document agrees with that statement and already
provides the text below in section 2. If that does not address the
concerns, please let us know how to update the text below

"""
The document provides two sets of security requirements:

1. SEC-OP: requirements to evaluate a given deployment of Geneve
overlay. Such requirements are intended to Geneve overlay
provider to evaluate a given deployment. Security of the Geneve
packet may be achieved using various mechanisms. Typically, some
deployments may use a limited subset of the capabilities provided
by Geneve and rely on specific assumptions. Given these
specificities, the secure deployment of a given Geneve deployment
may be achieved reusing specific mechanisms such as for example
DTLS [RFC6347] or IPsec [RFC4301].
"""
</mglt>

On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
mechanism.

3. Section 2: Paragraph beginning with SEC-OP: We need a single set of
requirements with MUST/SHOULD/MAY and not separate requirements into what
is needed to “evaluate a given deployment”. I do not agree with the
statement “On the other hand 
 to secure any Geneve deployment” – it
assumes that there should be a Geneve specific security mechanism, which is
not the case with other tunneling schemes – where they work with other
parts of the stack to realize security.

<mglt>
I believe that there is a misunderstanding here. SEC-OP and SEC-GEN
designates a category of security requirements. The security
requirements is listed later in the document. The category does not lead
to MUST/SHOULD/MAY statement.

SEC-OP are intended to an operator to check whether its deployment is
secured or not. This category has been added in this version. The
category has been added as this has been requested.

SEC-GEN defines the security requirements that a future Geneve security
mechanism needs to fulfill, in order to secure any Geneve deployment
that respect the Geneve architecture. The mechanism has not been yet
defined. There is no assumption that a new mechanism needs to be
designed. The design of such mechanism is expect to re-use existing
mechanisms. In this case all requirements will need to be fulfilled in
order to be considered as a Geneve security mechanism.

I think that the document clearly states that there is no such
assumption and that the design of new mechanism should be avoided as
much as possible.

"""
Such mechanism may require the design of a specific solution. In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""

Do we agree that this concern is addressed by the current draft ?
</mglt>


SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution.

4. Section 2: Paragraph beginning with SEC-GEN: We should remove
references to new protocols or design of a specific solution. There is no
rationale for a new protocol design while existing mechanisms would
suffice.

<mglt>
The protocols have been mentioned as examples, and I believe this is
clarifying to the reader. I see that as a nit and if the WG prefer to
remove them I will be fine with that. Do you agree with this as a way to
move forward ?

"""
In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""
</mglt>



5. Section 4: Suggest to make this document self-contained, we don’t
know the status of the other document. Just we can state that “securing
control plane is not in scope of this document”.

<mglt>
The sentence has an issue so it needs to be addressed anyway. The
intention of the text is to position the two documents. This has been
asked by the WG that we compare/position the two documents. In addition,
nvo3-security-requirements is a valid document and we expect the reader
to have a look at it.

For your second suggestion, I am reading the texts as equivalent, and
here is what I propose. I suppose this address the concern.

OLD:
Attacks from compromised NVO3 and underlay network devices, and
attacks from compromised tenant systems defined in
[I-D.ietf-nvo3-security-requirements]. This document considers these
attacks in the scope of Geneve, that is when the attackers knowing
the details of the Geneve packets can perform their attacks by
changing fields in the Geneve tunnel header, base header, Geneve
options and Geneve inner payload. The scope of Geneve excludes
security requirements related to the control plane.


NEW:
This section considers attacks performed by NVE, network devices or any
other devices using Geneve, that is when the attackers knowing the
details of the Geneve packets can perform their attacks by changing
fields in the Geneve tunnel header, base header, Geneve options and
Geneve inner payload. Attacks related to the control plane are outside
the scope of this document. The reader is encouraged to read
[I-D.ietf-nvo3-security-requirements] for a similar threat analysis of
NVO3 overlay networks.
</mglt>

6. Section 4.1 - paragraph beginning with “Avoiding” – this is a very
generic statement and imposes a requirement that is not needed
(“..typically making leaked data unusable..”). Also please identify which
is the rogue element described in this paragraph. For example, is this an
NVE or a forwarding element in the underlay?

<mglt>

I believe the text has been read as a security requirements, which is
not the case. I propose the following change:

OLD:
Avoiding leaking information is hard to enforced and the security
requirements expect to mitigate such attacks by lowering the
consequences, typically making leaked data unusable to an attacker..

NEW:
Avoiding leaking information is hard to enforced. The security
requirements provided in section {{sniffing} expect to mitigate such
attacks by lowering the consequences, typically making leaked data
unusable to an attacker.


The nature of the rogue element is described in section 4 with the text
provided in section 5. I believe this address this concern.

Note that the rogue element is a NVE, a forwarding element, a TS does
not really matter. What matters is its ability to interfere with the
Geneve overlay. Of course some elements have more capabilities than
others. I will add some text around those lines.

Do you think we should add such consideration ?
</mglt>

7. Section 4.2 – “Rogue element on path of TS traffic” Identify with
respect to Figure 1 where is the rogue element is located. For example in
server system where a TS is directly connected to an NVE this may not be
applicable, and hence are the requirements associated with this case. Also
as per section 5, the Network connecting TSes and NVEs are out of scope and
also an attacker controlling the underlying network device is out of scope.

<mglt>
The rogue elements are defined in section 4 - see concern 5.

The remaining of the comment seems to say that injecting traffic to a TS
requires the rogue element to be NVE and the TS. This is not what we are
trying to say.

Section 4.2 describes active attacks and mentions that injection attacks
can target TS or the overlay. Active attacks targeting TS injects
packets into the TS traffic. The document considers an attacker
injection packets to the TS by crafting Geneve packets. How the TS are
connected to the NVE does not change anything.

Section 4.2 is structured as follows:
* The first paragraph says that active attacks may concern the TS or the
overlay.
* The second paragraph develops active attacks on TS
* The third paragraph develops active attacks on the overlay network.

To clarify I propose the following changes. I believe this address the
concern.

OLD:
Active attacks involve modifying packets, injecting packets, or
interfering with packet delivery (such as by corrupting packet
checksum). Active attack may target the Tenant System or the Geneve
overlay.

NEW:
Active attacks involve modifying Geneve packets, injecting Geneve
packets, or interfering with Geneve packet delivery (such as by
corrupting packet checksum). Active attack may target the Tenant System
or the Geneve overlay.

</mglt>


Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.

8. Section 5. Selectively protecting portions of the Geneve packet,
because tenant is already protecting the packet is more of an optimization
and not an essential requirement as the security can be provide by
protecting the entire Geneve packet for example using IPsec. Also an NVE
may service multiple tenant systems and may have a policy to protect all
packets from tenant systems irrespective of whether a tenant systems uses
other mechanism at the payload level.

<mglt>
I believe the text you refer to is the one below:
"""
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
"""

The text does not provide any requirement. The requirements are provided
in section 5.1. with SEC-GEN-1 and SEC-GEN-2.

I understand the concern as: Does these SEC-GEN-1 and SEC-GEN-2 - see
below - prevents using IPsec as a Geneve Security Mechanism ? As
SEC-GEN-2 does not mandate partial encryption, SEC-GEN-1 and SEC-GEN-2
does not prevent using IPsec as a Geneve security mechanisms. I suppose
this addresses the concern.

"""
A Geneve security mechanism must fulfill the requirements below:

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

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

</mglt>


A secure deployment of a Geneve overlay must fulfill the requirement
below:

9. Section 5.1 “A secure deployment of Geneve must fulfill the
requirements below”. Not all scenarios need to meet all of these
requirements. Leading each paragraph with a blanket statement like this may
imply, if some of these requirements are not used or enabled (by the
operator based on their risk evaluation) then it is not a secure
deployment. This is not accurate, specifically state the conditions of the
risk and when such a requirement is applicable for risk mitigation, instead
of using blanket statement for each requirement.

<mglt>
I understand the comment as a concern of the SEC-OP security
requirements, and not specifically to SEC-OP-1.

The purpose of SEC-OP is clearly to provide the operator the ability to
evaluate the Geneve deployment is secure. If one of those is not met,
the deployment will not be considered as secured. I understand this as a
goal of the SEC-OP security requirements. That said, the SEC-OP
requirements are based on conditions - based on risks or specific
assumptions. When these condition are not met, the requirement does not
raise a security mismatch and as such is considered to pass
the requirement.

I suspect that the interpretation of the security requirements is main
reason of the concerns. I propose to add the following text in section
2. I guess this address the concern.

"""
SEC-OP : [..] A given Geneve
A given Geneve
deployment will be considered secured when matching with all SEC-OP
requirements does not raises any concern. As such the given deployment
will be considered passing SEC-OP requirements that are not applicable.
"""

"""
SEC-GEN: [...]
A given candidate for a
security mechanism will be considered as valid when matching with all
SEC-GEN requirements does not raise any concern. In other words, at
least all MUST status are met.
"""
</mglt>

10. Section 5.1 - First paragraph: Scenarios described in this first
paragraph were, for example a “passive network observer manipulating two
VMs on the same host” or “controlling network activity of other VMs on the
same host” are not specific to Geneve, so should be out of scope. So remove
these scenarios or state that these are out of scope.

<mglt>
The text you refer describes the passive attack. It is important to
mention that information retrieved from observing Geneve traffic can be
complemented by additional information. I believe this paragraph should
rather be moved to the threat description section (section 4.1). The
following text has been updated and moved. I believe this address the
concern.

"""
Passive attacks may also consist in inferring information about a
virtualized network or some Tenant System from observing the Geneve
traffic. This could also involve the correlation between observed
traffic and additional information. For example, a passive network
observer can determine two virtual machines are communicating by
manipulating activity or network activity of other virtual machines on
that same host. For example, the attacker could control (or be otherwise
aware of) network activity of the other VMs running on the same host,
and deduce other network activity is due to a victim VM.
"""

</mglt>


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.

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

11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that
all traffic should be encrypted. An operator may evaluate the risk and may
enable encryption to mitigate such risk, remove “default” requirement.


<mglt>
It is unclear to me where SEC-OP-1 does not address the concern.
"""
1. 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.
"""

SHOULD indicates this is not mandated and the remaining text mentions an
operator MAY disable this capability. I believe this address the
concern. If not it would be good to provide an example where SEC-OP-1
prevents the deployement as being secured.
</mglt>

Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of
an optimization that should not be mandated and should not be a
requirement.

<mglt>
I suspect the concern is whether Geneve deployment with NVE-to-NVE
communications and TS communications encrypted can be considered secure.
This is more related to a deployment. As this is a deployment it should
be related to SEC-OP requirements. The case provided fulfill SEC-OP-1 as
partial encryption comes with a MAY staus. I believe the concern is
addressed.

That said, the concern may also be whether a security mechanism that
does not provide partial encryption can be considered as a geneve
security mechanism.

SEC-GEN provide requirements the mechanism to secure Geneve overlay
needs to fulfill.

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

SEC-GEN-2 comes with a SHOULD statement that does not make it mandatory.
SEC-GEN-1 requires the capability to encrypt and comes with a MUST
statement. As a result a mechanism that encrypts fulfill SEC-GEN-1 and
SEC-GEN-2.

I suppose that address the concern. I provided text to explain how
requirements should be considered to match a deployment or a security
mechanism.
</mglt>


12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this
requirement. So need to clearly state under the conditions under which this
MUST requirement is applicable. For example an operator may do risk
assessment and based on the analysis needed may enable this to mitigate the
risk. Mandating Geneve security mechanism must fulfill the following
requirements is not applicable to all scenarios.

<mglt>
I believe SEC-OP-1 address the concern as explained in the previous concern..
</mglt>

13. Section 5.1 - paragraph beginning with “The Geneve Header and Geneve
Options”: Making a distinction about options that need to be read by
transit devices and “other” options may only be accessed by the tunnel end
point is not a valid description. Options are only intended for endpoints –
transit devices MAY interpret them.

<mglt>
My understanding from the Geneve architecture document is that a Geneve
packet with opt0,opt1,opt2 may have opt1 interpreted by the transit
device and opt0, opt2 interpreted by the NVE. With encrypted
NVE-to-NVE communication, the transit device will not be able to
interpret opt1. As a result, to remain compatible with the Geneve
architecture document, a mechanism that secures Geneve deployment needs
to enable opt1 to appear - at least -in clear text.

This is not always required, but if we do not enable this the security
mechanisms is not compatible with the architecture and I see that as an
potential issue.
</mglt>

o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.

14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry
sensitive information..” is high level. We already say that it is possible
to configure whether the network virtualization layer should also encrypt
in addition to the TS level encryption, that should address such a risk.
Hence this requirement is not necessary.

<mglt>
I suspect the concern is how the specific deployment can fulfill
SEC-OP-2. As NVE-NVE communications are encrypted, metadata are not
transmitted in clear text and as such SEC-OP-2 is met by the current
deployment.

I propose the following text to address the concern of too high level
description. I believe this address the concern.

"""
SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate the
information associated to the leakage of the Geneve Outer Header, Geneve
Header and Geneve Option. When a risk analysis concludes that the risk
of leaking sensitive information is too high, such MUST NOT be transmit
in clear text.
"""
</mglt>

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

15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the
communication between NVEs

<mglt>
I suspect the concern is to determine whether a deployment based on
IPsec, meet SEC-OP-3. SEC-OP-3 is provided below:
"""
* 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.
"""

If pattern recognition is not considered at risk. SEC-OP-3 is met. In
addition, when it is considered as at risk and IPsec is used, SEC-OP-3
is also met as IPsec provides dummy packet and padding facilities.

I believe this address the concern.
</mglt>

o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.

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

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

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

16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN
requirements (for partial encryption) are optimizations which should not be
part of requirements especially with “MUST” mandates. Also see previous
comment for SEC-GEN-5, 6. 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 threat especially when other existing
mechanisms are available to protect communications between NVEs. So adding
requirements for partial headers/payload could not be considered as a
security requirement to address a security threat, hence these requirements
should not be included.

<mglt>
I suspect there is some confusion as none of the requirements SEC-GEN{3-6}
are
related to partial encryption. SEC-GEN-5 and SEC-GEN-6 are related to
pattern traffic recognition and SEC-GEN-3 and SEC-GEN-4 are - in my
opinion - NOT related optimization.

Instead SEC-GEN-3 and SEC-GEN-4 are intended to have the security
mechanism compliant with the geneve architecture while protecting
metadata. Only SEC-GEN-2 is related to partial encryption.

If there is a concern, I suppose it needs to be re-stated.
</mglt>


The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.

17. Section 5.2 “Transit devices may process Geneve Options” Geneve
headers (including options) are generated and terminated by NVEs. So if NVE
to NVE communication is secured end to end (e.g. IPsec), then the options
are not visible to transit devices. This is no different than ECMP routers
not having access to inner header information when traffic is encrypted. So
the intent is not for creating authentication or encryption of partial
header (option) information with transit devices along the path. So remove
this paragraph or state that transit devices don’t have access to the bits
or if the tunnel transport communication is secured.

<mglt>
If I understand correctly the comment, deployment where a transit device
process an option of a clear text Geneve packet will not be able to
process that option in a secured deployment with NVE-NVE encrypted
communications. While this is may be an acceptable compromise for a
given deployment, and such compromise will not make the deployment
unsecure. Such compromise is not acceptable for a geneve security
mechanism. IN fact, this makes security not aligned with the
architecture. If my understanding is correct this is a major issue which
also needs to be addressed by the architecture document.

</mglt>

o SEC-OP-4: 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. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.

18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment
of a Geneve overlay SHOULD authenticate communications between NVE
” is
good enough to fulfill the security objective. The other statements are
optimizations and not needed to satisfy security objective, hence the
following sentences can removed, “A Geneve overlay provider MAY disable..”
and “This is not “NOT RECOMMENDED”.

<mglt>
The two authentication achieves different goals. Authentication of the
Geneve Header prevents mixing the virtual networks. Authentication of
the payload protects also the TS. This needs to be discussed further as
the WG has requested such granularity. I am open to the discussion. The
trade off here might between an optimal security that cannot be met
versus achieving at least the protection of the infrastructure.
</mglt>

o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
at least:

* the Geneve Header and a subset of Geneve Options

* the Geneve Header, a subset of Geneve options and the Geneve
inner payload

* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.

o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.

19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations
and should not be specified as requirements. Authentication of end points
is the only requirement that we should look at, which is already captured
in first statement of SEC-OP4. Partial authentication of headers etc., is
an optimization and not essential to secure the communication between NVEs.
Also SEC-GEN-9 specification of transit node behavior is not needed, and
hence to be removed (also see comment 17).

<mglt>
The purpose of these security requirements is to align security with the
Geneve architecture rather than to proceed to some optimizations. This
clearly needs some clarifications.
</mglt>

More
specifically, a rogue source NVE will still be able to redirect the
traffic in clear text before protecting ( and encrypting the packet).
A rogue destination NVE will still be able to redirect the traffic in
clear text after decrypting the Geneve packets. The same occurs with
a rogue transit that is in charge of encrypting and decrypting a
Geneve Option, Geneve Option or any information.

20. Section 5.3 First paragraph: In general securing nodes, NVEs and
transit devices should be beyond the scope of securing Geneve transport.
Securing such devices is not specific to Geneve. So the operator should
use other best practices for securing those devices and establish trust
between those devices and NVAs.

<mglt>
Unless I misunderstand the comment, I think we agree as stated in the text
below:
"""
If the rogue device is in
charge of the securing the Geneve packet, then Geneve security
mechanisms are not intended to address this threat.
"""

However, maybe we could to state this as these nodes are able to
interfere with Geneve and what makes them different - and out of scope
of a Geneve security mechanism is that there are tunnel endpoint. In
other words, if they are attacking another NVE-NVE communication they
become in scope. Do you want to propose some text ?
</mglt>

o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 both authenticated
with anti replay protection.

21. Section 5.4 – Reproducing earlier comment from the list on previous
version of this draft: “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. “ Hence remove SEC-OP-6.

<mglt>
SEC-OP-6 concerns anti-replay attack, not flow management.

I believe that the following text addresses the concern:

OLD:
* SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate the
flows subject to replay attacks. Flows 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 both authenticated with anti replay
protection.

NEW:
* SEC-OP-6: 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 both authenticated with
anti replay protection.
</mglt>

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

o SEC-OP-8: 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.

o SEC-GEN-11: 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).


22. Section 5.5 – Same comment as above applies to this section
SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level
granularity to be removed. These are prescribing implementations and undue
burden on NVEs that are not needed to secure communication between NVEs.

<mglt>
My understanding is that a communication is characterized by flows.
There is a need to define what is being encrypted and this si
characterized by a flow.

I believe the concern is about reducing the granularity of the flows. I
believe more discussion is needed to define the right set of
granularity.
</mglt>

o SEC-GEN-13: 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.

23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist
for multicasting tenant traffic. For example, implementations my use
multiple unicast tunnels to achieve this objective. So mandating MUST
requirement for specific multicast mechanism is not necessary. An operator
may decide based on their environment as to what multicast mechanism is
applicable to the deployment. Hence MUST requirement should be removed.

<mglt>
As I understand the comments exposes how to replace multicast
communications with unicast. If such deployment is achieved, SEC_GEN-13
is not applicable as SEC-GEN-13 is for multicast communications. I guess
this addresses the concern.

</mglt>

24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2
as we should not get into implementation details when discussing
requirements.

<mglt>

I believe they are good illustration of how the current security
mechanism match the requirements. The reason I suggest we keep them are:
* it answers most of the question what if I use IPsec, TLS. It helps
* reading the security requirements from an operational point of view as
well as from a design point of view.

I suppose that both of these items have raised issues, so illustrative
example should be welcome.

I suggest to place these section into an appendix, which I guess address
the concern.
</mglt>


/End of Comments/

Thanks,
Ilango


From: nvo3 [mailto:nvo3-***@ietf.org] On Behalf Of Daniel Migault
Sent: Friday, October 12, 2018 2:22 PM
To: ***@ietf.org
Subject: [nvo3] Fwd: [Curdle] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt

Hi,

Please find below an update of the security requirements. I believe the
document reflects the feed backs and comments we received during the
meetings as well the clarification of the transit device.

Any feed back is appreciated!
Yours,
Daniel

-----Original Message-----
From: internet-***@ietf.org <internet-***@ietf.org>
Sent: Friday, October 12, 2018 5:14 PM
To: Sami Boutros <***@vmware.com>; Dan Wings <***@vmware.com>; Dan
Wing <***@vmware.com>; Daniel Migault <***@ericsson.com>;
Suresh Krishnan <***@kaloom.com>
Subject: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt


A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF
repository.

Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
URL:
https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
Status:
https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
Htmlized:
https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
Diff:
https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04

Abstract:
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).

The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment




Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat

_______________________________________________
Curdle mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

Post by Ganga, Ilango S
Hello Authors,
Thanks for the revised draft. I reviewed the security requirements
document, and here is a list of comments. To summarize, this version has
not addressed many of the concerns raised in the previous version of the
draft. This version still makes certain assumptions on the functionality of
transit devices that is not consistent with the Geneve architecture. One of
the key concerns is the requirements 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. Please see below for detailed comments. Also, I would
like to thank T. Sridhar for his thorough review and contributions.
*List of comments on draft-mglt-nvo3-geneve-security-requirements-04:*
1. Section 2: The second paragraph assumes overlay cloud service
provider may be different from Cloud service provider. While this may be a
possibility, most common use cases should be outlined in this paragraph and
in the list of scenarios in the last paragraph of this section. For example
data center operator or cloud service provider hosts tenant systems and
provides virtual network as a service. The underlay infrastructure
including servers and data center network are managed by the same service
provider. The last paragraph of this section should identify which provider
manages the NVE and orchestrates tenant systems.
2. Section 2: Not all data centers environments have all the
risks/threats highlighted in this document. In certain data center
environments operated by a cloud provider or a private enterprise, where
certain risks highlighted in this document may not be applicable. Hence one
or more of the requirements identified in this document may not be
applicable to those use cases and the data center operator may do a risk
assessment and choose to deploy solutions with subset of requirements that
are relevant for their application(s). So the document should make this
clear upfront in section 2. So provide examples outlining the type of risk
and illustrate which requirement is applicable to such scenario.
On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
mechanism.
3. Section 2: Paragraph beginning with SEC-OP: We need a single
set of requirements with MUST/SHOULD/MAY and not separate requirements into
what is needed to “evaluate a given deployment”. I do not agree with the
statement “On the other hand 
 to secure any Geneve deployment” – it
assumes that there should be a Geneve specific security mechanism, which is
not the case with other tunneling schemes – where they work with other
parts of the stack to realize security.
SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution.
4. Section 2: Paragraph beginning with SEC-GEN: We should remove
references to new protocols or design of a specific solution. There is no
rationale for a new protocol design while existing mechanisms would
suffice.
5. Section 4: Suggest to make this document self-contained, we
don’t know the status of the other document. Just we can state that
“securing control plane is not in scope of this document”..
6. Section 4.1 - paragraph beginning with “Avoiding” – this is a
very generic statement and imposes a requirement that is not needed
(“..typically making leaked data unusable..”). Also please identify which
is the rogue element described in this paragraph. For example, is this an
NVE or a forwarding element in the underlay?
7. Section 4.2 – “Rogue element on path of TS traffic” Identify
with respect to Figure 1 where is the rogue element is located. For example
in server system where a TS is directly connected to an NVE this may not be
applicable, and hence are the requirements associated with this case. Also
as per section 5, the Network connecting TSes and NVEs are out of scope and
also an attacker controlling the underlying network device is out of scope.
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
8. Section 5. Selectively protecting portions of the Geneve packet,
because tenant is already protecting the packet is more of an optimization
and not an essential requirement as the security can be provide by
protecting the entire Geneve packet for example using IPsec. Also an NVE
may service multiple tenant systems and may have a policy to protect all
packets from tenant systems irrespective of whether a tenant systems uses
other mechanism at the payload level.
A secure deployment of a Geneve overlay must fulfill the requirement
9. Section 5.1 “A secure deployment of Geneve must fulfill the
requirements below”. Not all scenarios need to meet all of these
requirements. Leading each paragraph with a blanket statement like this may
imply, if some of these requirements are not used or enabled (by the
operator based on their risk evaluation) then it is not a secure
deployment. This is not accurate, specifically state the conditions of the
risk and when such a requirement is applicable for risk mitigation, instead
of using blanket statement for each requirement.
10. Section 5.1 - First paragraph: Scenarios described in this first
paragraph were, for example a “passive network observer manipulating two
VMs on the same host” or “controlling network activity of other VMs on the
same host” are not specific to Geneve, so should be out of scope. So remove
these scenarios or state that these are out of scope.
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.
o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.
11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that
all traffic should be encrypted. An operator may evaluate the risk and may
enable encryption to mitigate such risk, remove “default” requirement.
Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of
an optimization that should not be mandated and should not be a
requirement.
12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this
requirement. So need to clearly state under the conditions under which this
MUST requirement is applicable. For example an operator may do risk
assessment and based on the analysis needed may enable this to mitigate the
risk. Mandating Geneve security mechanism must fulfill the following
requirements is not applicable to all scenarios.
13. Section 5.1 - paragraph beginning with “The Geneve Header and
Geneve Options”: Making a distinction about options that need to be read by
transit devices and “other” options may only be accessed by the tunnel end
point is not a valid description. Options are only intended for endpoints –
transit devices MAY interpret them.
o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.
14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry
sensitive information..” is high level. We already say that it is possible
to configure whether the network virtualization layer should also encrypt
in addition to the TS level encryption, that should address such a risk.
Hence this requirement is not necessary.
o 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.
15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the
communication between NVEs
o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.
o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header. Reversely, a Geneve security
mechanism MUST be able to leave in clear header information while
encrypting the other.
o SEC-GEN-5: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.
o SEC-GEN-6: Geneve security mechanism MUST provide the ability to
send dummy packets.
16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN
requirements (for partial encryption) are optimizations which should not be
part of requirements especially with “MUST” mandates. Also see previous
comment for SEC-GEN-5, 6. 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 threat especially when other existing
mechanisms are available to protect communications between NVEs. So adding
requirements for partial headers/payload could not be considered as a
security requirement to address a security threat, hence these requirements
should not be included.
The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.
17. Section 5.2 “Transit devices may process Geneve Options” Geneve
headers (including options) are generated and terminated by NVEs. So if NVE
to NVE communication is secured end to end (e.g. IPsec), then the options
are not visible to transit devices. This is no different than ECMP routers
not having access to inner header information when traffic is encrypted. So
the intent is not for creating authentication or encryption of partial
header (option) information with transit devices along the path. So remove
this paragraph or state that transit devices don’t have access to the bits
or if the tunnel transport communication is secured.
o SEC-OP-4: 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. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.
18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment
of a Geneve overlay SHOULD authenticate communications between NVE
” is
good enough to fulfill the security objective. The other statements are
optimizations and not needed to satisfy security objective, hence the
following sentences can removed, “A Geneve overlay provider MAY disable..”
and “This is not “NOT RECOMMENDED”.
o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
* the Geneve Header and a subset of Geneve Options
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.
o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.
19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations
and should not be specified as requirements. Authentication of end points
is the only requirement that we should look at, which is already captured
in first statement of SEC-OP4. Partial authentication of headers etc., is
an optimization and not essential to secure the communication between NVEs.
Also SEC-GEN-9 specification of transit node behavior is not needed, and
hence to be removed (also see comment 17).
More
specifically, a rogue source NVE will still be able to redirect the
traffic in clear text before protecting ( and encrypting the packet).
A rogue destination NVE will still be able to redirect the traffic in
clear text after decrypting the Geneve packets. The same occurs with
a rogue transit that is in charge of encrypting and decrypting a
Geneve Option, Geneve Option or any information.
20. Section 5.3 First paragraph: In general securing nodes, NVEs and
transit devices should be beyond the scope of securing Geneve transport.
Securing such devices is not specific to Geneve. So the operator should
use other best practices for securing those devices and establish trust
between those devices and NVAs.
o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 both authenticated
with anti replay protection.
21. Section 5.4 – Reproducing earlier comment from the list on previous
version of this draft: “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. “ Hence remove SEC-OP-6.
o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and
authentication associated to each flow between NVEs.
o SEC-OP-8: 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.
o SEC-GEN-11: 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).
22. Section 5.5 – Same comment as above applies to this section
SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level
granularity to be removed. These are prescribing implementations and undue
burden on NVEs that are not needed to secure communication between NVEs.
o SEC-GEN-13: 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.
23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist
for multicasting tenant traffic. For example, implementations my use
multiple unicast tunnels to achieve this objective. So mandating MUST
requirement for specific multicast mechanism is not necessary. An operator
may decide based on their environment as to what multicast mechanism is
applicable to the deployment. Hence MUST requirement should be removed.
24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2
as we should not get into implementation details when discussing
requirements.
/End of Comments/
Thanks,
Ilango
*Sent:* Friday, October 12, 2018 2:22 PM
*Subject:* [nvo3] Fwd: [Curdle] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
Hi,
Please find below an update of the security requirements. I believe the
document reflects the feed backs and comments we received during the
meetings as well the clarification of the transit device.
Any feed back is appreciated!
Yours,
Daniel
-----Original Message-----
Sent: Friday, October 12, 2018 5:14 PM
Subject: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.
Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).
The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
The IETF Secretariat
_______________________________________________
Curdle mailing list
https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
nvo3 mailing list
https://www.ietf.org/mailman/listinfo/nvo3

[Ganga, Ilango S]

Hi Daniel,

Thanks for your responses. I think the fundamental disconnect is on how to frame the security requirements and how to provide guidance to the operators to evaluate potential risks for their deployments, and how to mitigate such risks. This document takes an extreme approach that all requirements must be met to call it a secure deployment. Both the SEC-OP and SEC-GEN take the same extreme approach. Whereas, an operator based on their operating conditions and risk analysis may enable one or more requirements that are applicable to their environment and such a deployment will be secure and will satisfy the objective.

Moreover the document prescribes development of a specific Geneve security mechanism; even though you say existing mechanisms such as IPsec or DTLS can be used, the document implies otherwise. In addition it prescribes implementations like flow level granularity, partial encryption, which are not necessarily needed to secure the deployments. Also, it adds unreasonable burden on operators and NVE implementations that is otherwise not needed to secure the encapsulation protocol. I have not seen precedence for such an approach/requirements for other transport encapsulation protocols.

The document has made certain assumptions about Geneve architecture, on transit nodes, we have proposed text to clarify this as part of the WG last call comments, so those requirements will not be applicable.

Let first address the basic approach for framing the requirements and guidelines for operators, and then we can resolve individual requirements otherwise we are not converging. Let us discuss more during the WG session and also hear from other WG members that have reviewed the document.

Thanks,
Ilango


From: Daniel Migault [mailto:***@ericsson.com]
Sent: Saturday, November 3, 2018 12:11 AM
To: Ganga, Ilango S <***@intel.com>
Cc: ***@ietf.org
Subject: Re: [nvo3] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

Hi Illango,

Please see my responses inline. In most cases I believe the current text
addresses the concerns you raised. In other cases, I addressed them with
additional text. The current version of the draft is available here:
https://github.com/mglt/draft-mglt-nvo3-geneve-security-requirements/blob/master/draft-mglt-nvo3-geneve-security-requirements.mkd

A few comments needs further discussion on the mailing list, but should
not raised any issues.

There one comment I think needs more clarifications on the Geneve
specifications.

As a general comment, I am wondering if the concerns have not been
raised due to a different interpretation of what matching the
requirements means. I believe the illustration of TLS, IPsec in the
appendix sections are good illustrations of how to read them.

In a nutshell, the draft provides two kinds of requirements:
* SEC-OP: provides security requirements to check whether a Geneve deployment is secure or not.
* intended for operators
* security mechanisms are not specified and could be anything
* conditional to some deployment specifities, risk analysis and in some case may not be applicable

* SEC-GEN: provides security requirements for Geneve security mechanism to secure any deployment
* The mechanism needs to be defined (not necessarily a new mechanism)
* The mechanism needs to fit ANY Geneve deployment (compatible with the Geneve architecture /protocol)

The way requirements have been written is that a Geneve deployment
(resp. Geneve Security Mechanism) passes SEC-OP (resp. SEC-GEN) as long
as there is no conflict.
* In some case the requirement does not apply which does not raises any conflict

However, in my view there is still one major concern related to the Geneve architecture that needs to be clarified.

Yours,
Daniel

From: Ganga, Ilango S <***@intel.com<mailto:***@intel.com>>
Sent: Thursday, October 25, 2018 10:13 PM
To: Daniel Migault <***@ericsson.com<mailto:***@ericsson.com>>; ***@ietf.org<mailto:***@ietf.org>
Subject: RE: [nvo3] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

Hello Authors,

Thanks for the revised draft. I reviewed the security requirements document, and here is a list of comments. To summarize, this version has not addressed many of the concerns raised in the previous version of the draft. This version still makes certain assumptions on the functionality of transit devices that is not consistent with the Geneve architecture. One of the key concerns is the requirements 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. Please see below for detailed comments. Also, I would like to thank T. Sridhar for his thorough review and contributions.

List of comments on draft-mglt-nvo3-geneve-security-requirements-04:

1. Section 2: The second paragraph assumes overlay cloud service provider may be different from Cloud service provider. While this may be a possibility, most common use cases should be outlined in this paragraph and in the list of scenarios in the last paragraph of this section. For example data center operator or cloud service provider hosts tenant systems and provides virtual network as a service. The underlay infrastructure including servers and data center network are managed by the same service provider. The last paragraph of this section should identify which provider manages the NVE and orchestrates tenant systems.

<mglt>
The second paragraph of section 2 is the text below:
"""
The underlay infrastructure on which the multi-tenancy overlay
networks are hosted, can be owned and provided by an underlay
provider who may be different from the overlay cloud provider.
"""

The last paragraph of this section is the text below:
"""
Given the different relations between Tenant, Geneve Overlay Provider
and Infrastructure Provider, this document aims providing
requirements to ensure: 1. The Geneve Overlay Provider delivers
tenant payload traffic (Geneve inner payload) and ensuring privacy
and integrity. 2. The Geneve Overlay Provider provides the
necessary means to prevent injection or redirection of the Tenant
traffic from a rogue node in the Geneve overlay network or a rogue
node from the infrastructure. 3. The Geneve Overlay Provider can
rely on the Geneve overlay in term of robustness and reliability of
the signaling associated to the Geneve packets (Geneve tunnel header,
Geneve header and Geneve options) in order to appropriately manage
its overlay.
"""

If I understand correctly, the comment says that the most common use
case- a Cloud Provider providing the virtual network as a service -
should be listed. I am inclined to think that use cases popularity is
out of the scope of a security analysis.

This document elaborates a model to perform a security analysis. The
model defines roles and relations between them as specified in the
Geneve architecture document. That a specific combination is
popular/common or not should not impact the security analysis.
Typically, while the most common use case of today is likely to evolve
over time, the security analysis must not. As a result, considering use
cases here seems to me out of scope of the document.

As a side note, basing the security analysis on specific use cases is
likely to create security vulnerabilities for deployment that do not
exactly match the considered *most* common use case. As a result, this
will limit drastically the usage of the protocol to a specific use case,
which is probably not what we are looking for.

Do we agree that use cases and security analysis are orthogonal, or do
you believe we should still add some considerations of the use cases ?

</mglt>

2. Section 2: Not all data centers environments have all the risks/threats highlighted in this document. In certain data center environments operated by a cloud provider or a private enterprise, where certain risks highlighted in this document may not be applicable. Hence one or more of the requirements identified in this document may not be applicable to those use cases and the data center operator may do a risk assessment and choose to deploy solutions with subset of requirements that are relevant for their application(s). So the document should make this clear upfront in section 2. So provide examples outlining the type of risk and illustrate which requirement is applicable to such scenario.

<mglt>
If I understand correctly, the comment says that section 2 should state
that deployment has different threats and risks so specific deployment
may only consider a subset of the requirements.

I believe the current document agrees with that statement and already
provides the text below in section 2. If that does not address the
concerns, please let us know how to update the text below

"""
The document provides two sets of security requirements:

1. SEC-OP: requirements to evaluate a given deployment of Geneve
overlay. Such requirements are intended to Geneve overlay
provider to evaluate a given deployment. Security of the Geneve
packet may be achieved using various mechanisms. Typically, some
deployments may use a limited subset of the capabilities provided
by Geneve and rely on specific assumptions. Given these
specificities, the secure deployment of a given Geneve deployment
may be achieved reusing specific mechanisms such as for example
DTLS [RFC6347] or IPsec [RFC4301].
"""
</mglt>

On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
mechanism.

3. Section 2: Paragraph beginning with SEC-OP: We need a single set of requirements with MUST/SHOULD/MAY and not separate requirements into what is needed to “evaluate a given deployment”. I do not agree with the statement “On the other hand 
 to secure any Geneve deployment” – it assumes that there should be a Geneve specific security mechanism, which is not the case with other tunneling schemes – where they work with other parts of the stack to realize security.

<mglt>
I believe that there is a misunderstanding here. SEC-OP and SEC-GEN
designates a category of security requirements. The security
requirements is listed later in the document. The category does not lead
to MUST/SHOULD/MAY statement.

SEC-OP are intended to an operator to check whether its deployment is
secured or not. This category has been added in this version. The
category has been added as this has been requested.

SEC-GEN defines the security requirements that a future Geneve security
mechanism needs to fulfill, in order to secure any Geneve deployment
that respect the Geneve architecture. The mechanism has not been yet
defined. There is no assumption that a new mechanism needs to be
designed. The design of such mechanism is expect to re-use existing
mechanisms. In this case all requirements will need to be fulfilled in
order to be considered as a Geneve security mechanism.

I think that the document clearly states that there is no such
assumption and that the design of new mechanism should be avoided as
much as possible.

"""
Such mechanism may require the design of a specific solution. In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""

Do we agree that this concern is addressed by the current draft ?
</mglt>


SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution.

4. Section 2: Paragraph beginning with SEC-GEN: We should remove references to new protocols or design of a specific solution. There is no rationale for a new protocol design while existing mechanisms would suffice.

<mglt>
The protocols have been mentioned as examples, and I believe this is
clarifying to the reader. I see that as a nit and if the WG prefer to
remove them I will be fine with that. Do you agree with this as a way to
move forward ?

"""
In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""
</mglt>



5. Section 4: Suggest to make this document self-contained, we don’t know the status of the other document. Just we can state that “securing control plane is not in scope of this document”.

<mglt>
The sentence has an issue so it needs to be addressed anyway. The
intention of the text is to position the two documents. This has been
asked by the WG that we compare/position the two documents. In addition,
nvo3-security-requirements is a valid document and we expect the reader
to have a look at it.

For your second suggestion, I am reading the texts as equivalent, and
here is what I propose. I suppose this address the concern.

OLD:
Attacks from compromised NVO3 and underlay network devices, and
attacks from compromised tenant systems defined in
[I-D.ietf-nvo3-security-requirements]. This document considers these
attacks in the scope of Geneve, that is when the attackers knowing
the details of the Geneve packets can perform their attacks by
changing fields in the Geneve tunnel header, base header, Geneve
options and Geneve inner payload. The scope of Geneve excludes
security requirements related to the control plane.


NEW:
This section considers attacks performed by NVE, network devices or any
other devices using Geneve, that is when the attackers knowing the
details of the Geneve packets can perform their attacks by changing
fields in the Geneve tunnel header, base header, Geneve options and
Geneve inner payload. Attacks related to the control plane are outside
the scope of this document. The reader is encouraged to read
[I-D.ietf-nvo3-security-requirements] for a similar threat analysis of
NVO3 overlay networks.
</mglt>

6. Section 4.1 - paragraph beginning with “Avoiding” – this is a very generic statement and imposes a requirement that is not needed (“..typically making leaked data unusable..”). Also please identify which is the rogue element described in this paragraph. For example, is this an NVE or a forwarding element in the underlay?

<mglt>

I believe the text has been read as a security requirements, which is
not the case. I propose the following change:

OLD:
Avoiding leaking information is hard to enforced and the security
requirements expect to mitigate such attacks by lowering the
consequences, typically making leaked data unusable to an attacker..

NEW:
Avoiding leaking information is hard to enforced. The security
requirements provided in section {{sniffing} expect to mitigate such
attacks by lowering the consequences, typically making leaked data
unusable to an attacker.


The nature of the rogue element is described in section 4 with the text
provided in section 5. I believe this address this concern.

Note that the rogue element is a NVE, a forwarding element, a TS does
not really matter. What matters is its ability to interfere with the
Geneve overlay. Of course some elements have more capabilities than
others. I will add some text around those lines.

Do you think we should add such consideration ?
</mglt>

7. Section 4.2 – “Rogue element on path of TS traffic” Identify with respect to Figure 1 where is the rogue element is located. For example in server system where a TS is directly connected to an NVE this may not be applicable, and hence are the requirements associated with this case. Also as per section 5, the Network connecting TSes and NVEs are out of scope and also an attacker controlling the underlying network device is out of scope.

<mglt>
The rogue elements are defined in section 4 - see concern 5.

The remaining of the comment seems to say that injecting traffic to a TS
requires the rogue element to be NVE and the TS. This is not what we are
trying to say.

Section 4.2 describes active attacks and mentions that injection attacks
can target TS or the overlay. Active attacks targeting TS injects
packets into the TS traffic. The document considers an attacker
injection packets to the TS by crafting Geneve packets. How the TS are
connected to the NVE does not change anything.

Section 4.2 is structured as follows:
* The first paragraph says that active attacks may concern the TS or the overlay.
* The second paragraph develops active attacks on TS
* The third paragraph develops active attacks on the overlay network.

To clarify I propose the following changes. I believe this address the
concern.

OLD:
Active attacks involve modifying packets, injecting packets, or
interfering with packet delivery (such as by corrupting packet
checksum). Active attack may target the Tenant System or the Geneve
overlay.

NEW:
Active attacks involve modifying Geneve packets, injecting Geneve
packets, or interfering with Geneve packet delivery (such as by
corrupting packet checksum). Active attack may target the Tenant System
or the Geneve overlay.

</mglt>


Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.

8. Section 5. Selectively protecting portions of the Geneve packet, because tenant is already protecting the packet is more of an optimization and not an essential requirement as the security can be provide by protecting the entire Geneve packet for example using IPsec. Also an NVE may service multiple tenant systems and may have a policy to protect all packets from tenant systems irrespective of whether a tenant systems uses other mechanism at the payload level.

<mglt>
I believe the text you refer to is the one below:
"""
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
"""

The text does not provide any requirement. The requirements are provided
in section 5.1. with SEC-GEN-1 and SEC-GEN-2.

I understand the concern as: Does these SEC-GEN-1 and SEC-GEN-2 - see
below - prevents using IPsec as a Geneve Security Mechanism ? As
SEC-GEN-2 does not mandate partial encryption, SEC-GEN-1 and SEC-GEN-2
does not prevent using IPsec as a Geneve security mechanisms. I suppose
this addresses the concern.

"""
A Geneve security mechanism must fulfill the requirements below:

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

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

</mglt>


A secure deployment of a Geneve overlay must fulfill the requirement
below:

9. Section 5.1 “A secure deployment of Geneve must fulfill the requirements below”. Not all scenarios need to meet all of these requirements. Leading each paragraph with a blanket statement like this may imply, if some of these requirements are not used or enabled (by the operator based on their risk evaluation) then it is not a secure deployment. This is not accurate, specifically state the conditions of the risk and when such a requirement is applicable for risk mitigation, instead of using blanket statement for each requirement.

<mglt>
I understand the comment as a concern of the SEC-OP security
requirements, and not specifically to SEC-OP-1.

The purpose of SEC-OP is clearly to provide the operator the ability to
evaluate the Geneve deployment is secure. If one of those is not met,
the deployment will not be considered as secured. I understand this as a
goal of the SEC-OP security requirements. That said, the SEC-OP
requirements are based on conditions - based on risks or specific
assumptions. When these condition are not met, the requirement does not
raise a security mismatch and as such is considered to pass
the requirement.

I suspect that the interpretation of the security requirements is main
reason of the concerns. I propose to add the following text in section
2. I guess this address the concern.

"""
SEC-OP : [..] A given Geneve
A given Geneve
deployment will be considered secured when matching with all SEC-OP
requirements does not raises any concern. As such the given deployment
will be considered passing SEC-OP requirements that are not applicable.
"""

"""
SEC-GEN: [...]
A given candidate for a
security mechanism will be considered as valid when matching with all
SEC-GEN requirements does not raise any concern. In other words, at
least all MUST status are met.
"""
</mglt>

10. Section 5.1 - First paragraph: Scenarios described in this first paragraph were, for example a “passive network observer manipulating two VMs on the same host” or “controlling network activity of other VMs on the same host” are not specific to Geneve, so should be out of scope. So remove these scenarios or state that these are out of scope.

<mglt>
The text you refer describes the passive attack. It is important to
mention that information retrieved from observing Geneve traffic can be
complemented by additional information. I believe this paragraph should
rather be moved to the threat description section (section 4.1). The
following text has been updated and moved. I believe this address the
concern.

"""
Passive attacks may also consist in inferring information about a
virtualized network or some Tenant System from observing the Geneve
traffic. This could also involve the correlation between observed
traffic and additional information. For example, a passive network
observer can determine two virtual machines are communicating by
manipulating activity or network activity of other virtual machines on
that same host. For example, the attacker could control (or be otherwise
aware of) network activity of the other VMs running on the same host,
and deduce other network activity is due to a victim VM.
"""

</mglt>


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.

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

11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that all traffic should be encrypted. An operator may evaluate the risk and may enable encryption to mitigate such risk, remove “default” requirement.


<mglt>
It is unclear to me where SEC-OP-1 does not address the concern.
"""
1. 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.
"""

SHOULD indicates this is not mandated and the remaining text mentions an
operator MAY disable this capability. I believe this address the
concern. If not it would be good to provide an example where SEC-OP-1
prevents the deployement as being secured.
</mglt>

Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of an optimization that should not be mandated and should not be a requirement.

<mglt>
I suspect the concern is whether Geneve deployment with NVE-to-NVE
communications and TS communications encrypted can be considered secure.
This is more related to a deployment. As this is a deployment it should
be related to SEC-OP requirements. The case provided fulfill SEC-OP-1 as
partial encryption comes with a MAY staus. I believe the concern is
addressed.

That said, the concern may also be whether a security mechanism that
does not provide partial encryption can be considered as a geneve
security mechanism.

SEC-GEN provide requirements the mechanism to secure Geneve overlay
needs to fulfill.

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

SEC-GEN-2 comes with a SHOULD statement that does not make it mandatory.
SEC-GEN-1 requires the capability to encrypt and comes with a MUST
statement. As a result a mechanism that encrypts fulfill SEC-GEN-1 and
SEC-GEN-2.

I suppose that address the concern. I provided text to explain how
requirements should be considered to match a deployment or a security
mechanism.
</mglt>


12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this requirement. So need to clearly state under the conditions under which this MUST requirement is applicable. For example an operator may do risk assessment and based on the analysis needed may enable this to mitigate the risk. Mandating Geneve security mechanism must fulfill the following requirements is not applicable to all scenarios.

<mglt>
I believe SEC-OP-1 address the concern as explained in the previous concern.
</mglt>

13. Section 5.1 - paragraph beginning with “The Geneve Header and Geneve Options”: Making a distinction about options that need to be read by transit devices and “other” options may only be accessed by the tunnel end point is not a valid description. Options are only intended for endpoints – transit devices MAY interpret them.

<mglt>
My understanding from the Geneve architecture document is that a Geneve
packet with opt0,opt1,opt2 may have opt1 interpreted by the transit
device and opt0, opt2 interpreted by the NVE. With encrypted
NVE-to-NVE communication, the transit device will not be able to
interpret opt1. As a result, to remain compatible with the Geneve
architecture document, a mechanism that secures Geneve deployment needs
to enable opt1 to appear - at least -in clear text.

This is not always required, but if we do not enable this the security
mechanisms is not compatible with the architecture and I see that as an
potential issue.
</mglt>

o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.

14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry sensitive information..” is high level. We already say that it is possible to configure whether the network virtualization layer should also encrypt in addition to the TS level encryption, that should address such a risk. Hence this requirement is not necessary.

<mglt>
I suspect the concern is how the specific deployment can fulfill
SEC-OP-2. As NVE-NVE communications are encrypted, metadata are not
transmitted in clear text and as such SEC-OP-2 is met by the current
deployment.

I propose the following text to address the concern of too high level
description. I believe this address the concern.

"""
SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate the
information associated to the leakage of the Geneve Outer Header, Geneve
Header and Geneve Option. When a risk analysis concludes that the risk
of leaking sensitive information is too high, such MUST NOT be transmit
in clear text.
"""
</mglt>

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

15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the communication between NVEs

<mglt>
I suspect the concern is to determine whether a deployment based on
IPsec, meet SEC-OP-3. SEC-OP-3 is provided below:
"""
* 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.
"""

If pattern recognition is not considered at risk. SEC-OP-3 is met. In
addition, when it is considered as at risk and IPsec is used, SEC-OP-3
is also met as IPsec provides dummy packet and padding facilities.

I believe this address the concern.
</mglt>

o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.

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

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

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

16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN requirements (for partial encryption) are optimizations which should not be part of requirements especially with “MUST” mandates. Also see previous comment for SEC-GEN-5, 6. 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 threat especially when other existing mechanisms are available to protect communications between NVEs. So adding requirements for partial headers/payload could not be considered as a security requirement to address a security threat, hence these requirements should not be included.

<mglt>
I suspect there is some confusion as none of the requirements SEC-GEN{3-6} are
related to partial encryption. SEC-GEN-5 and SEC-GEN-6 are related to
pattern traffic recognition and SEC-GEN-3 and SEC-GEN-4 are - in my
opinion - NOT related optimization.

Instead SEC-GEN-3 and SEC-GEN-4 are intended to have the security
mechanism compliant with the geneve architecture while protecting
metadata. Only SEC-GEN-2 is related to partial encryption.

If there is a concern, I suppose it needs to be re-stated.
</mglt>


The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.

17. Section 5.2 “Transit devices may process Geneve Options” Geneve headers (including options) are generated and terminated by NVEs. So if NVE to NVE communication is secured end to end (e.g. IPsec), then the options are not visible to transit devices. This is no different than ECMP routers not having access to inner header information when traffic is encrypted. So the intent is not for creating authentication or encryption of partial header (option) information with transit devices along the path. So remove this paragraph or state that transit devices don’t have access to the bits or if the tunnel transport communication is secured.

<mglt>
If I understand correctly the comment, deployment where a transit device
process an option of a clear text Geneve packet will not be able to
process that option in a secured deployment with NVE-NVE encrypted
communications. While this is may be an acceptable compromise for a
given deployment, and such compromise will not make the deployment
unsecure. Such compromise is not acceptable for a geneve security
mechanism. IN fact, this makes security not aligned with the
architecture. If my understanding is correct this is a major issue which
also needs to be addressed by the architecture document.

</mglt>

o SEC-OP-4: 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. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.

18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment of a Geneve overlay SHOULD authenticate communications between NVE
” is good enough to fulfill the security objective. The other statements are optimizations and not needed to satisfy security objective, hence the following sentences can removed, “A Geneve overlay provider MAY disable..” and “This is not “NOT RECOMMENDED”.

<mglt>
The two authentication achieves different goals. Authentication of the
Geneve Header prevents mixing the virtual networks. Authentication of
the payload protects also the TS. This needs to be discussed further as
the WG has requested such granularity. I am open to the discussion. The
trade off here might between an optimal security that cannot be met
versus achieving at least the protection of the infrastructure.
</mglt>

o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
at least:

* the Geneve Header and a subset of Geneve Options

* the Geneve Header, a subset of Geneve options and the Geneve
inner payload

* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.

o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.

19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations and should not be specified as requirements. Authentication of end points is the only requirement that we should look at, which is already captured in first statement of SEC-OP4. Partial authentication of headers etc., is an optimization and not essential to secure the communication between NVEs. Also SEC-GEN-9 specification of transit node behavior is not needed, and hence to be removed (also see comment 17).

<mglt>
The purpose of these security requirements is to align security with the
Geneve architecture rather than to proceed to some optimizations. This
clearly needs some clarifications.
</mglt>

More
specifically, a rogue source NVE will still be able to redirect the
traffic in clear text before protecting ( and encrypting the packet).
A rogue destination NVE will still be able to redirect the traffic in
clear text after decrypting the Geneve packets. The same occurs with
a rogue transit that is in charge of encrypting and decrypting a
Geneve Option, Geneve Option or any information.

20. Section 5.3 First paragraph: In general securing nodes, NVEs and transit devices should be beyond the scope of securing Geneve transport. Securing such devices is not specific to Geneve. So the operator should use other best practices for securing those devices and establish trust between those devices and NVAs.

<mglt>
Unless I misunderstand the comment, I think we agree as stated in the text below:
"""
If the rogue device is in
charge of the securing the Geneve packet, then Geneve security
mechanisms are not intended to address this threat.
"""

However, maybe we could to state this as these nodes are able to
interfere with Geneve and what makes them different - and out of scope
of a Geneve security mechanism is that there are tunnel endpoint. In
other words, if they are attacking another NVE-NVE communication they
become in scope. Do you want to propose some text ?
</mglt>

o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 both authenticated
with anti replay protection.

21. Section 5.4 – Reproducing earlier comment from the list on previous version of this draft: “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. “ Hence remove SEC-OP-6.

<mglt>
SEC-OP-6 concerns anti-replay attack, not flow management.

I believe that the following text addresses the concern:

OLD:
* SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate the
flows subject to replay attacks. Flows 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 both authenticated with anti replay
protection.

NEW:
* SEC-OP-6: 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 both authenticated with
anti replay protection.
</mglt>

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

o SEC-OP-8: 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.

o SEC-GEN-11: 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).


22. Section 5.5 – Same comment as above applies to this section SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level granularity to be removed. These are prescribing implementations and undue burden on NVEs that are not needed to secure communication between NVEs.

<mglt>
My understanding is that a communication is characterized by flows.
There is a need to define what is being encrypted and this si
characterized by a flow.

I believe the concern is about reducing the granularity of the flows. I
believe more discussion is needed to define the right set of
granularity.
</mglt>

o SEC-GEN-13: 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.

23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist for multicasting tenant traffic. For example, implementations my use multiple unicast tunnels to achieve this objective. So mandating MUST requirement for specific multicast mechanism is not necessary. An operator may decide based on their environment as to what multicast mechanism is applicable to the deployment. Hence MUST requirement should be removed.

<mglt>
As I understand the comments exposes how to replace multicast
communications with unicast. If such deployment is achieved, SEC_GEN-13
is not applicable as SEC-GEN-13 is for multicast communications. I guess
this addresses the concern.

</mglt>

24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2 as we should not get into implementation details when discussing requirements.

<mglt>

I believe they are good illustration of how the current security
mechanism match the requirements. The reason I suggest we keep them are:
* it answers most of the question what if I use IPsec, TLS. It helps
* reading the security requirements from an operational point of view as
well as from a design point of view.

I suppose that both of these items have raised issues, so illustrative
example should be welcome.

I suggest to place these section into an appendix, which I guess address
the concern.
</mglt>


/End of Comments/

Thanks,
Ilango


From: nvo3 [mailto:nvo3-***@ietf.org<mailto:nvo3-***@ietf.org>] On Behalf Of Daniel Migault
Sent: Friday, October 12, 2018 2:22 PM
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [nvo3] Fwd: [Curdle] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

Hi,

Please find below an update of the security requirements. I believe the document reflects the feed backs and comments we received during the meetings as well the clarification of the transit device.

Any feed back is appreciated!
Yours,
Daniel

-----Original Message-----
From: internet-***@ietf.org<mailto:internet-***@ietf.org> <internet-***@ietf.org<mailto:internet-***@ietf.org>>
Sent: Friday, October 12, 2018 5:14 PM
To: Sami Boutros <***@vmware.com<mailto:***@vmware.com>>; Dan Wings <***@vmware.com<mailto:***@vmware.com>>; Dan Wing <***@vmware.com<mailto:***@vmware.com>>; Daniel Migault <***@ericsson.com<mailto:***@ericsson.com>>; Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>>
Subject: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt


A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
URL: https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
Status: https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
Htmlized: https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04

Abstract:
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).

The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Curdle mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/curdle

On Thu, Oct 25, 2018 at 10:12 PM Ganga, Ilango S <***@intel.com<mailto:***@intel.com>> wrote:
Hello Authors,

Thanks for the revised draft. I reviewed the security requirements document, and here is a list of comments. To summarize, this version has not addressed many of the concerns raised in the previous version of the draft. This version still makes certain assumptions on the functionality of transit devices that is not consistent with the Geneve architecture. One of the key concerns is the requirements 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. Please see below for detailed comments. Also, I would like to thank T. Sridhar for his thorough review and contributions.

List of comments on draft-mglt-nvo3-geneve-security-requirements-04:


1. Section 2: The second paragraph assumes overlay cloud service provider may be different from Cloud service provider. While this may be a possibility, most common use cases should be outlined in this paragraph and in the list of scenarios in the last paragraph of this section. For example data center operator or cloud service provider hosts tenant systems and provides virtual network as a service. The underlay infrastructure including servers and data center network are managed by the same service provider. The last paragraph of this section should identify which provider manages the NVE and orchestrates tenant systems.



2. Section 2: Not all data centers environments have all the risks/threats highlighted in this document. In certain data center environments operated by a cloud provider or a private enterprise, where certain risks highlighted in this document may not be applicable. Hence one or more of the requirements identified in this document may not be applicable to those use cases and the data center operator may do a risk assessment and choose to deploy solutions with subset of requirements that are relevant for their application(s). So the document should make this clear upfront in section 2. So provide examples outlining the type of risk and illustrate which requirement is applicable to such scenario.


On the other hand, the

definition of a security mechanisms that enables to secure any

Geneve deployment requires the design of a Geneve specific

mechanism.


3. Section 2: Paragraph beginning with SEC-OP: We need a single set of requirements with MUST/SHOULD/MAY and not separate requirements into what is needed to “evaluate a given deployment”. I do not agree with the statement “On the other hand 
 to secure any Geneve deployment” – it assumes that there should be a Geneve specific security mechanism, which is not the case with other tunneling schemes – where they work with other parts of the stack to realize security.



SEC-GEN: requirements a security mechanism need to fulfill to

secure any deployment of Geneve overlay deployment. Such

mechanism may require the design of a specific solution.


4. Section 2: Paragraph beginning with SEC-GEN: We should remove references to new protocols or design of a specific solution. There is no rationale for a new protocol design while existing mechanisms would suffice.



5. Section 4: Suggest to make this document self-contained, we don’t know the status of the other document. Just we can state that “securing control plane is not in scope of this document”.



6. Section 4.1 - paragraph beginning with “Avoiding” – this is a very generic statement and imposes a requirement that is not needed (“..typically making leaked data unusable..”). Also please identify which is the rogue element described in this paragraph. For example, is this an NVE or a forwarding element in the underlay?



7. Section 4.2 – “Rogue element on path of TS traffic” Identify with respect to Figure 1 where is the rogue element is located. For example in server system where a TS is directly connected to an NVE this may not be applicable, and hence are the requirements associated with this case. Also as per section 5, the Network connecting TSes and NVEs are out of scope and also an attacker controlling the underlying network device is out of scope.


Selectively providing integrity / authentication, confidentiality /

encryption of only portions of the Geneve packet is in scope. This

will be the case if the Tenant Systems uses security protocol to

protect its communications.


8. Section 5. Selectively protecting portions of the Geneve packet, because tenant is already protecting the packet is more of an optimization and not an essential requirement as the security can be provide by protecting the entire Geneve packet for example using IPsec. Also an NVE may service multiple tenant systems and may have a policy to protect all packets from tenant systems irrespective of whether a tenant systems uses other mechanism at the payload level.


A secure deployment of a Geneve overlay must fulfill the requirement

below:


9. Section 5.1 “A secure deployment of Geneve must fulfill the requirements below”. Not all scenarios need to meet all of these requirements. Leading each paragraph with a blanket statement like this may imply, if some of these requirements are not used or enabled (by the operator based on their risk evaluation) then it is not a secure deployment. This is not accurate, specifically state the conditions of the risk and when such a requirement is applicable for risk mitigation, instead of using blanket statement for each requirement.



10. Section 5.1 - First paragraph: Scenarios described in this first paragraph were, for example a “passive network observer manipulating two VMs on the same host” or “controlling network activity of other VMs on the same host” are not specific to Geneve, so should be out of scope. So remove these scenarios or state that these are out of scope.



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.



o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability

to partially encrypt the inner payload header.



11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that all traffic should be encrypted. An operator may evaluate the risk and may enable encryption to mitigate such risk, remove “default” requirement. Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of an optimization that should not be mandated and should not be a requirement.



12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this requirement. So need to clearly state under the conditions under which this MUST requirement is applicable. For example an operator may do risk assessment and based on the analysis needed may enable this to mitigate the risk. Mandating Geneve security mechanism must fulfill the following requirements is not applicable to all scenarios.



13. Section 5.1 - paragraph beginning with “The Geneve Header and Geneve Options”: Making a distinction about options that need to be read by transit devices and “other” options may only be accessed by the tunnel end point is not a valid description. Options are only intended for endpoints – transit devices MAY interpret them.


o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate

the information associated to the leakage of the Geneve Outer

Header, Geneve Header and Geneve Option. When those information

are likely to carry sensitive information. they MUST NOT be

transmit in clear text.


14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry sensitive information..” is high level. We already say that it is possible to configure whether the network virtualization layer should also encrypt in addition to the TS level encryption, that should address such a risk. Hence this requirement is not necessary.


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


15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the communication between NVEs



o SEC-GEN-3: Geneve security mechanism MUST provide the capability

to encrypt a single or a set of options while leave other Geneve

Option in clear. Reversely, a Geneve security mechanism MUST be

able to leave a Geneve option in clear, while encrypting the

others.



o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt

the information of Geneve Header. Reversely, a Geneve security

mechanism MUST be able to leave in clear header information while

encrypting the other.



o SEC-GEN-5: Geneve security mechanism MUST provide the ability to

pad a Geneve packet.



o SEC-GEN-6: Geneve security mechanism MUST provide the ability to

send dummy packets.



16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN requirements (for partial encryption) are optimizations which should not be part of requirements especially with “MUST” mandates. Also see previous comment for SEC-GEN-5, 6. 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 threat especially when other existing mechanisms are available to protect communications between NVEs. So adding requirements for partial headers/payload could not be considered as a security requirement to address a security threat, hence these requirements should not be included.



The Geneve architecture

considers transit devices that MAY process some Geneve Option without

affecting the Geneve packet. These transit device MAY Authenticate

the Geneve packet as part of the Geneve packet processing but MAY

also process other Geneve options. As a result, integrity protection

and authentication SHOULD be performed by transit device, prior to

any processing.


17. Section 5.2 “Transit devices may process Geneve Options” Geneve headers (including options) are generated and terminated by NVEs. So if NVE to NVE communication is secured end to end (e.g. IPsec), then the options are not visible to transit devices. This is no different than ECMP routers not having access to inner header information when traffic is encrypted. So the intent is not for creating authentication or encryption of partial header (option) information with transit devices along the path. So remove this paragraph or state that transit devices don’t have access to the bits or if the tunnel transport communication is secured.



o SEC-OP-4: 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. To prevent injection between

virtualized network, it is strongly RECOMMENDED that at least the

Geneve Header is authenticated.



18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment of a Geneve overlay SHOULD authenticate communications between NVE
” is good enough to fulfill the security objective. The other statements are optimizations and not needed to satisfy security objective, hence the following sentences can removed, “A Geneve overlay provider MAY disable..” and “This is not “NOT RECOMMENDED”.



o SEC-GEN-8: Geneve Security mechanism MUST provide means for a

tunnel endpoint (NVE) to authenticate data prior it is being

processed. A tunnel endpoint (NVE) MUST be able to authenticate

at least:



* the Geneve Header and a subset of Geneve Options



* the Geneve Header, a subset of Geneve options and the Geneve

inner payload



* the Geneve Header, a subset of Geneve options and the Geneve

inner payload or the portion of the inner payload in case the

Tenant's System provides some authentication mechanism.


o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a

transit device to authenticate the Geneve Option prior processing

it. Authentication MAY concern the whole Geneve packet, but MAY

be limited to the Geneve Option.


19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations and should not be specified as requirements. Authentication of end points is the only requirement that we should look at, which is already captured in first statement of SEC-OP4. Partial authentication of headers etc., is an optimization and not essential to secure the communication between NVEs. Also SEC-GEN-9 specification of transit node behavior is not needed, and hence to be removed (also see comment 17).



More

specifically, a rogue source NVE will still be able to redirect the

traffic in clear text before protecting ( and encrypting the packet).

A rogue destination NVE will still be able to redirect the traffic in

clear text after decrypting the Geneve packets. The same occurs with

a rogue transit that is in charge of encrypting and decrypting a

Geneve Option, Geneve Option or any information.


20. Section 5.3 First paragraph: In general securing nodes, NVEs and transit devices should be beyond the scope of securing Geneve transport. Securing such devices is not specific to Geneve. So the operator should use other best practices for securing those devices and establish trust between those devices and NVAs.



o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate

the flows subject to replay attacks. Flows 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 both authenticated

with anti replay protection.



21. Section 5.4 – Reproducing earlier comment from the list on previous version of this draft: “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. “ Hence remove SEC-OP-6.



o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the

security policies that associates the encryption, and

authentication associated to each flow between NVEs.



o SEC-OP-8: 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.



o SEC-GEN-11: 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).





22. Section 5.5 – Same comment as above applies to this section SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level granularity to be removed. These are prescribing implementations and undue burden on NVEs that are not needed to secure communication between NVEs.


o SEC-GEN-13: 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.



23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist for multicasting tenant traffic. For example, implementations my use multiple unicast tunnels to achieve this objective. So mandating MUST requirement for specific multicast mechanism is not necessary. An operator may decide based on their environment as to what multicast mechanism is applicable to the deployment. Hence MUST requirement should be removed.



24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2 as we should not get into implementation details when discussing requirements.

/End of Comments/

Thanks,
Ilango


From: nvo3 [mailto:nvo3-***@ietf.org<mailto:nvo3-***@ietf.org>] On Behalf Of Daniel Migault
Sent: Friday, October 12, 2018 2:22 PM
To: ***@ietf.org<mailto:***@ietf.org>
Subject: [nvo3] Fwd: [Curdle] FW: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt

Hi,

Please find below an update of the security requirements. I believe the document reflects the feed backs and comments we received during the meetings as well the clarification of the transit device.

Any feed back is appreciated!
Yours,
Daniel

-----Original Message-----
From: internet-***@ietf.org<mailto:internet-***@ietf.org> <internet-***@ietf.org<mailto:internet-***@ietf.org>>
Sent: Friday, October 12, 2018 5:14 PM
To: Sami Boutros <***@vmware.com<mailto:***@vmware.com>>; Dan Wings <***@vmware.com<mailto:***@vmware.com>>; Dan Wing <***@vmware.com<mailto:***@vmware.com>>; Daniel Migault <***@ericsson.com<mailto:***@ericsson.com>>; Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>>
Subject: New Version Notification for draft-mglt-nvo3-geneve-security-requirements-04.txt


A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
URL: https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
Status: https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
Htmlized: https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04

Abstract:
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).

The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Curdle mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
nvo3 mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3

[Daniel Migault]

Hi Illango,

In order to track the issues you opened, I listed all of them into the
issue tracker with my responses [1]. I believe a lot of these issues are
addressed, so I would like you to respond to these issue and state whether
you believe they are closed or not. In case you believe they are not
closed, please provide your reasons so we can evaluate where the disconnect
is, so we can move forward. I believe that will help to define where the
disconnect is.

[1]
https://github.com/mglt/draft-mglt-nvo3-geneve-security-requirements/issues

Yours,
Daniel

Post by Ganga, Ilango S
Hi Daniel,
Thanks for your responses. I think the fundamental disconnect is on how to
frame the security requirements and how to provide guidance to the
operators to evaluate potential risks for their deployments, and how to
mitigate such risks. This document takes an extreme approach that all
requirements must be met to call it a secure deployment. Both the SEC-OP
and SEC-GEN take the same extreme approach. Whereas, an operator based on
their operating conditions and risk analysis may enable one or more
requirements that are applicable to their environment and such a deployment
will be secure and will satisfy the objective.
Moreover the document prescribes development of a specific Geneve security
mechanism; even though you say existing mechanisms such as IPsec or DTLS
can be used, the document implies otherwise. In addition it prescribes
implementations like flow level granularity, partial encryption, which are
not necessarily needed to secure the deployments. Also, it adds
unreasonable burden on operators and NVE implementations that is otherwise
not needed to secure the encapsulation protocol. I have not seen precedence
for such an approach/requirements for other transport encapsulation
protocols.
The document has made certain assumptions about Geneve architecture, on
transit nodes, we have proposed text to clarify this as part of the WG last
call comments, so those requirements will not be applicable.
Let first address the basic approach for framing the requirements and
guidelines for operators, and then we can resolve individual requirements
otherwise we are not converging. Let us discuss more during the WG session
and also hear from other WG members that have reviewed the document.
Thanks,
Ilango
*Sent:* Saturday, November 3, 2018 12:11 AM
*Subject:* Re: [nvo3] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
Hi Illango,
Please see my responses inline. In most cases I believe the current text
addresses the concerns you raised. In other cases, I addressed them with
https://github.com/mglt/draft-mglt-nvo3-geneve-security-requirements/blob/master/draft-mglt-nvo3-geneve-security-requirements.mkd
A few comments needs further discussion on the mailing list, but should
not raised any issues.
There one comment I think needs more clarifications on the Geneve
specifications.
As a general comment, I am wondering if the concerns have not been
raised due to a different interpretation of what matching the
requirements means. I believe the illustration of TLS, IPsec in the
appendix sections are good illustrations of how to read them.
* SEC-OP: provides security requirements to check whether a Geneve
deployment is secure or not.
* intended for operators
* security mechanisms are not specified and could be anything
* conditional to some deployment specifities, risk analysis and in some
case may not be applicable
* SEC-GEN: provides security requirements for Geneve security mechanism to
secure any deployment
* The mechanism needs to be defined (not necessarily a new mechanism)
* The mechanism needs to fit ANY Geneve deployment (compatible with the
Geneve architecture /protocol)
The way requirements have been written is that a Geneve deployment
(resp. Geneve Security Mechanism) passes SEC-OP (resp. SEC-GEN) as long
as there is no conflict.
* In some case the requirement does not apply which does not raises any conflict
However, in my view there is still one major concern related to the Geneve
architecture that needs to be clarified.
Yours,
Daniel
Sent: Thursday, October 25, 2018 10:13 PM
Subject: RE: [nvo3] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
Hello Authors,
Thanks for the revised draft. I reviewed the security requirements
document, and here is a list of comments. To summarize, this version has
not addressed many of the concerns raised in the previous version of the
draft. This version still makes certain assumptions on the functionality of
transit devices that is not consistent with the Geneve architecture. One of
the key concerns is the requirements 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. Please see below for detailed comments. Also, I would
like to thank T. Sridhar for his thorough review and contributions.
1. Section 2: The second paragraph assumes overlay cloud service
provider may be different from Cloud service provider. While this may be a
possibility, most common use cases should be outlined in this paragraph and
in the list of scenarios in the last paragraph of this section. For example
data center operator or cloud service provider hosts tenant systems and
provides virtual network as a service. The underlay infrastructure
including servers and data center network are managed by the same service
provider. The last paragraph of this section should identify which provider
manages the NVE and orchestrates tenant systems.
<mglt>
"""
The underlay infrastructure on which the multi-tenancy overlay
networks are hosted, can be owned and provided by an underlay
provider who may be different from the overlay cloud provider.
"""
"""
Given the different relations between Tenant, Geneve Overlay Provider
and Infrastructure Provider, this document aims providing
requirements to ensure: 1. The Geneve Overlay Provider delivers
tenant payload traffic (Geneve inner payload) and ensuring privacy
and integrity. 2. The Geneve Overlay Provider provides the
necessary means to prevent injection or redirection of the Tenant
traffic from a rogue node in the Geneve overlay network or a rogue
node from the infrastructure. 3. The Geneve Overlay Provider can
rely on the Geneve overlay in term of robustness and reliability of
the signaling associated to the Geneve packets (Geneve tunnel header,
Geneve header and Geneve options) in order to appropriately manage
its overlay.
"""
If I understand correctly, the comment says that the most common use
case- a Cloud Provider providing the virtual network as a service -
should be listed. I am inclined to think that use cases popularity is
out of the scope of a security analysis.
This document elaborates a model to perform a security analysis. The
model defines roles and relations between them as specified in the
Geneve architecture document. That a specific combination is
popular/common or not should not impact the security analysis.
Typically, while the most common use case of today is likely to evolve
over time, the security analysis must not. As a result, considering use
cases here seems to me out of scope of the document.
As a side note, basing the security analysis on specific use cases is
likely to create security vulnerabilities for deployment that do not
exactly match the considered *most* common use case. As a result, this
will limit drastically the usage of the protocol to a specific use case,
which is probably not what we are looking for.
Do we agree that use cases and security analysis are orthogonal, or do
you believe we should still add some considerations of the use cases ?
</mglt>
2. Section 2: Not all data centers environments have all the
risks/threats highlighted in this document. In certain data center
environments operated by a cloud provider or a private enterprise, where
certain risks highlighted in this document may not be applicable. Hence one
or more of the requirements identified in this document may not be
applicable to those use cases and the data center operator may do a risk
assessment and choose to deploy solutions with subset of requirements that
are relevant for their application(s). So the document should make this
clear upfront in section 2. So provide examples outlining the type of risk
and illustrate which requirement is applicable to such scenario.
<mglt>
If I understand correctly, the comment says that section 2 should state
that deployment has different threats and risks so specific deployment
may only consider a subset of the requirements.
I believe the current document agrees with that statement and already
provides the text below in section 2. If that does not address the
concerns, please let us know how to update the text below
"""
1. SEC-OP: requirements to evaluate a given deployment of Geneve
overlay. Such requirements are intended to Geneve overlay
provider to evaluate a given deployment. Security of the Geneve
packet may be achieved using various mechanisms. Typically, some
deployments may use a limited subset of the capabilities provided
by Geneve and rely on specific assumptions. Given these
specificities, the secure deployment of a given Geneve deployment
may be achieved reusing specific mechanisms such as for example
DTLS [RFC6347] or IPsec [RFC4301].
"""
</mglt>
On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
mechanism.
3. Section 2: Paragraph beginning with SEC-OP: We need a single set of
requirements with MUST/SHOULD/MAY and not separate requirements into what
is needed to “evaluate a given deployment”. I do not agree with the
statement “On the other hand 
 to secure any Geneve deployment” – it
assumes that there should be a Geneve specific security mechanism, which is
not the case with other tunneling schemes – where they work with other
parts of the stack to realize security.
<mglt>
I believe that there is a misunderstanding here. SEC-OP and SEC-GEN
designates a category of security requirements. The security
requirements is listed later in the document. The category does not lead
to MUST/SHOULD/MAY statement.
SEC-OP are intended to an operator to check whether its deployment is
secured or not. This category has been added in this version. The
category has been added as this has been requested.
SEC-GEN defines the security requirements that a future Geneve security
mechanism needs to fulfill, in order to secure any Geneve deployment
that respect the Geneve architecture. The mechanism has not been yet
defined. There is no assumption that a new mechanism needs to be
designed. The design of such mechanism is expect to re-use existing
mechanisms. In this case all requirements will need to be fulfilled in
order to be considered as a Geneve security mechanism.
I think that the document clearly states that there is no such
assumption and that the design of new mechanism should be avoided as
much as possible.
"""
Such mechanism may require the design of a specific solution. In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""
Do we agree that this concern is addressed by the current draft ?
</mglt>
SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution.
4. Section 2: Paragraph beginning with SEC-GEN: We should remove
references to new protocols or design of a specific solution. There is no
rationale for a new protocol design while existing mechanisms would
suffice.
<mglt>
The protocols have been mentioned as examples, and I believe this is
clarifying to the reader. I see that as a nit and if the WG prefer to
remove them I will be fine with that. Do you agree with this as a way to
move forward ?
"""
In the
case new protocol needs to be design, the document strongly
recommend to re-use existing security protocols like IP Security
(IPsec) [RFC4301] and Datagram Transport Layer Security (DTLS)
[RFC6347], and existing encryption algorithms (such as
[RFC8221]), and authentication protocols.
"""
</mglt>
5. Section 4: Suggest to make this document self-contained, we don’t
know the status of the other document. Just we can state that “securing
control plane is not in scope of this document”.
<mglt>
The sentence has an issue so it needs to be addressed anyway. The
intention of the text is to position the two documents. This has been
asked by the WG that we compare/position the two documents. In addition,
nvo3-security-requirements is a valid document and we expect the reader
to have a look at it.
For your second suggestion, I am reading the texts as equivalent, and
here is what I propose. I suppose this address the concern.
Attacks from compromised NVO3 and underlay network devices, and
attacks from compromised tenant systems defined in
[I-D.ietf-nvo3-security-requirements]. This document considers these
attacks in the scope of Geneve, that is when the attackers knowing
the details of the Geneve packets can perform their attacks by
changing fields in the Geneve tunnel header, base header, Geneve
options and Geneve inner payload. The scope of Geneve excludes
security requirements related to the control plane.
This section considers attacks performed by NVE, network devices or any
other devices using Geneve, that is when the attackers knowing the
details of the Geneve packets can perform their attacks by changing
fields in the Geneve tunnel header, base header, Geneve options and
Geneve inner payload. Attacks related to the control plane are outside
the scope of this document. The reader is encouraged to read
[I-D.ietf-nvo3-security-requirements] for a similar threat analysis of
NVO3 overlay networks.
</mglt>
6. Section 4.1 - paragraph beginning with “Avoiding” – this is a very
generic statement and imposes a requirement that is not needed
(“..typically making leaked data unusable..”). Also please identify which
is the rogue element described in this paragraph. For example, is this an
NVE or a forwarding element in the underlay?
<mglt>
I believe the text has been read as a security requirements, which is
Avoiding leaking information is hard to enforced and the security
requirements expect to mitigate such attacks by lowering the
consequences, typically making leaked data unusable to an attacker..
Avoiding leaking information is hard to enforced. The security
requirements provided in section {{sniffing} expect to mitigate such
attacks by lowering the consequences, typically making leaked data
unusable to an attacker.
The nature of the rogue element is described in section 4 with the text
provided in section 5. I believe this address this concern.
Note that the rogue element is a NVE, a forwarding element, a TS does
not really matter. What matters is its ability to interfere with the
Geneve overlay. Of course some elements have more capabilities than
others. I will add some text around those lines.
Do you think we should add such consideration ?
</mglt>
7. Section 4.2 – “Rogue element on path of TS traffic” Identify with
respect to Figure 1 where is the rogue element is located. For example in
server system where a TS is directly connected to an NVE this may not be
applicable, and hence are the requirements associated with this case. Also
as per section 5, the Network connecting TSes and NVEs are out of scope and
also an attacker controlling the underlying network device is out of scope.
<mglt>
The rogue elements are defined in section 4 - see concern 5.
The remaining of the comment seems to say that injecting traffic to a TS
requires the rogue element to be NVE and the TS. This is not what we are
trying to say.
Section 4.2 describes active attacks and mentions that injection attacks
can target TS or the overlay. Active attacks targeting TS injects
packets into the TS traffic. The document considers an attacker
injection packets to the TS by crafting Geneve packets. How the TS are
connected to the NVE does not change anything.
* The first paragraph says that active attacks may concern the TS or the overlay.
* The second paragraph develops active attacks on TS
* The third paragraph develops active attacks on the overlay network.
To clarify I propose the following changes. I believe this address the
concern.
Active attacks involve modifying packets, injecting packets, or
interfering with packet delivery (such as by corrupting packet
checksum). Active attack may target the Tenant System or the Geneve
overlay.
Active attacks involve modifying Geneve packets, injecting Geneve
packets, or interfering with Geneve packet delivery (such as by
corrupting packet checksum). Active attack may target the Tenant System
or the Geneve overlay.
</mglt>
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
8. Section 5. Selectively protecting portions of the Geneve packet,
because tenant is already protecting the packet is more of an optimization
and not an essential requirement as the security can be provide by
protecting the entire Geneve packet for example using IPsec. Also an NVE
may service multiple tenant systems and may have a policy to protect all
packets from tenant systems irrespective of whether a tenant systems uses
other mechanism at the payload level.
<mglt>
"""
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
"""
The text does not provide any requirement. The requirements are provided
in section 5.1. with SEC-GEN-1 and SEC-GEN-2.
I understand the concern as: Does these SEC-GEN-1 and SEC-GEN-2 - see
below - prevents using IPsec as a Geneve Security Mechanism ? As
SEC-GEN-2 does not mandate partial encryption, SEC-GEN-1 and SEC-GEN-2
does not prevent using IPsec as a Geneve security mechanisms. I suppose
this addresses the concern.
"""
o SEC-GEN-1: Geneve security mechanism MUST provide the capability
to encrypt the inner payload.
o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.
"""
</mglt>
A secure deployment of a Geneve overlay must fulfill the requirement
9. Section 5.1 “A secure deployment of Geneve must fulfill the
requirements below”. Not all scenarios need to meet all of these
requirements. Leading each paragraph with a blanket statement like this may
imply, if some of these requirements are not used or enabled (by the
operator based on their risk evaluation) then it is not a secure
deployment. This is not accurate, specifically state the conditions of the
risk and when such a requirement is applicable for risk mitigation, instead
of using blanket statement for each requirement.
<mglt>
I understand the comment as a concern of the SEC-OP security
requirements, and not specifically to SEC-OP-1.
The purpose of SEC-OP is clearly to provide the operator the ability to
evaluate the Geneve deployment is secure. If one of those is not met,
the deployment will not be considered as secured. I understand this as a
goal of the SEC-OP security requirements. That said, the SEC-OP
requirements are based on conditions - based on risks or specific
assumptions. When these condition are not met, the requirement does not
raise a security mismatch and as such is considered to pass
the requirement.
I suspect that the interpretation of the security requirements is main
reason of the concerns. I propose to add the following text in section
2. I guess this address the concern.
"""
SEC-OP : [..] A given Geneve
A given Geneve
deployment will be considered secured when matching with all SEC-OP
requirements does not raises any concern. As such the given deployment
will be considered passing SEC-OP requirements that are not applicable.
"""
"""
SEC-GEN: [...]
A given candidate for a
security mechanism will be considered as valid when matching with all
SEC-GEN requirements does not raise any concern. In other words, at
least all MUST status are met.
"""
</mglt>
10. Section 5.1 - First paragraph: Scenarios described in this first
paragraph were, for example a “passive network observer manipulating two
VMs on the same host” or “controlling network activity of other VMs on the
same host” are not specific to Geneve, so should be out of scope. So remove
these scenarios or state that these are out of scope.
<mglt>
The text you refer describes the passive attack. It is important to
mention that information retrieved from observing Geneve traffic can be
complemented by additional information. I believe this paragraph should
rather be moved to the threat description section (section 4.1). The
following text has been updated and moved. I believe this address the
concern.
"""
Passive attacks may also consist in inferring information about a
virtualized network or some Tenant System from observing the Geneve
traffic. This could also involve the correlation between observed
traffic and additional information. For example, a passive network
observer can determine two virtual machines are communicating by
manipulating activity or network activity of other virtual machines on
that same host. For example, the attacker could control (or be otherwise
aware of) network activity of the other VMs running on the same host,
and deduce other network activity is due to a victim VM.
"""
</mglt>
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.
o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.
11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that
all traffic should be encrypted. An operator may evaluate the risk and may
enable encryption to mitigate such risk, remove “default” requirement.
<mglt>
It is unclear to me where SEC-OP-1 does not address the concern.
"""
1. 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.
"""
SHOULD indicates this is not mandated and the remaining text mentions an
operator MAY disable this capability. I believe this address the
concern. If not it would be good to provide an example where SEC-OP-1
prevents the deployement as being secured.
</mglt>
Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of
an optimization that should not be mandated and should not be a
requirement.
<mglt>
I suspect the concern is whether Geneve deployment with NVE-to-NVE
communications and TS communications encrypted can be considered secure.
This is more related to a deployment. As this is a deployment it should
be related to SEC-OP requirements. The case provided fulfill SEC-OP-1 as
partial encryption comes with a MAY staus. I believe the concern is
addressed.
That said, the concern may also be whether a security mechanism that
does not provide partial encryption can be considered as a geneve
security mechanism.
SEC-GEN provide requirements the mechanism to secure Geneve overlay
needs to fulfill.
""" o SEC-GEN-2: Geneve security mechanism SHOULD provide the
capability to partially encrypt the inner payload header. """
SEC-GEN-2 comes with a SHOULD statement that does not make it mandatory.
SEC-GEN-1 requires the capability to encrypt and comes with a MUST
statement. As a result a mechanism that encrypts fulfill SEC-GEN-1 and
SEC-GEN-2.
I suppose that address the concern. I provided text to explain how
requirements should be considered to match a deployment or a security
mechanism.
</mglt>
12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this
requirement. So need to clearly state under the conditions under which this
MUST requirement is applicable. For example an operator may do risk
assessment and based on the analysis needed may enable this to mitigate the
risk. Mandating Geneve security mechanism must fulfill the following
requirements is not applicable to all scenarios.
<mglt>
I believe SEC-OP-1 address the concern as explained in the previous concern.
</mglt>
13. Section 5.1 - paragraph beginning with “The Geneve Header and
Geneve Options”: Making a distinction about options that need to be read by
transit devices and “other” options may only be accessed by the tunnel end
point is not a valid description. Options are only intended for endpoints –
transit devices MAY interpret them.
<mglt>
My understanding from the Geneve architecture document is that a Geneve
packet with opt0,opt1,opt2 may have opt1 interpreted by the transit
device and opt0, opt2 interpreted by the NVE. With encrypted
NVE-to-NVE communication, the transit device will not be able to
interpret opt1. As a result, to remain compatible with the Geneve
architecture document, a mechanism that secures Geneve deployment needs
to enable opt1 to appear - at least -in clear text.
This is not always required, but if we do not enable this the security
mechanisms is not compatible with the architecture and I see that as an
potential issue.
</mglt>
o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.
14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry
sensitive information..” is high level. We already say that it is possible
to configure whether the network virtualization layer should also encrypt
in addition to the TS level encryption, that should address such a risk.
Hence this requirement is not necessary.
<mglt>
I suspect the concern is how the specific deployment can fulfill
SEC-OP-2. As NVE-NVE communications are encrypted, metadata are not
transmitted in clear text and as such SEC-OP-2 is met by the current
deployment.
I propose the following text to address the concern of too high level
description. I believe this address the concern.
"""
SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate the
information associated to the leakage of the Geneve Outer Header, Geneve
Header and Geneve Option. When a risk analysis concludes that the risk
of leaking sensitive information is too high, such MUST NOT be transmit
in clear text.
"""
</mglt>
o 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.
15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the
communication between NVEs
<mglt>
I suspect the concern is to determine whether a deployment based on
"""
* 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.
"""
If pattern recognition is not considered at risk. SEC-OP-3 is met. In
addition, when it is considered as at risk and IPsec is used, SEC-OP-3
is also met as IPsec provides dummy packet and padding facilities.
I believe this address the concern.
</mglt>
o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.
o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header. Reversely, a Geneve security
mechanism MUST be able to leave in clear header information while
encrypting the other.
o SEC-GEN-5: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.
o SEC-GEN-6: Geneve security mechanism MUST provide the ability to
send dummy packets.
16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN
requirements (for partial encryption) are optimizations which should not be
part of requirements especially with “MUST” mandates. Also see previous
comment for SEC-GEN-5, 6. 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 threat especially when other existing
mechanisms are available to protect communications between NVEs. So adding
requirements for partial headers/payload could not be considered as a
security requirement to address a security threat, hence these requirements
should not be included.
<mglt>
I suspect there is some confusion as none of the requirements SEC-GEN{3-6} are
related to partial encryption. SEC-GEN-5 and SEC-GEN-6 are related to
pattern traffic recognition and SEC-GEN-3 and SEC-GEN-4 are - in my
opinion - NOT related optimization.
Instead SEC-GEN-3 and SEC-GEN-4 are intended to have the security
mechanism compliant with the geneve architecture while protecting
metadata. Only SEC-GEN-2 is related to partial encryption.
If there is a concern, I suppose it needs to be re-stated.
</mglt>
The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.
17. Section 5.2 “Transit devices may process Geneve Options” Geneve
headers (including options) are generated and terminated by NVEs. So if NVE
to NVE communication is secured end to end (e.g. IPsec), then the options
are not visible to transit devices. This is no different than ECMP routers
not having access to inner header information when traffic is encrypted. So
the intent is not for creating authentication or encryption of partial
header (option) information with transit devices along the path. So remove
this paragraph or state that transit devices don’t have access to the bits
or if the tunnel transport communication is secured.
<mglt>
If I understand correctly the comment, deployment where a transit device
process an option of a clear text Geneve packet will not be able to
process that option in a secured deployment with NVE-NVE encrypted
communications. While this is may be an acceptable compromise for a
given deployment, and such compromise will not make the deployment
unsecure. Such compromise is not acceptable for a geneve security
mechanism. IN fact, this makes security not aligned with the
architecture. If my understanding is correct this is a major issue which
also needs to be addressed by the architecture document.
</mglt>
o SEC-OP-4: 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. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.
18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment
of a Geneve overlay SHOULD authenticate communications between NVE
” is
good enough to fulfill the security objective. The other statements are
optimizations and not needed to satisfy security objective, hence the
following sentences can removed, “A Geneve overlay provider MAY disable..”
and “This is not “NOT RECOMMENDED”.
<mglt>
The two authentication achieves different goals. Authentication of the
Geneve Header prevents mixing the virtual networks. Authentication of
the payload protects also the TS. This needs to be discussed further as
the WG has requested such granularity. I am open to the discussion. The
trade off here might between an optimal security that cannot be met
versus achieving at least the protection of the infrastructure.
</mglt>
o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
* the Geneve Header and a subset of Geneve Options
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.
o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.
19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations
and should not be specified as requirements. Authentication of end points
is the only requirement that we should look at, which is already captured
in first statement of SEC-OP4. Partial authentication of headers etc., is
an optimization and not essential to secure the communication between NVEs.
Also SEC-GEN-9 specification of transit node behavior is not needed, and
hence to be removed (also see comment 17).
<mglt>
The purpose of these security requirements is to align security with the
Geneve architecture rather than to proceed to some optimizations. This
clearly needs some clarifications.
</mglt>
More
specifically, a rogue source NVE will still be able to redirect the
traffic in clear text before protecting ( and encrypting the packet).
A rogue destination NVE will still be able to redirect the traffic in
clear text after decrypting the Geneve packets. The same occurs with
a rogue transit that is in charge of encrypting and decrypting a
Geneve Option, Geneve Option or any information.
20. Section 5.3 First paragraph: In general securing nodes, NVEs and
transit devices should be beyond the scope of securing Geneve transport.
Securing such devices is not specific to Geneve. So the operator should
use other best practices for securing those devices and establish trust
between those devices and NVAs.
<mglt>
"""
If the rogue device is in
charge of the securing the Geneve packet, then Geneve security
mechanisms are not intended to address this threat.
"""
However, maybe we could to state this as these nodes are able to
interfere with Geneve and what makes them different - and out of scope
of a Geneve security mechanism is that there are tunnel endpoint. In
other words, if they are attacking another NVE-NVE communication they
become in scope. Do you want to propose some text ?
</mglt>
o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 both authenticated
with anti replay protection.
21. Section 5.4 – Reproducing earlier comment from the list on previous
version of this draft: “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. “ Hence remove SEC-OP-6.
<mglt>
SEC-OP-6 concerns anti-replay attack, not flow management.
* SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate the
flows subject to replay attacks. Flows 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 both authenticated with anti replay
protection.
* SEC-OP-6: 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 both authenticated with
anti replay protection.
</mglt>
o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and
authentication associated to each flow between NVEs.
o SEC-OP-8: 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.
o SEC-GEN-11: 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).
22. Section 5.5 – Same comment as above applies to this section
SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level
granularity to be removed. These are prescribing implementations and undue
burden on NVEs that are not needed to secure communication between NVEs.
<mglt>
My understanding is that a communication is characterized by flows.
There is a need to define what is being encrypted and this si
characterized by a flow.
I believe the concern is about reducing the granularity of the flows. I
believe more discussion is needed to define the right set of
granularity.
</mglt>
o SEC-GEN-13: 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.
23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist
for multicasting tenant traffic. For example, implementations my use
multiple unicast tunnels to achieve this objective. So mandating MUST
requirement for specific multicast mechanism is not necessary. An operator
may decide based on their environment as to what multicast mechanism is
applicable to the deployment. Hence MUST requirement should be removed.
<mglt>
As I understand the comments exposes how to replace multicast
communications with unicast. If such deployment is achieved, SEC_GEN-13
is not applicable as SEC-GEN-13 is for multicast communications. I guess
this addresses the concern.
</mglt>
24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2
as we should not get into implementation details when discussing
requirements.
<mglt>
I believe they are good illustration of how the current security
* it answers most of the question what if I use IPsec, TLS. It helps
* reading the security requirements from an operational point of view as
well as from a design point of view.
I suppose that both of these items have raised issues, so illustrative
example should be welcome.
I suggest to place these section into an appendix, which I guess address
the concern.
</mglt>
/End of Comments/
Thanks,
Ilango
Sent: Friday, October 12, 2018 2:22 PM
Subject: [nvo3] Fwd: [Curdle] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
Hi,
Please find below an update of the security requirements. I believe the
document reflects the feed backs and comments we received during the
meetings as well the clarification of the transit device.
Any feed back is appreciated!
Yours,
Daniel
-----Original Message-----
Sent: Friday, October 12, 2018 5:14 PM
Subject: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.
Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).
The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
The IETF Secretariat
_______________________________________________
Curdle mailing list
https://www.ietf.org/mailman/listinfo/curdle
Hello Authors,
Thanks for the revised draft. I reviewed the security requirements
document, and here is a list of comments. To summarize, this version has
not addressed many of the concerns raised in the previous version of the
draft. This version still makes certain assumptions on the functionality of
transit devices that is not consistent with the Geneve architecture. One of
the key concerns is the requirements 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. Please see below for detailed comments. Also, I would
like to thank T. Sridhar for his thorough review and contributions.
*List of comments on draft-mglt-nvo3-geneve-security-requirements-04:*
1. Section 2: The second paragraph assumes overlay cloud service
provider may be different from Cloud service provider. While this may be a
possibility, most common use cases should be outlined in this paragraph and
in the list of scenarios in the last paragraph of this section. For example
data center operator or cloud service provider hosts tenant systems and
provides virtual network as a service. The underlay infrastructure
including servers and data center network are managed by the same service
provider. The last paragraph of this section should identify which provider
manages the NVE and orchestrates tenant systems.
2. Section 2: Not all data centers environments have all the
risks/threats highlighted in this document. In certain data center
environments operated by a cloud provider or a private enterprise, where
certain risks highlighted in this document may not be applicable. Hence one
or more of the requirements identified in this document may not be
applicable to those use cases and the data center operator may do a risk
assessment and choose to deploy solutions with subset of requirements that
are relevant for their application(s). So the document should make this
clear upfront in section 2. So provide examples outlining the type of risk
and illustrate which requirement is applicable to such scenario.
On the other hand, the
definition of a security mechanisms that enables to secure any
Geneve deployment requires the design of a Geneve specific
mechanism.
3. Section 2: Paragraph beginning with SEC-OP: We need a single
set of requirements with MUST/SHOULD/MAY and not separate requirements into
what is needed to “evaluate a given deployment”. I do not agree with the
statement “On the other hand 
 to secure any Geneve deployment” – it
assumes that there should be a Geneve specific security mechanism, which is
not the case with other tunneling schemes – where they work with other
parts of the stack to realize security.
SEC-GEN: requirements a security mechanism need to fulfill to
secure any deployment of Geneve overlay deployment. Such
mechanism may require the design of a specific solution.
4. Section 2: Paragraph beginning with SEC-GEN: We should remove
references to new protocols or design of a specific solution. There is no
rationale for a new protocol design while existing mechanisms would
suffice.
5. Section 4: Suggest to make this document self-contained, we
don’t know the status of the other document. Just we can state that
“securing control plane is not in scope of this document”..
6. Section 4.1 - paragraph beginning with “Avoiding” – this is a
very generic statement and imposes a requirement that is not needed
(“..typically making leaked data unusable..”). Also please identify which
is the rogue element described in this paragraph. For example, is this an
NVE or a forwarding element in the underlay?
7. Section 4.2 – “Rogue element on path of TS traffic” Identify
with respect to Figure 1 where is the rogue element is located. For example
in server system where a TS is directly connected to an NVE this may not be
applicable, and hence are the requirements associated with this case. Also
as per section 5, the Network connecting TSes and NVEs are out of scope and
also an attacker controlling the underlying network device is out of scope.
Selectively providing integrity / authentication, confidentiality /
encryption of only portions of the Geneve packet is in scope. This
will be the case if the Tenant Systems uses security protocol to
protect its communications.
8. Section 5. Selectively protecting portions of the Geneve packet,
because tenant is already protecting the packet is more of an optimization
and not an essential requirement as the security can be provide by
protecting the entire Geneve packet for example using IPsec. Also an NVE
may service multiple tenant systems and may have a policy to protect all
packets from tenant systems irrespective of whether a tenant systems uses
other mechanism at the payload level.
A secure deployment of a Geneve overlay must fulfill the requirement
9. Section 5.1 “A secure deployment of Geneve must fulfill the
requirements below”. Not all scenarios need to meet all of these
requirements. Leading each paragraph with a blanket statement like this may
imply, if some of these requirements are not used or enabled (by the
operator based on their risk evaluation) then it is not a secure
deployment. This is not accurate, specifically state the conditions of the
risk and when such a requirement is applicable for risk mitigation, instead
of using blanket statement for each requirement.
10. Section 5.1 - First paragraph: Scenarios described in this first
paragraph were, for example a “passive network observer manipulating two
VMs on the same host” or “controlling network activity of other VMs on the
same host” are not specific to Geneve, so should be out of scope. So remove
these scenarios or state that these are out of scope.
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.
o SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
to partially encrypt the inner payload header.
11. Section 5.1- SEC-OP-1: This is a heavy “default” requirement that
all traffic should be encrypted. An operator may evaluate the risk and may
enable encryption to mitigate such risk, remove “default” requirement.
Partial encryption (SEC-GEN-2 below) 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 TSs. 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 is more of
an optimization that should not be mandated and should not be a
requirement.
12. Section 5.1-SEC-GEN-1. Not all scenarios will need to meet this
requirement. So need to clearly state under the conditions under which this
MUST requirement is applicable. For example an operator may do risk
assessment and based on the analysis needed may enable this to mitigate the
risk. Mandating Geneve security mechanism must fulfill the following
requirements is not applicable to all scenarios.
13. Section 5.1 - paragraph beginning with “The Geneve Header and
Geneve Options”: Making a distinction about options that need to be read by
transit devices and “other” options may only be accessed by the tunnel end
point is not a valid description. Options are only intended for endpoints –
transit devices MAY interpret them.
o SEC-OP-2: A secure deployment of a Geneve overlay MUST evaluate
the information associated to the leakage of the Geneve Outer
Header, Geneve Header and Geneve Option. When those information
are likely to carry sensitive information. they MUST NOT be
transmit in clear text.
14. Section 5.1 – SEC-OP2: This requirement of “
likely to carry
sensitive information..” is high level. We already say that it is possible
to configure whether the network virtualization layer should also encrypt
in addition to the TS level encryption, that should address such a risk.
Hence this requirement is not necessary.
o 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.
15. Section 5.1 SEC-OP3: “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 requirement. 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 such as IPsec to encrypt the
communication between NVEs
o SEC-GEN-3: Geneve security mechanism MUST provide the capability
to encrypt a single or a set of options while leave other Geneve
Option in clear. Reversely, a Geneve security mechanism MUST be
able to leave a Geneve option in clear, while encrypting the
others.
o SEC-GEN-4: Geneve security mechanism MUST provide means to encrypt
the information of Geneve Header. Reversely, a Geneve security
mechanism MUST be able to leave in clear header information while
encrypting the other.
o SEC-GEN-5: Geneve security mechanism MUST provide the ability to
pad a Geneve packet.
o SEC-GEN-6: Geneve security mechanism MUST provide the ability to
send dummy packets.
16. Section 5.1 SEC-GEN-3,4 and SEC-GEN-5,6: All these SEC-GEN
requirements (for partial encryption) are optimizations which should not be
part of requirements especially with “MUST” mandates. Also see previous
comment for SEC-GEN-5, 6. 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 threat especially when other existing
mechanisms are available to protect communications between NVEs. So adding
requirements for partial headers/payload could not be considered as a
security requirement to address a security threat, hence these requirements
should not be included.
The Geneve architecture
considers transit devices that MAY process some Geneve Option without
affecting the Geneve packet. These transit device MAY Authenticate
the Geneve packet as part of the Geneve packet processing but MAY
also process other Geneve options. As a result, integrity protection
and authentication SHOULD be performed by transit device, prior to
any processing.
17. Section 5.2 “Transit devices may process Geneve Options” Geneve
headers (including options) are generated and terminated by NVEs. So if NVE
to NVE communication is secured end to end (e.g. IPsec), then the options
are not visible to transit devices. This is no different than ECMP routers
not having access to inner header information when traffic is encrypted. So
the intent is not for creating authentication or encryption of partial
header (option) information with transit devices along the path. So remove
this paragraph or state that transit devices don’t have access to the bits
or if the tunnel transport communication is secured.
o SEC-OP-4: 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. To prevent injection between
virtualized network, it is strongly RECOMMENDED that at least the
Geneve Header is authenticated.
18. Section 5.2 SEC-OP4. Just the first statement “A secure deployment
of a Geneve overlay SHOULD authenticate communications between NVE
” is
good enough to fulfill the security objective. The other statements are
optimizations and not needed to satisfy security objective, hence the
following sentences can removed, “A Geneve overlay provider MAY disable..”
and “This is not “NOT RECOMMENDED”.
o SEC-GEN-8: Geneve Security mechanism MUST provide means for a
tunnel endpoint (NVE) to authenticate data prior it is being
processed. A tunnel endpoint (NVE) MUST be able to authenticate
* the Geneve Header and a subset of Geneve Options
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload
* the Geneve Header, a subset of Geneve options and the Geneve
inner payload or the portion of the inner payload in case the
Tenant's System provides some authentication mechanism.
o SEC-GEN-9: Geneve Security mechanism SHOULD provide means for a
transit device to authenticate the Geneve Option prior processing
it. Authentication MAY concern the whole Geneve packet, but MAY
be limited to the Geneve Option.
19. Section 5.2 SEC-GEN-8 and SEC-GEN-9 – these are only optimizations
and should not be specified as requirements. Authentication of end points
is the only requirement that we should look at, which is already captured
in first statement of SEC-OP4. Partial authentication of headers etc., is
an optimization and not essential to secure the communication between NVEs.
Also SEC-GEN-9 specification of transit node behavior is not needed, and
hence to be removed (also see comment 17).
More
specifically, a rogue source NVE will still be able to redirect the
traffic in clear text before protecting ( and encrypting the packet).
A rogue destination NVE will still be able to redirect the traffic in
clear text after decrypting the Geneve packets. The same occurs with
a rogue transit that is in charge of encrypting and decrypting a
Geneve Option, Geneve Option or any information.
20. Section 5.3 First paragraph: In general securing nodes, NVEs and
transit devices should be beyond the scope of securing Geneve transport.
Securing such devices is not specific to Geneve. So the operator should
use other best practices for securing those devices and establish trust
between those devices and NVAs.
o SEC-OP-6: A secure deployment of a Geneve overlay MUST evaluate
the flows subject to replay attacks. Flows 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 both authenticated
with anti replay protection.
21. Section 5.4 – Reproducing earlier comment from the list on previous
version of this draft: “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. “ Hence remove SEC-OP-6.
o SEC-OP-7: A secure deployment of a Geneve overlay MUST define the
security policies that associates the encryption, and
authentication associated to each flow between NVEs.
o SEC-OP-8: 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.
o SEC-GEN-11: 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).
22. Section 5.5 – Same comment as above applies to this section
SEC-OP-7, 8 and SEC-GEN-11. So the requirements needing flow level
granularity to be removed. These are prescribing implementations and undue
burden on NVEs that are not needed to secure communication between NVEs.
o SEC-GEN-13: 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.
23. Section 5.5. SEC-GEN-13. There are different mechanisms that exist
for multicasting tenant traffic. For example, implementations my use
multiple unicast tunnels to achieve this objective. So mandating MUST
requirement for specific multicast mechanism is not necessary. An operator
may decide based on their environment as to what multicast mechanism is
applicable to the deployment. Hence MUST requirement should be removed.
24. Sections 7.1 and 7.2: Please consider removing sections 7.1 and 7.2
as we should not get into implementation details when discussing
requirements.
/End of Comments/
Thanks,
Ilango
*Sent:* Friday, October 12, 2018 2:22 PM
*Subject:* [nvo3] Fwd: [Curdle] FW: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
Hi,
Please find below an update of the security requirements. I believe the
document reflects the feed backs and comments we received during the
meetings as well the clarification of the transit device.
Any feed back is appreciated!
Yours,
Daniel
-----Original Message-----
Sent: Friday, October 12, 2018 5:14 PM
Subject: New Version Notification for
draft-mglt-nvo3-geneve-security-requirements-04.txt
A new version of I-D, draft-mglt-nvo3-geneve-security-requirements-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.
Name: draft-mglt-nvo3-geneve-security-requirements
Revision: 04
Title: Geneve Security Requirements
Document date: 2018-10-12
Group: Individual Submission
Pages: 17
https://www.ietf.org/internet-drafts/draft-mglt-nvo3-geneve-security-requirements-04.txt
https://datatracker.ietf.org/doc/draft-mglt-nvo3-geneve-security-requirements/
https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-04
https://datatracker.ietf.org/doc/html/draft-mglt-nvo3-geneve-security-requirements
https://www.ietf.org/rfcdiff?url2=draft-mglt-nvo3-geneve-security-requirements-04
The document defines the security requirements to protect tenants
overlay traffic against security threats from the NVO3 network
components that are interconnected with tunnels implemented using
Generic Network Virtualization Encapsulation (Geneve).
The document provides two sets of security requirements: 1.
requirements to evaluate the data plane security of a given
deployment of Geneve overlay. Such requirements are intended to
Geneve overlay provider to evaluate a given deployment.
2. requirement a security mechanism need to fulfill to secure any
deployment of Geneve overlay deployment
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
The IETF Secretariat
_______________________________________________
Curdle mailing list
https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
nvo3 mailing list
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
https://www.ietf.org/mailman/listinfo/nvo3