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. 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 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. 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. 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. 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. 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. 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. 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. 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”? 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? 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. 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. 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. 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. 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. Thanks, Ilango From: nvo3 [mailto:[email protected]] On Behalf Of Bocci, Matthew (Nokia - GB) Sent: Wednesday, April 10, 2019 7:38 AM To: NVO3 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/nvo3
