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

[Kathleen Moriarty <[e-mail]>]

Thank you, Ilango, inline.

On Thu, Jul 25, 2019 at 5:18 PM Ganga, Ilango S <[e-mail]>
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.
>
> I think the additional text is helpful to have the full security
considerations understood.  I appreciate you adding it in the draft.

I'll respond to other messages in the thread and apologize for my delay.

Best regards,
Kathleen

>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* nvo3 [mailto:[e-mail]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, July 2, 2019 12:43 PM
> *To:* [e-mail]
> *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
>


-- 

Best regards,
Kathleen