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

[Daniel Migault <[e-mail]>]

Hi Matt,

>From my reading of [1], mentioning draft (WG or not) does not seems to
be an issue especially when these are expected to be informational. As a
result, this would enable to redirect to text that is more appropriated and
thus, in my opinion, enhance the quality of the current specification.

I see neither my comments/reviews nor the security analysis as show
stopper. Instead, the strong disagreement from some co-authors of the
Geneve specification to the security analysis seems to me a show
stopper.

In fact, the current security analysis takes as input the revised
version of Geneve and from it sets a number of requirements. If there is
a disagreement, either the analyse is incorrect, or the input is not
appropriate. Unless I am missing something, the disagreement from the
co-authors seems to indicate there is an issue, but I - and I am happy
to be proved wrong - am not able to tell if the issue comes from the
analyse or the input.

As early versions of the security considerations led to protocol changes
in the way the Geneve Options are handled by transit devices. I am
uncomfortable to say the issue is solely on the analyse side.

We are more then happy to address any concern regarding the security
analysis. So far we have answered to all comments we have received on
the mailing list, we proposed to structure the discussion with Geneve
co-author with an issue tracker [2] (Nov 7 2018), we proposed to have a
interim meeting. Based on the intent we perceived from our reading of the
security
consideration section of the newly published Geneve specification, we
provided some architectural considerations. We currently received no
feed backs from the co-authors of the Geneve since the last IETF
meeting. It is unclear whether there is other thing we can do to have a
dialogue, but I remain open to suggestions and I am happy to
collaborate.

Yours,
Daniel



[1]
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
[2]
https://github.com/mglt/draft-mglt-nvo3-geneve-security-requirements/issues
~


On Fri, Mar 1, 2019 at 11:24 AM Bocci, Matthew (Nokia - GB) <
[e-mail]> wrote:

> 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
>