Hello Roman, Thanks for your review and suggestions. Please see below for our responses inline, with revised text based on your suggestions. We will be incorporating this in draft-15 and will be posting it shortly.
Thanks, Ilango From: Roman Danyliw <[email protected]> Sent: Wednesday, February 26, 2020 10:15 AM To: Ganga, Ilango S <[email protected]>; The IESG <[email protected]> Cc: [email protected]; Matthew Bocci <[email protected]>; [email protected]; [email protected]; Martin Vigoureux <[email protected]> Subject: RE: Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT) Hello Ilango! Your proposed text addresses my DISCUSS points. Thank you for the clarifications. Please note the additional non-blocking editorial feedback inline. Thanks, Roman From: Ganga, Ilango S <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 14, 2020 11:57 PM To: Roman Danyliw <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Matthew Bocci <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Martin Vigoureux <[email protected]<mailto:[email protected]>> Subject: RE: Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT) Hello Roman, Thanks for your review and comments. Please see our responses inline below, enclosed within <Response> </Response>. Let us know if you are satisfied with the resolution. Regards, Ilango Ganga Geneve Editor -----Original Message----- From: Roman Danyliw via Datatracker <[email protected]<mailto:[email protected]>> Sent: Wednesday, December 4, 2019 6:04 PM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Matthew Bocci <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Roman Danyliw's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-nvo3-geneve-14: Discuss ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) The threat model assumed by geneve appears to be expressed in conflicting ways. Section 4.1 notes that RFC8085’s definition of “controlled environment” applies. However, - Section 6 notes “When crossing an untrusted link, such as the public Internet, …” - Section 6.1 notes “Geneve data traffic between tenant systems across such separated networks should be protected from threats when traversing public networks. Any Geneve overlay data leaving the data center network beyond the operator's security domain SHOULD be secured by encryption mechanisms such as IPsec or other VPN mechanisms to protect the communications between the NVEs when they are geographically separated over untrusted network links.” The advice provided in Section 6.x is sound. Nevertheless, it doesn’t appear to describe a “controlled environment”. IG>> <Response> Geographically separated data centers does not mean Geneve directly goes over the general internet, whereas Geneve traffic needs to be carried over other VPN technologies to bridge Geneve traffic across geographically separated data centers. The principles described in Section 4 regarding controlled environment still applies to Section 6.1.1 usage with geographically separated data centers. We will add the following sentence to the end of Section 6.1.1 to clarify this point: “The principles described in Section 4 regarding controlled environments still apply to the geographically separated data center usage outlined in this section. </Response> [Roman] Understood. That seems like a reasonable compromise. This updated text addresses my feedback. As further editorial feedback (non-blocking), the text in Section 4.1 could also be refined to reiterate this point. Per “[RFC8085] outlines two applicability scenarios for UDP applications, 1) general Internet and 2) controlled environment.”, it’s helpful to cite [RFC8085], but only scenario (2) applies so referencing (1) didn’t make sense to me. Clearer to me would have been: OLD [RFC8085] outlines two applicability scenarios for UDP applications, 1) general Internet and 2) controlled environment. PROPOSED (approximately) Geneve is intended for a controlled environment applicability scenario as described in [RFC8085]. IG>> <Response> We removed the first sentence as you have suggested but there was already text similar to your proposed text in the next paragraph, so we combined those two paragraphs to address your comment as follows: OLD (text in Section 4.1): [RFC8085] outlines two applicability scenarios for UDP applications, 1) general Internet and 2) controlled environment. The controlled environment means a single administrative domain or adjacent set of cooperating domains. A network in a controlled environment can be managed to operate under certain conditions whereas in general Internet this cannot be done. Hence requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements of general internet. Geneve is intended to be deployed in a data center network environment operated by a single operator or adjacent set of cooperating network operators that fits with the definition of controlled environments in [RFC8085<https://tools.ietf.org/html/rfc8085>]. NEW: Geneve is intended to be deployed in a data center network environment operated by a single operator or adjacent set of cooperating network operators that fits with the definition of controlled environments in [RFC8085]. A network in a controlled environment can be managed to operate under certain conditions whereas in the general Internet this cannot be done. Hence requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements of the general Internet. </Response> (2) Section 6. Per “Compromised tunnel endpoints may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants”, couldn’t compromised transit devices do the same? IG>> <Response> We will update the sentence as follows: “Compromised tunnel endpoints or transit devices may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants” </Response> [Roman] Thank you. This updated text addresses my feedback. (3) Section 6.1. Similar to what is discussed in Section 6.2 (for integrity), please refer to the impact of a compromised node on confidentiality. For example (not verbatim) “A compromised network node or a transit device within a data center may passively monitor Geneve packet data between NVEs; or route traffic for further inspection.” IG>> <Response> Agreed. As suggested, we will add the following sentence before the last sentence of the first paragraph of section 6.1 as follows: “A compromised network node or a transit device within a data center may passively monitor Geneve packet data between NVEs; or route traffic for further inspection.” A tenant may expect the overlay service provider…. </Response> [Roman] Thank you. This updated text addresses my feedback. (4) Section 6.1. Per “Due to the nature of multi-tenancy in such environments, a tenant system may expect data confidentiality to ensure its packet data is not tampered with (active attack) in transit or a target of unauthorized monitoring (passive attack).”, please provide additional precision on the confidentiality. It is only relative to other tenants, but not from the provider (who can engage in tampering and passive monitoring). IG>> <Response> We will update the sentence as follows to provide clarity: “Due to the nature of multi-tenancy in such environments, a tenant system may expect data confidentiality to ensure its packet data is not tampered with (active attack) in transit or a target of unauthorized monitoring (passive attack) for example by other tenant systems or underlay service provider.” </Response> [Roman] Thank you. This updated text addresses my feedback. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben Kaduk’s DISCUSS position. To reiterate part of his write-up, the role of the transit device which is only permitted to inspect the geneve traffic isn’t clear, especially if end-to-end security is applied. RFC7365 didn’t provide insight into this architectural element. IG>> <Response> Please see our response to Benjamin’s comments on transit devices (link below): https://mailarchive.ietf.org/arch/msg/nvo3/G37hH5brjYzYPQLHAfUr54_-Fwg </Response> <End of Responses>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
