We have a number of L3 tunnelling mechanisms for the cloud such as VXLAN, Geneve, GUE etc. In addition we also have have new socket types like PF_RDS and the kcm proposal which tunnel over tcp from the socket layer and have their own set of challenges. See http://www.spinics.net/lists/netdev/msg347648.html.
In all these cases, the L3 socket is a kernel socket that is transparently created in the kernel, and over which tenant/user-space/application data is tunnelled.
The challenge here is "how to encrypt/secure the traffic". Minimally want to encrypt application payload, you may additionally want to secure the tunnelling protocol itself.
Since these are kernel sockets, TLS is not easily available.
Some possible options are:
- TLS in kernel? Historically, Solaris tried this with kssl in 1999, I can supply some history on the techincal problems that were encountered and why it is eventually being EOF'ed.
- Netflix has investigated the client side implementation of a kernel-TLS to an extent [https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf] and their results, which are based on using a very restricted version of TLS, needs some examination. However, the assumption is hat even if a kernel-TLS were feasible/interesting, it would eventually use existing kernel crypto APIs, which are also used by ipsec today (see below).
- You could use IPSEC in transport mode, and encrypt both the application data and the L3 header itself. IPSEC is well-understood, commonly deployed technology which makes it attractive as a solution here.
I will share some result of the benefits and drawbacks of using IPSEC for L3 tunnelling techniques, and the performance profiles using a few crytpo algorithms and platforms. Our test results will be based on micro-benchmarking tools like iperf/netperf, as well as typical database workloads using PF_RDS sockets. The objective will be to generate some focussed discussion on the areas where we need to improve ipsec performance and/or come up with config utilities to make this easier to use.
In this talk, I'll be providing an analysis of these possible solutions.