Hi Lizhong, thanks for the feedback! Some replies inline. On Fri, Aug 19, 2016 at 8:07 AM, Lizhong Jin <[email protected]> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
