[Openswan dev] thoughts on openswan initscripts

[Paul Wouters]

Openswan integration into Fedora's initscripts.



I talked to Michael and Bill from RedHat about adopting openswan as a
userland alternative to racoon. They were happy to support a choice for
the user to pick their favourite userland. So I set out to see how best
to integrate openswan in their initscripts structure. Let me briefly
explain the structure.

For all interfaces, and now tunnels, RedHat has a configuratin file in
/etc/sysconfig/network-scripts/ifcfg-NAME

The ifcfg file contains the configuration info nececssary start
start and stop the device (or rather up and down it using ifup
or ifdown). If a certain type of interface needs something special,
a helper script provides the functionality, for exmaple ifup-ippp for
isdn or ifup-wireless for the wireless paramters.

So for ipsec tunnels, there is now ifup-ipsec and ifdown-ipsec. If the
ifcfg- file contains TYPE=ipsec, this helper script is called. This
script then deals with ipsec specific variables defined in the ifcfg file.

The idea was to support a variable like IPSEC_USERLAND in
/etc/sysconfig/network that would allow one to choose between ipsec
userland implementation. Either racoon or openswan or something
else. This part was easily created. I moved most of ifup-ipsec
into ifup-ipsec.racoon, and change ifup-ipsec to basicly call
./ifup-ipsec.$IPSEC_USERLAND $@. The same applies to ifdown-ipsec.

But then it gets tricky. The ideal situation is that one only needs to
change IPSEC_USERLAND to change implementations, but this means that
both implementations needs to use the same variables, at least for those
where they overlap, in the ifcfg- files. This proved to be a much bigger
problem then I thought at first, because the variables that have been
chosen now by RedHat are basicly the variables as passed to one very
specific userland implementation, basicly the arguments to setkey. I
found myself making a translations of all the openswan ipsec.conf options
into shell variables.  Some are different (SRC versus left, SRCNET versus
leftsubnet) but some of them are quite similar, such as IKE_CERTFILE and
IKE_PEER_CERTFILE, and leftcert and rightca. But most of the fifty(!) or
so options are completely new. Surely it wouldn't make much sense to
change all option53= to OPTION53= constructs. It began to make less and
less sense to me. Especially because the overlap between racoon and 
openswan is not that great, and switching userland with one variable
is not very likely going to work to begin with.

Then I looked at how it is implemented for racoon, and I found that
basicly they have the same problem we have. They are need to replicate
their ifcfg- variables into "conn" like structures. In short, what the
current ifup-ipsec.racoon does is fling the ifcfg- contents with some
setkey glue in a file in /etc/racoon/$DST.conf and -HUP the racoon daemon.
(as a side note, when I tried to do this with initscipts-7.46-1 this
didn't work. The /etc/racoon/$DST.conf file could not be parsed by racoon)

So I figured well, we can do that too. Just use the variables to make
a conn, fling it in /etc/ipsec.d/conns/ and whack pluto with a --reread.

But all of this hardly makes any sense! Why go through such a weird ifcfg-
translation, especially with the userlands having such different set of
options? It will only introduce errors and maintanance. So it led me to
the "why" of the ifcfg- files? Likely what i really wanted by RedHat is
configuration via the redhat-config-network tool. But redhat-config-network
could just as easily get its configuration from /etc/ipsec.d/conns/$CONN.conf 
or /etc/racoon/$CONN.conf 

Another advantadge I can see is the use of "ifup amsterdam-toronto". One
can easily up and down tunnels by name. Well, both for racoon and
openswan, a much simpler ifup/ifdown wrapper can be written. For openswan,
this would just be a call to do "/sbin/ipsec --up amsterdam-toronto".

So, what it boils down to I guess is this. Why don't racoon and openswan
just keep their tunnel configurations in their seperate files, in their
own syntax, in their own directory structure? The only other argument
in favour of the ifcfg- files is simplicity for the enduser. Frankly,
if John Enduser looks at the supported variables in the ifup scripts,
especially if it has both racoon's and openswan's options, he'll run
away screaming to his Microsoft MMC snapin.

There are other problems as well. PSK's are stored in the ifcfg-
files, unless one starts to use PSK=`cat /etc/foobar`, which is also
far from user friendly. However, for security reasons, pluto reads one
static (compile time) filename for the PSK's of all tunnels, normally
/etc/ipsec.secrets). The format of PSK's is different between racoon
and openswan. Racoon has them per ip-address or hostname, where Pluto 
has them as src-dst entry.

For Openswan, this construct also brings other problems. Our "conn
default" cannot be used anymore. Our also= construct can also not be
used anymore.  This means that if for instance your IP changes, you need
to go change them in all tunnel ifcfg- files.

One feature that would probably make it more acceptable for the non
openswan user's to get more easily aquainted with the connection
definitions, would be the equivalnt of left to source and right to
destination. I am not sure how difficult adding such an alias for
left/right would be.

I would really like to get some feedback from people on this. I am not
sure what is really the best way forward.

Paul