Re: Generic IPSEC vpn plugin

[Dan Williams <dcbw redhat com>]

On Fri, 2009-04-24 at 12:03 -0400, Paul Wouters wrote:
> On Fri, 24 Apr 2009, Dan Williams wrote:
> 
> > The current VPN handling in NM does need a rework, and I started on that
> > last fall but it was too close to release to land.  Specific issues that
> > need to be fixed include:
> >
> >    - interactive authentication instead of one-shot credentials
> 
> I would not put too much effort in this. Most "interactive" authentication
> (I assume you mean XAUTH password or L2TP password) can be "remembered"
> on most OS'es. Openswan for a long time refused to support XAUTH
> passwords being configured, but we ended up helping people write stupid
> shell scripts to work around it. Also, not all IPsec devices worked
> properly with XAUTH rekying, when the credentials are needed again. So
> in the end we just made it an option and recommend people not to use it.

Except for rekeying with OTP tokens like RSA SecurKey or whatever they
are called.  That's a pretty huge use-case where the authentication
isn't the same the next time a reauth happens.  Intentionally so of
course.

> >    - multiple VPN connections
> 
> There is no problem from an ipsec/openwan point of view, as long as you
> pass along unique names for these connections to openswan. Note that
> there are some unsolvable options, such as ending up having connections
> to two remote networks with the same IP range, or one with the same
> IP range as your NAT'ed range. I'd recommend ignoring these problems.

Right.  We pretty much ignore that problem right now anyway; whatever
gets the highest priority in the routing table wins.  That's not
something that we can really fix, that's a VPN configuration problem for
the user and their sysadmin, if any.

> > The largest problem with IPSec is that since it's half-kernel and
> > half-daemon, there isn't necessarily something there (AFAIK) to alert
> > NetworkManager to the presence of a dropped connection or something like
> > that.  If there is, that's great, lets use it and it'll be awesome.
> 
> DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan
> has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can
> be to turn off the vpn or to try and restart it.

You mean a daemon component, right?  If there's a daemon watching the
connection already, that's awesome, since then the notifications can be
delivered somehow.

> > There's a few things we'll need from the specific VPN stack in *any*
> > case:
> >
> > * Configuration readable on stdin
> > Since config files would need to be written out before starting the
> > connection and removed cleanly after the connection goes away, whatever
> > daemon manages the connection needs to accept configuration on stdin.
> > Command-line based configuration doesn't work because the command line
> > is visible in /proc/pid.
> 
> How about a socket? NM should be able to talk to the pluto IKE daemon
> of openswan using a socket and sending it commands via the "whack" API.

That could work, yes.  As long as connection setup, authentication, and
reauthentication can all happen without using config files or statically
stored on-disk secrets that sounds fine.  Certificates should actually
be stored on-disk or in a Certificate Store like NSS.  Private keys
should typically not be expected to be stored on-disk since they may
exist in a PKCS#11 device or some other location.

> > * Ability to take secrets from external processes
> 
> This functionaliy is missing and will need to be added, though it should
> be a relatively simple change. XAUTH credentials can already be passed
> in via whack. xl2tpd (the client to start l2tp after ipsec is established)
> takes commands (including passwwords) on a named pipe, so this should also
> not be a problem.

Hmm, I'll have to dig in the l2tp stuff a bit more.

> > * Ability to notify external process of connection failures
> > This is crucial.  Users need to know what's going on and when there's a
> > failure.  Daemons work well here because when they die, we know the
> > connection is down.
> 
> This is also fairly easy to add, but you should less us know how best to
> do this for NM. Is there a NM "helper" command we can use for this? Does
> this require any authentication?

How about an unsolicited message on the whack socket?  Isn't there
already some mechanism to emit status messages or something?  Or does it
depend on periodically polling the connection status?

> > * Descriptive error codes
> > Also crucial; vpnc for example doesn't provide much information during
> > the connection process, and only 2 exit error codes.  Quite unhelpful if
> > the user can't figure out whether their group password or user password
> > was wrong, and then of course NM can't do anything intelligent about the
> > failure either.
> 
> This is not always possible, as commercial end points tend to believe it
> is more secure not to explain the reason of failure, but just stop to
> communicate with you. So you only find out after a few retransmits that
> something is wrong. Where possible, xl2tpd and openswan do know about the
> reason for failure, and we just need to add a way of signaling this back
> to other applications.

Ok, that should be fine, ideally via the socket used to control the
connection.  Obviously the client side can only return as much as it
knows.

Dan