[Openswan dev] ocf debian

[Harald Jenny]

On Fri, Dec 17, 2010 at 09:07:05AM +1000, David McCullough wrote:
> 
> 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

Ok

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

Hmmm maybe we should then do some cleanup?

> 
> Simple is good.

Agreed

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

Could you elaborate on this?

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