Re: [nvo3] Review of draft-ietf-nvo3-geneve-13

Thanks Ilango.  Sorry I missed it.

Anoop

On Wed, Jul 31, 2019 at 10:04 PM Ganga, Ilango S <ilango.s.ganga@intel.com>
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:anoop@alumni.duke.edu]
> *Sent:* Tuesday, July 30, 2019 1:13 PM
> *To:* Greg Mirsky <gregimirsky@gmail.com>
> *Cc:* Daniel Migault <daniel.migault@ericsson.com>; Ganga, Ilango S <
> ilango.s.ganga@intel.com>; Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com>; nvo3@ietf.org
> *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 <gregimirsky@gmail.com>
> 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 <anoop@alumni.duke.edu>
> 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 <
> daniel.migault@ericsson.com> 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 <anoop@alumni.duke.edu
> <anoop@alumni.duke..edu>> 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 <ilango.s.ganga@intel.com>
> 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:nvo3-bounces@ietf.org] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, July 2, 2019 12:43 PM
> *To:* nvo3@ietf.org
> *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
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
>