[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx
From: |
David Woodhouse |
Subject: |
Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx |
Date: |
Mon, 02 Feb 2015 15:30:25 +0000 |
On Mon, 2015-02-02 at 09:24 +0100, Steffen Klassert wrote:
>
> Maybe you want to use a virtual tunnel interface (vti) what we have
> already. Everything that is routed through such an interface is
> guaranteed to be either encrypted if a matching xfrm state is present
> or dropped. Same on the rceive side, everything that is received by
> this interface is guaranteed to be IPsec processed. So you can do
> a routing based decision about the IPsec processing.
>
> While I'm sure it could handle the ESP in UDP encapsulation, I'm not that
> sure about your TCP fallback because this requires a valid xfrm state
> to allow packets to pass. Using the same interface for both is probably
> not possible.
I'm trying to imagine how we could make it work in practice if we end up
exposing two *different* interfaces and having to change the kernel's
routing according to whether we have UDP connectivity at any given
moment in time.
Given how painful it already is to maintain vpnc-script and make it do
the right thing for split-include and split-exclude routing, I'm not
really sure I want to go there.
Even if we could get such a scheme to work, it would probably also
require retaining root privileges to make the changes — and one of the
security benefits over the proprietary VPN clients is that we don't
*need* to run as root. We can either drop privs after running
vpnc-script to do the initial routing setup, or in the NetworkManager
case we *never* run with elevated privileges; we just pass the
IP/routing information back over DBus to NetworkManager.
It occurs to me that for the approach I was thinking about, I wouldn't
even need to touch the internals of the tun driver. It could be a
separate driver which just uses tun_get_socket(). Userspace could hand
it the file descriptors of the tun device and the connected UDP socket,
along with the encryption parameters — and then just stop reading
packets from the tun device for itself.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/01
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, Michael S. Tsirkin, 2015/02/01
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/01
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Miller, 2015/02/01
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/01
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Miller, 2015/02/02
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/02
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, Steffen Klassert, 2015/02/02
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx,
David Woodhouse <=
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, Phil Sutter, 2015/02/02
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/02
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Miller, 2015/02/03
- Re: [Qemu-devel] [PATCH] tun: orphan an skb on tx, David Woodhouse, 2015/02/04