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) < [email protected]> 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 <[email protected]> on behalf of "Bocci, > Matthew (Nokia - GB)" <[email protected]> > *Date: *Friday, 1 March 2019 at 16:24 > *To: *Daniel Migault <[email protected]> > *Cc: *"[email protected]" <[email protected]>, > Pankaj Garg <[email protected]>, NVO3 <[email protected]> > *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 <[email protected]> > *Date: *Friday, 1 March 2019 at 16:11 > *To: *"Bocci, Matthew (Nokia - GB)" <[email protected]> > *Cc: *Pankaj Garg <[email protected]>, " > [email protected]" <[email protected]>, NVO3 < > [email protected]> > *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) < > [email protected]> 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 <[email protected]> > *Date: *Friday, 1 March 2019 at 03:06 > *To: *Pankaj Garg <[email protected]> > *Cc: *"Bocci, Matthew (Nokia - GB)" <[email protected]>, NVO3 < > [email protected]>, "[email protected]" < > [email protected]> > *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= > [email protected]> 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) <[email protected]> > *Sent:* Tuesday, October 9, 2018 2:08 AM > *To:* NVO3 <[email protected]> > *Cc:* [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
