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

From: "Ganga, Ilango S" <[email-masked]>
Date: Fri, 26 Oct 2018 02:12:34 +0000

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