Any chance to get encryption over l2tp offloading? about fastd HOT 5 OPEN

The reason why L2TP is fast is that the whole data path is entirely handled in the kernel - fastd doesn't see any of the traffic, so there is no way for fastd to do any encryption. The common solution for encrypted L2TP is wrapping the whole connection in IPsec, which is complex to configure and requires additional userspace software (which is not aligned with fastd's main design goal to be usable on very small embedded Linux devices).

The best idea I have to have to get an encrypted connection with a fast in-kernel data path would be to make fastd an alternative userspace for the wireguard kernel module. This unfortunately doesn't solve the problem of wireguard's missing L2 support...

from fastd.

So, what we need is a kernel offloading module at L2 level with encryption support? E.g. something like l2tp that gets a symmetric key as a parameter (and maybe some re-keying mechanism from time to time)?

from fastd.

I don't intend to support any out-of-tree module, and I don't think getting another separate solution after Wireguard into the mainline kernel is feasible. That leaves us with a few options:

• Extend Wireguard with proper L2 support
• Combine Wireguard with VXLAN/GRETAP/..., possibly with integrated handling in fastd (performance penalty?)
• Add an IPv6 encapsulation feature to batman-adv (I have no idea if this makes sense)
• Accept that there is no nice solution with batman-adv, and hope for better support of L3 mesh routing protocols in Gluon
• Other ideas?

from fastd.

I think, "Extend Wireguard with proper L2 support" would be the best solution here. Unfortunately, wireguard started as a L3 only solution from the beginning. It might be hard to convince the devs there to support L2.
A good starting point might be to ask them to remove the "more useful than IPsec" statement from their homepage unless they implement L2 ^^

from fastd.

A good starting point might be to ask them to remove the "more useful than IPsec" statement from their homepage unless they implement L2 ^^

I don't think that's quite accurate - IPsec also only handles IP after all, L2 would be provided by some other encapsulation protocol inside the IPsec-protected packets, like L2TP. So in that regard, Wireguard isn't less useful than IPsec.

from fastd.