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