Re: Generic IPSEC vpn plugin

[Paul Wouters <paul xelerance com>]

On Fri, 24 Apr 2009, Dan Williams wrote:

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

Those connections tend to use 8 hour plus IKE/IPsec SA lifetimes, so they
basically "never" rekey. But you are right. There are two ways of handling
this. Either you just bring down the IKE connection (while the IPsec SA
is still up so packets still flow) and this triggers an event to NM so
it can ask for the OTP and then rekey the IKE connection, or you kill
the connection and let the user connect from scratch. The latter is
mostly found in GUI software.

Openswan currently does not have a method for signaling, but if we're building
that in via dbus or something anyway, this becomes an easy possibility,
and with no packet loss to the end user.

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

Agreed.

> > > 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 is. The IKE daemon always runs. I am not sure how familiar you are
with IKE, so let me give an exec summary.

The IKE daemon establish a command channel over which they agree IPsec
paramters. These daemons always run. Once they agree something, they
inform the kernel, which install the actual keying information along
with lifetime information for the tunnel (in time units or in byte units)
The kernel never talks to userland IKE, it only listens for it. IKE
makes all the decisions.

IKE is userland, which is the openswan pluto daemon. That entity will
have to listen and talk to NM somehow.

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

Not yet, but that modification will be made for you.

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

Openswan 2.6.21 has limited support for NSS. The current development
release 2.6.22dr1 has (full?) NSS support. So this should not be a
problem anymore.

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

I'll need to check that too. 
Currently, from the unit test in openswan-2.x.y/testing/pluto/*l2tp*
I only see us do:

echo "c server" >/var/run/l2tp-control

I think this is taking the user/password information from /etc/ppp,
so if you have a system in place for pppd already, I think this should
just work as well.

> > 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?

Yes, you can do the whack equivalent of "ipsec auto --status" to get a lot
of information from the ike daemon. This currently required root to be
able to send the whack command.

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

That's right. But you might need to depend on whack.h to interpret some
of the resulting codes. Then again, you would probably want to link
against libwhack anyway, though I don't think we currently export that
as a shared library.

Paul