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

[Greg Mirsky <[e-mail]>]

Hi Ilango, et al.,
if I understand the text you're proposing:
Transit devices not interpreting Geneve headers (that may or may not
include Options)
   SHOULD process Geneve packets as any other UDP packet and maintain
   consistent forwarding behavior.
a transit node MAY process Geneve packets using Geneve layer information.
What are scenarios that would require such an option? How that
functionality controlled, advertised, and traceable by OAM?

Regards,
Greg

On Sun, Oct 21, 2018 at 9:22 PM Ganga, Ilango S <[e-mail]>
wrote:

> Hi Daniel,
>
>
>
> Please see my responses inline. I think this should address all your
> comments.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[e-mail]]
> *Sent:* Wednesday, October 17, 2018 7:28 AM
> *To:* Ganga, Ilango S <[e-mail]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail];
> [e-mail]; T. Sridhar <[e-mail]>
> *Subject:* RE: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi Illango,
>
>
>
> Thanks for the response, please see my comments. I believe they can be
> easily addressed in the next version.
>
>
>
> Yours,
> Daniel
>
>
>
> *From:* Ganga, Ilango S <[e-mail]>
> *Sent:* Wednesday, October 17, 2018 1:45 AM
> *To:* Daniel Migault <[e-mail]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail];
> [e-mail]; T. Sridhar <[e-mail]>
> *Subject:* RE: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi Daniel,
>
>
>
> Thanks for your review and comments. Please see my responses inline.
>
>
>
> Regards,
>
> Ilango
>
>
>
>
>
> *From:* Daniel Migault [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, October 12, 2018 2:57 PM
> *To:* Ganga, Ilango S <[e-mail]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> Hi,
>
>
>
> I reviewed the document. Please find my comments below.
>
>
>
> Yours,
>
> Daniel
>
> 3.4.  Tunnel Header Fields
>
>    C (1 bit):  Critical options present.  One or more options has the
>       critical bit set (see Section 3.5).  If this bit is set then
>       tunnel endpoints MUST parse the options list to interpret any
>       critical options.  On endpoints where option parsing is not
>       supported the packet MUST be dropped on the basis of the 'C' bit
>       in the base header.  If the bit is not set tunnel endpoints MAY
>       strip all options using 'Opt Len' and forward the decapsulated
>       packet.
> <mglt>
> I am fine with the text, but this may contradict that Opt Len is compared
> to the sum of option len. (see my comment next section). I guess that is a
> clarification to be made next section.
> </mglt>
>
> <Ilango> The text in this section reads fine; since the option header is
> defined in next section 3.5, it is appropriate to keep the text in that
> section. Also, please see response to next section.
>
> </>
>
> <mglt2>I will see the next section. </mglt2>
>
>
> 3.5.  Tunnel Options
>
>
>    Type (8 bits):  Type indicating the format of the data contained in
>       this option.  Options are primarily designed to encourage future
>       extensibility and innovation and so standardized forms of these
>       options will be defined in a separate document.
>
>       The high order bit of the option type indicates that this is a
>       critical option.  If the receiving endpoint does not recognize
>       this option and this bit is set then the packet MUST be dropped.
>       If the critical bit is set in any option then the 'C' bit in the
>       Geneve base header MUST also be set.  Transit devices MUST NOT
>       drop packets on the basis of this bit.  The following figure shows
>       the location of the 'C' bit in the 'Type' field:
>
>       0 1 2 3 4 5 6 7 8
>       +-+-+-+-+-+-+-+-+
>       |C|    Type     |
>       +-+-+-+-+-+-+-+-+
>
>       The requirement to drop a packet with an unknown critical option
> <mglt>
> maybe s/an unknown critical option/an unknown option with the critical bit
> set would be clearer.
> </mglt>
>
>
>
> <Ilango> The term critical option is described in section 3.4 and used in
> 3.5, so use of this term here to refer to an unknown critical option reads
> fine.  Though for consistency with the sentence in section 3.5.1, we could
> also say “unknown options with C-bit set”.
>
> </>
>
> <mglt2> I am fine with your proposed change. </mglt>
>
>
>       applies to the entire tunnel endpoint system and not a particular
>       component of the implementation.  For example, in a system
>       comprised of a forwarding ASIC and a general purpose CPU, this
>       does not mean that the packet must be dropped in the ASIC.  An
>       implementation may send the packet to the CPU using a rate-limited
>       control channel for slow-path exception handling.
>
>    R (3 bits):  Option control flags reserved for future use.  MUST be
>       zero on transmission and ignored on receipt.
>
>    Length (5 bits):  Length of the option, expressed in four byte
>       multiples excluding the option header.  The total length of each
>       option may be between 4 and 128 bytes.  A value of 0 in the Length
>       field implies an option with only the option header without the
>       variable option data.
>
>
>
> <mglt>
> I understand the sentence below as a check between the sum of option
> length and Opt len. This does not seems related to the treatment of one
> option, and maybe should be moved up to the description of Opt Len in the
> Geneve Header section.
>
>
>
> <Ilango> This section is where the Tunnel Options are defined hence this
> is the most appropriate and right place for this text.
>
> </>
>
>
>
> <mglt2>I am fine with that as well, as long as you believe that is the
> right place.</mglt2>
>
>
> I also have an issue on how to interpret that sentence. When receiving a
> Geneve Packet, the following sentence prevent from jumping to Opt Len
> skipping off options. It could be understood as a mandatory check in which
> case (whether there is a C bit set in the Geneve Header or not) the
> terminating node to go through all options, read the Length sum them and
> them compare it to the Opt Len. If such check is mandatory, I am wondering
> if Opt Len in the Geneve Header is then limited for internal use of the
> terminating node. If that is something optional, maybe we should explicitly
> say it, or maybe detail when such comparison is expect to happen.
> </mglt>
>
>
>
> <Ilango> No, it does not prevent the nodes from skipping the options to
> reach the start of encapsulated payload. For example a transit node that
> does not process the options can skip over the options by using the Option
> length field in the Geneve header. The endpoints that process the options
> are the ones that need to do this check as stated in this sentence.
>
> For better clarity, we could add clarifying text to the sentence as
> follows:
>
> “…. invalid and MUST be silently dropped if received by an endpoint *that
> processes the options*.”
>
> </>
>
> <mglt2>I believe that is clarifying to add the text you proposed.</mglt2>
>
>
> Packets in which the total length of all
>       options is not equal to the 'Opt Len' in the base header are
>       invalid and MUST be silently dropped if received by an endpoint.
>
>
>
>
> Gross, et al.            Expires April 10, 2019                [Page 15]
>
> Internet-Draft               Geneve Protocol                October 2018
>
>
>    Variable Option Data:  Option data interpreted according to 'Type'.
>
>
> 3.5.1.  Options Processing
>
>    Geneve options are intended to be originated and processed by tunnel
>    endpoints.  However, options MAY be interpreted by transit devices
>    along the tunnel path.  Transit devices not processing Geneve headers
> <mglt>
> I am reading Genve header as a Geneve option of the Genve header, but not
> the fixed Geneve header. If that is correct, It may be clearer to use Genve
> option instead of Geneve header as to avoid confusion on the scope of
> transit device. From the text above, using Geneve header could mean the fix
> header, in which case it may make easier to figure out  the difference
> between transit device and tunnel endpoint.
> </mglt>
>
> <Ilango> As illustrated clearly in sections 3.1 and 3.2 Geneve header
> includes fixed length headers and options. So in this statement, Geneve
> header includes options.
>
> </>
>
> <mglt2>
>
> This is I believe English clarification and English is not my native
> language, so I am only providing my feed back, but differ to others on what
> to do.
>
>
>
> The statement as I read it says that transit devices MAY interpret
> options. Which I interprete as the scope of transit device is limited to
> these options and transit device are not supposed to interprete the fix
> header.
>
>
>
> The following sentence says transit devices not interpreting the Geneve
> Header….” Which I read as fix header and option. While the statement is
> true, as header include option, I found it somehow confusing to introduce
> the fix header at that stage, as my understanding is that transit device
> are limited to the options.
>
>
>
> Re-reading the text I also believe - if that is correct -, we should
> specify that transit devices MAY treat a subset of the options. </mglt2>
>
>
>
> <Ilango2> The header may include options, and a transit device has to
> interpret the header to get to the options. We will rephrase the text to
> the following for clarity.
>
> Transit devices not interpreting Geneve headers (that may or may not
> include Options)
>
>    SHOULD process Geneve packets as any other UDP packet and maintain
>
>    consistent forwarding behavior.
>
> </Ilango2>
>
>
>    SHOULD process Geneve packets as any other UDP packet and maintain
>    consistent forwarding behavior.
>
>    In tunnel endpoints, the generation and interpretation of options is
>    determined by the control plane, which is out of the scope of this
>    document.  However, to ensure interoperability between heterogeneous
>    devices some requirements are imposed on options and the devices that
>    process them:
>
>    o  Receiving endpoints MUST drop packets containing unknown options
>       with the 'C' bit set in the option type.  Conversely, transit
>       devices MUST NOT drop packets as a result of encountering unknown
>       options, including those with the 'C' bit set.
>
>    o  Some options may be defined in such a way that the position in the
>       option list is significant.  Options or their ordering, MUST NOT
>       be changed by transit devices.
>
>    o  An option MUST NOT affect the parsing or interpretation of any
>       other option.
>
>
>
>
> <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>
>
> <Ilango2> The intent of this statement is, parsing and interpretation of
> options is not dependent on one another. It does not preclude processing of
> any security option.
>
> </Ilango2>
>
>
> 6.  Security Considerations
>
>    As encapsulated within an UDP/IP packet, Geneve does not have any
>    inherent security mechanisms.  As a result, an attacker with access
>    to the underlay network transporting the IP packets has the ability
>    to snoop or inject packets.
>
>
> <mglt>
> I believe that monitoring is also an attack that should be mentioned.
> </mglt>
>
> <Ilango> Snooping covers the case of monitoring as well, so I don’t see a
> need for additional text.
>
> </>
>
>
>
> <mglt2>I  understood “snoop” as being more active  than passive
> monitoring. I am fine with the text.</mglt2>
>
>
>
>
>  Legitimate but malicious tunnel
>    endpoints may also spoof identifiers in the tunnel header to gain
>    access to networks owned by other tenants.
>
> <mglt>
> I think Legitimate and malicious are not compatible. This is probably a
> "corrupted legitimate tunnel endpoint. I think we should also add that
> securing the geneve tunnel cannot prevent this type of threat.
> </mglt>
>
> <Ilango> Yes, we could change this to “Compromised endpoints may also
> spoof ….”.
>
> The next paragraph states that tunnel endpoints should only be operated in
> environments controlled by the service provider, this could potentially
> mitigate the threat of endpoints from getting compromised.
>
> </>
>
>
>
>
>    Within a particular security domain, such as a data center operated
>    by a single service provider, the most common and highest performing
>    security mechanism is isolation of trusted components.  Tunnel
>    traffic can be carried over a separate VLAN and filtered at any
>    untrusted boundaries.  In addition, tunnel endpoints should only be
>    operated in environments controlled by the service provider, such as
>    the hypervisor itself rather than within a customer VM.
>
>
>    When crossing an untrusted link, such as the public Internet, IPsec
>    [RFC4301] may be used to provide authentication and/or encryption of
>    the IP packets formed as part of Geneve encapsulation.
>
> <mglt>
> I understand the first paragraph as the one where the service provider
> owns the tenant, the geneve overlay as well as the infrastructure in which
> case, isolation and separation is performed by VLAN. The second paragraph
> mentions that the previously described data centers can be interconnected
> using a secure link. I consider this case as the one building a trusted
> environment to run Geneve overlay.
>
>
>
> I believe the security considerations for Geneve may be more focused on
> Genve itself, that is how the Geneve overlay network may remain secure
> while not relying on the security provided by the infrastructure. In that
> extent it help to consider the case where tenants, Geneve overlay provider,
> infrastructure providers are different entities.
> </mglt>
>
> <Ilango>The operator could use multiple security mechanisms, which could
> span across layers. For example, the operator could very well choose
> security mechanisms already provided by the underlay to secure their
> overlay networks.  </>
>
> <mglt2>I understand, but it seems to me that the important things here are
> :
>
>    - Corrupted legitimate tunnel endpoint is not expected to be addressed
>    by Geneve security mechanisms.
>    - Geneve overlay deployment relies on reliable (trusted) tunnel
>    endpoints. This later point may be achieved in one or the other ways. You
>    provide one way to do it, another way could be simply trusting your
>    infrastructure provider.
>
> I believe that it may be more helpful to explicitly provide a trust model,
> illustrating it and leave the door open to other solutions. My current
> reading is that one way is proposed, but we may lack some information to
> evaluate if other ways can be acceptable as well.</mglt2>
>
> <Ilango2> I am not sure where you are going with this. The intent is to
> highlight potential risks and outline how to mitigate such risks, this
> paragraph describes the best practices used to secure a tunnel endpoint. We
> believe that this is sufficiently illustrated in the description.
>
> </Ilango2>
>
>
>
>    Geneve does not otherwise affect the security of the encapsulated
>    packets.  As per the guidelines of BCP72 [RFC3552], the following
>    sections describe potential security risks that may be applicable to
>    Geneve deployments and approaches to mitigate such risks.  It is also
>    noted that not all such risks are applicable to all Geneve deployment
>    scenarios, i.e., only a subset may be applicable to certain
>    deployments.  So an operator has to make an assessment based on their
>    network environment and determine the risks that are applicable to
>    their specific environment and use appropriate mitigation approaches
>    as applicable.
>
>
>
> Gross, et al.            Expires April 10, 2019                [Page 21]
>
> Internet-Draft               Geneve Protocol                October 2018
>
>
> 6.1.  Data Confidentiality
>
>    Geneve is a network virtualization overlay encapsulation protocol
>    designed to establish tunnels between network virtualization end
>    points (NVE) over an existing IP network.  It can be used to deploy
>    multi-tenant overlay networks over an existing IP underlay network in
>    a public or private data center.  The overlay service is typically
>    provided by a service provider, for example a cloud services provider
>    or a private data center operator.
>
> <mglt>
> The text above seems to assume that the service overlay is always provided
> by the cloud provider (i.e. infrastructure provider). I do not believe this
> assumption is always true.
>
> A company may sell a system based on Geneve and may be willing to provide
> some protection against the infrastructure provider.
> </mglt>
>
> <Ilango> Yes, “typically” means not always, but it is the most common use
> case.</>
>
> <mglt2> I believe it is good we mention a use case we envisioned as being
> the most common use case, but I also think the security consideration
> should not only be based on one deployment. </mglt2>
>
> <Ilango2> We will add the following statement to the end of this
> paragraph for clarification.
>
> “This may or not may be the same provider as an underlay service provider”
>
> </Ilango2>
>
>
>    Due to the nature of multi-
>    tenancy in such environments, a tenant system may expect data
>    confidentiality to ensure its packet data is not tampered with
>    (active attack) in transit or a target of unauthorized monitoring
>    (passive attack).  A tenant may expect the overlay service provider
>    to provide data confidentiality as part of the service or a tenant
>    may bring its own data confidentiality mechanisms like IPsec or TLS
>    to protect the data end to end between its tenant systems.
> <mglt>
> When a tenant is securing its communication using TLS or IPsec, there are
> still some metadata that the Geneve overlay MAY protect - typically (IP,
> ports).
> </mglt>
>
> <Ilango> The intent of this statement is a tenant may bring its own data
> confidentiality mechanism to protect its data without relying on the
> service provider. This is irrespective of security mechanisms provided by
> the service provider.</>
>
>
>
> <mglt2>I would suggest that we clearly state that data confidentiality
> provided by the tenant does not prevent the geneve overlay to provide it.
> From my reading of the text, it seems that tenant security is sufficient.I
> believe that is a bit misleading. </mglt2>
>
> <Ilango2>The text does not preclude a service provider to provide security
> mechanisms when the tenant brings its own security. I am not sure where you
> are getting this interpretation. If needed we can remove the last sentence
> of the second paragraph, if that addresses your concern.
>
> <Delete the following sentence from the end of next paragraph>
>
> The operator may choose not to enable the encryption if,
>
>    for example, the packet data is already encrypted by the tenant
>
>    system.
>
> </Ilango2>
>
>    If an operator determines data confidentiality is necessary in their
>    environment based on their risk analysis, for example as in multi-
>    tenant environments, then an encryption mechanism SHOULD be used to
>    encrypt the tenant data end to end between the NVEs.  The NVEs may
>    use existing well established encryption mechanisms such as IPsec,
>    DTLs, etc., The operator may choose not to enable the encryption if,
>    for example, the packet data is already encrypted by the tenant
>    system.
>
> 6.1.1.  Inter-data center traffic
>
>    A tenant system in a customer premises (private data center) may want
>    to connect to tenant systems on their tenant overlay network in a
>    public cloud data center or a tenant may want to have its tenant
>    systems located in multiple geographically separated data centers for
>    high availability.  Geneve data traffic between tenant systems across
>    such separated networks should be protected from threats when
>    traversing public networks.  Any Geneve overlay data leaving the data
>    center network beyond the operator's security domain, for example
>    over the public Internet, SHOULD be secured by encryption mechanisms
>    such as IPsec or other VPN mechanisms to protect the communications
>    between the NVEs when they are geographically separated over
>    untrusted network links.  Implementation of specific data protection
>    mechanisms employed between data centers is beyond the scope of this
>    document.
>
> <mglt>
> I see that inter-data center traffic protection is more IP traffic protection than specific to Geneve. I think we can also safely go for a MUST be secured when the traffic is sent to the wild Internet.
> </mglt>
>
> <Ilango> Inter-data center need not always mean internet, for example it
> could be dedicated secure links. In which case the operator may decide to
> rely on the underlying security of the dedicated links, so we believe
> “SHOULD” is more appropriate here.</>
>
> <mglt2>I am reading this as two different implementations of a secure link
> between the data center. The requirement is that this link MUST be secured.
> One way to provide a secure link is to have a dedicated line in which case
> we SHOULD encrypt the traffic. Another way to establish a connection over
> the internet in which case the traffic MUST be encrypted.
>
> I believe it would help to clarify why SHOULD is mentioned here. One
> reason of the confusion is that only the link over internet is mentioned.
> </mglt2>
>
> <Ilango2>The operator based on their risk assessment should enable
> appropriate security mechanism.
>
> We could remove “for example over public Internet” from this sentence and
> this should address your concern.
>
> </Ilango2>
>
>
> 6.2.  Data Integrity
>
>    Geneve encapsulation is used between NVEs to establish overlay
>    tunnels over an existing IP underlay network.  In a multi-tenant data
>    center, a rogue or compromised tenant system may try to launch a
>
>
>
> Gross, et al.            Expires April 10, 2019                [Page 22]
>
> Internet-Draft               Geneve Protocol                October 2018
>
>
>    passive attack such as monitoring the traffic of other tenants, or an
>    active attack such as spoofing or trying to inject unauthorized
>    Geneve encapsulated traffic into the network.  To prevent such
>    attacks, an NVE MUST not propagate Geneve packets beyond the NVE to
>    tenant systems and SHOULD employ packet filtering mechanisms so as
>    not to forward unauthorized traffic between TSs in different tenant
>    networks.
>
> <mglt>I believe that replayed traffic is also unauthorized in this case
> and may be considered in the description.</mglt>
>
> <Ilango> Unauthorized traffic should include all type of unauthorized
> traffic including traffic such as spoofing, replay, etc.,. This is minor
> editorial, if need be we could rephrase to provide clarity  “unauthorized
> traffic such as spoofing, replay, etc.”
>
> </>
>
> <mglt2>I agree this is minor editorial, but the use of UDP eases such
> attacks, so I think it is important this appears in the security
> consideration.</mglt2>
>
> <Ilango2> Ok, we will rephrase to provide clarity
>
> “unauthorized traffic such as spoofing, replay, etc.”
>
> </Ilango2>
>
>
>
> <END>
>
>
>
> On Thu, Oct 11, 2018 at 1:34 PM Ganga, Ilango S <[e-mail]>
> wrote:
>
> As a co-author, I believe the document is ready for publication as a
> standards track RFC.
>
>
>
> Thanks,
>
> Ilango
>
>
>
>
>
> *From:* Bocci, Matthew (Nokia - GB) [mailto:[e-mail]]
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> This email begins a two-week working group last call for
> draft-ietf-nvo3-geneve-08.txt.
>
>
>
> Please review the draft and post any comments to the NVO3 working group
> list. If you have read the latest version of the draft but have no comments
> and believe it is ready for publication as a standards track RFC, please
> also indicate so to the WG email list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> Currently there are two IPR disclosures against this document.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll will run until Friday 26th October.
>
>
>
> Regards
>
>
>
> Matthew and Sam
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>