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

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
I am not aware of any IP related to draft-ietf-nvo3-geneve which has not already been disclosed.

Thanks
Pankaj

From: Bocci, Matthew (Nokia - GB) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 9, 2018 2:08 AM
To: NVO3 <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

This email begins a two-week working group last call for draft-ietf-nvo3-geneve-08.txt.

Please review the draft and post any comments to the NVO3 working group list. If you have read the latest version of the draft but have no comments and believe it is ready for publication as a standards track RFC, please also indicate so to the WG email list.

We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an Author or a Contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.

Currently there are two IPR disclosures against this document.

If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll will run until Friday 26th October.

Regards

Matthew and Sam
_______________________________________________
nvo3 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nvo3