[Openswan dev] ocf debian

[Harald Jenny]

On Mon, Dec 20, 2010 at 10:01:07PM +1000, David McCullough wrote:
> 
> 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.

Well this sounds interesting but as far as I have understood Paul splitting the
KLIPS module is not an option for him. I would not mind compiling ipsec.ko
per default with OCF if I would have the option to decide not to use it. May
sound foolish but wouldn't it be possible build use function pointers for this
purpose?

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

That would be really good indeed.

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

Hmmm ok

> 
> 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 main problem (at least for me) is not the package but the usage depedency.

> 
> 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 ;-)

Well as currently cryptoapi code is far away from being complete and Debian
itself is in Freeze we still have some time I guess.

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

Hmmm the SARef support is an issue which may be targeted upstream rather than
in Debian I would say? And NETKEY - well it works but the problem with NETKEY
comes when debugging starts...

> 
> Cheers,
> Davidm

Kind regards
Harald

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