Hello Chairs, Authors, and WG, I have the following comments on draft-mglt-nvo3-geneve-security-requirements that needs to satisfied before the WG adoption:
1. Section 2: Not all data centers environments have all the risks/threats highlighted in this document. The text in this section could be interpreted that all of the requirements in this document needs to be met, whereas in practice only some of the requirements (not all of these requirements) may be applicable to a certain deployment(s). So some of the requirements would not be applicable in such scenarios. So rephrase the paragraphs in section 2 (and in section 4) that captures the intent that not all requirements are applicable in to all deployments, you could state something along the lines of the following: In certain data center environments operated by a cloud provider or a private enterprise or data centers where certain risks/threats 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 choose to deploy solutions that are only relevant for their application(s). 2. GEN-REQ1. As a policy, a tenant may decide to encrypt the packets irrespective of the privacy mechanisms offered by the service provider. So in this scenario the Tenant system administrator will enforce the policy for data privacy in the tenant systems/network, if needed. So it is not the NVE responsibility in all cases to enforce privacy. Only if the overlay provider is offering data privacy as a service then the NVE would provide that as a service. So GEN-REQ1 NVE requirement should be changed to “MAY”. This is consistent with the “MAY” in confidentiality REQ 11 (and REQ16) in the draft-ietf-nvo3-security-requirements document. In fact this is not unique to Geneve encap and could apply to even other encapsulations. So consider keeping this consistent with nvo3 security requirements document. 3. GEN-REQ2: This could simply be stated as, “If best protection from traffic analysis is needed, the NVE MAY encrypt the entire Geneve payload that includes the inner headers and payload”. Geneve supports multi-protocol payloads, so this is not just specific to IP, and applies to other protocols as well. The objective of this requirement is data privacy/confidentiality between NVEs for the entire Geneve payload carried over Geneve. Generally, the service provider may provide this assurance to tenants as part of their overlay service, if required by the tenant. This requirement is consistent with the confidentiality requirement “MAY” in draft-ietf-nvo3-security-requirements document and should cover all protocols including IP. 4. Section 5.2. This section introduces a Geneve Transit Node (GTN) that performs authentication on behalf of an NVE, and defines the requirements for this model. This is not part of the NVO3 architecture. Architecturally one could consider such GTN as part of the NVE. In general, this section builds a case for authentication on partial headers or selected fields by prescribing a certain architecture and introducing new components/functions (in sections 5.2 and 5.3). Though this could be considered an optimization, however, it is not otherwise required to address a potential security threat(s). Hence requirements related this model and therefore partial authentication of partial header(s) for NVE or GTN would not be considered as a security requirement. This just adds undue requirements to NVE and GTNs, which otherwise is not needed to address any threat. GEN-REQ 4-7 and GEN-REQ 9 fall in this category and hence can be removed. The section mentions that these are consistent with draft-ietf-nvo3-security-requirements draft, however that document does not call for partial header(s)/field(s)/partial payload handling or a transit node performing authentication/encryption on behalf of an NVE. * The requirement for authentication should be to ensure the packet originated from the right source NVE and it reached the right destination NVE. I think, this is the actual requirement that needs to be captured. GEN-REQ8. 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 consider removing flow level granularity requirement in GEN-REQ8. 5. Section 5.3: The main objective of requirements in this section is for protecting the traffic between the NVEs (privacy/confidentiality). Applying partial encryption because the tenant payload is already encrypted is not a security requirement for a threat, this can be considered more of an optimization. A tenant requesting a service provider to offer data confidentiality as a service would expect the NVE to NVE links to be protected irrespective of whether the tenant chooses to use encryption of its data at the application level or otherwise. So adding requirements for partial headers/payload could not be considered as a security requirement to address a security threat, hence consider removing this requirement(s). GEN-REQ10-12 fall under this category. * Hence in this section, the requirement for confidentiality/privacy between the NVEs need be captured. And in addition GEN-REQ13 is applicable that describes using different cryptographic keys to protect tunnels between NVEs. These two are consistent with REQ11 and REQ12 in draft-ietf-nvo3-security-requirements document. 6. GEN-REQ14. Multicast-packets: This requirement is already captured in draft-ietf-nvo3-security-requirement document and also not unique to Geneve encapsulation. So this requirement could be removed as it is already covered. In most cases multicast is not supported in underlay networks and multiple unicast tunnels are used for supporting multicast at overlay level. Even if such a capability is desired for some use cases, this is addressed in REQ 13 of draft-ietf-nvo3-security-requirements document. 7. Section 5.4: Anti-Replay: GEN-REQ15. Consider changing this requirement to “SHOULD” to be consistent with REQ10 in draft-ietf-nvo3 security requirements document. Also GTN is included in this requirement, and GTN may not always be responsible for this validation. So “SHOULD” is more appropriate for this requirement. 8. GEN-REQ12: This requirement prescribes that a transit underlay intermediate node must be able to insert an encrypted Geneve Option in an encrypted/authenticated Geneve packet. Architecturally it makes it more appropriate to make such an intermediate node (that deals with encrypted Geneve packets) an NVE (even if it does not process the payload). This simplifies and keeps it consistent with the existing architecture and existing protocols could be used. Thanks for your consideration. Regards, Ilango From: nvo3 [mailto:[email protected]] On Behalf Of Bocci, Matthew (Nokia - GB) Sent: Tuesday, February 27, 2018 1:04 AM To: NVO3 <[email protected]> Cc: [email protected]; [email protected] Subject: [nvo3] Poll for WG adoption of draft-mglt-nvo3-geneve-security-requirements-03 This email begins a two-week poll for adoption of draft-mglt-nvo3-geneve-security-requirements-03 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. Simultaneously, we are also poling for any IPR that may apply to the draft. Authors and contributors, are you aware of any IPR that applies to this draft? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor, please respond to this email stating of whether or not you are aware of any relevant IPR. The response needs to be sent to the NVO3 WG mailing list. The document will not advance to the next stage until a response has been received from each author and each contributor. This poll closes on Wednesday 14th March 2018. Regards Matthew and Sam
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
