Thanks Ilango. Sorry I missed it. Anoop
On Wed, Jul 31, 2019 at 10:04 PM Ganga, Ilango S <[email protected]> wrote: > 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]> > 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]> > 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]> 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] > <[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]> > 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]] *On Behalf Of *Kathleen > Moriarty > *Sent:* Tuesday, July 2, 2019 12:43 PM > *To:* [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] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
