[Openswan dev] ocf debian

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Thu, 16 Dec 2010, Harald Jenny wrote:
> 
> >>> Sounds like a very good idea - but must it even be made a compile time option
> >>> then for KLIPS? I guess it would rather call for two options like protostack,
> >>> namely cryptstack and hashstack, with values "built-in" (both crypto and hash,
> >>> default value and fallback), "ocf" (both crypto and hash) and "cryptoapi"
> >>> (currently only crypto). How about this?
> >>
> >> The big issue is that OCF requires us to link to openssl,
> >
> > For userspace that may be true, but for kernel space?
> 
> Oh sorry. Right. Currently (according to David) if OCF and CryptoAPI support
> are enabled in KLIPS, then first OCF is attempted, then CryptoAPI, then KLIPS
> native code. I have not verified if this is so - if it is the compiler #warning
> statements are misleading.
> 
> I'm not sure what happens for ciphers that one does not support. For instance if
> you pick esp=twofish, will it use CryptoAPI (the only place that supports it)


It will fall through to the first one in the list that support what you ask
for.  So it goes something like:

	try OCF
	if (not found)
		try cryptoapi
	if (not found)
		try internal
	if (not found)
		fail


> I am not sure if making these available to the user makes much sense. We would
> also like to get rid of KLIPS native crypto code (3des,aes) in favour of the
> cryptoapi code, though I think currently would break OCF (as the native crypto
> code in cryptoapi does not have OCF support) and I think the native klips code
> might be a few percent faster for 3des/aes (benchmark results might not be up to
> date anymore)
> 
> >> and for instance
> >> Red Hat does not allow us to do that because of certification.
> >
> > Ok sounds reasonable but this would not prevent us from giving users the option
> > in ipsec.conf?
> 
> What informed decisions could a user make not to prefer the faster over the slower
> kernel method?
> 
> >>>> Okay, and that's probably the most useful and easest to do. So a dkms without
> >>>> userland ocf pacakge. Then change the klips DKMS to require the ocf-dkms.
> >>>
> >>> Well I would rather call it an option, not a requirements - maybe there are
> >>> people out there who don't want to use OCF?
> >>
> >> David, can we have a module parameter for OCF? eg modprobe ipsec ocf={0,1} ?
> >
> > I would rather vote for crypt={1,2,3} and hash={1,2|,3(in the future)|}.
> 
> I'm still not entirely sure what that buys though.

My only comment is that ipsec is so full of gotchs and options that adding
anything to that mix should be avoided at all costs :-)

Simple is good.

Since the only user likely to want "something special" is someone with a
better understanding or technical skillset, don't provide more options if
there are already ways to achieve the same thing,  even if they are a little
more terse/obscure.

Cheers,
Davidm


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