mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: David Miller <davem@davemloft.net>
Cc: mst@redhat.com, herbert@gondor.apana.org.au,
	eric.dumazet@gmail.com, jan.kiszka@siemens.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH] tun: orphan an skb on tx
Date: Sun, 01 Feb 2015 21:29:43 +0000	[thread overview]
Message-ID: <1422826183.11044.72.camel@infradead.org> (raw)
In-Reply-To: <20150201.121948.998046471405758397.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

On Sun, 2015-02-01 at 12:19 -0800, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Sun, 01 Feb 2015 13:33:50 +0000
> 
> > Of course, now I'm looking closely at the path these packets take to
> > leave the box, it starts to offend me that they're being passed up to
> > userspace just to encrypt them (as DTLS or ESP) and then send them back
> > down to the kernel on a UDP socket. The kernel already knows how to
> > {en,de}crypt ESP, and do the sequence number checking on incoming
> > packets.
> 
> It's funny, I thought we had an IPSEC stack....

Right. But I'm trying to work out how we can sanely *use* that from a
VPN client.

The client normally sets up a tun device, configuring it with
appropriate IP addresses and routes by invoking vpnc-script or passing
the information back to NetworkManager. The client itself might not even
have root privs, in the NetworkManager case.

The initial authentication and connection are done over HTTPS, and
packets *can* be passed that way if they need to be. But obviously the
client *also* tries to set up a UDP data transport too — which is DTLS
in the case of Cisco AnyConnect, and ESP in UDP for Juniper.

If it *can* get communication over UDP, it'll use it. Otherwise it just
passes packets over the TCP connection. So it needs to dynamically set
up and tear down the ESP/DTLS tunnels as and when they are working.

Ideally we want it such that that packets routed to the tun device get
transparently encrypted and sent out on the UDP socket, and packets
received from UDP and successfully decrypted will appear to have arrived
on the tun device. The user may be manually tweaking the routing, or
setting up firewall/NAT/etc. on the tun device.

I can see how to set up an ESP in UDP tunnel such that it looks like the
packets are actually departing on the *physical* interface (which in
practice I suppose they are). But that's going to be fairly complex to
set up, and extremely non-intuitive and hard to manage for the user. To
the extent that I don't think it's actually deployable.

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".

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

  reply	other threads:[~2015-02-01 21:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13 14:59 Michael S. Tsirkin
2010-04-13 15:12 ` Herbert Xu
2010-04-13 15:36 ` Jan Kiszka
2010-04-13 16:40   ` Eric Dumazet
2010-04-13 16:52     ` Jan Kiszka
2010-04-13 17:39     ` Michael S. Tsirkin
2010-04-13 18:31       ` Eric Dumazet
2010-04-13 20:25         ` Michael S. Tsirkin
2010-04-13 20:38           ` Eric Dumazet
2010-04-13 20:43             ` Michael S. Tsirkin
2010-04-14  0:58         ` Herbert Xu
2010-04-14 11:55           ` David Miller
2015-02-01 11:20           ` David Woodhouse
2015-02-01 12:26             ` Michael S. Tsirkin
2015-02-01 13:33               ` David Woodhouse
2015-02-01 20:19                 ` David Miller
2015-02-01 21:29                   ` David Woodhouse [this message]
2015-02-02  5:07                     ` David Miller
2015-02-02  7:27                       ` David Woodhouse
2015-02-02  8:24                         ` Steffen Klassert
2015-02-02 15:30                           ` David Woodhouse
2015-02-02 15:23                         ` Phil Sutter
2015-02-02 15:47                           ` David Woodhouse
2015-02-04  0:19                         ` David Miller
2015-02-04  6:35                           ` David Woodhouse
2010-04-21 11:35 ` Michael S. Tsirkin
2010-04-21 11:46   ` Jan Kiszka
2010-04-21 11:45     ` Michael S. Tsirkin
2010-04-21 19:16   ` [stable] " Greg KH
2010-09-14 15:20 ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1422826183.11044.72.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®