Re: [nvo3] Extensions in nvo3 encapsulations

[Tom Herbert <[e-mail]>]

Hi Lizhong, thanks for the feedback! Some replies inline.

On Fri, Aug 19, 2016 at 8:07 AM, Lizhong Jin <[e-mail]> wrote:
> Hi Tom,
> Thank
>> Six fundamental extensions have been defined for GUE
>>
>> 1) VNID (draft-hy-nvo3-gue-4-nvo-03)
>> 2) Checksum (draft-herbert-gue-extensions-00)
>
> [Lizhong] one more checksum will add additional load to hardware NAT, and it
> is required to update checksum for every NAT router which was not supposed
> to support GUE.
>
Right, the GUE checksum cannot be used through a NAT. In that case UDP
checksum is required. There's really no point in using UDP checksum
and GUE checksum simultaneously, the GUE checksum is really only for
those cases where a device is incapable of computing the full UDP
checksum over a packet (RX or TX).

>>
>> 3) Remote checksum offload or RCO  (draft-herbert-gue-extensions-00)
>
> [Lizhong] this is a feature to enhance legacy NIC. But is two checksum
> (e.g., both outer&inner UDP checksum enabled) enabled really useful? It
> seems, to me, only outer or inner UDP checksum is enough.
>
I assume you mean inner transport checksum (e.g. TCP checksum) and
outer UDP checksum... Generally we found that it is better to set the
outer UDP checksum because 1) It provides coverage over more of the
packet including addresses which is especially important in IPv6 2) It
is better performance since deployed hardware, i.e. NICs, already
provide checksum offload for UDP and we are able to leverage that.

>>
>> 4) Fragmentation (draft-herbert-gue-extensions-00)
>
> [Lizhong] such kind of fragmentation is also not perfect. E.g., the receiver
> side hardware without reassembling could not get inner header, and fail to
> do RSS. I still like #3 as described in the draft.
>
RSS and ECMP are performed on outer IP addresses and UDP ports so we
don't lose that, these must be the same for all fragments of a packet.
DPI cannot be done on fragments (problem with any fragmentation
method), but it is also true for payload transform such as DTLS. One
of the goals of GUE (especially like in TOU) is to discourage and
eliminate DPI in middleboxes by encrypting the whole GUE payload.
Encryption is the only proposed solution to protocol ossification.

>>
>> 5) Security (draft-herbert-gue-extensions-00)
>> 6) Payload transform (draft-herbert-gue-extensions-00)
>
> [Lizhong] I doubt if GUE header security is necessary. In MPLS network, we
> also use label to implicitly identify a VPN, and it works well.
>
The GUE header security is primarily needed to verify the VNID. IMO in
a multi-tenant network the most critical requirement is to maintain
isolation between tenant networks. We need to protect against either
packets illegitimately crossing networks are someone attempting to
inject packets into a virtual network (the latter problem is
exacerbated by the use of UDP for encapsulations because that allows
non-priveleged applications to easily spoof packets to virtual
networks). The header security extension provides explicit security
for this. The payload transform option with DLTS should also be able
to secure the VNID as well. I would expect that we deploy with one of
those two options.

Thanks,
Tom