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

[Daniel Migault <[e-mail]>]

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
>