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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> 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
>
> *From:* Daniel Migault [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, March 20, 2019 1:56 PM
> *To:* Ganga, Ilango S <[e-mail]>
> *Cc:* NVO3 <[e-mail]>
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt - geneve options
>
> Hi,
>
> I am looking at the version 12 and see how it address my concern,
> regarding the integration of security options.
>
> The new text in version 12 mentions:
> """
>    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.  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 <[e-mail]>
> 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
>
>
> On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <[e-mail]>
> 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]>
> 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]]
> *Sent:* Saturday, March 2, 2019 8:49 AM
> *To:* Bocci, Matthew (Nokia - GB) <[e-mail]>
> *Cc:* [e-mail]; Pankaj Garg <pankajg=
> [e-mail]>; NVO3 <[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]> 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]> on behalf of "Bocci,
> Matthew (Nokia - GB)" <[e-mail]>
> *Date: *Friday, 1 March 2019 at 16:24
> *To: *Daniel Migault <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>,
> Pankaj Garg <pankajg=[e-mail]>, NVO3 <[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]>
> *Date: *Friday, 1 March 2019 at 16:11
> *To: *"Bocci, Matthew (Nokia - GB)" <[e-mail]>
> *Cc: *Pankaj Garg <pankajg=[e-mail]>, "
> [e-mail]" <[e-mail]>, NVO3 <
> [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]> 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]>
> *Date: *Friday, 1 March 2019 at 03:06
> *To: *Pankaj Garg <pankajg=[e-mail]>
> *Cc: *"Bocci, Matthew (Nokia - GB)" <[e-mail]>, NVO3 <
> [e-mail]>, "[e-mail]" <
> [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-requirements-05
>
>
>
>
>
> On Wed, Feb 27, 2019 at 7:30 PM Pankaj Garg <pankajg=
> [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]>
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <[e-mail]>
> *Cc:* [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 26th October.
>
> Regards
>
> Matthew and Sam
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>