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

["Ganga, Ilango S" <[e-mail]>]

Hi Joel,

Joel- Thanks for your comment.  Though the behavior is not explicitly specified, it could be inferred from the description in sections 3.5.1 and 6.4.  However, we take your point, we could explicitly specify the behavior of transit devices handling for encrypted packets. We have the following proposed text to address your comment. Please let us know if you are fine with it.

------------------
Change 3.5.1 as follows:
Transit devices not interpreting Geneve
   headers (that may or may not include Options) <substitute/SHOULD/>  MUST handle Geneve
   packets as any other UDP packet and maintain consistent forwarding
   behavior.

Insert proposed text to section 6.4 at the end of the following sentence:
However, if the packet is protected by tunnel
   endpoint to tunnel endpoint encryption, for example through IPsec,
   transit devices will not have visibility into the Geneve header or
  options in the packet. <Insert> In such cases transit devices MUST handle Geneve packets as any other UDP packet and maintain consistent forwarding behavior.</Insert>
-------------------

Thanks,
Ilango


-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Wednesday, March 6, 2019 6:48 PM
To: Ganga, Ilango S <[e-mail]>; Daniel Migault <[e-mail]>
Cc: NVO3 <[e-mail]>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Regarding Geneve and Transit Devices, to my reading there is an issue.

The Geneve document, by describing transit behavior indicates that devices wishing to perform these operations can expect to be able to do so.
End-to-end encryption means that intermediate devices can not do so.

One way out I think can work is to explicitly note in the description of transit device behaviors that such devices MUST allow for encryption such that inspection is not possible.
Another way out that seems to work is to not describe Transit devices inspection at all.  Simply state that intermediate devices MUST not modify the Geneve header or its extensions.  If Transit inspection is not something we need to standardize, then don't.

The current wording does not do either of these things, creating apparent inconsistency.

Yours,
Joel

On 3/6/19 9:33 PM, Ganga, Ilango S wrote:
> Hi Daniel,
> 
> Please see my responses inline below.
> 
> Thanks,
> 
> Ilango
> 
> *From:*nvo3 [mailto:[e-mail]] *On Behalf Of *Daniel 
> Migault
> *Sent:* Monday, March 4, 2019 9:15 AM
> *To:* Ganga, Ilango S <[e-mail]>
> *Cc:* [e-mail]
> *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 
> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Saturday, March 2, 2019 8:49 AM
>     *To:* Bocci, Matthew (Nokia - GB) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>; Pankaj Garg
>     <pankajg=[e-mail]
>     <mailto:[e-mail]>>; NVO3 <[e-mail]
>     <mailto:[e-mail]>>
>     *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)
>     <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> on behalf of "Bocci, Matthew
>         (Nokia - GB)" <[e-mail]
>         <mailto:[e-mail]>>
>         *Date: *Friday, 1 March 2019 at 16:24
>         *To: *Daniel Migault <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc: *"[e-mail]
>         <mailto:[e-mail]>"
>         <[e-mail]
>         <mailto:[e-mail]>>, Pankaj Garg
>         <pankajg=[e-mail]
>         <mailto:[e-mail]>>, NVO3 <[e-mail]
>         <mailto:[e-mail]>>
>         *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 <[e-mail]
>         <mailto:[e-mail]>>
>         *Date: *Friday, 1 March 2019 at 16:11
>         *To: *"Bocci, Matthew (Nokia - GB)" <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc: *Pankaj Garg <pankajg=[e-mail]
>         <mailto:[e-mail]>>,
>         "[e-mail]
>         <mailto:[e-mail]>"
>         <[e-mail]
>         <mailto:[e-mail]>>, NVO3 <[e-mail]
>         <mailto:[e-mail]>>
>         *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)
>         <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>             <mailto:[e-mail]>>
>             *Date: *Friday, 1 March 2019 at 03:06
>             *To: *Pankaj Garg <pankajg=[e-mail]
>             <mailto:[e-mail]>>
>             *Cc: *"Bocci, Matthew (Nokia - GB)" <[e-mail]
>             <mailto:[e-mail]>>, NVO3 <[e-mail]
>             <mailto:[e-mail]>>, "[e-mail]
>             <mailto:[e-mail]>"
>             <[e-mail]
>             <mailto:[e-mail]>>
>             *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-requiremen
> ts-05
> 
>             On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg
>             <pankajg=[e-mail]
>             <mailto:[e-mail]>> 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)
>                 <[e-mail] <mailto:[e-mail]>>
>                 *Sent:* Tuesday, October 9, 2018 2:08 AM
>                 *To:* NVO3 <[e-mail] <mailto:[e-mail]>>
>                 *Cc:* [e-mail]
>                 <mailto:[e-mail]>
>                 *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 26^th October.
> 
>                 Regards
> 
>                 Matthew and Sam
> 
>                 _______________________________________________
>                 nvo3 mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/nvo3
> 
>             _______________________________________________
>             nvo3 mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/nvo3
> 
>         _______________________________________________
>         nvo3 mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/nvo3
> 
>     _______________________________________________
>     nvo3 mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/nvo3
> 
> 
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>