Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices
Daniel Migault <daniel.migault@ericsson.com> Wed, 27 March 2019 18:38 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFEF12035D for <nvo3@ietfa.amsl.com>; Wed, 27 Mar 2019 11:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbMQk91ty-gt for <nvo3@ietfa.amsl.com>; Wed, 27 Mar 2019 11:38:20 -0700 (PDT)
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C257120354 for <nvo3@ietf.org>; Wed, 27 Mar 2019 11:38:19 -0700 (PDT)
Received: by mail-lf1-f45.google.com with SMTP id y18so12222416lfe.1 for <nvo3@ietf.org>; Wed, 27 Mar 2019 11:38:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ko7TgfMtHWzKBS8EMeEmrTXEsJ3UOnbVEqRx9uyf3jg=; b=KK9XujfBQHprK9E0EE9uKaU1BNJxphi8RcIJKeTBU5U4tAGYXTcPqly723DiniX6sl aLEuwJqzi504EUMCgKNnqurZCzMPy2RWc8TRJfztxxiza2zk+wiBCwno133hk/pkCfQ+ gwlNOkdhGDm4jhfBwCR0yjwP6Z2bmSxORvpvPtxufh0KcDE1X421ib6etmjzDsb+xioZ w56Pry1x+vzUYo0fYo1T1qCMwEUa22zKEtWTUZsS+TBc3x/DKZWP2AAtMqnQ/x9Z+76+ kv1feY1sZRrk5sSQt+werAzLJiZtyT+ho7ZuFjy65PudBZB7Jznb4pE1XQ4srqdftROH 35XA==
X-Gm-Message-State: APjAAAUAsC2rj/DLjrEX0p2Jn6g7PaQfKKqD7CDuM/NAVmmXLQryW9Oc QakCPJTxYUH18BEftC4aNV8ZzvsL+G2lBKZFMcQ=
X-Google-Smtp-Source: APXvYqxEcRZWd7E0Da0BHvxVMoP9MuFjhOBhRBudJBXRBRsciBgTv+nXYqqpchcZW28jfHiCwTKcn2yug4NHTzlGBG0=
X-Received: by 2002:ac2:514a:: with SMTP id q10mr19179996lfd.17.1553711897387; Wed, 27 Mar 2019 11:38:17 -0700 (PDT)
MIME-Version: 1.0
References: <C35AB375-99DA-4629-8D67-D8991FF69434@nokia.com> <MWHPR21MB01917E5CF224896CE3B49552B9750@MWHPR21MB0191.namprd21.prod.outlook.com> <CADZyTkmTZkkCQ-r4PcwuzYnevAQkq=iXPatG7LgMFKZ8Z59zdA@mail.gmail.com> <97EAAD15-1A6C-4EBD-92A2-2FCFAC89AC62@nokia.com> <CADZyTkmASuuKX_oHXsBdHoGhyk+uAHeag0v3O_j=GLBYcD5KJA@mail.gmail.com> <1F82320E-5CBC-47D1-968F-6EA58D776A17@nokia.com> <6528AF40-D971-4496-8963-7540C5DDE650@nokia.com> <CADZyTkk=zGKCYGkXyUYEVTBm2TKg_cy8HjcDSnySiP8BveNC+A@mail.gmail.com> <C5A274B25007804B800CB5B289727E35904EDDA6@ORSMSX111.amr.corp.intel.com> <CADZyTkkU=ThA0q6aq_gtFq2oxqPX29JsCNqFa5q=qWmM0aLqfg@mail.gmail.com> <C5A274B25007804B800CB5B289727E35904F15A3@ORSMSX111.amr.corp.intel.com> <CADZyTknO3-WiODFDgZHUcYymD93-mM=sSK7uDjYKuikNr-dR8A@mail.gmail.com> <C5A274B25007804B800CB5B289727E3590501F1E@ORSMSX116.amr.corp.intel.com> <CADZyTkmawz68h+4HnHEfpnZHZ_3z8dMJ9kWc6=kNMRozvw9FPA@mail.gmail.com> <C5A274B25007804B800CB5B289727E359050DA74@ORSMSX116.amr.corp.intel.com>
In-Reply-To: <C5A274B25007804B800CB5B289727E359050DA74@ORSMSX116.amr.corp.intel.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 27 Mar 2019 14:38:04 -0400
Message-ID: <CADZyTkkkEjhecDCcn87VD9tA+qjE2JS+9GoXaT=XkutKoJnqPA@mail.gmail.com>
To: "Ganga, Ilango S" <ilango.s.ganga@intel.com>
Cc: NVO3 <nvo3@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba275a058517bd9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/b8rKwwml_6R0jvbDypQ5RQIZm3A>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt - transit devices
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 18:38:27 -0000
Hi Illango, Unless i am missing something, I am unclear how the text you provide answers the questions/concerns, so perhaps you could elaborate and maybe be a bit more specific. My first concern was the use case you envision transit devices. The transit device are supposed to read some Geneve options and process them. I expected you provided some example of options as well as some processing. My second concern was how the draft version 12 addresses a concrete deployment. As a reminder here is the scenario mentioned is below. The question is how the draft secures such a deployment. The basic scenario could be a Geneve deployment that processes options O_i ( i in [1,,n]) in the NVE and that process option P_j [1, m] in the Transit devices. While unprotected O_i and P_j are processed. Securing the deployment with DTLS prevents options P_j to be processed. Yours, Daniel On Wed, Mar 27, 2019 at 2:11 PM Ganga, Ilango S <ilango.s.ganga@intel.com> wrote: > Hi Daniel, > > > > We will try to explain the transit devices and example use cases again. > Hopefully this clarifies your question. > > > > >The transit devices seems to me problematic, but maybe I am not really > > >catching what is their intent. I might be helpful if you could provide > > >some behaviour the transit devices is expected to implement. Typically > > >what are the use cases for these transit devices? > > Transit devices exist in the underlay network, these are simply forwarding > elements (e.g. switches, routers) that generally forward packets based on > outer header information, there is nothing that stops such devices from > reading or interpreting the contents. At present, this works with any > transport protocols (encapsulated or non-encapsulated), for example, IP, IP > in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, etc. For example, routers > (transit device) 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 will 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 either unable to, or does not need to interpret the Geneve header > (which may or may not include options), it simply uses 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. > > Thanks, > > Ilango > > > > > > *From:* Daniel Migault [mailto:daniel.migault@ericsson.com] > *Sent:* Wednesday, March 20, 2019 1:58 PM > *To:* Ganga, Ilango S <ilango.s.ganga@intel.com> > *Cc:* NVO3 <nvo3@ietf.org> > *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for > draft-ietf-nvo3-geneve-08.txt - transit devices > > > > Hi, > > > > I am looking at the version 12 and see how it address my concern, > > regarding the transit devices and the compatibility with end to end > > security. Could you please point out how the text address this concern ? > > > > The basic scenario could be a Geneve deployment that processes options > > O_i ( i in [1,,n]) in the NVE and that process option P_j [1, m] in the > > Transit devices. While unprotected O_i and P_j are processed. Securing > > the deployment with DTLS prevents options P_j to be processed. I am > > unclear how the version 12 address this concern. > > > > The transit devices seems to me problematic, but maybe I am not really > > catching what is their intent. I might be helpful if you could provide > > some behaviour the transit devices is expected to implement. Typically > > what are the use cases for these transit devices? > > > > <Response> > > Transit devices exist 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 or interpreting the contents. At present, this works with any > transport protocols (encapsulated or non-encapsulated), for example, IP, IP > in IP, GRE, VXLAN, MPLS in UDP, GRE-in-UDP, 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 will 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 either unable to, or don’t have the option to interpret the > header or option, it simply uses 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. > For example, if a middle box has a need to see an encrypted packet, then it > has to implement tunnel endpoint functionality. > > </end of response> > > > > Yours, > > Daniel > > > > > > On Mon, Mar 11, 2019 at 7:20 PM Ganga, Ilango S <ilango.s.ganga@intel.com> > wrote: > > Hi Daniel, > > > > We posted a new version of the draft that we believe addresses your > comment on options processing. > > We have already provided clarification on the role transit devices as > noted in this thread below. > > > > Thanks, > Ilango > > > > > > *From:* Daniel Migault [mailto:daniel.migault@ericsson.com] > *Sent:* Friday, March 8, 2019 6:51 PM > *To:* Ganga, Ilango S <ilango.s.ganga@intel.com> > *Cc:* NVO3 <nvo3@ietf.org> > *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for > draft-ietf-nvo3-geneve-08.txt - transit devices > > > > Hi, > > > > Thanks for the comment. Let me first recap my perception of the > > discussion. My comment was that end-to-end security (IPsec, DTLS) does > > not apply to Geneve with transit device. Your previous response was that > > Geneve was an end-to-end protocol since transit device are optional. My > > response was that an architecture that defines elements even optional > > that interfere between the two end points contradicts the status of > > end-to-end protocol. At that time my understanding was that the > > specification was targeting an end-to-end protocol, with transit devices > > with very limited capabilities. Thus I proposed to removed the transit > > devices from the architecture. These would have been a great step toward a > > end-to-end architecture. However, from the current response, it > > seems that transit device play an important part in the architecture, and > > we are moving backward from the end-to-end protocol. As > > a result, there is - in my opinion to make a coherent choice to make > > between Geneve architecture and the security associated. This is > > currently very unclear and contradicting - at least to me reading of the > > geneve specification and the responses I receive to my comments.. > > > > My understanding of your latest response - and please correct me > > if I am wrong - is that transport protocols like IP, > > IP in IP, GRE or VXLAN among others are used to an architecture with > > transit nodes. These latter examples show that end-to-end security is > > incompatible with Geneve and that security in Geneve MUST be handled > > using options. In addition, these examples seems - up to my > > understanding - to challenge the optional status of the transit device > > as well as their ability to read-only does not always seems realistic. > > > > Overall, my impression is that Genve is not an end-to-end protocol, > > end-to-end security protocols such as DTLS or IPsec do not apply > > realistically. The alternative approach of using option is also > > compromised by the current specification of Geneve as well as by > > security documents being opposed. Geneve seems mandated to be unsecured. > > > > > > IP is the first protocol you cite. IP enables end-to-end security with > > IPsec. However there are a few major difference between IPsec and secure > > Geneve communications. > > 1. - IPsec leave in clear the information that > > need to be read in transit. This is not the case with Geneve over DTLS > > or IPsec as even the Geneve Header is encrypted. If we want this > > information to be accessible to transit device security must be handled > > by geneve security option in order to leave the header in clear text. > > 2. IPsec/ESP versus IPsec/AH clearly shows that transit elements do not > > restrict from reading the options. As a result, the transit device are > > likely to evolve and become more active in the future. As a result, the > > security MUST consider this in early stage and I do not see that met. > > > > > > Yours, > > Daniel > > > > On Wed, Mar 6, 2019 at 9:33 PM Ganga, Ilango S <ilango.s.ganga@intel.com> > wrote: > > Hi Daniel, > > > > Please see my responses inline below. > > > > Thanks, > > Ilango > > > > > > *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Daniel Migault > *Sent:* Monday, March 4, 2019 9:15 AM > *To:* Ganga, Ilango S <ilango.s.ganga@intel.com> > *Cc:* nvo3@ietf.org > *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 <ilango.s.ganga@intel.com> > 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:daniel.migault@ericsson.com] > *Sent:* Saturday, March 2, 2019 8:49 AM > *To:* Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> > *Cc:* draft-ietf-nvo3-geneve@ietf.org; Pankaj Garg <pankajg= > 40microsoft.com@dmarc.ietf.org>; NVO3 <nvo3@ietf.org> > *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) < > matthew.bocci@nokia.com> 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 <nvo3-bounces@ietf.org> on behalf of "Bocci, > Matthew (Nokia - GB)" <matthew.bocci@nokia.com> > *Date: *Friday, 1 March 2019 at 16:24 > *To: *Daniel Migault <daniel.migault@ericsson.com> > *Cc: *"draft-ietf-nvo3-geneve@ietf.org" <draft-ietf-nvo3-geneve@ietf.org>, > Pankaj Garg <pankajg=40microsoft.com@dmarc.ietf.org>, NVO3 <nvo3@ietf.org> > *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 <daniel.migault@ericsson.com> > *Date: *Friday, 1 March 2019 at 16:11 > *To: *"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> > *Cc: *Pankaj Garg <pankajg=40microsoft.com@dmarc.ietf.org>, " > draft-ietf-nvo3-geneve@ietf.org" <draft-ietf-nvo3-geneve@ietf.org>, NVO3 < > nvo3@ietf.org> > *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) < > matthew.bocci@nokia.com> 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 <daniel.migault@ericsson.com> > *Date: *Friday, 1 March 2019 at 03:06 > *To: *Pankaj Garg <pankajg=40microsoft.com@dmarc.ietf.org> > *Cc: *"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, NVO3 < > nvo3@ietf.org>, "draft-ietf-nvo3-geneve@ietf.org" < > draft-ietf-nvo3-geneve@ietf.org> > *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= > 40microsoft.com@dmarc.ietf.org> 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) <matthew.bocci@nokia.com> > *Sent:* Tuesday, October 9, 2018 2:08 AM > *To:* NVO3 <nvo3@ietf.org> > *Cc:* draft-ietf-nvo3-geneve@ietf.org > *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 > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >
- [nvo3] Working Group Last Call and IPR Poll for d… Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Working Group Last Call and IPR Poll f… T. Sridhar
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… T. Sridhar
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jon Hudson
- Re: [nvo3] Working Group Last Call and IPR Poll f… Anoop Ghanwani
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Anoop Ghanwani
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Tal Mizrahi
- Re: [nvo3] Working Group Last Call and IPR Poll f… Chris Wright
- Re: [nvo3] Working Group Last Call and IPR Poll f… Dinesh Dutt
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Greg Mirsky
- Re: [nvo3] Working Group Last Call and IPR Poll f… Pankaj Garg
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Working Group Last Call and IPR Poll f… Bocci, Matthew (Nokia - GB)
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Joel M. Halpern
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Joel Halpern Direct
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Ganga, Ilango S
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross
- Re: [nvo3] Working Group Last Call and IPR Poll f… Joe Touch
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Joe Touch
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Joe Touch
- Re: [nvo3] Working Group Last Call and IPR Poll f… Daniel Migault
- Re: [nvo3] Working Group Last Call and IPR Poll f… Jesse Gross