[nvo3] Extensions in nvo3 encapsulations

[Tom Herbert <[e-mail]>]

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