Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve

From: "Ganga, Ilango S" <[email-masked]>
Date: Wed, 7 Nov 2018 03:11:54 +0000

Hi Magnus,

Here is our proposed text that we believe will satisfy your comment on 3.5.1:

In Section 2.2.1 add new highlighted text in paragraph that began with “Transit devices..”
Options, if present in the packet, MUST be generated and terminated by end points. Transit devices MAY be able to interpret the options, however, as
   non-terminating devices, transit devices do not originate or
   terminate the Geneve packet, hence MUST NOT insert or delete options,
   which is the responsibility of Geneve endpoints.  The participation
   of transit devices in interpreting options is OPTIONAL.

Section 3.5.1 - Remove the highlighted text:
o  Some options may be defined in such a way that the position in the
      option list is significant.  Options or their ordering, MUST NOT
      be changed by transit devices.

Section 3.5.1 - Add highlighted text to the last bullet:
   o  An option SHOULD NOT be dependent upon any other option in the packet,
 i.e., options can be processed independent of one another. Hence an option MUST NOT affect the parsing or interpretation of any other option.

Remove the following paragraph from 6.2:
Geneve supports Geneve Options, so an operator may choose to use a
   Geneve option TLV to provide a cryptographic data protection
   mechanism, to verify the data integrity of the Geneve header, Geneve
   options or the entire Geneve packet including the payload.
   Implementation of such a mechanism is beyond the scope of this
   document.

Introduce new section after 6.3 as follows:
6.4  Options Interpretation by Transit Devices

Options, if present in the packet, are generated and terminated by end points. As indicated in 2.2.1, transit devices may interpret the options. However, if the packet is protected by end point to end point encryption, for example through IPsec, transit devices will not have visibility into the Geneve header or options in the packet. In cases where options are interpreted by transit devices, the operator MUST ensure that transit devices are trusted and not compromised. Implementation of a mechanism to ensure this trust is beyond the scope of this document.

Please let us know if this addresses your comment on 3.5.1.  The other two comments have been satisfied as noted below.

Thanks,
Ilango

From: Magnus Nyström [mailto:[email-masked]]
Sent: Wednesday, October 31, 2018 11:34 AM
To: Ganga, Ilango S <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Secdir review (early review) of draft-ietf-nvo3-geneve

Hi Ilango,
For 3.4, I think this may be sufficient.

For 6.2, I will defer to the IETF director/telechat discussion that will occur at some point for this draft. If the intent is interoperability and robustness of such an option, then I would recommend it to be specified in the IETF, but I can also see how you would prefer that such specification work occurs outside this particular draft – which should be doable. Perhaps staying silent on the option alternative and just recommend leveraging layer-provided infrastructure such as ipsec may be best for now?

I'll await your suggested updated language for 3.5.1.

Thanks,

Sent from my Windows 10 phone

From: Ganga, Ilango S<mailto:[email-masked]>
Sent: Tuesday, October 30, 2018 18:12
To: Magnus Nyström<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Secdir review (early review) of draft-ietf-nvo3-geneve

Hi Magnus,

Thanks for your review and feedback. Please see inline for my responses.

Regards,
Ilango

From: Magnus Nyström [mailto:[email-masked]]
Sent: Tuesday, October 23, 2018 9:01 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Secdir review (early review) of draft-ietf-nvo3-geneve

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes "Geneve," a protocol for GEneric NEtwork Virtualization Encapsulation. The document is written in a clear manner and with a thorough Security Considerations section. I have just a few questions/comments:

- Section 3.4: The "MUST ignore" for the reserved bits should presumably state "SHALL be ignored for this version of the Geneve protocol." - as I imagine that in a future version, these bits may not be ignored?

<Ilango> In theory, a future version may change the behavior of any of the header fields including the reserved bits.  The header definition is for this version of the protocol.

Please see if the following text would satisfy the intent of your comment.
“Reserved field which MUST be zero on transmission and MUST be ignored on receipt.”

Or let us know if you still want to have this qualified with “for this version of the protocol”
</>

- Section 3.5.1: I wonder about the simultaneous requirement that one option must not affect the parsing or interpretation of another option but that the sequencing (order) of options may be significant - they seem to be contradictory since if the sequencing *is* significant, then some option must be impacted by a previous one's value? From a security perspective, I also wonder if there could be security consequences of re-ordering options (and how to tell if someone did re-order - see below)?

<Ilango> You raise a good point. The intent of this statement is, parsing and interpretation of options should not be dependent on one another. We are discussing among the authors to see how we can include appropriate clarifying statements to address your point. I will update you shortly.
</>

- Section 6.2, shouldn't such an Option be defined to reduce the risk of under-specified or subpar specifications of such integrity mechanisms? Or also from an interop perspective?

<Ilango> Using a Geneve option for the purpose of data integrity is more of an optimization. Otherwise data integrity could be provided by using existing mechanisms like IPsec (as stated in second paragraph of 6.2). We included the last paragraph to show other possibilities. We could remove this paragraph if it may cause any confusion.

We would like to keep the Geneve base specification independent of options specifications, options could be a defined in a future standards action.
</>

Thanks.
-- Magnus

---

From: Magnus Nyström <[email-masked]>
Date: Tue, 6 Nov 2018 23:19:49 -0800

Hi Ilango,
Thanks for your thorough follow-up. To me, the new text looks very good.
You could shorten (and perhaps add clarity) by replacing "Hence an
option..." with just "An option ..."

Thanks,
/M

On Tue, Nov 6, 2018 at 7:11 PM Ganga, Ilango S <[email-masked]>
wrote:

> *In Section 2.2.1 add new highlighted text in paragraph that began with
> “Transit devices..”*
>
> Options, if present in the packet, MUST be generated and terminated by end
> points. Transit devices MAY be able to interpret the options, however, as
>
> *Section 3.5.1 - Remove the highlighted text:*
>
> *Section 3.5.1 - Add highlighted text to the last bullet:*
>
>    o  *An option SHOULD NOT be dependent upon any other option in the
> packet, *
>
> * i.e., options can be processed independent of one another. Hence* an
> option MUST NOT affect the parsing or interpretation of any other option.
>
>
>
> *Remove the following paragraph from 6.2:*
>
> *Introduce new section after 6.3 as follows:*
>
> Options, if present in the packet, are generated and terminated by end
> points. As indicated in 2.2.1, transit devices may interpret the options.
> However, if the packet is protected by end point to end point encryption,
> for example through IPsec, transit devices will not have visibility into
> the Geneve header or options in the packet. In cases where options are
> interpreted by transit devices, the operator MUST ensure that transit
> devices are trusted and not compromised. Implementation of a mechanism to
> ensure this trust is beyond the scope of this document.
>
>
>
> Please let us know if this addresses your comment on 3.5.1.  The other two
> comments have been satisfied as noted below.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Magnus Nyström [mailto:[email-masked]]
> *Sent:* Wednesday, October 31, 2018 11:34 AM
> *To:* Ganga, Ilango S <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* RE: Secdir review (early review) of draft-ietf-nvo3-geneve
>
>
>
> Hi Ilango,
>
> For 6.2, I will defer to the IETF director/telechat discussion that will
> occur at some point for this draft. If the intent is interoperability and
> robustness of such an option, then I would recommend it to be specified in
> the IETF, but I can also see how you would prefer that such specification
> work occurs outside this particular draft – which should be doable. Perhaps
> staying silent on the option alternative and just recommend leveraging
> layer-provided infrastructure such as ipsec may be best for now?
>
>
>
> *From: *Ganga, Ilango S <[email-masked]>
> *Sent: *Tuesday, October 30, 2018 18:12
> *To: *Magnus Nyström <[email-masked]>; [email-masked];
> [email-masked]
> *Subject: *RE: Secdir review (early review) of draft-ietf-nvo3-geneve
>
>
>
> Hi Magnus,
>
>
>
> *From:* Magnus Nyström [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, October 23, 2018 9:01 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Secdir review (early review) of draft-ietf-nvo3-geneve
>
>
>
> This document describes "Geneve," a protocol for GEneric NEtwork
> Virtualization Encapsulation. The document is written in a clear manner and
> with a thorough Security Considerations section. I have just a few
> questions/comments:
>
>
>
> - Section 3.4: The "MUST ignore" for the reserved bits should presumably
> state "SHALL be ignored for this version of the Geneve protocol." - as I
> imagine that in a future version, these bits may not be ignored?
>
>
>
> <Ilango> In theory, a future version may change the behavior of any of the
> header fields including the reserved bits.  The header definition is for
> this version of the protocol.
>
>
>
> “Reserved field which MUST be zero on transmission and *MUST be* ignored
> on receipt.”
>
>
>
> - Section 3.5.1: I wonder about the simultaneous requirement that one
> option must not affect the parsing or interpretation of another option but
> that the sequencing (order) of options may be significant - they seem to be
> contradictory since if the sequencing *is* significant, then some option
> must be impacted by a previous one's value? From a security perspective, I
> also wonder if there could be security consequences of re-ordering options
> (and how to tell if someone did re-order - see below)?
>
>
>
> <Ilango> You raise a good point. The intent of this statement is, parsing
> and interpretation of options should not be dependent on one another. We
> are discussing among the authors to see how we can include appropriate
> clarifying statements to address your point. I will update you shortly.
>
> </>
>
>
>
> - Section 6.2, shouldn't such an Option be defined to reduce the risk of
> under-specified or subpar specifications of such integrity mechanisms? Or
> also from an interop perspective?
>
>
>
> <Ilango> Using a Geneve option for the purpose of data integrity is more
> of an optimization. Otherwise data integrity could be provided by using
> existing mechanisms like IPsec (as stated in second paragraph of 6.2). We
> included the last paragraph to show other possibilities. We could remove
> this paragraph if it may cause any confusion.
>
>
>
> We would like to keep the Geneve base specification independent of options
> specifications, options could be a defined in a future standards action.
>
> </>
>
>
>
>
>
> Thanks.
>
> -- Magnus
>
>
>

-- 
-- Magnus

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Wed, 7 Nov 2018 19:30:17 +0000

Hi Magnus,
Thanks for your review and feedback. We have addressed all 3 of your comments. We will be updating the draft to address these and WG LC comments, in the next week or two.
Regards,
Ilango

From: Magnus Nyström [mailto:[email-masked]]
Sent: Tuesday, November 6, 2018 11:20 PM
To: Ganga, Ilango S <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Secdir review (early review) of draft-ietf-nvo3-geneve

Hi Ilango,
Thanks for your thorough follow-up. To me, the new text looks very good. You could shorten (and perhaps add clarity) by replacing "Hence an option..." with just "An option ..."
<Ilango> Yes, this should be fine.

Thanks,
/M

On Tue, Nov 6, 2018 at 7:11 PM Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> wrote:
Hi Magnus,

Thanks,
Ilango

From: Magnus Nyström [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 31, 2018 11:34 AM
To: Ganga, Ilango S <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Secdir review (early review) of draft-ietf-nvo3-geneve

Hi Ilango,

Thanks,

Hi Magnus,

Regards,
Ilango

Thanks.
-- Magnus

--
-- Magnus

---

From: Magnus Nyström <[email-masked]>
Date: Thu, 15 Nov 2018 22:47:49 -1000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the  security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document specifies the "leaptofrogans" URI scheme. Its security
considerations section provides a discussion of common URI risks and how
they apply to the frogans URIs. I do wonder a bit about the statement that
"[the] risk of confusion i[due to the true address being hidden in the link
text visible to the user] is mitigated because Frogans Player must always
display the real Frogans address contained in the URI" - does this
necessarily also apply to "inbound" direction cases - i.e., when a regular
browser displays a link which allows the user to launch a frogans site?

(Unrelated, the "leaptofrogans" name seems long. The scheme part of URIs is
typically the name of a protocol or similar. In the frogans case, "fsdl"
comes to mind as iI understand it to be the language used to create frogans
sites (I do not know what protocol is used to commuicate with such sites).)
Thanks,
-- Magnus