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:[email protected]] On Behalf Of Daniel Migault
Sent: Friday, October 12, 2018 2:22 PM
To: [email protected]
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: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Friday, October 12, 2018 5:14 PM
To: Sami Boutros <[email protected]<mailto:[email protected]>>; Dan Wings
<[email protected]<mailto:[email protected]>>; Dan Wing
<[email protected]<mailto:[email protected]>>; Daniel Migault
<[email protected]<mailto:[email protected]>>; Suresh
Krishnan <[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/curdle
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
