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

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tue, 9 Oct 2018 09:08:15 +0000

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

---

From: "T. Sridhar" <[email-masked]>
Date: Tue, 9 Oct 2018 15:11:09 +0000

I am not aware of any relevant undisclosed IPR.

Thanks,
Sridhar

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tuesday, October 9, 2018 at 2:08 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Ilango Ganga <[email-masked]>, "[email-masked]" <[email-masked]>
Resent-Date: Tuesday, October 9, 2018 at 2:08 AM

Regards

Matthew and Sam

---

From: Jesse Gross <[email-masked]>
Date: Tue, 9 Oct 2018 13:53:04 -0700

I'm not aware of any IPR related to draft-ietf-nvo3-geneve which has
not already been disclosed.

Jesse

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Tue, 9 Oct 2018 23:31:03 +0000

I am not aware of any undisclosed IPR related to draft-ietf-nvo3-geneve.

Regards,
Ilango

From: Bocci, Matthew (Nokia - GB) [mailto:[email-masked]]
Sent: Tuesday, October 9, 2018 2:08 AM
To: NVO3 <[email-masked]>
Cc: [email-masked]
Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Regards

Matthew and Sam

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 11 Oct 2018 17:34:39 +0000

As a co-author, I believe the document is ready for publication as a standards track RFC.

Thanks,
Ilango

Regards

Matthew and Sam

---

From: Daniel Migault <[email-masked]>
Date: Fri, 12 Oct 2018 17:57:15 -0400

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 <[email-masked]>
wrote:

> *From:* Bocci, Matthew (Nokia - GB) [mailto:[email-masked]]
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Working Group Last Call and IPR Poll 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.
>
>
>
> 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.
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "T. Sridhar" <[email-masked]>
Date: Fri, 12 Oct 2018 23:15:37 +0000

As a co-author, I believe that the draft is ready for publication as a standards track RFC.

Thanks,
Sridhar

Regards

Matthew and Sam

---

From: Jon Hudson <[email-masked]>
Date: Fri, 12 Oct 2018 17:46:30 -0700

Hello,

Thanks
Jon

You may have mail
> On Oct 12, 2018, at 4:15 PM, T. Sridhar <[email-masked]> wrote:
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sat, 13 Oct 2018 11:54:09 -0700

I have a few comments.

Thanks,
Anoop

--

section 3.5

what if none of the options are critical and the implementation is choosing
to remove the options headers without even processing them?  does this
still apply?  if so, it would be good to call it out.

section 4.1
what is the guidance for ttl?  like dscp, there is also a uniform and pipe
model for ttl.

section 4.1.3
may be helpful to add a reference to rfc 8293.

editorial
- endpoint, tunnel endpoint, geneve endpoint are used interchangeably.
also endpoint and end point.  suggest change all to "tunnel endpoint" which
is the only term defined.
- in the definition of ECMP, change:
  while avoiding reordering a single stream. ->
  while avoiding reordering of packets within a flow.
  (stream is not used or defined anywhere else.)
- transit and non-terminating are used interchangeably.  suggest change to
transit which is defined.
- section 3.5.1
  Options or their ordering, ... -> Options, or their ordering, ...
- section 5
  "(VXLAN, NVGRE )" has an extra space
- section 6.1
  DTLs -> DTLS
- section 6.2
  change implementation to specification in the text below.

Implementation of such a mechanism is beyond the scope of this
   document.

- section 6.3

 Authentication mechanism -> authentication mechanism

> *From:* Bocci, Matthew (Nokia - GB) [mailto:[email-masked]
> <[email-masked]>]

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Oct 2018 18:01:16 -0700

Dear All,
I am concerned that the current definition of O-bit contradicts the
definition of the Protocol Type field. Consider that O-bit defined as:
   O (1 bit):  OAM packet.  This packet contains a control message
      instead of a data payload.
My interpretation, please correct me if it is wrong, is that the O-bit
indicates that a message that immediately follows the Geneve header is
OAM command or data. But that is what the Protocol Type field is for:
   Protocol Type (16 bits):  The type of the protocol data unit
      appearing after the Geneve header.
What is the precedence processing O-bit and the Protocol Type values?
Should the specification explain how to interpret the value of the Protocol
type field when O-bit is set? If the value of the Protocol Type field is
equivalent to None, i.e., no message following the Geneve header, can O-bit
be set to indicate that one of TLVs includes OAM? If that is the valid
case, then the current definition of O-bit is not complete as it does not
mention OAM in TLV case.

And I have to point to an overall lack of discussion of OAM in the
specification.

Regards,
Greg

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Wed, 17 Oct 2018 05:44:35 +0000

Hi Daniel,

Thanks for your review and comments. Please see my responses inline.

Regards,
Ilango

From: Daniel Migault [mailto:[email-masked]]
Sent: Friday, October 12, 2018 2:57 PM
To: Ganga, Ilango S <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi,

Yours,
Daniel

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.
</>

3.5.  Tunnel Options

      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”.
</>

<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.
</>

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 process the options.”
</>

   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.
</>

<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.
</>

<mglt>

<Ilango> Snooping covers the case of monitoring as well, so I don’t see a need for additional text.
</>

<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.
</>

<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.
</>

<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.
</>

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.
</>

<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.
</>

6.2.  Data Integrity

<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.”
</>
<END>

On Thu, Oct 11, 2018 at 1:34 PM Ganga, Ilango S <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 9, 2018 2:08 AM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Regards

Matthew and Sam
_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Oct 2018 14:27:35 +0000

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 <[email-masked]>
Sent: Wednesday, October 17, 2018 1:45 AM
To: Daniel Migault <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]; T. Sridhar <[email-masked]>
Subject: RE: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi Daniel,

Regards,
Ilango

From: Daniel Migault [mailto:[email-masked]]
Sent: Friday, October 12, 2018 2:57 PM
To: Ganga, Ilango S <[email-masked]<mailto:[email-masked]>>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi,

Yours,
Daniel

<mglt2>I will see the next section. </mglt2>

3.5.  Tunnel Options

      0 1 2 3 4 5 6 7 8
      +-+-+-+-+-+-+-+-+
      |C|    Type     |
      +-+-+-+-+-+-+-+-+

<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>

<mglt>

<mglt2>I am fine with that as well, as long as you believe that is the right place.</mglt2>

<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 process the options.”
</>
<mglt2>I believe that is clarifying to add the text you proposed.</mglt2>

<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>

<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>

<mglt>

<mglt2>I  understood “snoop” as being more active  than passive monitoring. I am fine with the text.</mglt2>

<mglt>

<mglt>

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>

<mglt>

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>

<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>

<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>

6.2.  Data Integrity

<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>
<END>

Thanks,
Ilango

Regards

Matthew and Sam

---

From: Jesse Gross <[email-masked]>
Date: Wed, 17 Oct 2018 11:31:17 -0700

Greg,

The 'O' bit does not override or interact with the Protocol Type
field, so there is no issue with precedence. It is possible to
implement OAM on Geneve using options, in which case the payload could
be a stub of a packet to ensure consistent behavior between OAM and
data packets as has been done with other protocols. In this situation,
the Protocol Type would still indicate the type of the stub packet as
usual. It is also possible to implement OAM using the payload of the
packet as you describe and the Protocol Type would indicate that using
an EtherType assigned for this purpose.

In either case, the meaning of the 'O' bit is the same and it only
affects the behavior of endpoint devices processing OAM. Most devices
are oblivious to this and will simply use the Protocol Type field to
process the payload as usual. The appropriate behavior for 'O' bit
flagged packets is described in the draft:

      Endpoints MUST NOT forward the payload and
      transit devices MUST NOT attempt to interpret or process it.
      Since these are infrequent control messages, it is RECOMMENDED
      that endpoints direct these packets to a high priority control
      queue (for example, to direct the packet to a general purpose CPU
      from a forwarding ASIC or to separate out control traffic on a
      NIC).  Transit devices MUST NOT alter forwarding behavior on the
      basis of this bit, such as ECMP link selection.

The 'O' bit does not otherwise change the interpretation of the packet.

Jesse

On Mon, Oct 15, 2018 at 6:01 PM Greg Mirsky <[email-masked]> wrote:
>
> Dear All,
> I am concerned that the current definition of O-bit contradicts the definition of the Protocol Type field. Consider that O-bit defined as:
> My interpretation, please correct me if it is wrong, is that the O-bit indicates that a message that immediately follows the Geneve header is
> What is the precedence processing O-bit and the Protocol Type values? Should the specification explain how to interpret the value of the Protocol type field when O-bit is set? If the value of the Protocol Type field is equivalent to None, i.e., no message following the Geneve header, can O-bit be set to indicate that one of TLVs includes OAM? If that is the valid case, then the current definition of O-bit is not complete as it does not mention OAM in TLV case.
>
> And I have to point to an overall lack of discussion of OAM in the specification.
>
> Regards,
> Greg
>
> On Tue, Oct 9, 2018 at 2:08 AM Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
>>

---

From: Jesse Gross <[email-masked]>
Date: Wed, 17 Oct 2018 12:05:11 -0700

As a coauthor, I believe the document is ready for publication as a
standards track RFC after addressing the comments from Daniel and
Anoop (which should not cause significant change).

Jesse

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Oct 2018 13:32:41 -0700

Hi Jesse,
thank you for the very detailed explanation of how authors understand the
role of O-bit and its relationship with an OAM packet. Please find my notes
in-line tagged GIM>>.

Regards,
Greg

> an EtherType assigned for this purpose.
GIM>> If understand you correctly, O-bit indicates presence of OAM TLV(s)
not the type of the payload. But, in my opinion, that is not how the O-bit
is currently defined:
 O (1 bit):  OAM packet.  This packet contains a control message instead of
a data payload.
The definition is the definition of a packet in active OAM per RFC 7799 but
your description suggests that the O-bit only characterizes the content of
TLVs, not of the payload of the Geneve packet. Would you agree?
GIM>> In addition, yes, TLV may be used to implement OAM but, as I believe,
it would not support all requirements usually set for OAM. For example,
because the length of the Value field is limited TLV could not support
testing with synthetic packets of large size. You can find more details in
draft-mirsky-rtgwg-oam-identify
<https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00>.

>       basis of this bit, such as ECMP link selection.
GIM>> Could you please clarify what is considered as "transit devices"? Is
it node in Geneve layer or is it a node in the underlay network. If it is
the latter, then the requirement is just re-stating layer preservation. If
it is the former, then it appears to prohibit tracing OAM operation on
multi-segment Geneve tunnel.

> The 'O' bit does not otherwise change the interpretation of the packet.
GIMM> I disagree. At least as the curreent definition of the O-bit states -
O-bit defines the payload of the Geneve packet.

> >> 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
> >> 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.
> >>

---

From: Jesse Gross <[email-masked]>
Date: Wed, 17 Oct 2018 14:13:53 -0700

On Wed, Oct 17, 2018 at 1:32 PM Greg Mirsky <[email-masked]> wrote:
> GIM>> If understand you correctly, O-bit indicates presence of OAM TLV(s) not the type of the payload. But, in my opinion, that is not how the O-bit is currently defined:
>  O (1 bit):  OAM packet.  This packet contains a control message instead of a data payload.
> The definition is the definition of a packet in active OAM per RFC 7799 but your description suggests that the O-bit only characterizes the content of TLVs, not of the payload of the Geneve packet. Would you agree?

No, I am not saying that the bit indicates the presence of OAM TLVs.
TLVs are always processed in the usual way by looking at the Opt Len
field and the individual TLV header fields. The 'O' bit does not
change this, similar to how it does not change the Protocol Type
field.

I think we can rework the first sentence to simply say something like
"This packet is a control message." As you point out, the text about
"instead of a data payload" is confusing because the bit does not
impact the processing of the payload.

> GIM>> In addition, yes, TLV may be used to implement OAM but, as I believe, it would not support all requirements usually set for OAM. For example, because the length of the Value field is limited TLV could not support testing with synthetic packets of large size. You can find more details in draft-mirsky-rtgwg-oam-identify.

This is a good example of a use for a stub of packet that I mentioned
earlier. However, that does not mean that the OAM instructions also
need to be in the payload. They can still be in a TLV and then a
synthetic payload is present. I believe that this is the cleanest
implementation because it keeps everything consistent between OAM and
non-OAM packets and active and passive OAM.

Although I prefer the use of TLVs for OAM, it is possible to implement
OAM using a shim layer in the payload as well - Geneve has the
flexibility to do it both ways and the behavior of the 'O' bit remains
the same.

> GIM>> Could you please clarify what is considered as "transit devices"? Is it node in Geneve layer or is it a node in the underlay network. If it is the latter, then the requirement is just re-stating layer preservation. If it is the former, then it appears to prohibit tracing OAM operation on multi-segment Geneve tunnel.

The draft defines a transit device as:

Transit device.  A forwarding element along the path of the tunnel
   making up part of the Underlay Network.  A transit device MAY be
   capable of understanding the Geneve packet format but does not
   originate or terminate Geneve packets.

i.e. it is a node in the underlay.

> GIMM> I disagree. At least as the curreent definition of the O-bit states - O-bit defines the payload of the Geneve packet.

I think by changing the first sentence as I suggested above, we can
correct this. The intention is that the 'O' bit only has the effects
quoted above.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 18 Oct 2018 08:21:06 -0700

Hi Jesse,
thank you for kind consideration of my comments and I'm looking forward to
the updated definition of the O-bit flag. In the meantime, I'll note that
using the flag to indicate that the payload, e.g., Ethernet frame of IP
packet, contains OAM message, e.g., CCM or BFD, seems unnecessary to me.
Consider that Ethernet uses EtherTypeand IP uses port number to demultiplex
OAM. I imagine that the egress Geneve node will terminate a packet and
realize that the payload, the frame or the packet, is addressed to it. Then
the type will be properly identified and acted upon. In MPLS we use IP/UDP
encapsulation for BFD and Ping, and over VXLAN have to add Ethernet header
to IP/UDP encapsulated BFD control message. At the same time, MPLS label
stack may include GAL special label that indicates that the label stack is
followed by the Generic Associated Channel header, which includes the
Channel Type field to demultiplex the payload. In this case, IP/UDP
encapsulation is not used.
Apologies if my example came out too wordy. My point is that if Geneve
identifies the payload as OAM, there's no an apparent benefit in having the
payload encapsulated in one of the network layers.

Regards,
Greg

On Wed, Oct 17, 2018 at 2:14 PM Jesse Gross <[email-masked]> wrote:

> > GIM>> If understand you correctly, O-bit indicates presence of OAM
> TLV(s) not the type of the payload. But, in my opinion, that is not how the
> O-bit is currently defined:
> > The definition is the definition of a packet in active OAM per RFC 7799
> but your description suggests that the O-bit only characterizes the content
> of TLVs, not of the payload of the Geneve packet. Would you agree?
>
> > GIM>> In addition, yes, TLV may be used to implement OAM but, as I
> believe, it would not support all requirements usually set for OAM. For
> example, because the length of the Value field is limited TLV could not
> support testing with synthetic packets of large size. You can find more
> details in draft-mirsky-rtgwg-oam-identify.
>
> > GIM>> Could you please clarify what is considered as "transit devices"?
> Is it node in Geneve layer or is it a node in the underlay network. If it
> is the latter, then the requirement is just re-stating layer preservation.
> If it is the former, then it appears to prohibit tracing OAM operation on
> > GIMM> I disagree. At least as the curreent definition of the O-bit
> states - O-bit defines the payload of the Geneve packet.
>

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Fri, 19 Oct 2018 10:26:33 +0000

Greg, Jesse

Is there any value in renaming the O bit to something more generic to indicate that it is really acting as an exception mechanism to tell the terminating NVE to process the packet in its control plane, rather than forward it or imply something about the protocol. It seems that its function is more aligned with the GAL or ‘0001b’ nibble in the PW-ACH.

Matthew

From: Greg Mirsky <[email-masked]>
Date: Thursday, 18 October 2018 at 16:21
To: "[email-masked]" <[email-masked]>
Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi Jesse,
thank you for kind consideration of my comments and I'm looking forward to the updated definition of the O-bit flag. In the meantime, I'll note that using the flag to indicate that the payload, e.g., Ethernet frame of IP packet, contains OAM message, e.g., CCM or BFD, seems unnecessary to me. Consider that Ethernet uses EtherTypeand IP uses port number to demultiplex OAM. I imagine that the egress Geneve node will terminate a packet and realize that the payload, the frame or the packet, is addressed to it. Then the type will be properly identified and acted upon. In MPLS we use IP/UDP encapsulation for BFD and Ping, and over VXLAN have to add Ethernet header to IP/UDP encapsulated BFD control message. At the same time, MPLS label stack may include GAL special label that indicates that the label stack is followed by the Generic Associated Channel header, which includes the Channel Type field to demultiplex the payload. In this case, IP/UDP encapsulation is not used.
Apologies if my example came out too wordy. My point is that if Geneve identifies the payload as OAM, there's no an apparent benefit in having the payload encapsulated in one of the network layers.

Regards,
Greg

On Wed, Oct 17, 2018 at 2:14 PM Jesse Gross <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Oct 17, 2018 at 1:32 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
> On Wed, Oct 17, 2018 at 11:31 AM Jesse Gross <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Greg,
>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 19 Oct 2018 13:52:56 -0700

Hi Matthew,
a very promising idea, thank you. But I'll note that "not all OAM packets
created equal", i.e., some, like BFD, usually don't go to the control plane
and handled by a bump-in-a-wire of specialized ACIS altogether. If we are
entertaining the idea to re-purpose the O-bit, may I propose the following:

   - remove references to OAM from the Geneve specification and handle OAM
   in the separate document (I already have an idea to use EtherType OAM and
   light Geneve OAM shim to demux OAM protocols);
   - regarding the O-bit I see two options:
      - either release it to the Reserved pool;
      - or re-name as Mark and one of the possible users would be the
      Alternate Marking method.

Regards,
Greg

On Fri, Oct 19, 2018 at 3:26 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> Greg, Jesse
>
>
>
> Is there any value in renaming the O bit to something more generic to
> indicate that it is really acting as an exception mechanism to tell the
> terminating NVE to process the packet in its control plane, rather than
> forward it or imply something about the protocol. It seems that its
> function is more aligned with the GAL or ‘0001b’ nibble in the PW-ACH.
>
>
>
> Matthew
>
>
>
>
>
>
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Thursday, 18 October 2018 at 16:21
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [nvo3] Working Group Last Call and IPR Poll for

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Sun, 21 Oct 2018 15:40:29 +0000

Hi Anoop,

Regards,
Ilango

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Saturday, October 13, 2018 11:54 AM
To: [email-masked]
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

I have a few comments.

Thanks,
Anoop

--

section 3.5

what if none of the options are critical and the implementation is choosing to remove the options headers without even processing them?  does this still apply?  if so, it would be good to call it out.

<Ilango> The intent of this statement is for endpoints that processes the options to drop such packets, this is not applicable for endpoints that do not process the options. For better clarity, we will add clarifying text to the end of sentence as follows:

“invalid and MUST be silently dropped if received by an endpoint that processes the options.”
</>

section 4.1
what is the guidance for ttl?  like dscp, there is also a uniform and pipe model for ttl.

<Ilango> You bring up a good point, we will add text outlining TTL behavior to the end of section 4.1.2 as follows:

4.1.2.  DSCP, ECN and TTL
<Add the following paragraph at the end of section 4.1.2 >
Though Uniform or Pipe models could be used for TTL (or Hop Limit in case of IPv6) handling when tunneling IP packets, Pipe model is more aligned with network virtualization. [RFC 2003] provides guidance on handling TTL between inner IP header and outer IP tunnels; this model is more aligned with the Pipe model and is recommended for use with Geneve for network virtualization applications.
</>

section 4.1.3

<Ilango> Yes, it could be useful to provide an informative reference to 8293, to the end of section 4.1.3 as follows:

“In addition, [RFC 8293] provides examples of various mechanisms that can be used for multicast handling in network virtualization overlay networks.”
</>

<Ilango> We will address the following Editorial items as appropriate to make it consistent.
</>
Editorial
- endpoint, tunnel endpoint, geneve endpoint are used interchangeably.  also endpoint and end point.  suggest change all to "tunnel endpoint" which is the only term defined.
- in the definition of ECMP, change:
  while avoiding reordering a single stream. ->
  while avoiding reordering of packets within a flow.
  (stream is not used or defined anywhere else.)
- transit and non-terminating are used interchangeably.  suggest change to transit which is defined.
- section 3.5.1
  Options or their ordering, ... -> Options, or their ordering, ...
- section 5
  "(VXLAN, NVGRE )" has an extra space
- section 6.1
  DTLs -> DTLS
- section 6.2
  change implementation to specification in the text below.

   document.
- section 6.3

Regards

Matthew and Sam

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 21 Oct 2018 14:28:30 -0700

Thanks Ilango.  Your response below addresses all of my comments.

Anoop

On Sun, Oct 21, 2018 at 8:40 AM Ganga, Ilango S <[email-masked]>
wrote:

> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Anoop Ghanwani
> *Sent:* Saturday, October 13, 2018 11:54 AM
> *To:* [email-masked]
> *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for
> what if none of the options are critical and the implementation is
> choosing to remove the options headers without even processing them?  does
> this still apply?  if so, it would be good to call it out.
>
>
>
> <Ilango> The intent of this statement is for endpoints that processes the
> options to drop such packets, this is not applicable for endpoints that do
> not process the options. For better clarity, we will add clarifying text to
> the end of sentence as follows:
>
>
>
> “invalid and MUST be silently dropped if received by an endpoint *that
> processes the options*.”
>
> </>
>
>
>
> section 4.1
>
> <Ilango> You bring up a good point, we will add text outlining TTL
> behavior to the end of section 4.1.2 as follows:
>
>
>
> 4.1.2.  DSCP, ECN *and TTL*
>
> Though Uniform or Pipe models could be used for TTL (or Hop Limit in case
> of IPv6) handling when tunneling IP packets, Pipe model is more aligned
> with network virtualization. [RFC 2003] provides guidance on handling TTL
> between inner IP header and outer IP tunnels; this model is more aligned
> with the Pipe model and is recommended for use with Geneve for network
> virtualization applications.
>
> </>
>
>
>
> section 4.1.3
>
> <Ilango> Yes, it could be useful to provide an informative reference to
> 8293, to the end of section 4.1.3 as follows:
>
>
>
> “In addition, [RFC 8293] provides examples of various mechanisms that can
> be used for multicast handling in network virtualization overlay
> networks.”
>
> </>
>
>
>
>
>

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Mon, 22 Oct 2018 04:21:36 +0000

Hi Daniel,

Please see my responses inline. I think this should address all your comments.

Thanks,
Ilango

Sent: Wednesday, October 17, 2018 7:28 AM

Hi Illango,

Yours,
Daniel

From: Ganga, Ilango S <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 17, 2018 1:45 AM
To: Daniel Migault <[email-masked]<mailto:[email-masked]>>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; T. Sridhar <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi Daniel,

Regards,
Ilango

Hi,

Yours,
Daniel

3.5.  Tunnel Options

      0 1 2 3 4 5 6 7 8
      +-+-+-+-+-+-+-+-+
      |C|    Type     |
      +-+-+-+-+-+-+-+-+

<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>

<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>

<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>

<mglt>

<mglt>

<mglt>

  *   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>

<mglt>

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>

<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,

   system.

</Ilango2>

<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

<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>

Thanks,
Ilango

Regards

Matthew and Sam

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Oct 2018 09:22:52 +0000

Hi,

If everyone agrees, this seems fine to me. Thanks for addressing them.

From your response, I understand “a Transit device can process a geneve header with no option”. If that is correct, I suggest this is clearly mentioned in the document as my initial understanding was that only geneve option were concerned.

OLD:
Transit devices MAY be able to interpret the options, however, as
   non-terminating devices, transit devices do not originate or
   terminate the Geneve packet, hence MUST NOT insert or delete options,
   which is the responsibility of Geneve endpoints.  The participation
   of transit devices in interpreting options is OPTIONAL.

NEW:
s/options/geneve header including geneve options /

It may also be needed to specify what is possible for the transit device to perform on the geneve header excluding the options.

I would also suggest that draft-ietf-nvo3-security-requirements and draft-mglt-nvo3-geneve-security-requirements be referenced in the security consideration section as they provide more details. As these are informational reference, they should not block the publication of the current draft.

Yours,
Daniel

Sent: Monday, October 22, 2018 12:22 AM

Hi Daniel,

Thanks,
Ilango

Hi Illango,

Yours,
Daniel

Hi Daniel,

Regards,
Ilango

Hi,

Yours,
Daniel

3.5.  Tunnel Options

      0 1 2 3 4 5 6 7 8
      +-+-+-+-+-+-+-+-+
      |C|    Type     |
      +-+-+-+-+-+-+-+-+

<mglt>

<mglt>

<mglt>

<mglt>

<mglt>

<mglt>

   system.

</Ilango2>

<mglt>

6.2.  Data Integrity

<END>

Thanks,
Ilango

Regards

Matthew and Sam

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Oct 2018 02:34:36 -0700

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 <[email-masked]>
wrote:

> *From:* Daniel Migault [mailto:[email-masked]]
> *Sent:* Wednesday, October 17, 2018 7:28 AM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked];
> [email-masked]; T. Sridhar <[email-masked]>
> *Subject:* RE: [nvo3] Working Group Last Call and IPR Poll for
> *From:* Ganga, Ilango S <[email-masked]>
> *Sent:* Wednesday, October 17, 2018 1:45 AM
> *To:* Daniel Migault <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked];
> [email-masked]; T. Sridhar <[email-masked]>
> *Subject:* RE: [nvo3] Working Group Last Call and IPR Poll for
> *From:* Daniel Migault [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, October 12, 2018 2:57 PM
> *To:* Ganga, Ilango S <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked];
> [email-masked]
> <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.
>
> </>
>
> <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”.
>
> </>
>
> 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.
>
> </>
>
>
>
> <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.
>
> “…. invalid and MUST be silently dropped if received by an endpoint *that
> processes the options*.”
>
> </>
>
> <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.
>
> <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>
>
>
> <mglt2>I  understood “snoop” as being more active  than passive
> monitoring. I am fine with the text.</mglt2>
>
>
>
>
> 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.
>
> </>
>
>
>
>
> 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
> <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.  </>
>
>    - 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>
>
>
>
> <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>
>
> <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.
>
> <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>
>
> <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>
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 22 Oct 2018 15:41:47 +0300

Hi,

A couple of comments:

1.       I want to thank the authors for addressing the comments about the
Security Considerations section of the previous version of the draft.

2.       Regarding the IANA Considerations section:

a.       [RFC5226] was obsoleted by [RFC8126].

b.       I believe that requiring “IETF Review” is too stringent; “Expert
Review” would make more sense in my opinion.

Therefore, I would suggest the following change:

OLD:

The identifiers 0x0-0xFF are to be reserved for standardized options for
allocation by IETF Review [RFC5226]

NEW:

The identifiers 0x0-0xFF are to be allocated by Expert Review, according to
Section 4.5 of [RFC8126]

Cheers,
Tal.

---

From: Chris Wright <[email-masked]>
Date: Mon, 22 Oct 2018 15:43:02 -0400

> Currently there are two IPR disclosures against this document.

I am unaware of any relevant undisclosed IPR.

thanks,
-chris

---

From: Dinesh Dutt <[email-masked]>
Date: Mon, 22 Oct 2018 11:23:25 -0700

I'm not aware of any undisclosed IPR that's relevant,

Dinesh

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 25 Oct 2018 15:39:31 +0000

Hi Tal,

Thanks for your review.  Please see my responses inline.

Regards,
Ilango

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Monday, October 22, 2018 5:42 AM
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: NVO3 <[email-masked]>; [email-masked]
Subject: Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Hi,

A couple of comments:

1.          I want to thank the authors for addressing the comments about the Security Considerations section of the previous version of the draft.

<Ilango> Glad to know that the new version addresses your previous comments on security considerations section.

<Ilango> We will update the reference to [RFC8126]

b.       I believe that requiring “IETF Review” is too stringent; “Expert Review” would make more sense in my opinion.

 <Ilango>  We don’t see a good reason to change this policy. Only the range 0x00-0xFF is reserved for standardized options under IETF Review. We already have a large range (0x0100- 0xFFEF) that is available under a very lenient policy (First Come First Served),  so it is hard to see the overall policy as being too stringent.

OLD:

The identifiers 0x0-0xFF are to be reserved for standardized options for allocation by IETF Review [RFC5226]

NEW:

The identifiers 0x0-0xFF are to be allocated by Expert Review, according to Section 4.5 of [RFC8126]

Cheers,
Tal.

On Tue, Oct 9, 2018, 12:08 Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
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.

Regards

Matthew and Sam

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 25 Oct 2018 20:32:11 +0000

Hi Daniel,

Please see my response below.

>From your response, I understand “a Transit device can process a geneve header with no option”. If that is correct, I suggest this is clearly mentioned in the document as my initial >understanding was that only geneve option were concerned.

>It may also be needed to specify what is possible for the transit device to perform on the geneve header excluding the options.

<Ilango> We will add appropriate clarification to indicate that Geneve header includes options.

Thanks,
Ilango

Sent: Monday, October 22, 2018 2:23 AM

Hi,

OLD:

NEW:

Yours,
Daniel

Hi Daniel,

Thanks,
Ilango

Hi Illango,

Yours,
Daniel

Hi Daniel,

Regards,
Ilango

Hi,

Yours,
Daniel

3.5.  Tunnel Options

      0 1 2 3 4 5 6 7 8
      +-+-+-+-+-+-+-+-+
      |C|    Type     |
      +-+-+-+-+-+-+-+-+

<mglt>

<mglt>

<mglt>

<mglt>

<mglt>

<mglt>

   system.

</Ilango2>

<mglt>

6.2.  Data Integrity

<END>

Thanks,
Ilango

Regards

Matthew and Sam

---

From: Jesse Gross <[email-masked]>
Date: Thu, 25 Oct 2018 15:24:42 -0700

Hi Matthew,

Thank you for the suggestion. We've been thinking about it and believe
that this can address everyone's concerns. The description of this bit
already references control messages rather than OAM, so that name
seems like a more accurate reflection of its purpose. It also allows
the flexibility for OAM to be specified separately by not commingling
the two concepts, as Greg mentioned.

We will edit the text to read:

   O (1 bit):  Control packet.  This packet contains a control message.
      Control messages are sent between
      Geneve endpoints.  Endpoints MUST NOT forward the payload and
      transit devices MUST NOT attempt to interpret or process it.
      Since these are infrequent control messages, it is RECOMMENDED
      that endpoints direct these packets to a high priority control
      queue (for example, to direct the packet to a general purpose CPU
      from a forwarding ASIC or to separate out control traffic on a
      NIC).  Transit devices MUST NOT alter forwarding behavior on the
      basis of this bit, such as ECMP link selection.

Jesse

---

From: Jesse Gross <[email-masked]>
Date: Thu, 25 Oct 2018 15:43:59 -0700

Hi Greg,

One example of this use case is described in draft-brockners-ippm-ioam-geneve

Jesse

On Mon, Oct 22, 2018 at 2:34 AM Greg Mirsky <[email-masked]> wrote:
> 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 <[email-masked]> wrote:
>>
>> Hi Daniel,
>>
>>
>>
>> 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.
>>
>> On Thu, Oct 11, 2018 at 1:34 PM Ganga, Ilango S <[email-masked]> wrote:
>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Oct 2018 20:26:11 -0700

Hi Jesse,
I have some concerns with what is proposed in
draft-brockners-ippm-ioam-geneve. The main - it requires additional
capability negotiation to avoid the data packets being dropped because of
the egress Geneve node not supporting iOAM and fails to parse the iOAM
message. Second - inconsistency in the use of O-bit. The draft states
(though without proper use of the normative language):
   Packets that carry IOAM
   data fields in addition to regular data payload / customer traffic
   must not set the O bit.  Packets that carry only IOAM data fields
   without any payload must set the O bit.
That, in my opinion, is confusing and inconsistent. iOAM requests
allocation of two Next Protocol values and that should be sufficient. Why
the value of O-bit depends on whether there is or there is no data payload
immediately following iOAM message? How does that help in processing?

Regards,
Greg

On Thu, Oct 25, 2018 at 3:44 PM Jesse Gross <[email-masked]> wrote:

> > a transit node MAY process Geneve packets using Geneve layer
> information. What are scenarios that would require such an option? How that
> >> Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>;
> [email-masked]; [email-masked]; T. Sridhar <
> [email-masked]>
> >> Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>;
> [email-masked]; [email-masked]; T. Sridhar <
> [email-masked]>
> >> Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>;
> [email-masked]; [email-masked]
> >> 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
> >> <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”.
> >>
> >> </>
> >>
> >> <Ilango> This section is where the Tunnel Options are defined hence
> this is the most appropriate and right place for this text.
> >>
> >> </>
> >>
> >>
> >>
> >> 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
> >> 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
> >> 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>
> >>
> >> <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>
> >>
> >>
> >> The next paragraph states that tunnel endpoints should only be operated
> in environments controlled by the service provider, this could potentially
> >> <Ilango>The operator could use multiple security mechanisms, which
> could span across layers. For example, the operator could very well choose
> >> Geneve overlay deployment relies on reliable (trusted) tunnel
> >> 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>
> >>
> >> 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>
> >>
> >> <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
> >> 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
> >> <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.
> >>
> >> <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
> >> <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.
> >>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Oct 2018 20:35:43 -0700

Hi Jesse,
I think that directing the O-bit to identify the presence of "a control
message" would require the definition of the control message or, at least,
some examples. Another question may arise to the interpretation of "packet
contains a control message". Can other, non-control messages, be present in
the packet with O-bit set? I can only re-state my proposal I've shared
earlier:

   - release O-bit to Reserved pool
   - defer discussion of OAM in Geneve to the future work.

Regards,
Greg

On Thu, Oct 25, 2018 at 3:24 PM Jesse Gross <[email-masked]> wrote:

> > Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, NVO3 <
> > thank you for kind consideration of my comments and I'm looking forward
> to the updated definition of the O-bit flag. In the meantime, I'll note
> that using the flag to indicate that the payload, e.g., Ethernet frame of
> IP packet, contains OAM message, e.g., CCM or BFD, seems unnecessary to me.
> > > The definition is the definition of a packet in active OAM per RFC
> 7799 but your description suggests that the O-bit only characterizes the
> content of TLVs, not of the payload of the Geneve packet. Would you agree?
> >
> > > GIM>> Could you please clarify what is considered as "transit
> devices"? Is it node in Geneve layer or is it a node in the underlay
> network. If it is the latter, then the requirement is just re-stating layer
> preservation. If it is the former, then it appears to prohibit tracing OAM
> operation on multi-segment Geneve tunnel.
> >

---

From: Jesse Gross <[email-masked]>
Date: Fri, 26 Oct 2018 11:52:29 -0700

Hi Greg,

These comments seem to be mostly about the specifics of
draft-brockners-ippm-ioam-geneve rather than the infrastructure that
Geneve provides. I think the best way to address them might be to
direct the comments to the authors of that draft in a separate thread.
That should allow more people to see them rather than being buried in
this thread.

Several of your comments also do not align with my understanding of
draft-brockners-ippm-ioam-geneve - they appear to be referencing
properties of your OAM proposals rather than that which is in the
draft. I would suggest that you re-read the draft to make sure that it
matches what you believe. However, I will defer to the authors of that
draft for further comment.

Jesse

On Thu, Oct 25, 2018 at 8:26 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Jesse,
> I have some concerns with what is proposed in draft-brockners-ippm-ioam-geneve. The main - it requires additional capability negotiation to avoid the data packets being dropped because of the egress Geneve node not supporting iOAM and fails to parse the iOAM message. Second - inconsistency in the use of O-bit. The draft states (though without proper use of the normative language):
>    Packets that carry IOAM
> That, in my opinion, is confusing and inconsistent. iOAM requests allocation of two Next Protocol values and that should be sufficient. Why the value of O-bit depends on whether there is or there is no data payload immediately following iOAM message? How does that help in processing?
>
> Regards,
> Greg
>

---

From: Jesse Gross <[email-masked]>
Date: Fri, 26 Oct 2018 11:58:55 -0700

Hi Greg,

I believe that the rewording of the text previously sent out addresses
the bulk of your concerns in a balanced way. It both clarifies the
role of the payload and leaves flexibility for specifying OAM to
additional drafts to flesh out. As far as going further and actually
removing the bit from the base specification, I'm not comfortable
making that change at this point in time. This bit has existed in the
protocol for quite some time and I personally don't see that there is
consensus within the working group for making the change that you are
proposing. I think we need to table this discussion for now unless
there is further support for modifying it.

Jesse

On Thu, Oct 25, 2018 at 8:35 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Jesse,
> I think that directing the O-bit to identify the presence of "a control message" would require the definition of the control message or, at least, some examples. Another question may arise to the interpretation of "packet contains a control message". Can other, non-control messages, be present in the packet with O-bit set? I can only re-state my proposal I've shared earlier:
>
> release O-bit to Reserved pool
> defer discussion of OAM in Geneve to the future work.
>
> Regards,
> Greg
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 Oct 2018 09:28:53 -0700

Hi Jesse,
I appreciate the work you've put into responding to my comments, but I
don't feel that the new proposed text regarding the O-bit addresses them.
Looking forward to the discussion in Bangkok.

Regards,
Greg

On Fri, Oct 26, 2018 at 11:59 AM Jesse Gross <[email-masked]> wrote:

> >> > thank you for kind consideration of my comments and I'm looking
> forward to the updated definition of the O-bit flag. In the meantime, I'll
> note that using the flag to indicate that the payload, e.g., Ethernet frame
> of IP packet, contains OAM message, e.g., CCM or BFD, seems unnecessary to
> me. Consider that Ethernet uses EtherTypeand IP uses port number to
> demultiplex OAM. I imagine that the egress Geneve node will terminate a
> packet and realize that the payload, the frame or the packet, is addressed
> to it. Then the type will be properly identified and acted upon. In MPLS we
> use IP/UDP encapsulation for BFD and Ping, and over VXLAN have to add
> Ethernet header to IP/UDP encapsulated BFD control message. At the same
> time, MPLS label stack may include GAL special label that indicates that
> the label stack is followed by the Generic Associated Channel header, which
> includes the Channel Type field to demultiplex the payload. In this case,
> IP/UDP encapsulation is not used.
> >> >
> >> > Apologies if my example came out too wordy. My point is that if
> Geneve identifies the payload as OAM, there's no an apparent benefit in
> having the payload encapsulated in one of the network layers.
> >> >
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Greg
> >> >
> >> >
> >> >