Subject: [nvo3] Extensions in nvo3 encapsulations

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Aug 2016 16:24:42 -0700

Alia has asked that we provide some more information as to what the
motivations for extensions are for nvo3 and to what form they should
take. Here is some high level explanation with respect to GUE.

Six fundamental extensions have been defined for GUE

1) VNID (draft-hy-nvo3-gue-4-nvo-03)
2) Checksum (draft-herbert-gue-extensions-00)
3) Remote checksum offload or RCO  (draft-herbert-gue-extensions-00)
4) Fragmentation (draft-herbert-gue-extensions-00)
5) Security (draft-herbert-gue-extensions-00)
6) Payload transform (draft-herbert-gue-extensions-00)

All of these share some common properties:

* The extensions seem cover three areas: integrity/security,
addressing, and protocol processing.
* These extensions break down into two classes: those that can be
processed without any additional information (checksum, RCO,
fragmentation), and those that require context (VNID, security,
payload xfrm)..
* These are all intrinsic to the encapsulation layer and are part of
correct processing of the encapsulation when present. For instance the
security option is expressly needed to secure the GUE header and in
particular to provide security for VNID.
* All of these are mandatory in the sense that they can't be ignored
at a receiver. For instance, if some receiver decided to ignore RCO
then that would just become a checksum error at the ultimate receiver.
Anything to do with security can pretty much never be ignored. Also,
as a general principle in large scale DCs, it's much better to drop a
packet when we're not sure something is correct as opposed to allowing
it through even if the risk is slight. Packet loss is much easier to
debug than incorrectness!
* With the exception of fragmentation, a subset of these will commonly
be set in packets for some deployment. For instance in a nvo3
deployment, VNID and security might be set all the time.
* These are not intended for processing by middleboxes in transit. As
I mentioned in my response to Bob Briscoe, intermediate devices cannot
correctly parse UDP payloads (port number ambiguity problem in the
network). Such information should be in HBH for IPv6 or IP options in
IPv4.
* These are interoperable and not proprietary.We allow proprietary
extensions via a private data field but do do not encourage it, to do
so otherwise would be to encourage vendor lock-in.

While these six fundamental cover current needs, we cannot predict
that they cover all the future needs of the protocol. At some point we
will need to extend a deployed encapsulation protocol in the data
center. The most likely scenario that we would need to extend the
protocol is to addressed a newly discovered security vulnerability. We
anticipate that extending a protocol is a rare event, but at large
scale we need this capability. Extending a protocol is far simpler
that replacing a protocol especially if we can avoid needing to swap
out massive amounts of hardware.

Another general characteristic is that GUE extensions are contained
within a single header, as opposed to using shim headers or following
headers. There are benefits to do this:

* It's very clear that the extensions refer to the encapsulation. For
instance if implement a checksum in a shim header then we need some
consideration as to how the checksum covers prior headers.
* We can limit the extensibility. This is important consideration for
efficiency and avoid DOS attacks.
* This allows "skip ahead". If a device just wants to look at the
encapsulated IP packet for instance it does not need to parse a header
chain for that.

Thanks,
Tom

---

From: Lucy yong <[email-masked]>
Date: Fri, 19 Aug 2016 00:04:55 +0000

This is very good summary of the motivation for extensions. GUE design was given quite thought on that.

For supporting tunnel stitching (draft-yong-nvo3-tunnel-stitching), it requires a new field in the encap. protocol to carry the next tunnel identifier. GUE can easily support that by defining a new flag and corresponding optional field.

Extensibility is important for a protocol to retain long.

Lucy 

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Thursday, August 18, 2016 6:25 PM
To: [email-masked]
Subject: [nvo3] Extensions in nvo3 encapsulations

Alia has asked that we provide some more information as to what the motivations for extensions are for nvo3 and to what form they should take. Here is some high level explanation with respect to GUE.

* The extensions seem cover three areas: integrity/security, addressing, and protocol processing.
* These extensions break down into two classes: those that can be processed without any additional information (checksum, RCO, fragmentation), and those that require context (VNID, security, payload xfrm)..
* These are all intrinsic to the encapsulation layer and are part of correct processing of the encapsulation when present. For instance the security option is expressly needed to secure the GUE header and in particular to provide security for VNID.
* All of these are mandatory in the sense that they can't be ignored at a receiver. For instance, if some receiver decided to ignore RCO then that would just become a checksum error at the ultimate receiver.
Anything to do with security can pretty much never be ignored. Also, as a general principle in large scale DCs, it's much better to drop a packet when we're not sure something is correct as opposed to allowing it through even if the risk is slight. Packet loss is much easier to debug than incorrectness!
* With the exception of fragmentation, a subset of these will commonly be set in packets for some deployment. For instance in a nvo3 deployment, VNID and security might be set all the time.
* These are not intended for processing by middleboxes in transit. As I mentioned in my response to Bob Briscoe, intermediate devices cannot correctly parse UDP payloads (port number ambiguity problem in the network). Such information should be in HBH for IPv6 or IP options in IPv4.
* These are interoperable and not proprietary.We allow proprietary extensions via a private data field but do do not encourage it, to do so otherwise would be to encourage vendor lock-in.

While these six fundamental cover current needs, we cannot predict that they cover all the future needs of the protocol. At some point we will need to extend a deployed encapsulation protocol in the data center. The most likely scenario that we would need to extend the protocol is to addressed a newly discovered security vulnerability. We anticipate that extending a protocol is a rare event, but at large scale we need this capability. Extending a protocol is far simpler that replacing a protocol especially if we can avoid needing to swap out massive amounts of hardware.

Another general characteristic is that GUE extensions are contained within a single header, as opposed to using shim headers or following headers. There are benefits to do this:

* It's very clear that the extensions refer to the encapsulation. For instance if implement a checksum in a shim header then we need some consideration as to how the checksum covers prior headers.
* We can limit the extensibility. This is important consideration for efficiency and avoid DOS attacks.
* This allows "skip ahead". If a device just wants to look at the encapsulated IP packet for instance it does not need to parse a header chain for that.

Thanks,
Tom

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 19 Aug 2016 13:39:15 +0300

Hi Tom,

thinking out of the box - what will break if you slightly change the
order in which the packets are processed at the VTEP/PE/NVE?
>From the VM perspective, you insert a new L2 module before the packets
are sent down to the virtual circuit. In this module you have e.g.
MACSec for encryption, MEF modules for OAM functions, perhaps add some
new mechanisms for fragmenting on L2 level , have some kind of Path
MTU discovery mechanism etc. Depending on you performance requirements
and amount of tunnels that need these extended features you could run
this undefined module as VM or when high performance is required then
have it deployed in DPDK or if hardware appliance exists insert them
to your hosting device. With service chaining you can direct these
extended services to appropriate tunnels regardless what kind of L3
tunnels are deployed between the VTEPs/PEs/NVEs peers as long as the
remote peer supports this undefined module. If VNID is needed on the
tunnel itself between the NVE peers, then chose a tunnel protocol that
supports that, if not then go for the tunnel with the smallest
overhead, Ethernet over UDP(?) and so on.

Regards,
Patrick