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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 2 Jul 2019 15:42:47 -0400

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 8 Jul 2019 10:55:54 -0400

Hi Kathleen,

My understanding of the document is that IPsec is not used to secure
Geneve. Instead, IPsec is used to secure the infrastructure on top of which
Geneve would be operated, thus lowering down the security of Geneve itself.
As far as I understand, Geneve is incompatible with en-to-end security
(IPsec, DTLS) to protect Geneve NVE-to-NVE communications. The document
defines Transit Devices that intercept on-path packets of an NVE-to-NVE
communications, which is not possible with DTLS or IPsec.

Yours,
Daniel

On Tue, Jul 2, 2019 at 3:43 PM Kathleen Moriarty <
[email-masked]> wrote:

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 8 Jul 2019 12:34:18 -0400

HI Daniel,

I read the document and saw that it was used as a tunnel and the end points
were the ones that had access to the GENEVE information.  With this in
mind, the UDP layer for GENEVE encapsulated in an IP packet could then use
IPsec.  The security recommendations mentions the use of IPsec to fix many
of the stated considerations.

I don't understand your comment that IPsec is used to secure the
infrastructure, what do you mean, can you provide an example?  I think the
security considerations section says it's protecting GENEVE and that GENEVE
is essentially a tunnel - you can use it over the Internet to join VLANs
(this is a pretty obvious use case where IPsec would be used).

Integrity protection on any routing overlay protocol should be a
requirement, especially when the path of traffic can be altered by the
routing overlay protocol from what would normally be used.  The document
says (or I read somewhere) no AH only support, so I am guessing that
vendors have not implemented that interoperably, hence the reason for the
ESP recommendation.

Thanks for any clarification.

Best regards,
Kathleen

On Mon, Jul 8, 2019 at 10:56 AM Daniel Migault <[email-masked]>
wrote:

>> 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 security considerations section does address the recommendation to
>> use IPsec, but making the connection on the UDP checksum being inadequate
>> could be helpful.
>>
>> Reality:
>>

-- 

Best regards,
Kathleen

---

From: Daniel Migault <[email-masked]>
Date: Mon, 8 Jul 2019 14:43:50 -0400

Hi,

I agree that Geneve is essentially a tunnel between NVEs. If NVEs are
considered as end points, the communication can be secured using IPsec or
DTLS from one NVE to the other NVE. However, the document specifies Transit
Devices that can interpret the Geneve packets (section 2.2.1). If the
Geneve communication between NVEs were protected by IPsec or DTLS, the
Transit Devices would not be able to access the Geneve packet as a result,
my understanding is that a Geneve tunnel cannot be secured with transit
device. In other words, securing a Geneve deployment with transit devices
will require to redesign the deployment - without transit devices - if
security should be enabled. I see this as a major issue.

When I mentioned that IPsec was used to secure the infrastructure,  I meant
that IPsec is used between the originating NVE and the transit device as
well as between the transit device and the terminating NVE - as opposed to
IPsec being used between NVEs. In this case, I would not consider IPsec
protecting the end-to-end Geneve tunnel, but instead IPsec would be used to
segments of the communications. The reason I mentioned infrastructure is
that NVEs and the transit devices could be seen as a mesh trusted platform
carrying the Geneve tunnel. I am not saying this is what I would recommend.

Your concern seems to be integrity protection. I have not found any mention
of AH or ESP in the document, so maybe there is a reference I am missing.
On the other hand, integrity protection-only might be the only case
compatible with transit devices as long as they are able to interpret
appropriately the packet. In this case, the transit device should support
AH, ESP, DTLS with authentication only. If that would be the case, a given
deployment including transit device, would be ale to provide integrity
protection by only activating integrity protection only at the NVEs. I am
not aware of transit device implementing this.

Yours,
Daniel

On Mon, Jul 8, 2019 at 12:37 PM Kathleen Moriarty <
[email-masked]> wrote:

> HI Daniel,
>
> I read the document and saw that it was used as a tunnel and the end
> points were the ones that had access to the GENEVE information.  With this
> in mind, the UDP layer for GENEVE encapsulated in an IP packet could then
> use IPsec.  The security recommendations mentions the use of IPsec to fix
> many of the stated considerations.
>
> On Mon, Jul 8, 2019 at 10:56 AM Daniel Migault <
> [email-masked]> wrote:
>
>> Hi Kathleen,
>>
>>> 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.
>>>

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 25 Jul 2019 21:18:36 +0000

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-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, July 2, 2019 12:43 PM
To: [email-masked]
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.

--

Best regards,
Kathleen

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 26 Jul 2019 11:52:15 -0700

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-masked]>
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.
>
>
>
>    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.
>
>
>
>    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-masked]] *On Behalf Of *Kathleen
> Moriarty
> *Sent:* Tuesday, July 2, 2019 12:43 PM
> *To:* [email-masked]
> *Subject:* [nvo3] Review of draft-ietf-nvo3-geneve-13
>
>
>
> Hello,
>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 28 Jul 2019 16:23:03 -0400

A nit:

         | 0x0108..0x110  | Amazon.com, Inc.                     |

"0x110" should be "0x0110".

Dale

---

From: Daniel Migault <[email-masked]>
Date: Tue, 30 Jul 2019 09:49:30 -0400

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jul 2019 10:01:14 -0400

Hi Daniel,
thank you for following on the discussion of using Geneve options for OAM.
There certainly is value in a theoretical discussion of this scenario but
the first question I'd ask Are there any proposals to use Geneve options
for OAM? Please note that such use case is not in the scope of
draft-mmbb-nvo3-geneve-oam-00
<https://tools.ietf.org/html/draft-mmbb-nvo3-geneve-oam-00>.

Regards,
Greg

On Tue, Jul 30, 2019 at 9:50 AM Daniel Migault <[email-masked]>
wrote:

> Geneve Option non authenticated.. while other parts of the packet is
>> On Thu, Jul 25, 2019 at 2:18 PM Ganga, Ilango S <
>> ilango.s.ganga@intel..com <[email-masked]>> wrote:
>>
>>> Hello Kathleen,
>>>
>>>
>>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 30 Jul 2019 09:20:18 -0700

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Jul 2019 13:19:56 -0400

Thank you, Ilango, inline.

On Thu, Jul 25, 2019 at 5:18 PM Ganga, Ilango S <[email-masked]>
wrote:

> 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

-- 

Best regards,
Kathleen

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jul 2019 13:36:10 -0400

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-masked]>
wrote:

> Hi Daniel,
>
> Perhaps what is causing confusion is that there's a difference between
> NVO3 OAM and I-OAM (the reference provided below).
>
> On Tue, Jul 30, 2019 at 6:49 AM Daniel Migault <
>> On Fri, Jul 26, 2019 at 2:52 PM Anoop Ghanwani <[email-masked]
>> <[email-masked]..edu>> wrote:
>>
>>> Hi Ilango,
>>>
>>> [email-masked]> wrote:
>>>
>>>> Hello Kathleen,
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Jul 2019 14:06:39 -0400

Sent from my mobile device

> On Jul 30, 2019, at 1:36 PM, Greg Mirsky <[email-masked]> 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.

I do like this addition.

Thank you,
Kathleen 
> 
> 
> Regards,
> Greg
> 
>> On Tue, Jul 30, 2019 at 12:20 PM Anoop Ghanwani <[email-masked]> 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-masked]> 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-masked]> 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:
>>>>> On Thu, Jul 25, 2019 at 2:18 PM Ganga, Ilango S <[email-masked]> wrote:
>>>>> Hello Kathleen,
>>>>> 
>>>>>  
>>>>> 
>>>>>    additional checksums or if one of the conditions in Section 4.3.1 a,
>>>>>    b, c are met.
>>>>>  
>>>>> 
>>>>>    additional checksums or if one of the conditions in Section 4.3.1 a,
>>>>>    b, c are met.
>>>>>  
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Ilango
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Jul 2019 14:11:57 -0400

> https://tools.ietf.org/html/draft-brockners-ippm-ioam-geneve-02
Could IPsec AH or IPsec NULL encryption (https://tools.ietf.org/html/rfc2410)
be used for that purpose?  NULL encryption leaves the header untouched, so
more can be accessed than with AH.  In either case, integrity protection is
possible without confidentiality.

It would be good to represent the range of options (confidentiality as was
mentioned in another message in this thread and/or integrity and
authentication).

Best regards,
Kathleen

Thanks,

-- 

Best regards,
Kathleen

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 30 Jul 2019 13:12:30 -0700

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-masked]> wrote:

>>>>> 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.
>>>>>

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 1 Aug 2019 05:04:29 +0000

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

From: Anoop Ghanwani [mailto:[email-masked]]
Sent: Tuesday, July 30, 2019 1:13 PM
To: Greg Mirsky <[email-masked]>
Cc: Daniel Migault <[email-masked]>; Ganga, Ilango S <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]
Subject: Re: [nvo3] Review of draft-ietf-nvo3-geneve-13

Hi Greg,

Thanks,
Anoop

On Tue, Jul 30, 2019 at 10:36 AM Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Thanks,
Anoop

On Tue, Jul 30, 2019 at 6:49 AM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours,
Daniel

On Fri, Jul 26, 2019 at 2:52 PM Anoop Ghanwani <[email-masked]<mailto:[email-masked]..edu>> wrote:
Hi Ilango,

Thanks,
Anoop

On Thu, Jul 25, 2019 at 2:18 PM Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> wrote:
Hello Kathleen,

   b, c are met.

   b, c are met.

Thanks,
Ilango

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
Sent: Tuesday, July 2, 2019 12:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] Review of draft-ietf-nvo3-geneve-13

Hello,

Section 4.3.1

Reality:

--

Best regards,
Kathleen
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3