netdev - Re: [PATCH] tun: orphan an skb on tx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Feb 2015 07:27:10 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	mst@...hat.com, herbert@...dor.apana.org.au,
	eric.dumazet@...il.com, jan.kiszka@...mens.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	qemu-devel@...gnu.org
Subject: Re: [PATCH] tun: orphan an skb on tx

On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote:
> From: David Woodhouse <dwmw2@...radead.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

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)