Hi Daniel,
Please see my responses inline below.
Thanks,
Ilango
*From:*nvo3 [mailto:[email protected]] *On Behalf Of *Daniel Migault
*Sent:* Monday, March 4, 2019 9:15 AM
*To:* Ganga, Ilango S <[email protected]>
*Cc:* [email protected]
*Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
draft-ietf-nvo3-geneve-08.txt
Hi Ilango,
Thanks for the response. Please see a concrete example to illustrate my
concern
for comment 1. For comment 2, it really helped you indicated that Geneve
is expected
to be an end-to-end protocol. This will help me update the security
requirement
document. However, the current Geneve specification with transit devices
seems -
at least to me - to raise an architecture concern as raised in [1].
-- comment 1:
Thanks for the feed back. I understand the purpose of keeping option
independent one from each other, and favour this is strongly recommended.
However, I am not convinced this applies always. More specifically, in a
context of security, the purpose of a security option may be related to
another option. Typically, a security option providing authentication or
encryption is potentially authenticating/encryption another option or
other information contained in the header.
The typical scenario I have in mind would be an authentication option A
authenticating option O. There will clearly some dependencies between A
and O as O could only be used if A has been primarily been validated.
The current statement "SHOULD NOT be dependent" enables this. However, I
have concerns regarding the statement "MUST NOT affect the parsing or
interpretation". In fact, the output of A, will determine if O should be
dropped or processed normally. In case A shows O is not appropriately
authenticated, O might be rejected based on its C value. The ambiguity I
see is that A can be understood as affecting the parsing and
interpretation of O or as a pre-processing operation before parsing or
interpretation of O.
I think, the text needs further clarifications to remove such ambiguity.
Changing MUST NOT by SHOULD NOT was of course only one proposition and
this could be also addressed otherwise. It might be better, I agree, to
explicitly mention that some options may provide condition on the
parsing of the options. This would leave the parsing of the options
unchanged.
<Ilango>
If I understand your example correctly, you want to have one option
authenticate the contents of another option and if that authentication
fails, drop the option. This would not drop the entire packet unless
that option is critical. Can you give a use case for this? This seems
unusual and not something that is supported by other security protocols
such as IPsec or TLS to the best of our knowledge.
I believe a more common outcome of a failed authentication is that the
entire packet would be dropped. As previously noted, the current text
does not preclude this. It seems like going beyond this would result in
significant complexity, both for processing options in this specific
case as well as the possibility of introducing ambiguity in how other
options might be defined or processed as an unintended consequence.
Without a strong use case, this does not seem desirable.
</>
-- comment 2:
Thanks for the response that clarifies a bit my understanding of the
transit devices.. I believe the issue I have is related to the transit
devices which I do not see, unless I am wrong, meeting the requirements
for being OPTIONAL and that seems - at least to me - contradicting the
status of end-to-end protocol. As suggested in [1], transit devices seem
to raise
architectural concerns that is not needed.
You are correct that the text is clear that transit devices are
OPTIONAL. However, my understanding of OPTIONAL from 2119 is that there
are two sides of it. One is that a vendor may implement it or not, but
the other side is that interoperability with other implementations are
not affected. In this case, two Geneve endpoints using TLS or IPsec will
not be able to interoperate with an implementation based on transit
devices (unless the process being performed by the transit devices is
also performed by the NVE). In that sense, I believe OPTIONAL statement
is not appropriated here.
An implementation with transit devices seems to prevent the
interoperability of with an implementation where options are treated
by the NVE over a secure channel. If we suppose that NVE and
transit devices support the same options, then transit devices are not
necessary and could be removed from the specification. If options
supported by transit devices are different from those supported by
the NVE, interoperability will not be achieved. Transit device will not be
able to process the options, resulting in options will be ignored (while
being supported by the implementation).. In addition, if the options
are critical, the NVE is likely to drop the packet as it does not support
the option.
In addition, I have some hard time to understand the end-to-end model
with a transit device even optional. I believe that end-to-end protocol
is a good path, though. However, my understanding of end-to-end protocol
is that they should only involve two end points. I see the NVE as end
points but the optional transit device does not seems to be one of
these. However, to help me understand better this, as it seems Geneve is
similar to other end-to-end protocol, maybe you could provide similar
end-to-end protocol that involves a transit devices or something similar.
I also have another clarification regarding transit device. I see these
transit devices as adding a lot of complexity to the end-to-end model
with little benefits. Typically, as far as I understand, they can only
read an option. I am thus wondering whether we should not be better off
removing them from the specification. This would end up with a clear
end-to-end model. Reversely, I do not see anything preventing a vendor
to implement them at least for unsecure deployments. Removing them
from the specification would leave the transit devices as implementation
specific. What are actually the benefits of the transit devices that would
justify them to be part of the specification?
<Ilango>
Transit devices exists in the underlay network, these are simply
forwarding elements (e.g. switches, routers) that generally forwards
packets based on outer header information, there is nothing that stops
such devices from reading the contents if the data is in the clear.
This works with any transport protocols like IP, IP in IP, GRE, VXLAN,
etc. For example, routers may look at headers and/or inner payload for
ECMP purposes or for statistics or logging purposes. If the packet is
encrypted then such transit devices cannot look into the packets but
would simply forward based on the outer headers and use information in
outer headers for entropy. There is no interoperability issue between
the endpoints. Geneve is no different.
Recognizing the fact that such a device is anyway going to exist in the
network, Geneve draft provides guidance on how to handle Geneve headers
(if a device has the option to do so). Geneve options are part of
Geneve header, a transit device that is capable of interpreting Geneve
headers may interpret an option or skip over the option to view the
payload, etc. If a transit device is not able interpret the header or
option, it has to simply use the outer header to forward the packet
(outer IP/UDP). This is what the Geneve draft clarifies.
These guidelines reduce possible interoperability issues compared to if
behavior was left undefined. For example, transit devices are not
allowed to drop packets or fall back to a slow path on the basis of an
unknown option. If this were to happen, it would hamper the introduction
of new options. It might also be worth mentioning that anything that
could be considered a middlebox is not a transit device but needs to be
modeled as an endpoint and so Geneve really should be viewed as a tunnel
endpoint-to-endpoint protocol.
<end>
[1] https://mailarchive.ietf.org/arch/msg/nvo3/ekLofhq8erRLE_Msuk8N_SCdhcs
Yours,
Daniel
On Sat, Mar 2, 2019 at 8:18 PM Ganga, Ilango S <[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[email protected]>]
*Sent:* Saturday, March 2, 2019 8:49 AM
*To:* Bocci, Matthew (Nokia - GB) <[email protected]
<mailto:[email protected]>>
*Cc:* [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
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 26^th 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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
