Hi Anoop, There is already text in Section 6.4 of Geneve draft that captures this information. Thanks, Ilango
>>I think that captures the essence of what I was suggesting. >>Thanks, >>Anoop >>Transit devices may not be capable to process Geneve option content if the >>Geneve header is secured. From: Anoop Ghanwani [mailto:[email protected]] Sent: Tuesday, July 30, 2019 1:13 PM To: Greg Mirsky <[email protected]> Cc: Daniel Migault <[email protected]>; Ganga, Ilango S <[email protected]>; Kathleen Moriarty <[email protected]>; [email protected] Subject: Re: [nvo3] Review of draft-ietf-nvo3-geneve-13 Hi Greg, I think that captures the essence of what I was suggesting. Thanks, Anoop On Tue, Jul 30, 2019 at 10:36 AM Greg Mirsky <[email protected]<mailto:[email protected]>> wrote: Hi Anoop, thank you for pointing to iOAM as the use case of Geneve options. As I understand, the iOAM for Geneve document offers several options, including one that takes advantage of Geneve options. But such use of options must not, in my opinion, weaken the security in Geneve. We can emphasize that with the text you've proposed and minor, in my opinion, re-wording: Transit devices may not be capable to process Geneve option content if the Geneve header is secured. Regards, Greg On Tue, Jul 30, 2019 at 12:20 PM Anoop Ghanwani <[email protected]<mailto:[email protected]>> wrote: Hi Daniel, Perhaps what is causing confusion is that there's a difference between NVO3 OAM and I-OAM (the reference provided below). From my understanding, NVO3 OAM will involve only NVEs processing those packets, while depending on other OAM methods for the underlay. On the other hand, with I-OAM the idea is to gather information about all devices along the path. There are several different encapsulation drafts (e.g. IOAM using Geneve, IOAM using VXLAN GPE, IOAM using NSH, etc.), so this is not NVO3-specific. Perhaps what the Geneve document needs to note is that the Geneve header cannot be secured if there are devices other than NVEs that are required to process its contents. Unless there is some non-obvious way of doing it and, if it exists, it would be helpful if a reference is provided. Thanks, Anoop On Tue, Jul 30, 2019 at 6:49 AM Daniel Migault <[email protected]<mailto:[email protected]>> wrote: Hi, OAM has been raised during the meeting, so thank you for providing the appropriated references of OAM. My understanding is that OAM is a Geneve option that is updated by the OAM devices that are on path. Is that correct ? IPsec or DTLS authenticate or encrypt the full Geneve packet ( Geneve Header, Geneve Options and Geneve payload) between the NVEs. If my assumption regarding the OAM devices is correct, the use of DTLS or IPsec would not make possible to authenticate or encrypt and Geneve packet with OAM enabled. Again if my assumption is correct, I believe that an appropriated way to address this concern might be to be able to leave some Geneve Option non authenticated. while other parts of the packet is authenticated or encrypted. Such mechanism needs to be implemented at the Geneve layer. Yours, Daniel On Fri, Jul 26, 2019 at 2:52 PM Anoop Ghanwani <[email protected]<mailto:[email protected]>> wrote: Hi Ilango, What would be the recommended way to secure the Geneve header in cases where Geneve header extensions are used and routers in the underlay need to access/process the contents of the Geneve header? For example, this proposal: https://tools.ietf.org/html/draft-brockners-ippm-ioam-geneve-02 Thanks, Anoop On Thu, Jul 25, 2019 at 2:18 PM Ganga, Ilango S <[email protected]<mailto:[email protected]>> wrote: Hello Kathleen, Thanks for your review of draft-ietf-nvo3-geneve-13. We could provide additional clarification in section 4.3 to address your comment. Please let us know if this satisfies your comment. Current text in Section 4.3, first paragraph: In order to provide integrity of Geneve headers, options and payload, for example to avoid mis-delivery of payload to different tenant systems in case of data corruption, outer UDP checksum SHOULD be used with Geneve when transported over IPv4. An operator MAY choose to disable UDP checksum and use zero checksum if Geneve packet integrity is provided by other data integrity mechanisms such as IPsec or additional checksums or if one of the conditions in Section 4.3.1<https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a, b, c are met. Proposed text to 4.3 that we believe would address your comments: In order to provide integrity of Geneve headers, options and payload, for example to avoid mis-delivery of payload to different tenant systems in case of data corruption, outer UDP checksum SHOULD be used with Geneve when transported over IPv4. "The UDP checksum provides a statistical guarantee that a payload was not corrupted in transit. These integrity checks are not strong from a coding or cryptographic perspective and are not designed to detect physical-layer errors or malicious modification of the datagram (see RFC 8085 section 3.4). In deployments where such a risk exists, an operator SHOULD use additional data integrity mechanisms such as offered by IPSec (see Section 6.2)." An operator MAY choose to disable UDP checksum and use zero checksum if Geneve packet integrity is provided by other data integrity mechanisms such as IPsec or additional checksums or if one of the conditions in Section 4.3.1<https://tools.ietf.org/html/draft-ietf-nvo3-geneve-13#section-4.3.1> a, b, c are met. Thanks, Ilango From: nvo3 [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kathleen Moriarty Sent: Tuesday, July 2, 2019 12:43 PM To: [email protected]<mailto:[email protected]> Subject: [nvo3] Review of draft-ietf-nvo3-geneve-13 Hello, I just read through draft-ietf-nvo3-geneve, sorry I am out-of-cycle in the review process, but it looks like it has not started IETF last call yet. I have what's really just a nit and request for a little more text. Section 4.3.1 The value of the UDP checksum is overstated. The text should note that corruption is still possible as this is a checksum and not a hash with low collision rates. Corruption happens and goes undetected in normal operations today. The security considerations section does address the recommendation to use IPsec, but making the connection on the UDP checksum being inadequate could be helpful. Reality: The way this is written, I suspect there really are no plans to use IPsec with GENEVE, are there? The MUST statements around not altering traffic can only be achieved with IPsec, so if the intent is really to enforce the early MUST statements in the document, sooner mention of IPsec would be good. If this is more for detecting corruption (and not having that be 100% or close) that should be clear up front. I'm just envisioning use cases where the virtual path is set differently to the physical path for expected operations to route through desired security functions, then an attacker alters checksums to avoid detection of these changes. Thanks and sorry for a late review! -- Best regards, Kathleen _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
