On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Sun, 01 Feb 2015 21:29:43 +0000 > > > I really was looking for some way to push down something like an XFRM > > state into the tun device and just say "shove them out here until I tell > > you otherwise". > > People decided to use TUN and push VPN stuff back into userspace, > and there are repercussions for that decision. > > I'm not saying this to be mean or whatever, but I was very > disappointed when userland IPSEC solutions using TUN started showing > up.
Yeah. That's a valid criticism of vpnc, certainly. I never did understand why it reimplemented the IPSec stack. For my OpenConnect client it's somewhat more justified though — the initial data transport there is over TLS, which the kernel doesn't support. And if we *can* establish UDP communication, that's over DTLS which the kernel doesn't support either. It's not even the *standard* version of DTLS because Cisco are still using a pre-RFC4347 version of the protocol. And we also need to probe the UDP connectivity and do keepalives and manage the fallback to using the TCP data transport. It's not like vpnc where it really is just a case of setting up the ESP context and letting it run. It's only now I've added Juniper support, which uses ESP-in-UDP for the data transport, that I'm doing something that the kernel supports at all. And now I'm looking at how to make use of that. > We might as well have not have implemented the IPSEC stack at all, > because as a result of the userland VPN stuff our IPSEC stack is > largely unused except by a very narrow group of users. Well, I'd love to make better use of it if I can. I do suspect it makes most sense for userspace to continue to manage the probing of UDP connectivity, and the fallback to TCP mode — and I suspect it also makes sense to continue to use tun for passing packets up to the VPN client when it's using the TCP transport. So the question would be how we handle redirecting the packet flow to the optional UDP transport, when the VPN client determines that it's available. For the sake of the user setting up firewall and routing rules, I do think it's important that it continues to appear to userspace as the *same* device for the entire lifetime of the session, regardless of which transport the packets happen to be using at a given moment in time. It doesn't *have* to be tun, though. You don't seem to like my suggestion of somehow pushing down an XFRM state to the tun device to direct the packets out there instead of up to userspace. Do you have an alternative suggestion... or a specific concern that would help me come up with something you like better? I'm guessing you don't want to push the *whole* management of the TLS control connection *and* the UDP transport, and probing the latter with keepalives, into the kernel? I certainly don't :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
