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

[Anoop Ghanwani <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <
>> [e-mail]> 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 <[e-mail]
>>> <[e-mail]..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 <
>>>> [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.
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>> _______________________________________________
>>>>> nvo3 mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>
>>>> _______________________________________________
>>>> nvo3 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>
>>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>