Re: [nvo3] Extensions in nvo3 encapsulations

[Lizhong Jin <[e-mail]>]

Hi Tom, see inline below.

Lizhong

On Sat, Aug 20, 2016 at 6:53 AM, Tom Herbert <[e-mail]> wrote:

> 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).
>
[Lizhong] Then can I say, when checksum extension is deployed, the underlay
network
is restricted to be no NAT. This will be a limitation.


>
> >>
> >> 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.
>
[Lizhong] Since the link layer has already provide checksum, e.g., FCS in
Ethernet, it would be also safe to have only inner UDP checksum, right?
Anyway, if either inner or outer transport checksum is acceptable, does
that mean the motivation of RCO will not exist?


>
> >>
> >> 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.
>
[Lizhong] Relying on outer IP addresses and UDP ports maybe not a good way.
For the
IP fragmented packet, first&second fragments belong to same flow may have
different source
UDP ports, especially in the scenario where TS and NVE is separated. Method
of generating
the source UDP ports is not standardized, and using source UDP port may not
have even distribution of RSS hash value. E.g., 3bits of hash value maybe
enough for source UDP port, because usually ECMP in network will support 8
path. But RSS needs 7bits of hash value. Then the best way to do RSS for
fragments is to parse the inner header at receive side, and do the hash
based on 3/2-tuple as currently doing.


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