Re: Generic IPSEC vpn plugin

[Dan Williams <dcbw redhat com>]

On Fri, 2009-04-24 at 16:40 -0400, Paul Wouters wrote:
> 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.

Ideally the first thing you mentioned occurs, the daemon somehow signals
NM that it needs new credentials, and "pauses" the connection for a bit
until they are entered.  I assume if the user isn't around to type in
the password, then the connection should just die after a timeout since
those resources won't be allocated forever on both sides (otherwise it's
a nice DoS).  We can (and should) handle this intelligently in the NM
stack as long as there's supporting infrastructure in the VPN stack
itself.

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

Excellent.  That means (as I understand it) that since pluto has the
whack-style control interface, we could use that for communication with
the IKE daemon?

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

Excellent.

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

Yeah, though we have a general problem in that we don't have a coherent
story on Linux for a good system certificate store.  That's not
openswan's problem but something we need to solve as a whole.  In the
future that means passing not certificate/key data, but a token that's
used as a reference into the NSS certificate store to get the actual
certificate (which might be on a card) or which tells NSS which private
key (which might also be on a card and not retrievable) to use for
encryption/decryption.

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

Yeah, the PPP plugins NM uses for PPTP and and 3G dialup have CHAP and
PAP hooks that pass the password back to pppd when required.

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

That's fine, since NM (and the VPN plugin) would be running as root for
the time being.  David woodhouse wants to make them not run as root, but
that might only happen for the VPN daemons that don't actually need
root.  Sounds like for now, the openswan one would.

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

That's fine; the NM openswan VPN plugin would be expected to use
openswan headers and (if required) libraries as appropriate.  Since the
interface back to NM is all through D-Bus, only the VPN plugin itself
needs to know about openswan specifics.

Sounds like there's a plan.  Lets do it :)

Dan