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

[Daniel Migault <[e-mail]>]

Hi,

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

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


>
> SEC-GEN-13: Geneve Security mechanism MUST provide means for a
> transit device to authenticate data prior it is being processed.
>
>
>
> This requirement is not consistent with Geneve architecture, hence remove this requirement.
>
>
>
> <mglt>My reading of your comment is that you are mandating that transit
devices are not expected to be able to authenticate the data they process.
Could you clarify your concern as well you clarify where the inconsistency
is? Text from the geneve architecture would be welcome. My understanding is
that the requirement that transit device authenticate the option they
process has been stated at the mic by David at the mic during the Prague
meeting. As a result, I am very confused by that concern. Of course if that
is inconsistent with the Geneve architecture, such requirement will be
removed. .</mglt>

Yours,
Daniel


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

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


> Hence, I do not support the adoption of the draft in its current form.
>
>
>
> Please see below for list of comments on the current draft:
>
>
>
> General comments related to the draft:
>
> SEC-OP vs SEC-GEN requirements. There was lengthy discussion in NVO3 WG
> meeting on should we have SEC-OP and SEC-GEN requirements, should we
> include SEC-OP, how to get feedback from operators, should this be in a
> single document or multiple separate documents etc., There was no consensus
> on this issue. Hence we still need to revisit this issue.  There was
> supposed to be mailing list discussion on this topic.  However, I did not
> see such discussion.
>
> https://datatracker.ietf.org/meeting/103/materials/minutes-103-nvo3-00
>
>
>
<mglt>If I understand correctly your comment, you would like a discussion
on how to deal with the SEC-GEN, SEC-OP requirements. The question was do
we want to have SEC-OP in that document or in another one. I am happy to do
what the WG wants. Nothing prevents this to be done after adoption. </mglt>


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


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


> Specific comments related to Requirements:
>
>
>
> SEC-OP-1: A secure deployment of a Geneve overlay SHOULD by
> default encrypt the inner payload. A Geneve overlay provider MAY
> disable this capability for example when encryption is performed
> by the Tenant System and that level of confidentiality is believed
> to be sufficient. In order to provide additional protection to
> traffic already encrypted by the Tenant the Geneve network
> operator MAY partially encrypt the clear part of the inner
> payload.
>
>
>
> SEC-GEN-2: Geneve security mechanism SHOULD provide the capability
> to partially encrypt the inner payload header.
>
>
>
> SEC-OP-4: A secure deployment of a Geneve overlay MUST provide the
> capability authenticate the inner payload when encryption is not
> provided. A Geneve overlay provider MAY disable this capability
> for example when this is performed by the Tenant System and that
> level of integrity is believed to be sufficient. In order to
> provide additional protection to traffic already protected by the
> Tenant the Geneve network operator MAY partially protect the
> unprotected part of the inner payload.
>
>
>
>
>
> Partial encryption (SEC-OP-1 and SEC-GEN2) is an optimization (as had been
> indicated in a comment on the previous version of this draft) and should
> not be a requirement.  The traffic between NVE pairs should be secured and
> operator may have a policy to encrypt the traffic irrespective of the any
> security mechanisms employed by the Tenant Systems Also an NVE may handle
> traffic from multiple TSes and hence the service provider may enable
> encryption between NVE pairs. So partial encryption or selective encryption
> should not be a requirement.
>
>
<mglt>Your comment seems to say these requirements prevent a NVE to encrypt
the traffic irrespective to the TSs. This is wrong and SHOULD makes this
requirement non blocking. The appendix provides  also two examples of DTLS
and IPsec that do not have this capability and such requirement does not
block IPsec nor TLS to be used. In addition, the same requirement is in the
nvo3 security requirement. As result, your concern does not seem relevant.
</mglt>

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


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


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

SEC-OP-5: A secure deployment of a Geneve overlay MUST evaluate
> the risk associated to a change of the Geneve Outer Header, Geneve
> Header (excluding Geneve Options) and Geneve Option. When a risk
> analysis concludes that the risk is too high, this piece of
> information MUST be authenticated.
>
>
>
> SEC-OP-6: A secure deployment of a Geneve overlay SHOULD
> authenticate communications between NVE to protect the Geneve
> Overlay infrastructure as well as the Tenants System’s
> communications (Geneve Packet). A Geneve overlay provider MAY
> disable authentication of the inner packet and delegates it to the
> Tenant Systems when communications between Tenant’s System is
> secured. This is NOT RECOMMENDED. Instead, it is RECOMMENDED
> that mechanisms binds the inner payload to the Geneve Header. To
> prevent injection between virtualized network, it is strongly RECOMMENDED that at least the Geneve Header without Geneve Options
> is authenticated.
>
>
>
> What specific risk does the operator see based on the threat model and what piece of information should be authenticated,
>
> why this should be selectively authenticated as called for in these requirements? Can you specify the usage model for these requirements.
>
> <mglt> The threat model and risks are described in section 4.
Authentication of Options or metadata is not something new. The threat
model of protecting the NVI is to prevent packets to be steered in the
wrong network. Unless I am not understanding your comment, I believe it is
irrelevant here. Maybe it could be handled in clarifying the threat model,
but that is not something your seem to have concern with. </mglt>

>
>
> SEC-OP-7: A secure deployment of a Geneve overlay SHOULD NOT
> process data prior authentication. If that is not possible, the
> Geneve overlay provider SHOULD evaluate its impact.
>
>
>
> This is too generic, what should the operator do with this requirement,  “…SHOUD evaluate its impact”?
>
>  <mglt>The operator needs to ensure authentication is performed prior the
data is processed. I do not see how to clarify the purpose.
 This requirement comes from the transit devices, and the purpose is to
avoid option being for example processed by a transit device and
authenticated by the NVE.  </mglt>


>
>
> SEC-GEN-8: Geneve security mechanism MUST provide the capability
> to authenticate the inner payload.
>
> SEC-GEN-9: Geneve security mechanism SHOULD provide the capability
> to partially authenticate the inner payload header.
>
> SEC-GEN-10: Geneve security mechanism MUST provide the capability
> to authenticate a single or a set of options while leave other
> Geneve Option unauthenticated. Reversely, a Geneve security
> mechanism MUST be able to leave a Geneve option unauthenticated,
> while encrypting the others.
>
>
>
> SEC-GEN-11: Geneve security mechanism MUST provide means to
> authenticate the information of Geneve Header (Geneve Option
> excluded). Reversely, a Geneve security mechanism MUST be able to
> leave unauthenticated Geneve header information (Geneve Options
> excluded) while authenticating the other.
>
>
>
> What is the threat model and what is use case that is driving the partial encryption or authentication of options?
>
> <mglt>see section 4 for the threat model.</mglt>

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

SEC-OP-8: A secure deployment of a Geneve overlay MUST evaluate
> the communications subject to replay attacks. Communications that
> are subject to this attacks MUST be authenticated with an anti
> replay mechanism. Note that when partial authentication is
> provided, the part not covered by the authentication remains a
> surface of attack. It is strongly RECOMMENDED that the Geneve
> Header is authenticated with anti replay protection
>
>
>
> What is the threat model and use case that calls for partial authentication. Same comments as partial encryption applies to this comment as well.
>
>
>
> <mglt> same response. please read the threat model section. The concern is
</mglt>

> SEC-OP-9: A secure deployment of a Geneve overlay MUST define the
> security policies that associates the encryption, and
> authentication associated to each flow between NVEs.
>
>
>
> SEC-OP-10: A secure deployment of a Geneve overlay SHOULD define
> distinct material for each flow. The cryptographic depends on the
> nature of the flow (multicast, unicast) as well as on the security
> mechanism enabled to protect the flow.
>
>
>
> SEC-GEN-15: A Geneve security mechanism MUST be managed via
> security policies associated for each traffic flow to be
> protected. Geneve overlay provider MUST be able to configure NVEs
> with different security policies for different flows. A flow MUST
> be identified at minimum by the Geneve virtual network identifier
> and the inner IP and transport headers, and optionally additional
> fields which define a flow (e.g., inner IP DSCP, IPv6 flow id,
> Geneve options)
>
>
>
>
>
> It is not clear as to what threat is being addressed by requiring flow level granularity.  If communication between NVE to NVE need be encrypted/authenticated, then, at a minimum, security policy should be applied for the traffic between, for example, NVE A to NVE B or NVE A to NVE C, etc.
>
>

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

>
>
> SEC-GEN-17: A Geneve security mechanisms, when multicast is used,
> packets,MUST be able to assign distinct cryptographic group keys
> to protect the multicast packets exchanged among the NVEs within
> different multicast groups. Upon receiving a data packet, an
> egress Geneve NVE MUST be able to verify whether the packet is
>
> sent from a proper ingress NVE which is authorized to forward that
> packet.
>
>
>
> Need to define the threat model for multicast, define multicast,  most deployments multicast is implemented using multiple unicast. So the requirement does not apply to such deployments.
>
>
>
> <mglt>My reading of your comment is that as multicast can be replaced by
multiple unicast, the requirement should be removed. The document is
focused on Geneve which may use multicast, not to replace multicast. The
nvo3 security requirement document got similar requirements. I believe your
concern is irrelevant to the document. </mglt>

> 8. Appendix
>
>
>
> I suggest to remove the entire Appendix from the document. Let us first agree on the requirements before we get into mapping different solutions to meet the requirements.
>
> <mglt>I believe that the appendix is illustrating the requirements and as
such is useful to understand the requirements as well as how to read them.
Ithe appendix was completed based on the comments received from the secdir
reviewer of the geneve document.  Of course the requirement needs to be
agreed on. However, I believe that lots of your concerns could have been
avoided if this section has been read, so I strongly believe it is a useful
section. </mglt>

>
>
> Thanks,
>
> Ilango
>
>
>
>
>
>
>
> *From:* nvo3 [mailto:[e-mail]] *On Behalf Of *Bocci, Matthew
> (Nokia - GB)
> *Sent:* Wednesday, April 10, 2019 7:38 AM
> *To:* NVO3 <[e-mail]>
> *Subject:* [nvo3] Poll for adoption of
> draft-mglt-nvo3-geneve-security-requirements-06
>
>
>
> This email begins a second two-week poll for adoption of
> draft-mglt-nvo3-geneve-security-requirements-06 in the NVO3 working group.
>
>
>
> Please review the draft and send any comments to the NVO3 list.
>
>
>
> Please also indicate whether you support adoption of the draft as an NVO3
> working group document.
>
>
>
> Note that supporting working group adoption indicates that you think the
> draft is headed in the right direction and represents a piece of work that
> the working group should take on and progress. It does not have to be
> technically perfect at this stage.
>
>
>
> This poll closes on Wednesday 24th April 2019.
>
>
>
> Regards
>
> Matthew and Sam
>
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>