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

From: Daniel Migault <[email-masked]>
Date: Tue, 26 Feb 2019 15:01:56 -0500

Hi Illango,

If there are any remaining concerns, it would help you indicate the
remaining concern for each open issue. I suggest to use the github [1] to
structure the discussion,

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

On Thu, Nov 8, 2018 at 1:50 AM Daniel Migault <[email-masked]>
wrote:

> 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
>
> On Tue, Nov 6, 2018 at 9:04 PM Ganga, Ilango S <[email-masked]>
> wrote:
>
>> 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:[email-masked]]
>> *Sent:* Saturday, November 3, 2018 12:11 AM
>> *To:* Ganga, Ilango S <[email-masked]>
>> *Cc:* [email-masked]
>> *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 <[email-masked]>
>> Sent: Thursday, October 25, 2018 10:13 PM
>> To: Daniel Migault <[email-masked]>; [email-masked]
>> 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:[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] <[email-masked]>
>> Sent: Friday, October 12, 2018 5:14 PM
>> To: Sami Boutros <[email-masked]>; Dan Wings <[email-masked]>; Dan
>> Wing <[email-masked]>; Daniel Migault <[email-masked]>;
>> Suresh Krishnan <[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.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Curdle mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>>
>>
>> On Thu, Oct 25, 2018 at 10:12 PM Ganga, Ilango S <
>> [email-masked]> 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:[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] <[email-masked]>
>> Sent: Friday, October 12, 2018 5:14 PM
>> To: Sami Boutros <[email-masked]>; Dan Wings <[email-masked]>; Dan
>> Wing <[email-masked]>; Daniel Migault <[email-masked]>;
>> Suresh Krishnan <[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.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Curdle mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/curdle
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>