Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Apr 2019 16:56:34 -0400

Hi Ilango,

Thanks for the response. The use case of ECMP to justify transit devices
does not seem - to my understanding aligned with RFC6438 which indicates
TLV is inconvenient for ECMP or LAG, and that flow label should be used
instead.
In addition, the problem of ossification by transit devices is not he
ability to bypass DTLS traffic, but rather the ability to detect a
packet is a Geneve packet.

Unless I misunderstood the use case, it does not seem sufficient (at
least to me) to balance the complexity introduced by transit devices,
i.e. negotiation with middle boxes, protocol ossification, incoherence
in the architecture. I would be happy to hear what the WG thinks about
it.

Following the analogy with IPv6 to determine what options could be used
by transit devices, RFC4306 lists hop-by-hop, routing, and fragmentation
extension headers. RFC 2460 seems to limit that to hop-by-hops. From
hop-by-hop options I do not see equivalence for transit devices with
padding, jumbo or router alert options [1]

Yours,
Daniel

[1] https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

On Wed, Mar 27, 2019 at 9:35 PM Ganga, Ilango S <[email-masked]>
wrote:

> Hi Daniel,
>
>
>
> Here is a specific example use case:
>
> A router (transit device) could use information in the Geneve header for
> ECMP purposes. For example, an option could carry flow context and the
> router may look at Geneve header information, such as VNI and/or flow
> context (Flow ID) in an option or may skip over the options and use
> information in payload for ECMP purposes.  However if the NVEs decide to
> secure the packet with for example DTLS, in this case, the transit devices
> will forward packets as any other UDP packets. It is not a requirement that
> transit devices must see Geneve header information for its normal
> operation; if a transit device cannot view or interpret Geneve headers then
> it simply forwards like any other IP or UDP packets.
>
>
>
> This is very similar to how currently routers look into the IP payload
> information like TCP/UDP port numbers for flow entropy purposes. If the
> packets are encrypted, then routers don’t have visibility into the TCP/UDP
> port numbers and simply forward based on outer header information.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Wednesday, March 27, 2019 11:38 AM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* NVO3 <[email-masked]>
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt - transit devices
>
>
>
> Hi Illango,
>
>
>
> Unless i am missing something, I am unclear how the text you provide
> answers the questions/concerns, so perhaps you could elaborate and maybe be
> a bit more specific.
>
>
>
> My first concern was the use case you envision transit devices. The
> transit device are supposed to read some Geneve options and process them. I
> expected you provided some example of options as well as some processing.
>
>
>
> My second concern was how the draft version 12 addresses a concrete
> deployment. As a reminder here is the scenario mentioned is below. The
> question is how the draft secures such a deployment.
>
>
>
> The basic scenario could be a Geneve deployment that processes options
>
> O_i ( i in [1,,n]) in the NVE and that process option P_j [1, m] in the
>
> Transit devices. While unprotected O_i and P_j are processed. Securing
>
> the deployment with DTLS prevents options P_j to be processed.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Wed, Mar 27, 2019 at 2:11 PM Ganga, Ilango S <[email-masked]>
> wrote:
>
> Hi Daniel,
>
>
>
> We will try to explain the transit devices and example use cases again.
> Hopefully this clarifies your question.
>
>
>
> >The transit devices seems to me problematic, but maybe I am not really
>
> >catching what is their intent. I might be helpful if you could provide
>
> >some behaviour the transit devices is expected to implement. Typically
>
> >what are the use cases for these transit devices?
>
> Transit devices exist in the underlay network, these are simply forwarding
> elements (e.g. switches, routers) that generally forward packets based on
> outer header information, there is nothing that stops such devices from
> reading or interpreting the contents.  At present, this works with any
> transport protocols (encapsulated or non-encapsulated), for example, IP, IP
> in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc.  For example, routers
> (transit device) may look at headers and/or inner payload for ECMP purposes
> or for statistics or logging purposes. If the packet is encrypted then such
> transit devices cannot look into the packets but would simply forward based
> on the outer headers and use information in outer headers for entropy.
> There is no interoperability issue between the endpoints. Geneve is no
> different.
>
> Recognizing the fact that such a device will exist in the network, Geneve
> draft provides guidance on how to handle Geneve headers (if a device has
> the option to do so).  Geneve options are part of Geneve header, a transit
> device that is capable of interpreting Geneve headers may interpret an
> option or skip over the option to view the payload, etc.  If a transit
> device is either unable to, or does not need to interpret the Geneve header
> (which may or may not include options), it simply uses the outer header to
> forward the packet (outer IP/UDP). This is what the Geneve draft clarifies.
>
> These guidelines reduce possible interoperability issues compared to if
> behavior was left undefined. For example, transit devices are not allowed
> to drop packets or fall back to a slow path on the basis of an unknown
> option. If this were to happen, it would hamper the introduction of new
> options.
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Wednesday, March 20, 2019 1:58 PM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* NVO3 <[email-masked]>
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt - transit devices
>
>
>
> Hi,
>
>
>
> I am looking at the version 12 and see how it address my concern,
>
> regarding the transit devices and the compatibility with end to end
>
> security. Could you please point out how the text address this concern ?
>
>
>
> The basic scenario could be a Geneve deployment that processes options
>
> O_i ( i in [1,,n]) in the NVE and that process option P_j [1, m] in the
>
> Transit devices. While unprotected O_i and P_j are processed. Securing
>
> the deployment with DTLS prevents options P_j to be processed. I am
>
> unclear how the version 12 address this concern.
>
>
>
> The transit devices seems to me problematic, but maybe I am not really
>
> catching what is their intent. I might be helpful if you could provide
>
> some behaviour the transit devices is expected to implement. Typically
>
> what are the use cases for these transit devices?
>
>
>
> <Response>
>
> Transit devices exist in the underlay network, these are simply forwarding
> elements (e.g. switches, routers) that generally forwards packets based on
> outer header information, there is nothing that stops such devices from
> reading or interpreting the contents.  At present, this works with any
> transport protocols (encapsulated or non-encapsulated), for example, IP, IP
> in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc.  For example, routers may
> look at headers and/or inner payload for ECMP purposes or for statistics or
> logging purposes. If the packet is encrypted then such transit devices
> cannot look into the packets but would simply forward based on the outer
> headers and use information in outer headers for entropy. There is no
> interoperability issue between the endpoints. Geneve is no different.
>
> Recognizing the fact that such a device will exist in the network, Geneve
> draft provides guidance on how to handle Geneve headers (if a device has
> the option to do so).  Geneve options are part of Geneve header, a transit
> device that is capable of interpreting Geneve headers may interpret an
> option or skip over the option to view the payload, etc.  If a transit
> device is either unable to, or don’t have the option to interpret the
> header or option, it simply uses the outer header to forward the packet
> (outer IP/UDP). This is what the Geneve draft clarifies.
>
> These guidelines reduce possible interoperability issues compared to if
> behavior was left undefined. For example, transit devices are not allowed
> to drop packets or fall back to a slow path on the basis of an unknown
> option. If this were to happen, it would hamper the introduction of new
> options.
>
> It might also be worth mentioning that anything that could be considered a
> middlebox is not a transit device but needs to be modeled as an endpoint.
> For example, if a middle box has a need to see an encrypted packet, then it
> has to implement tunnel endpoint functionality.
>
> </end of response>
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
> On Mon, Mar 11, 2019 at 7:20 PM Ganga, Ilango S <[email-masked]>
> wrote:
>
> Hi Daniel,
>
>
>
> We posted a new version of the draft that we believe addresses your
> comment on options processing.
>
> We have already provided clarification on the role transit devices as
> noted in this thread below.
>
>
>
> Thanks,
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Friday, March 8, 2019 6:51 PM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* NVO3 <[email-masked]>
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt - transit devices
>
>
>
> Hi,
>
>
>
> Thanks for the comment. Let me first recap my perception of the
>
> discussion. My comment was that end-to-end security (IPsec, DTLS) does
>
> not apply to Geneve with transit device. Your previous response was that
>
> Geneve was an end-to-end protocol since transit device are optional. My
>
> response was that an architecture that defines elements even optional
>
> that interfere between the two end points contradicts the status of
>
> end-to-end protocol. At that time my understanding was that the
>
> specification was targeting an end-to-end protocol, with transit devices
>
> with very limited capabilities. Thus I proposed to removed the transit
>
> devices from the architecture. These would have been a great step toward a
>
> end-to-end architecture. However, from the current response, it
>
> seems that transit device play an important part in the architecture, and
>
> we are moving backward from the end-to-end protocol. As
>
> a result, there is - in my opinion to make a coherent choice to make
>
> between Geneve architecture and the security associated. This is
>
> currently very unclear and contradicting - at least to me reading of the
>
> geneve specification and the responses I receive to my comments..
>
>
>
> My understanding of your latest response - and please correct me
>
> if I am wrong - is that transport protocols like IP,
>
> IP in IP, GRE or VXLAN  among others are used to an architecture with
>
> transit nodes.  These latter examples show that end-to-end security is
>
> incompatible with Geneve and that security in Geneve MUST be handled
>
> using options. In addition, these examples seems - up to my
>
> understanding - to challenge the optional status of the transit device
>
> as well as their ability to read-only does not always seems realistic.
>
>
>
> Overall, my impression is that Genve is not an end-to-end protocol,
>
> end-to-end security protocols such as DTLS or IPsec do not apply
>
> realistically. The alternative approach of using option is also
>
> compromised by the current specification of Geneve as well as by
>
> security documents being opposed. Geneve seems mandated to be unsecured.
>
>
>
>
>
> IP is the first protocol you cite. IP enables end-to-end security with
>
> IPsec. However there are a few major difference between IPsec and secure
>
> Geneve communications.
>
>     1. - IPsec leave in clear the information that
>
> need to be read in transit. This is not the case with Geneve over DTLS
>
> or IPsec as even the Geneve Header is encrypted. If we want this
>
> information to be accessible to transit device security must be handled
>
> by geneve security option in order to leave the header in clear text.
>
>     2. IPsec/ESP versus IPsec/AH clearly shows that transit elements do not
>
> restrict from reading the options. As a result, the transit device are
>
> likely to evolve and become more active in the future. As a result, the
>
> security MUST consider this in early stage and I do not see that met.
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <[email-masked]>
> wrote:
>
> Hi Daniel,
>
>
>
> Please see my responses inline below.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Daniel Migault
> *Sent:* Monday, March 4, 2019 9:15 AM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi Ilango,
>
>
>
> Thanks for the response. Please see a concrete example to illustrate my
> concern
>
> for comment 1. For comment 2, it really helped you indicated that Geneve
> is expected
>
> to be an end-to-end protocol. This will help me update the security
> requirement
>
> document. However, the current Geneve specification with transit devices
> seems -
>
> at least to me - to raise an architecture concern as raised in [1].
>
>
>
> -- comment 1:
>
>
>
> Thanks for the feed back. I understand the purpose of keeping option
>
> independent one from each other, and favour this is strongly recommended.
>
> However, I am not convinced this applies always. More specifically, in a
>
> context of security, the purpose of a security option may be related to
>
> another option. Typically, a security option providing authentication or
>
> encryption is potentially authenticating/encryption another option or
>
> other information contained in the header.
>
>
>
> The typical scenario I have in mind would be an authentication option A
>
> authenticating option O. There will clearly some dependencies between A
>
> and O as O could only be used if A has been primarily been validated.
>
> The current statement "SHOULD NOT be dependent" enables this. However, I
>
> have concerns regarding the statement "MUST NOT affect the parsing or
>
> interpretation". In fact, the output of A, will determine if O should be
>
> dropped or processed normally. In case A shows O is not appropriately
>
> authenticated, O might be rejected based on its C value. The ambiguity I
>
> see is that A can be understood as affecting the parsing and
>
> interpretation of O or as a pre-processing operation before parsing or
>
> interpretation of O.
>
>
>
> I think, the text needs further clarifications to remove such ambiguity.
>
> Changing MUST NOT by SHOULD NOT was of course only one proposition and
>
> this could be also addressed otherwise. It might be better, I agree, to
>
> explicitly mention that some options may provide condition on the
>
> parsing of the options. This would leave the parsing of the options
> unchanged.
>
>
>
> <Ilango>
>
> If I understand your example correctly, you want to have one option
> authenticate the contents of another option and if that authentication
> fails, drop the option. This would not drop the entire packet unless that
> option is critical. Can you give a use case for this? This seems unusual
> and not something that is supported by other security protocols such as
> IPsec or TLS to the best of our knowledge.
>
>
>
> I believe a more common outcome of a failed authentication is that the
> entire packet would be dropped. As previously noted, the current text does
> not preclude this. It seems like going beyond this would result in
> significant complexity, both for processing options in this specific case
> as well as the possibility of introducing ambiguity in how other options
> might be defined or processed as an unintended consequence. Without a
> strong use case, this does not seem desirable.
>
> </>
>
>
>
> -- comment 2:
>
>
>
> Thanks for the response that clarifies a bit my understanding of the
>
> transit devices.. I believe the issue I have is related to the transit
>
> devices which I do not see, unless I am wrong, meeting the requirements
>
> for being OPTIONAL and that seems - at least to me - contradicting the
>
> status of end-to-end protocol. As suggested in [1], transit devices seem
> to raise
>
> architectural concerns that is not needed.
>
>
>
> You are correct that the text is clear that transit devices are
>
> OPTIONAL. However, my understanding of OPTIONAL from 2119 is that there
>
> are two sides of it. One is that a vendor may implement it or not, but
>
> the other side is that interoperability with other implementations are
>
> not affected. In this case, two Geneve endpoints using TLS or IPsec will
>
> not be able to interoperate with an implementation based on transit
>
> devices (unless the process being performed by the transit devices is
>
> also performed by the NVE). In that sense, I believe OPTIONAL statement
>
> is not appropriated here.
>
>
>
> An implementation with transit devices seems to prevent the
>
> interoperability of with an implementation where  options are treated
>
> by the NVE over a secure channel. If we suppose that NVE and
>
> transit devices support the same options, then transit devices are not
>
> necessary and could be removed from the specification. If options
>
> supported by transit devices are different from those supported by
>
> the NVE, interoperability will not be achieved. Transit device will not be
>
> able to process the options, resulting in options will be ignored (while
>
> being supported by the implementation).. In addition, if the options
>
> are critical, the NVE is likely to drop the packet as it does not support
>
> the option.
>
>
>
> In addition, I have some hard time to understand the end-to-end model
>
> with a transit device even optional. I believe that end-to-end protocol
>
> is a good path, though. However, my understanding of end-to-end protocol
>
> is that they should only involve two end points. I see the NVE as end
>
> points but the optional transit device does not seems to be one of
>
> these. However, to help me understand better this, as it seems Geneve is
>
> similar to other end-to-end protocol, maybe you could provide similar
>
> end-to-end protocol that involves a transit devices or something similar.
>
>
>
>
> I also have another clarification regarding transit device. I see these
>
> transit devices as adding a lot of complexity to the end-to-end model
>
> with little benefits. Typically, as far as I understand, they can only
>
> read an option. I am thus wondering whether we should not be better off
>
> removing them from the specification. This would end up with a clear
>
> end-to-end model. Reversely, I do not see anything preventing a vendor
>
> to implement them at least for unsecure deployments. Removing them
>
> from the specification would leave the transit devices as implementation
>
> specific. What are actually the benefits of the transit devices that would
>
> justify them to be part of the specification?
>
>
>
> <Ilango>
>
> Transit devices exists in the underlay network, these are simply
> forwarding elements (e.g. switches, routers) that generally forwards
> packets based on outer header information, there is nothing that stops such
> devices from reading the contents if the data is in the clear.  This works
> with any transport protocols like IP, IP in IP, GRE, VXLAN, etc.  For
> example, routers may look at headers and/or inner payload for ECMP purposes
> or for statistics or logging purposes. If the packet is encrypted then such
> transit devices cannot look into the packets but would simply forward based
> on the outer headers and use information in outer headers for entropy.
> There is no interoperability issue between the endpoints. Geneve is no
> different.
>
>
>
> Recognizing the fact that such a device is anyway going to exist in the
> network, Geneve draft provides guidance on how to handle Geneve headers (if
> a device has the option to do so).  Geneve options are part of Geneve
> header, a transit device that is capable of interpreting Geneve headers may
> interpret an option or skip over the option to view the payload, etc.  If a
> transit device is not able interpret the header or option, it has to simply
> use the outer header to forward the packet (outer IP/UDP). This is what the
> Geneve draft clarifies.
>
>
>
> These guidelines reduce possible interoperability issues compared to if
> behavior was left undefined. For example, transit devices are not allowed
> to drop packets or fall back to a slow path on the basis of an unknown
> option. If this were to happen, it would hamper the introduction of new
> options. It might also be worth mentioning that anything that could be
> considered a middlebox is not a transit device but needs to be modeled as
> an endpoint and so Geneve really should be viewed as a tunnel
> endpoint-to-endpoint protocol.
>
> <end>
>
>
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/ekLofhq8erRLE_Msuk8N_SCdhcs
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Sat, Mar 2, 2019 at 8:18 PM Ganga, Ilango S <[email-masked]>
> wrote:
>
> Hi Daniel,
>
>
>
> Let us be specific. I see that you have two comments on the latest
> draft-ietf-nvo3-geneve-09.  Please see below for responses to your comments.
>
>
>
> Comment 1:
>
> OLD
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option MUST NOT affect the parsing or interpretation of any
>
>       other option.
>
>
>
> NEW
>
>
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option SHOULD NOT affect the parsing or interpretation of any
>
>       other option.
>
>
>
> <Ilango>
>
> Architecturally Geneve options can be processed independent of one
> another. The second statement clearly states that parsing or interpretation
> of one option must not affect the other.  This is a reasonable constraint
> to avoid nested dependencies. Options can be designed to work with the
> requirements specified in Geneve.
>
>
>
> Let us take specific examples:
>
> We could think of a design of a Header Integrity check option (related to
> your example). In this case if the header integrity check fails, as a
> result the entire header is invalid and hence the most likely outcome of a
> failed check is that the packet being dropped (including any options in
> that packet whether parsed/interpreted or not). The current text does not
> preclude the packet being dropped as result of failure.
>
>
>
> It is possible to design options, including any security options, with
> these constraints.  We don’t see a reason to change this requirement that
> may have unintended consequences.
>
>
>
> Comment 2:
>
>
>
> NEW
>
> Security Consideration
>
>
>
> Geneve Overlay may be secured using by protecting the NVE-to-NVE
>
> communication using IPsec or DTLS. However, such mechanisms cannot be
>
> applied for deployments that include transit devices..
>
>
>
> Some deployment may not be able to secure the full communication using
>
> IPsec or DTLS between the NVEs. This could be motivated by the presence
>
> of transit devices or by a risk analysis that concludes that the Geneve
>
> packet be only partially protected - typically reduced to the Geneve
>
> Header information. In such cases Geneve specific mechanisms needs to be
>
> designed.
>
>
>
> <Ilango> The challenge is, you are asking to impose requirements that is
> not supported by Geneve architecture. Geneve has an optional feature where
> transit devices may be able to interpret Geneve options. However this is
> not a requirement for Geneve operation between tunnel end point to tunnel
> end point. We have tried make this very clear by adding clarifying text
> during the last two revisions. If the Geneve packet is in the clear then
> transit devices may be able to view the Genve header, options, and the
> payload. However if the packet is encrypted then transit devices cannot
> view the packet contents. This is consistent with other transport protocols
> encrypting the packets. So we don’t see a reason why Geneve should be
> different.
>
>
>
> Geneve is an end to end protocol between tunnel endpoints and the NVEs
> decide to secure (encrypt) the packets between tunnel endpoints. If a
> middle box has a need to see an encrypted packet, then it has to implement
> tunnel endpoint functionality.
>
>
>
> We already have text in 6.4 security consideration section that provides
> clear guidance to the operators.
>
>
>
> So we don’t see a good reason to add the suggested text above.
>
>
>
> For a complete threat analysis, a security analysis of Geneve or some
>
> guide lines to secure a Geneve overlay network, please refer to
>
> [draft-mglt-nvo3-geneve-security-requirements] as well as
>
> [draft-ietf-nvo3-security-requirements].
>
>
>
> <Ilango>
>
> The security requirements document  makes certain assumptions that is
> unsupported by Geneve architecture. We have tried to clarify this multiple
> times, however you have still maintained this in the requirements document.
> So this needs to be addressed. Also the document is not yet adopted by the
> working group.
>
>
>
> Moreover, Geneve security consideration section has been significantly
> enhanced to provide guidance to operators and to address the comments. So
> both documents can progress independently.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Saturday, March 2, 2019 8:49 AM
> *To:* Bocci, Matthew (Nokia - GB) <[email-masked]>
> *Cc:* [email-masked]; Pankaj Garg <pankajg=
> [email-masked]>; NVO3 <[email-masked]>
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi Matt,
>
>
>
>
>
> You are correct, this is at least not an regular process to have a
>
> standard track document being updated by an informational. I do not see
>
> either any requirements for having a WG status to become a reference,
>
> but that is something we could confirm with the RFC-editor.
>
>
>
> Back to the initial suggestion, I also believe the difficulties of
> updating
>
> the Geneve specifications are far less complex than updating the
>
> implementation, and for that specific reason, it would be good we have a
>
> consensus on the security analyse.
>
>
>
> I agree that WG draft would be better, and RFC would be even better as
>
> we have seen WG document being stalled. I am confident we can make this
>
> happen or at least I do not see major issues.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
> On Fri, Mar 1, 2019 at 11:51 AM Bocci, Matthew (Nokia - GB) <
> [email-masked]> wrote:
>
> WG, Daniel,
>
>
>
> Apologies but I mis-spoke on the suggestion for the security requirements
> to act as an update to the encapsulation RFC in future. This would be
> difficult to do as it is informational.
>
>
>
> Nonetheless I think we should only be referencing a WG draft (at a
> minimum) here.
>
>
>
> Matthew
>
>
>
>
>
>
>
> *From: *Dacheng Zhang <[email-masked]> on behalf of "Bocci,
> Matthew (Nokia - GB)" <[email-masked]>
> *Date: *Friday, 1 March 2019 at 16:24
> *To: *Daniel Migault <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>,
> Pankaj Garg <pankajg=[email-masked]>, NVO3 <[email-masked]>
> *Subject: *Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Daniel
>
>
>
> From a procedural perspective, referring to your draft creates a
> dependency and that draft has not yet been adopted by the WG. The old
> Security requirements framework expired a couple of years ago and does not
> seem to be being progressed.
>
> Maybe a better approach to allow progress, as long as the WG can agree to
> your text (if needed) to satisfy the concern that future security
> mechanisms can be used, and that the evolving threat analysis is understood
> by implementers and users of Geneve, would be to mark the Geneve security
> requirements as an update to the geneve encapsulation RFC when it is
> published.
>
>
>
> Matthew
>
>
>
> *From: *Daniel Migault <[email-masked]>
> *Date: *Friday, 1 March 2019 at 16:11
> *To: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>
> *Cc: *Pankaj Garg <pankajg=[email-masked]>, "
> [email-masked]" <[email-masked]>, NVO3 <
> [email-masked]>
> *Subject: *Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi Matthew,
>
>
>
> I am happy to clarify and be more specific. However, despite your
>
> reading of [1] I think [1] clearly indicates the changes I expected as
>
> well as that these changes needs to be made.
>
>
>
> I believe the responsibility of not addressing an acknowledged issue is
>
> more on the side of people ignoring the issue  then on the side of the
>
> one raising this issue. My impression is that this is the situation we
>
> are in.
>
>
>
> I agree that my initial comment saying "I am fine with the text if we do
>
> not find something better." might have been confusing and I apology for
>
> this. At the time of writing the initial comment I was not sure I was
>
> not missing something nor that the problem could not be solved here or
>
> somewhere else (in another section). My meaning behind those words were
>
> that I was open to the way the concerned could be addressed. However, -
>
> from my point of view - the text does not say the issue does not need to
>
> be solved which is the way it has been interpreted. In addition, I
>
> believe I have clarified this right away after the concern has been
>
> acknowledged and not addressed. As result, I do not think my comment
>
> could be reasonably read as the text is fine.
>
>
>
> Please fine the below the initial comment its response and the response
>
> to the response from [1].
>
>
>
> """
>
> <mglt> In case we have a option providing authentication, such option
>
> may affect the interpretation of the other options.
>
> s/interpretation/ndependance may not be better.... I think what we want
>
> to say is that option MUST be able to be processed in any order or in
>
> parallel.  I am fine with the text if we do not find something better.
>
> </mglt>
>
>
>
> <Ilango> This is a good point, however we believe that this text
>
> captures the intent.  </>
>
>
>
> <mglt2>The problem I have is that the current text prevents security
>
> options, so I guess some clarification should be brought to clarify the
>
> intent.</mglt2>
>
> """
>
>
>
> If I had to suggest some text I would suggest the following - or
>
> something around the following lines.
>
>
>
>
>
> OLD
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option MUST NOT affect the parsing or interpretation of any
>
>       other option.
>
>
>
> NEW
>
>
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option SHOULD NOT affect the parsing or interpretation of any
>
>       other option.
>
>
>
> There are rare cases were the parsing of one option affects the parsing
>
> or the interpretation of other option. Option related to security may
>
> fall into this category. Typically, if an option enables the
>
> authentication of another option and the authentication does not
>
> succeed, the authenticated option MUST NOT be processed. Other options
>
> may be designed in the future.
>
>
>
> NEW
>
> Security Consideration
>
>
>
> Geneve Overlay may be secured using by protecting the NVE-to-NVE
>
> communication using IPsec or DTLS. However, such mechanisms cannot be
>
> applied for deployments that include transit devices.
>
>
>
> Some deployment may not be able to secure the full communication using
>
> IPsec or DTLS between the NVEs. This could be motivated by the presence
>
> of transit devices or by a risk analysis that concludes that the Geneve
>
> packet be only partially protected - typically reduced to the Geneve
>
> Header information. In such cases Geneve specific mechanisms needs to be
>
> designed.
>
>
>
> For a complete threat analysis, a security analysis of Geneve or some
>
> guide lines to secure a Geneve overlay network, please refer to
>
> [draft-mglt-nvo3-geneve-security-requirements] as well as
>
> [draft-ietf-nvo3-security-requirements].
>
>
>
> For full disclosure I am a co-author of
>
> draft-mglt-nvo3-geneve-security-requirement. However the reason for
>
> referring to these documents is motivated by the fact that I believe
>
> these analysis provide a better security analysis than the current (OLD)
>
> security consideration section.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
> On Fri, Mar 1, 2019 at 6:03 AM Bocci, Matthew (Nokia - GB) <
> [email-masked]> wrote:
>
> Hi Daniel
>
>
>
> Thanks for reviewing the latest version. At this stage it would be helpful
> if you could be much more concrete and give specifics.
>
>
>
> I think that the main issue is whether the design of Geneve prevents
> future security extensions.
>
>
>
> However, in [1], you stated that you were comfortable with the text if
> nothing else could be found.
>
>
>
> What specifically do you want to change in the following, bearing in mind
> that there are already claimed implementations of Geneve:
>
> """
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option MUST NOT affect the parsing or interpretation of any
>
>       other option.
>
> """
>
>
>
>
>
> Matthew
>
>
>
>
>
> *From: *Daniel Migault <[email-masked]>
> *Date: *Friday, 1 March 2019 at 03:06
> *To: *Pankaj Garg <pankajg=[email-masked]>
> *Cc: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi,
>
>
>
> I just briefly went through the document quickly and in my opinion, the
> document still faces some security issues.
>
>
>
> The current text (in my opinion) prevents any geneve security related
>
> options. Currently Geneve cannot be secured and this prevents future
>
> work to eventually secure Geneve. In my opinion the current text
>
> mandates Geneve to remain unsecure.
>
>
>
> Geneve security option that are willing to authenticate/encrypt a part
>
> of the Geneve Header will affect the parsing of the protected option and
>
> will affect the order in which option needs to be process. Typically a
>
> protected option (authenticated, encrypted) cannot or should not be
>
> processed before authenticated or decrypted.
>
>
>
> This has already been mentioned in [1], and the text needs in my opinion
>
> further clarifications.
>
>
>
> """
>
>    o  An option SHOULD NOT be dependent upon any other option in the
>
>       packet, i.e., options can be processed independent of one another.
>
>       An option MUST NOT affect the parsing or interpretation of any
>
>       other option.
>
> """
>
>
>
>
>
>
>
> As stated in [2] it remains unclear to me why this section is not
>
> referencing and leveraging on the security analysis [3-4] performed by
>
> two different independent teams..
>
>
>
> My reading of the security consideration is that the message is that
>
> IPsec or TLS could be used to protect a geneve overlay network. This is
>
> - in my opinion- not correct as this does not consider the transit
>
> device. In addition, the security consideration only considers the case
>
> where the cloud provider and the overlay network provider are a single
>
> entity, which I believe oversimplifies the problem.
>
>
>
> The threat model seems to me very vague, so the current security
>
> consideration is limited to solving a problem that is not stated.
>
>
>
> My reading of the text indicates the tenant can handle by itself the
>
> confidentiality of its information without necessarily relying on the
>
> overlay service provider. This is not correct. Even when the tenant uses
>
> IPsec/TLS, it still leaks some information. The current text contradicts
>
> [3] section 6.2 and [4] section 5.1.
>
>
>
> My reading is that the text indicates that IPsec/DTLS could be used to
>
> protect the overlay service for both confidentiality and integrity.
>
> While this could be used in some deployment this is not compatible with
>
> transit devices. As such the generic statement is not correct. Section
>
> 6.4 indicates that transit device must be trusted which is incorrect.
>
> Instead the transit device with all nodes between the transit device and
>
> the NVE needs to be trusted.  Overall the impression provided is that
>
> IPsec (or TLS) can be used by the service overlay provider, which is (in
>
> my opinion) not true.
>
>
>
> It is unclear to me how authentication of NVE peers differs from the
>
> authentication communication as the latest usually rely on the first.
>
> Maybe the section should insist on mutual authentication.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o
>
> [2] https://mailarchive.ietf.org/arch/msg/nvo3/e7YHFlqIuOwIJoL2ep7jyHIrSGw
>
> [3] https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07
>
> [4]
> https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-05
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg <pankajg=
> [email-masked]> wrote:
>
> I am not aware of any IP related to draft-ietf-nvo3-geneve which has not
> already been disclosed.
>
>
>
> Thanks
>
> Pankaj
>
>
>
> *From:* Bocci, Matthew (Nokia - GB) <[email-masked]>
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> This email begins a two-week working group last call for
> draft-ietf-nvo3-geneve-08.txt.
>
>
>
> Please review the draft and post any comments to the NVO3 working group
> list. If you have read the latest version of the draft but have no comments
> and believe it is ready for publication as a standards track RFC, please
> also indicate so to the WG email list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> Currently there are two IPR disclosures against this document.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll will run until Friday 26th October.
>
>
>
> Regards
>
>
>
> Matthew and Sam
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Apr 2019 17:00:20 -0400

Hi Ilango,

Thank you for the update. The text addresses my concerns and I also think
it indicates clearly the design principle for options.

Yours,
Daniel

On Wed, Mar 27, 2019 at 1:31 AM Ganga, Ilango S <[email-masked]>
wrote:

> Hi Daniel,
>
>
>
> We updated the draft to restate the requirement on options processing, the
> revised text is much simpler, provides better clarity, and retains the
> original intent. We believe, this should address your concerns.
>
>
>
> https://mailarchive.ietf.org/arch/msg/nvo3/-jwq1fjwDufvPl8Qcbk7Iheiegg
>
>
>
> Revised text:
>
> “An option SHOULD NOT be dependent upon any other option in the
>
> packet, i.e., options can be processed independently of one
>
> another.  Architecturally, options are intended to be self-
>
> descriptive and independent.  This enables parallelism in option
>
> processing and reduces implementation complexity.”
>
>
>
> Thanks
>
> Ilango
>
>
>
> *Sent:* Wednesday, March 20, 2019 1:56 PM
> draft-ietf-nvo3-geneve-08.txt - geneve options
>
>
>
> Hi,
>
>
>
> regarding the integration of security options.
>
>
>
> The new text in version 12 mentions:
>
> """
>
>       other option.  However, option processing by tunnel endpoints may
>
>       result in the packet being dropped.  Options may also be used in
>
>       conjunction with each other or combined with packet data but this
>
>       processing is done above the encapsulation layer.
>
> """
>
>
>
> I am reading the text as a security option can be combined with another
>
> option or the data payload. More specifically, an authentication option
>
> that authenticates some options and/or the payload may result in the
>
> packet to be discarded or not.
>
>
>
> I think we are making progress. However, I am not clear about the text:
>
>
>
> """ but this processing is done above the encapsulation layer."""
>
>
>
> I am reading the encapsulation layer as the Geneve protocol, but I am
>
> not clear what the layer above is. I am assuming that is a layer
>
> that takes the output of the Geneve decapsulation. If that is correct,
>
> I understand the text saying Geneve processes the options even though
>
> the authentication has failed. Typically, suppose option A covers
>
> options O. Upon verification of A fails, Geneve processes O and returns
>
> to some upper layers that O has been processed while its authentication
>
> did not succeed. I am sure that I misunderstood the text, but I suggest
>
> some clarification are provided to prevent such interpretation as the
>
> purpose of the authenticating O MUST be able to prevent the processing
>
> of the option O.
>
>
>
> In the current text I believe the text """but ...layer""" can be
>
> removed. Another way might be to clarify the layer above the
>
> encapsulation.
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
>
>
> On Fri, Mar 8, 2019 at 9:44 PM Daniel Migault <[email-masked]>
> wrote:
>
> Hi,
>
>
>
> Thanks for the response. Let me first recap the previous conversation,
>
> or at least my perception of them. My initial comment was that the
>
> current Geneve specification prevents the design of security options and
>
> I provided an example. My understanding is there is an agreement that
>
> such option is prevented by the current geneve specification and you
>
> challenge the usefulness of such an option (designated as A) as well as
>
> argue that an authentication upon failure MUST result in discarding the
>
> packet.
>
>
>
> The security options considered has been mentioned in two independent
>
> security analysis. The example has been described and commented
>
> extensively in the threat analysis as well.  I argue further that
>
> mandating that dropping the packet, in our case is neither a decision
>
> that can be taken at the option level, nor at the geneve level. Instead,
>
> it belongs to a policy decision that is likely to result in incoherent
>
> deployments.
>
>
>
> As result, the current geneve specification prevents security options.
>
> Please see below for more additional information.
>
>
>
> The current option works similarly to IPsec: IPsec/ESP is IP option. AH
>
> is an option that authenticates the full IP packet. ESP
>
> authenticate/encrypt the IP payload and not the full packet.  Upon
>
> authentication failure *the scope of the authentication* is discarded
>
> and in that sense the example I am providing is no more different.
>
>
>
> In our case, the option authenticate an portion of the geneve packet
>
> that is limited to the option. Tthe coverage of the security option is a
>
> portion of the geneve header.  As such, the option cannot mandate
>
> anything outside of its coverage: the covered option O. As a result,
>
> dropping the full packet is outside of the scope. Mandating a packet
>
> drop hardly, in my opinion apply here.
>
>
>
> Options are usually non critical for interoperability. Mandating to drop
>
> the packet when option O cannot be authenticated would contradict the
>
> non critical status of that option, which is the packet can be processed
>
> without the option. This would be a policy that overwrite the geneve
>
>  - as well as the geneve option - specification.
>
> A possible incoherence would be if option A and O are non critical would
>
> be that the implementation ignoring the option A and O will accept the
>
> packet, an implementation understanding option O but not option A will
>
> accept the packet while the implementation understanding option A and O
>
> will reject the packet.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>

---

From: Jesse Gross <[email-masked]>
Date: Tue, 2 Apr 2019 19:45:26 -0700

Daniel,

Speaking as a member of the working group rather than as a coauthor, I
think there is confusion about the NVO3 architecture that is
independent of Geneve.

Transit devices are not middle boxes. They are routers and switches,
used to move packets between endpoints in an L3 network. This is
fundamental to the NVO3 architecture and to remove them is not
possible.

What would be possible is to remove mention of them from the protocol
document. However, transit devices would continue to exist and would
still be able to read unencrypted packets. Again, there is no getting
around this. The only way to prevent transit devices from interacting
with packets at the encapsulation layer and above is through the use
of end-to-end encryption.

What the Geneve draft does do is provide guidelines for how these
transit devices should behave to ensure that they are good citizens.
For example, routers today look into packets beyond the IP header and
it's likely that this will continue when encapsulation is in use. The
Geneve draft specifies that if they do this, they must not drop or
slow path packets even if they encounter unknown options. Describing
this behavior is not incoherence in the architecture - it is a method
of ensuring that the protocol remains flexible for end-to-end users.

Jesse

On Tue, Apr 2, 2019 at 1:57 PM Daniel Migault
<[email-masked]> wrote:
> On Wed, Mar 27, 2019 at 9:35 PM Ganga, Ilango S <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> A router (transit device) could use information in the Geneve header for ECMP purposes. For example, an option could carry flow context and the router may look at Geneve header information, such as VNI and/or flow context (Flow ID) in an option or may skip over the options and use information in payload for ECMP purposes.  However if the NVEs decide to secure the packet with for example DTLS, in this case, the transit devices will forward packets as any other UDP packets. It is not a requirement that transit devices must see Geneve header information for its normal operation; if a transit device cannot view or interpret Geneve headers then it simply forwards like any other IP or UDP packets.
>>
>>
>>
>> This is very similar to how currently routers look into the IP payload information like TCP/UDP port numbers for flow entropy purposes. If the packets are encrypted, then routers don’t have visibility into the TCP/UDP port numbers and simply forward based on outer header information.
>>
>>
>>
>> Thanks,
>>
>> Ilango
>>
>>
>>
>>
>>
>> From: Daniel Migault [mailto:[email-masked]]
>> Sent: Wednesday, March 27, 2019 11:38 AM
>> To: Ganga, Ilango S <[email-masked]>
>> Cc: NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices
>>
>>
>>
>> Hi Illango,
>>
>>
>>
>> Unless i am missing something, I am unclear how the text you provide answers the questions/concerns, so perhaps you could elaborate and maybe be a bit more specific.
>>
>>
>>
>> My first concern was the use case you envision transit devices. The transit device are supposed to read some Geneve options and process them. I expected you provided some example of options as well as some processing.
>>
>>
>>
>> My second concern was how the draft version 12 addresses a concrete deployment. As a reminder here is the scenario mentioned is below. The question is how the draft secures such a deployment.
>>
>>
>>
>> On Wed, Mar 27, 2019 at 2:11 PM Ganga, Ilango S <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> We will try to explain the transit devices and example use cases again. Hopefully this clarifies your question.
>>
>>
>>
>> Transit devices exist in the underlay network, these are simply forwarding elements (e.g. switches, routers) that generally forward packets based on outer header information, there is nothing that stops such devices from reading or interpreting the contents.  At present, this works with any transport protocols (encapsulated or non-encapsulated), for example, IP, IP in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc.  For example, routers (transit device) may look at headers and/or inner payload for ECMP purposes or for statistics or logging purposes. If the packet is encrypted then such transit devices cannot look into the packets but would simply forward based on the outer headers and use information in outer headers for entropy. There is no interoperability issue between the endpoints. Geneve is no different.
>>
>> Recognizing the fact that such a device will exist in the network, Geneve draft provides guidance on how to handle Geneve headers (if a device has the option to do so).  Geneve options are part of Geneve header, a transit device that is capable of interpreting Geneve headers may interpret an option or skip over the option to view the payload, etc.  If a transit device is either unable to, or does not need to interpret the Geneve header (which may or may not include options), it simply uses the outer header to forward the packet (outer IP/UDP). This is what the Geneve draft clarifies.
>>
>> These guidelines reduce possible interoperability issues compared to if behavior was left undefined. For example, transit devices are not allowed to drop packets or fall back to a slow path on the basis of an unknown option. If this were to happen, it would hamper the introduction of new options.
>>
>> Thanks,
>>
>> Ilango
>>
>>
>>
>>
>>
>> From: Daniel Migault [mailto:[email-masked]]
>> Sent: Wednesday, March 20, 2019 1:58 PM
>> To: Ganga, Ilango S <[email-masked]>
>> Cc: NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices
>>
>>
>>
>> Hi,
>>
>>
>>
>> Transit devices exist in the underlay network, these are simply forwarding elements (e.g. switches, routers) that generally forwards packets based on outer header information, there is nothing that stops such devices from reading or interpreting the contents.  At present, this works with any transport protocols (encapsulated or non-encapsulated), for example, IP, IP in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc.  For example, routers may look at headers and/or inner payload for ECMP purposes or for statistics or logging purposes. If the packet is encrypted then such transit devices cannot look into the packets but would simply forward based on the outer headers and use information in outer headers for entropy. There is no interoperability issue between the endpoints. Geneve is no different.
>>
>> Recognizing the fact that such a device will exist in the network, Geneve draft provides guidance on how to handle Geneve headers (if a device has the option to do so).  Geneve options are part of Geneve header, a transit device that is capable of interpreting Geneve headers may interpret an option or skip over the option to view the payload, etc.  If a transit device is either unable to, or don’t have the option to interpret the header or option, it simply uses the outer header to forward the packet (outer IP/UDP). This is what the Geneve draft clarifies.
>>
>> These guidelines reduce possible interoperability issues compared to if behavior was left undefined. For example, transit devices are not allowed to drop packets or fall back to a slow path on the basis of an unknown option. If this were to happen, it would hamper the introduction of new options.
>>
>> It might also be worth mentioning that anything that could be considered a middlebox is not a transit device but needs to be modeled as an endpoint. For example, if a middle box has a need to see an encrypted packet, then it has to implement tunnel endpoint functionality.
>>
>> </end of response>
>>
>>
>>
>> Yours,
>>
>> Daniel
>>
>>
>>
>>
>>
>> On Mon, Mar 11, 2019 at 7:20 PM Ganga, Ilango S <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> We posted a new version of the draft that we believe addresses your comment on options processing.
>>
>> We have already provided clarification on the role transit devices as noted in this thread below.
>>
>>
>>
>> Thanks,
>> Ilango
>>
>>
>>
>>
>>
>> From: Daniel Migault [mailto:[email-masked]]
>> Sent: Friday, March 8, 2019 6:51 PM
>> To: Ganga, Ilango S <[email-masked]>
>> Cc: NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices
>>
>>
>>
>> Hi,
>>
>>
>>
>> On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> From: nvo3 [mailto:[email-masked]] On Behalf Of Daniel Migault
>> Sent: Monday, March 4, 2019 9:15 AM
>> To: Ganga, Ilango S <[email-masked]>
>> Cc: [email-masked]
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> Hi Ilango,
>>
>>
>>
>> Thanks for the response. Please see a concrete example to illustrate my concern
>>
>> for comment 1. For comment 2, it really helped you indicated that Geneve is expected
>>
>> to be an end-to-end protocol. This will help me update the security requirement
>>
>> document. However, the current Geneve specification with transit devices seems -
>>
>> parsing of the options. This would leave the parsing of the options unchanged.
>>
>>
>>
>> <Ilango>
>>
>> If I understand your example correctly, you want to have one option authenticate the contents of another option and if that authentication fails, drop the option. This would not drop the entire packet unless that option is critical. Can you give a use case for this? This seems unusual and not something that is supported by other security protocols such as IPsec or TLS to the best of our knowledge.
>>
>>
>>
>> I believe a more common outcome of a failed authentication is that the entire packet would be dropped. As previously noted, the current text does not preclude this. It seems like going beyond this would result in significant complexity, both for processing options in this specific case as well as the possibility of introducing ambiguity in how other options might be defined or processed as an unintended consequence. Without a strong use case, this does not seem desirable.
>>
>> </>
>>
>>
>>
>> -- comment 2:
>>
>>
>>
>> status of end-to-end protocol. As suggested in [1], transit devices seem to raise
>>
>> Transit devices exists in the underlay network, these are simply forwarding elements (e.g. switches, routers) that generally forwards packets based on outer header information, there is nothing that stops such devices from reading the contents if the data is in the clear.  This works with any transport protocols like IP, IP in IP, GRE, VXLAN, etc.  For example, routers may look at headers and/or inner payload for ECMP purposes or for statistics or logging purposes. If the packet is encrypted then such transit devices cannot look into the packets but would simply forward based on the outer headers and use information in outer headers for entropy. There is no interoperability issue between the endpoints. Geneve is no different.
>>
>>
>>
>> Recognizing the fact that such a device is anyway going to exist in the network, Geneve draft provides guidance on how to handle Geneve headers (if a device has the option to do so).  Geneve options are part of Geneve header, a transit device that is capable of interpreting Geneve headers may interpret an option or skip over the option to view the payload, etc.  If a transit device is not able interpret the header or option, it has to simply use the outer header to forward the packet (outer IP/UDP).. This is what the Geneve draft clarifies.
>>
>>
>>
>> These guidelines reduce possible interoperability issues compared to if behavior was left undefined. For example, transit devices are not allowed to drop packets or fall back to a slow path on the basis of an unknown option. If this were to happen, it would hamper the introduction of new options. It might also be worth mentioning that anything that could be considered a middlebox is not a transit device but needs to be modeled as an endpoint and so Geneve really should be viewed as a tunnel endpoint-to-endpoint protocol.
>>
>> <end>
>>
>>
>>
>>
>>
>> On Sat, Mar 2, 2019 at 8:18 PM Ganga, Ilango S <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> Let us be specific. I see that you have two comments on the latest draft-ietf-nvo3-geneve-09.  Please see below for responses to your comments.
>>
>>
>>
>> Comment 1:
>>
>> OLD
>>
>> Architecturally Geneve options can be processed independent of one another. The second statement clearly states that parsing or interpretation of one option must not affect the other.  This is a reasonable constraint to avoid nested dependencies. Options can be designed to work with the requirements specified in Geneve.
>>
>>
>>
>> We could think of a design of a Header Integrity check option (related to your example). In this case if the header integrity check fails, as a result the entire header is invalid and hence the most likely outcome of a failed check is that the packet being dropped (including any options in that packet whether parsed/interpreted or not). The current text does not preclude the packet being dropped as result of failure.
>>
>>
>>
>> It is possible to design options, including any security options, with these constraints.  We don’t see a reason to change this requirement that may have unintended consequences.
>>
>>
>>
>> Comment 2:
>>
>>
>>
>> NEW
>>
>> Security Consideration
>>
>>
>>
>> applied for deployments that include transit devices...
>>
>>
>>
>> <Ilango> The challenge is, you are asking to impose requirements that is not supported by Geneve architecture. Geneve has an optional feature where transit devices may be able to interpret Geneve options. However this is not a requirement for Geneve operation between tunnel end point to tunnel end point. We have tried make this very clear by adding clarifying text during the last two revisions. If the Geneve packet is in the clear then transit devices may be able to view the Genve header, options, and the payload. However if the packet is encrypted then transit devices cannot view the packet contents. This is consistent with other transport protocols encrypting the packets. So we don’t see a reason why Geneve should be different.
>>
>>
>>
>> Geneve is an end to end protocol between tunnel endpoints and the NVEs decide to secure (encrypt) the packets between tunnel endpoints. If a middle box has a need to see an encrypted packet, then it has to implement tunnel endpoint functionality.
>>
>>
>>
>> We already have text in 6.4 security consideration section that provides clear guidance to the operators.
>>
>>
>>
>> The security requirements document  makes certain assumptions that is unsupported by Geneve architecture. We have tried to clarify this multiple times, however you have still maintained this in the requirements document. So this needs to be addressed. Also the document is not yet adopted by the working group.
>>
>>
>>
>> Moreover, Geneve security consideration section has been significantly enhanced to provide guidance to operators and to address the comments. So both documents can progress independently.
>>
>>
>>
>> Thanks,
>>
>> Ilango
>>
>>
>>
>>
>>
>> From: Daniel Migault [mailto:[email-masked]]
>> Sent: Saturday, March 2, 2019 8:49 AM
>> To: Bocci, Matthew (Nokia - GB) <[email-masked]>
>> Cc: [email-masked]; Pankaj Garg <pankajg=[email-masked]>; NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> Hi Matt,
>>
>>
>>
>>
>>
>> Back to the initial suggestion, I also believe the difficulties of updating
>>
>> On Fri, Mar 1, 2019 at 11:51 AM Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
>>
>> WG, Daniel,
>>
>>
>>
>> Apologies but I mis-spoke on the suggestion for the security requirements to act as an update to the encapsulation RFC in future. This would be difficult to do as it is informational.
>>
>>
>>
>> Nonetheless I think we should only be referencing a WG draft (at a minimum) here.
>>
>>
>>
>> Matthew
>>
>>
>>
>>
>>
>>
>>
>> From: Dacheng Zhang <[email-masked]> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked]>
>> Date: Friday, 1 March 2019 at 16:24
>> To: Daniel Migault <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>, Pankaj Garg <pankajg=[email-masked]>, NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> Daniel
>>
>>
>>
>> From a procedural perspective, referring to your draft creates a dependency and that draft has not yet been adopted by the WG. The old Security requirements framework expired a couple of years ago and does not seem to be being progressed.
>>
>> Maybe a better approach to allow progress, as long as the WG can agree to your text (if needed) to satisfy the concern that future security mechanisms can be used, and that the evolving threat analysis is understood by implementers and users of Geneve, would be to mark the Geneve security requirements as an update to the geneve encapsulation RFC when it is published.
>>
>>
>>
>> Matthew
>>
>>
>>
>> From: Daniel Migault <[email-masked]>
>> Date: Friday, 1 March 2019 at 16:11
>> To: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
>> Cc: Pankaj Garg <pankajg=[email-masked]>, "[email-masked]" <[email-masked]>, NVO3 <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> Hi Matthew,
>>
>>
>>
>> On Fri, Mar 1, 2019 at 6:03 AM Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
>>
>> Hi Daniel
>>
>>
>>
>> Thanks for reviewing the latest version. At this stage it would be helpful if you could be much more concrete and give specifics.
>>
>>
>>
>> I think that the main issue is whether the design of Geneve prevents future security extensions.
>>
>>
>>
>> However, in [1], you stated that you were comfortable with the text if nothing else could be found.
>>
>>
>>
>> What specifically do you want to change in the following, bearing in mind that there are already claimed implementations of Geneve:
>>
>> """
>>
>> From: Daniel Migault <[email-masked]>
>> Date: Friday, 1 March 2019 at 03:06
>> To: Pankaj Garg <pankajg=[email-masked]>
>> Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <[email-masked]>, "[email-masked]" <[email-masked]>
>> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> Hi,
>>
>>
>>
>> I just briefly went through the document quickly and in my opinion, the document still faces some security issues.
>>
>>
>>
>> two different independent teams...
>>
>>
>>
>> [4] https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-05
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg <pankajg=[email-masked]> wrote:
>>
>> I am not aware of any IP related to draft-ietf-nvo3-geneve which has not already been disclosed.
>>
>>
>>
>> Thanks
>>
>> Pankaj
>>
>>
>>
>> From: Bocci, Matthew (Nokia - GB) <[email-masked]>
>> Sent: Tuesday, October 9, 2018 2:08 AM
>> To: NVO3 <[email-masked]>
>> Cc: [email-masked]
>> Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
>>
>>
>>
>> This email begins a two-week working group last call for draft-ietf-nvo3-geneve-08.txt.
>>
>>
>>
>> Please review the draft and post any comments to the NVO3 working group list. If you have read the latest version of the draft but have no comments and believe it is ready for publication as a standards track RFC, please also indicate so to the WG email list.
>>
>>
>>
>> We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>> If you are listed as an Author or a Contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
>>
>>
>>
>> If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
>>
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Apr 2019 20:36:08 -0700

Hi, all,

FWIW - I don’t understand this requirement.

Clearly, an option MUST NOT depend on options that come before it in the order they occur, otherwise you could have options defined in a circular manner that cannot be resolved.

However, if you prevent options that depend on other, later options you would undermine the ability to have an option that provides authentication (which is useful only when it includes both the payload and subsequent options) or encryption (which should at least authenticate the option area, even if it isn’t encrypted). It also undermines the ability to have options that create new checksum algorithms.

Are you really seeking to prevent these future possibilities?

Joe

> On Mar 26, 2019, at 10:30 PM, Ganga, Ilango S <[email-masked]> wrote:
> 
> Hi Daniel,
>  
> We updated the draft to restate the requirement on options processing, the revised text is much simpler, provides better clarity, and retains the original intent. We believe, this should address your concerns.
>  
> https://mailarchive.ietf.org/arch/msg/nvo3/-jwq1fjwDufvPl8Qcbk7Iheiegg <https://mailarchive.ietf.org/arch/msg/nvo3/-jwq1fjwDufvPl8Qcbk7Iheiegg>
>  
> Revised text:
>   <>
>  <>From: Daniel Migault [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: Wednesday, March 20, 2019 1:56 PM
> To: Ganga, Ilango S <[email-masked] <mailto:[email-masked]>>
> Cc: NVO3 <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - geneve options
>  
> Hi,
>  
> On Fri, Mar 8, 2019 at 9:44 PM Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>  
> On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Daniel,
>  
> From: nvo3 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Daniel Migault
> To: Ganga, Ilango S <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> Recognizing the fact that such a device is anyway going to exist in the network, Geneve draft provides guidance on how to handle Geneve headers (if a device has the option to do so).  Geneve options are part of Geneve header, a transit device that is capable of interpreting Geneve headers may interpret an option or skip over the option to view the payload, etc.  If a transit device is not able interpret the header or option, it has to simply use the outer header to forward the packet (outer IP/UDP). This is what the Geneve draft clarifies.
>  
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/ekLofhq8erRLE_Msuk8N_SCdhcs <https://mailarchive.ietf.org/arch/msg/nvo3/ekLofhq8erRLE_Msuk8N_SCdhcs>
>  
>  
> Yours, 
> Daniel 
>  
> On Sat, Mar 2, 2019 at 8:18 PM Ganga, Ilango S <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Daniel,
>  
>  <>From: Daniel Migault [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Pankaj Garg <pankajg=[email-masked] <mailto:[email-masked]>>; NVO3 <[email-masked] <mailto:[email-masked]>>
> On Fri, Mar 1, 2019 at 11:51 AM Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
> WG, Daniel,
>  
> From: Dacheng Zhang <[email-masked] <mailto:[email-masked]>> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked] <mailto:[email-masked]>>
> To: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Pankaj Garg <pankajg=[email-masked] <mailto:[email-masked]>>, NVO3 <[email-masked] <mailto:[email-masked]>>
> From: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> To: "Bocci, Matthew (Nokia - GB)" <[email-masked] <mailto:[email-masked]>>
> Cc: Pankaj Garg <pankajg=[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, NVO3 <[email-masked] <mailto:[email-masked]>>
> On Fri, Mar 1, 2019 at 6:03 AM Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Daniel
>  
> From: Daniel Migault <[email-masked] <mailto:[email-masked]>>
> To: Pankaj Garg <pankajg=[email-masked] <mailto:[email-masked]>>
> Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked] <mailto:[email-masked]>>, NVO3 <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> [1] https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o <https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o>
> [2] https://mailarchive.ietf.org/arch/msg/nvo3/e7YHFlqIuOwIJoL2ep7jyHIrSGw <https://mailarchive.ietf.org/arch/msg/nvo3/e7YHFlqIuOwIJoL2ep7jyHIrSGw>
> [3] https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07 <https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07>
> [4] https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-05 <https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-05>
>  
>  
>  
>  
>  
> On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg <pankajg=[email-masked] <mailto:[email-masked]>> wrote:
> From: Bocci, Matthew (Nokia - GB) <[email-masked] <mailto:[email-masked]>> 
> To: NVO3 <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>_______________________________________________
> nvo3 mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 11:30:15 -0400

Hi Jesse,

Thanks for the response. I am definitively willing to understand these
transit devices to move forward the geneve specification as well as
associated security documents. I do not see them mentioned in in
RFC 8014 but maybe a different terminology is used or I am reading
the wrong document.

>From your response, I understand that transit devices will be part of
the deployments and inspect the Geneve Header. What would be clarifying
to me is:

1) what is a typical behavior for such transit devices, what
Geneve information will they look at, what would be the outcome.
Currently I have not seen a use case for it.

2) I am not so familiar with routing, be my understanding is that router
forwards based on unprotected information. One reason is that end points
may not share some specific context with these intermediary nodes. In
the case of Geneve, the main issue I have, is to understand the relation
between NVE and transit devices. It is fairly easy to have a key
exchange between two NVEs, but this is very difficult to have a key
exchange between NVEs and transit devices. In my view - and I might be
completely wrong - NVEs should not be aware of transit devices that are
on-path. This would mean that that Geneve option accessed by the NVE
could be left unprotected or NVE will be configured by an admin to
protect these options in a certain way. This will avoid a key
negotiation between the NVEs to consider the transit devices.

If we do not have any valid use case, removing transit devices from the
Geneve specification would work for me, or add a section in the security
consideration to avoid ossification.

If we assume there is a valid use case, I am wondering if the following
assumptions seem reasonable to you. If that does not seem reasonable,
feel free to let me know what is not acceptable:

* Geneve is an end-to-end protocol between two NVE.
* transit device are intermediary nodes NVE may not know their existence.
* transit devices may access certain Geneve Options.
* The specification of Geneve Options MUST specify whether the option is
made visible to the transit device or only to the NVE.
* Geneve Options made visible to transit devices are configured in the
NVE.

* The protection of the Geneve information accessed to the transit
device is left to the underlay infrastructure, or configuration by an
admin. It may remain un-protected by Geneve, but could also be protected
by an option. However, it remains outside the scope of the NVE.

* NVEs may agree on cryptographic material via a Key Exchange Protocol
but the protection of information accessed by transit devices is
outside the scope of that cryptographic material.

* Because we have two classes of options, those read (processed) by the
transit
 devices and those processed by the NVE. The security of Geneve needs to
involve a mechanisms based on security options ( similar to IPsec) in
the general case. On the other hand, when transit devices are not
deployed DTLS could be used as an alternative. As this document does not
describes any Geneve Options DTLS can be used here.

* In order to prevent transit devices to interfere and ossify Geneve,
traffic that is not understood MUST be bypassed.

Yours,
Daniel

On Tue, Apr 2, 2019 at 10:46 PM Jesse Gross <[email-masked]> wrote:

> > [1]
> https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
> >
> >
> >
> >> A router (transit device) could use information in the Geneve header
> for ECMP purposes. For example, an option could carry flow context and the
> >> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for
> >> Transit devices exist in the underlay network, these are simply
> forwarding elements (e.g. switches, routers) that generally forward packets
> based on outer header information, there is nothing that stops such devices
> from reading or interpreting the contents.  At present, this works with any
> >> Recognizing the fact that such a device will exist in the network,
> Geneve draft provides guidance on how to handle Geneve headers (if a device
> has the option to do so).  Geneve options are part of Geneve header, a
> transit device that is capable of interpreting Geneve headers may interpret
> an option or skip over the option to view the payload, etc.  If a transit
> >> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for
> >> Transit devices exist in the underlay network, these are simply
> devices from reading or interpreting the contents.  At present, this works
> with any transport protocols (encapsulated or non-encapsulated), for
> example, IP, IP in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc.  For
> >> Recognizing the fact that such a device will exist in the network,
> Geneve draft provides guidance on how to handle Geneve headers (if a device
> has the option to do so).  Geneve options are part of Geneve header, a
> transit device that is capable of interpreting Geneve headers may interpret
> an option or skip over the option to view the payload, etc.  If a transit
> >> It might also be worth mentioning that anything that could be
> an endpoint. For example, if a middle box has a need to see an encrypted
> packet, then it has to implement tunnel endpoint functionality.
> >>
> >> </end of response>
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >>
> >>
> >> Subject: Re: [nvo3] Working Group Last Call and IPR Poll for
> use the outer header to forward the packet (outer IP/UDP).. This is what
> the Geneve draft clarifies.
> >>
> >>
> >>
> >> [1]
> https://mailarchive.ietf.org/arch/msg/nvo3/ekLofhq8erRLE_Msuk8N_SCdhcs
> >>
> >>
> >>
> >>
> >>
> >> Yours,
> >>
> >> Daniel
> >>
> >>
> >>
> >> We could think of a design of a Header Integrity check option (related
> to your example). In this case if the header integrity check fails, as a
> >> <Ilango> The challenge is, you are asking to impose requirements that
> is not supported by Geneve architecture. Geneve has an optional feature
> where transit devices may be able to interpret Geneve options. However this
> is not a requirement for Geneve operation between tunnel end point to
> tunnel end point. We have tried make this very clear by adding clarifying
> text during the last two revisions. If the Geneve packet is in the clear
> then transit devices may be able to view the Genve header, options, and the
> >> We already have text in 6.4 security consideration section that
> provides clear guidance to the operators.
> >>
> >>
> >>
> >> Cc: [email-masked]; Pankaj Garg <pankajg=
> >> Apologies but I mis-spoke on the suggestion for the security
> requirements to act as an update to the encapsulation RFC in future. This
> would be difficult to do as it is informational.
> >>
> >>
> >>
> >> From: Dacheng Zhang <[email-masked]> on behalf of "Bocci,
> >> Cc: "[email-masked]" <[email-masked]>,
> >> Maybe a better approach to allow progress, as long as the WG can agree
> to your text (if needed) to satisfy the concern that future security
> >> Cc: Pankaj Garg <pankajg=[email-masked]>, "
> >> Thanks for reviewing the latest version. At this stage it would be
> helpful if you could be much more concrete and give specifics.
> >>
> >>
> >>
> >> What specifically do you want to change in the following, bearing in
> mind that there are already claimed implementations of Geneve:
> >>
> >> """
> >>
> >> Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <
> >> [1]
> https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o
> >>
> >> [2]
> https://mailarchive.ietf.org/arch/msg/nvo3/e7YHFlqIuOwIJoL2ep7jyHIrSGw
> >>
> >> [3]
> https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07
> >>
> >> [4]
> >> We are also polling for knowledge of any undisclosed IPR that applies
> to this document, to ensure that IPR has been disclosed in compliance with
> >> If you are listed as an Author or a Contributor of this document,
> please respond to this email and indicate whether or not you are aware of
> any relevant undisclosed IPR. The Document won't progress without answers
> from all the Authors and Contributors.
> >>
> >>
> >>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 11:33:41 -0400

Hi,

My reading is that SHOULD NOT means MUST NOT unless we have a good reason
for it and security or checksum options fall in that category. AM I missing
something ?

Yours,
Daniel

On Tue, Apr 2, 2019 at 11:36 PM Joe Touch <[email-masked]> wrote:

> Clearly, an option MUST NOT depend on options that come before it in the
> order they occur, otherwise you could have options defined in a circular
> manner that cannot be resolved.
>
> However, if you prevent options that depend on other, later options you
> would undermine the ability to have an option that provides authentication
> (which is useful only when it includes both the payload and subsequent
> options) or encryption (which should at least authenticate the option area,
> even if it isn’t encrypted). It also undermines the ability to have options
> that create new checksum algorithms.
>
> *From:* Daniel Migault [mailto:[email-masked]
> <[email-masked]>]

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Apr 2019 08:43:35 -0700

FWIW, IMO SHOULD NOT needs to come with a description of what would
qualify as an exception. 

However, you can't allow two such exceptions UNLESS they're
deconflicted, i.e., who goes first. That never works well in practice
because every new option says "I come first". 

I.e., the point isn't whether you have exceptions - you will. The point
is to specify how those cases work, in which case you don't need the
SHOULD NOT. 

Joe

On 2019-04-03 08:33, Daniel Migault wrote:

> Hi,  
> My reading is that SHOULD NOT means MUST NOT unless we have a good reason for it and security or checksum options fall in that category. AM I missing something ? 
> 
> Yours,  
> Daniel 
> 
> FWIW - I don't understand this requirement. 
> 
> However, if you prevent options that depend on other, later options you would undermine the ability to have an option that provides authentication (which is useful only when it includes both the payload and subsequent options) or encryption (which should at least authenticate the option area, even if it isn't encrypted). It also undermines the ability to have options that create new checksum algorithms. 
> 
> "An option SHOULD NOT be dependent upon any other option in the 
> processing and reduces implementation complexity."
> 
> Thanks 
> Ilango 
> 
> FROM: Daniel Migault [mailto:[email-masked]] 
> SENT: Wednesday, March 20, 2019 1:56 PM
> TO: Ganga, Ilango S <[email-masked]>
> CC: NVO3 <[email-masked]>
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - geneve options 
> 
> Hi, 
> 
> On Fri, Mar 8, 2019 at 9:44 PM Daniel Migault <[email-masked]> wrote: 
> 
> Hi, 
> 
> FROM: nvo3 [mailto:[email-masked]] ON BEHALF OF Daniel Migault
> SENT: Monday, March 4, 2019 9:15 AM
> TO: Ganga, Ilango S <[email-masked]>
> CC: [email-masked]
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 
> Hi Ilango,  
> 
> independent one from each other, and favour this is strongly recommended.. 
> 
> is not appropriated here..  
> 
> It is possible to design options, including any security options, with these constraints.  We don't see a reason to change this requirement that may have unintended consequences. 
> 
> Comment 2: 
> 
> NEW 
> Security Consideration 
> 
> <Ilango> The challenge is, you are asking to impose requirements that is not supported by Geneve architecture. Geneve has an optional feature where transit devices may be able to interpret Geneve options. However this is not a requirement for Geneve operation between tunnel end point to tunnel end point. We have tried make this very clear by adding clarifying text during the last two revisions. If the Geneve packet is in the clear then transit devices may be able to view the Genve header, options, and the payload. However if the packet is encrypted then transit devices cannot view the packet contents. This is consistent with other transport protocols encrypting the packets. So we don't see a reason why Geneve should be different.    
> 
> So we don't see a good reason to add the suggested text above. 
> 
> FROM: Daniel Migault [mailto:[email-masked]] 
> SENT: Saturday, March 2, 2019 8:49 AM
> TO: Bocci, Matthew (Nokia - GB) <[email-masked]>
> CC: [email-masked]; Pankaj Garg <pankajg=[email-masked]>; NVO3 <[email-masked]>
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 
> Hi Matt, 
> 
> FROM: Dacheng Zhang <[email-masked]> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked]>
> DATE: Friday, 1 March 2019 at 16:24
> TO: Daniel Migault <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, Pankaj Garg <pankajg=[email-masked]>, NVO3 <[email-masked]>
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 
> Daniel 
> 
> FROM: Daniel Migault <[email-masked]>
> DATE: Friday, 1 March 2019 at 16:11
> TO: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
> CC: Pankaj Garg <pankajg=[email-masked]>, "[email-masked]" <[email-masked]>, NVO3 <[email-masked]>
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 
> Hi Matthew,  
> 
> FROM: Daniel Migault <[email-masked]>
> DATE: Friday, 1 March 2019 at 03:06
> TO: Pankaj Garg <pankajg=[email-masked]>
> CC: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <[email-masked]>, "[email-masked]" <[email-masked]>
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 
> Hi,  
> 
> [1] https://mailarchive.ietf..org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o [1] 
> 
> FROM: Bocci, Matthew (Nokia - GB) <[email-masked]> 
> SENT: Tuesday, October 9, 2018 2:08 AM
> TO: NVO3 <[email-masked]>
> CC: [email-masked]
> SUBJECT: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt 
> 

Links:
------
[1]

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 12:18:26 -0400

I agree that would be better, however I do not have a clear idea on what
could qualify as an exception. I see security as such an exception, but I
cannot say for sure that is the only exception. My concern was that the
previous text prevent such security extensions. The current text address
that concern. I am happy to hear how we could do better.
Yours,
Daniel

On Wed, Apr 3, 2019 at 11:44 AM Joe Touch <[email-masked]> wrote:

> I.e., the point isn't whether you have exceptions - you will. The point is
> to specify how those cases work, in which case you don't need the SHOULD
> NOT.
>
> Joe
>
>
>
>> even if it isn't encrypted). It also undermines the ability to have options
>> We updated the draft to restate the requirement on options processing,
>> the revised text is much simpler, provides better clarity, and retains the
>> these constraints.  We don't see a reason to change this requirement that
>> encrypting the packets. So we don't see a reason why Geneve should be
>> different.
>>
>> Pankaj Garg <pankajg=[email-masked]>, NVO3 <[email-masked]
>> >
>> [email-masked]" <[email-masked]>, NVO3
>> <[email-masked]>
>> https://mailarchive.ietf..org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o
>> <https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o>
>> [2]
>> *From:* Bocci, Matthew (Nokia - GB) <[email-masked]
>> <[email-masked]>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Apr 2019 09:47:23 -0700

FYI, I provided suggestions in my initial post: 

- MUST process in-order 

- MUST not depend on information in earlier options, in the order they
are proceessed 

If you have some other reason for SHOULD NOT depend on option contents
or payload contents, they that's a separate issue. I.e., if you retain
that SHOULD NOT, it would be useful to indicate authentication,
encryption, and integrity checks as possible exceptions. 

Joe

On 2019-04-03 09:18, Daniel Migault wrote:

> I agree that would be better, however I do not have a clear idea on what could qualify as an exception. I see security as such an exception, but I cannot say for sure that is the only exception. My concern was that the previous text prevent such security extensions. The current text address that concern. I am happy to hear how we could do better.  
> Yours, 
> Daniel 
> 
> FWIW, IMO SHOULD NOT needs to come with a description of what would qualify as an exception. 
> 
> However, you can't allow two such exceptions UNLESS they're deconflicted, i.e., who goes first. That never works well in practice because every new option says "I come first". 
> 
> I.e., the point isn't whether you have exceptions - you will. The point is to specify how those cases work, in which case you don't need the SHOULD NOT. 
> 
> Joe
> 
> FROM: Daniel Migault [mailto:daniel.migault@ericsson..com] 
> is an option that authenticates the full IP packet.. ESP 
> 
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08..txt 
> 
> Hi Matthew,  
> 
> could be reasonably read as the text is fine.. 
> 
> SUBJECT: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08..txt 
> 
> Hi,  
> 
> https://www.ietf.org/mailman/listinfo/nvo3 [2] 
> https://www.ietf.org/mailman/listinfo/nvo3 [2]

Links:
------
[1]
https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o
[2] https://www.ietf..org/mailman/listinfo/nvo3

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Apr 2019 16:53:19 +0000

If the text mentions that options  for authentication, encryption, and integrity checks are exceptions to these rules. I am fine as well.
Yours,
Daniel

From: Joe Touch <[email-masked]>
Sent: Wednesday, April 03, 2019 6:47 PM
To: Daniel Migault <[email-masked]>
Cc: FY"Ganga, Ilango S" <[email-masked]>; NVO3 <[email-masked]>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - geneve options

- MUST process in-order

- MUST not depend on information in earlier options, in the order they are proceessed

If you have some other reason for SHOULD NOT depend on option contents or payload contents, they that's a separate issue. I.e., if you retain that SHOULD NOT, it would be useful to indicate authentication, encryption, and integrity checks as possible exceptions.

Joe

On Wed, Apr 3, 2019 at 11:44 AM Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

Joe

Yours,
Daniel

On Tue, Apr 2, 2019 at 11:36 PM Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all,

Joe

On Mar 26, 2019, at 10:30 PM, Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> wrote:

Hi Daniel,

Revised text:

Thanks
Ilango

From: Daniel Migault [mailto:daniel.migault@ericsson..com<mailto:[email-masked]>]
Sent: Wednesday, March 20, 2019 1:56 PM
To: Ganga, Ilango S <[email-masked]<mailto:[email-masked]>>
Cc: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - geneve options

Hi,

Yours,
Daniel

On Fri, Mar 8, 2019 at 9:44 PM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours,
Daniel

On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Thanks,
Ilango

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Daniel Migault
Sent: Monday, March 4, 2019 9:15 AM
To: Ganga, Ilango S <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi Ilango,

-- comment 1:

<Ilango>

-- comment 2:

<Ilango>

Yours,
Daniel

On Sat, Mar 2, 2019 at 8:18 PM Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

Comment 1:
OLD

NEW

<Ilango>

Comment 2:

NEW
Security Consideration

<Ilango>

Thanks,
Ilango

From: Daniel Migault [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 2, 2019 8:49 AM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Pankaj Garg <pankajg=[email-masked]<mailto:[email-masked]>>; NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi Matt,

Yours,
Daniel

On Fri, Mar 1, 2019 at 11:51 AM Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
WG, Daniel,

Matthew

From: Dacheng Zhang <[email-masked]<mailto:[email-masked]>> on behalf of "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2019 at 16:24
To: Daniel Migault <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pankaj Garg <pankajg=[email-masked]<mailto:[email-masked]>>, NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Daniel

Matthew

From: Daniel Migault <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2019 at 16:11
To: "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Cc: Pankaj Garg <pankajg=[email-masked]>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08..txt

Hi Matthew,

"""

OLD

NEW

NEW
Security Consideration

Yours,
Daniel

On Fri, Mar 1, 2019 at 6:03 AM Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel

Matthew

From: Daniel Migault <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2019 at 03:06
To: Pankaj Garg <pankajg=[email-masked]>
Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>, NVO3 <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08..txt

Hi,

"""

Yours,
Daniel

[1] https://mailarchive.ietf..org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o<https://mailarchive.ietf.org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o>
[2] https://mailarchive.ietf.org/arch/msg/nvo3/e7YHFlqIuOwIJoL2ep7jyHIrSGw
[3] https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-07
[4] https://tools.ietf.org/html/draft-mglt-nvo3-geneve-security-requirements-05

On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg <pankajg=[email-masked]<mailto:[email-masked]>> wrote:
I am not aware of any IP related to draft-ietf-nvo3-geneve which has not already been disclosed.

Thanks
Pankaj

From: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 9, 2018 2:08 AM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Regards

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

_______________________________________________
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

---

From: Jesse Gross <[email-masked]>
Date: Tue, 9 Apr 2019 22:06:58 -0700

Joe,

The current text:

One of the goals of this text is to enable parallel processing, so
mandating in-order processing changes the meaning. We believe “SHOULD
NOT” accurately captures the intent by describing the general rule and
the guiding principle - options are intended to be self-descriptive &
independent. We do not want to limit the scope of what options can do
in the future or what kind of options can be specified by listing
exceptions.  Processing of authentication, encryption, etc. is allowed
and would yield correct behavior with the current text.

Jesse

On Wed, Apr 3, 2019 at 9:47 AM Joe Touch <[email-masked]> wrote:
>>> From: Daniel Migault [mailto:daniel.migault@ericsson..com]
>>> [1] https://mailarchive.ietf..org/arch/msg/nvo3/RFFjYHAUUlMvOsYwRNtdOJOIk9o
>>> From: Bocci, Matthew (Nokia - GB) <[email-masked]>