[Openswan dev] ocf debian

[David McCullough]

Jivin Harald Jenny lays it down ...
[...]
> For me this would be ok - we may add the following options to KLIPS module:
> ocf
> cryptoapi
> builtin
> which would deactivate the corresponding set of algs (crypto/hash/compress).
> This could be triggered by algostack= in ipsec.conf which should explicitly
> list all the stacks the user wants to use (per default all 3). It's a question
> wether the order should matter in this case (setting a preference in the KLIPS
> module) or not (if yes the argument to the three options for the module may
> reflect the user's choice, like 1,2,3)
> For the userspace a ocf=0|1 option should be enough which states if we want to
> use OCF when it's compiled in or not (log a warning when we want to activate it
> and it's not there).

Based on the direction the discussion is going here and to help a lot with
package simplicity,  I think something like this may be the solution:

	* pull all the crypto out of the klips ipsec.ko module itself,  allowing
	  the klips module to load with no crypto driver support at all.

	* put the ocf,  cryptoapi and internal crypto support into seperate
	  modules.  load these modules to add the various crypto support to klips.

	  The order they are loaded in is the order of preference.

	* have a config option in ipsec.conf to specify which modules to
	  load at start time.  If that option is not present try and load all
	  modules in some order of preference.

This is a little bit of work to clean up,  but its not far off what I would
like to see done in klips to sort out the crypto spaghetti.

Obviously the ipsec-ocf.ko module itself will not load unless OCF support is
available. So just probe it and ignore the error or log it.  OCF does not
need to be packaged as part of openswan but can be a package of it's own.
If you install it (how ever you want, source package etc) then the standard
openswan package can use it.

Similarly the ipsec-cryptoapi.ko driver can load, probe and add support for
the appropriate algs if the kernel supports them.

Finally the old internal crypto can also be loaded as ipsec-native.ko and is
sure to work if none of the others do.

I think this would allow a single openswan package which can have support
for everything but dependancies on nothing for distro packaging.

The probing would work something like:

	1) modprobe ipsec
	2) modprobe ipsec-ocf
	3) modprobe ipsec-cryptoapi
	4) modprobe ipsec-native
	5) check /proc to make sure ipsec has some alg's available,  if not
	   fail and unload ipsec.ko

with 2,3 and 4 being optional,  but obviously one needs to load for ipsec
to work.

So this doesn't help with building packages for the current release,  but
I think it would help the next one ;-)

Of course,  don't forget in all this that openswan works fine with netkey.
Also,  this in no way helps the SAref support as it stands now.

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org