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

[Daniel Migault <[e-mail]>]

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>


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>

      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.

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>

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>

   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>




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>

 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>

   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>

   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>

   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>

   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>

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>




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
>