[Openswan dev] ocf debian
harald at a-little-linux-box.at
Tue Dec 21 11:39:37 EST 2010
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
> 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.
> 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...
> David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
More information about the Dev