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

[Daniel Migault <[e-mail]>]

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

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