[Openswan dev] ocf debian

[David McCullough]

Jivin Harald Jenny lays it down ...
> On Thu, Dec 16, 2010 at 02:51:39PM -0500, Paul Wouters wrote:
> > 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.
> 
> Well I think we should test this - the order would be ok for me as OCF could
> only be used when the module is present (which could be preloaded).
> 
> > 
> > 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)
> 
> I would guess no, therefore the ipsec.conf options would make sense.


Its a fall through mechanism,  so you can have some tunnels using OCF while
others are using cryptoapi and other are using built in.

As long as the algorithm is "registered" by one the the crypto levels you
will be able to use it.

I reguarly remove OCF HW drivers (so there are none) and fall back to
cryptoapi.

> > I am not sure if making these available to the user makes much sense.
> 
> To be nitpicking we could also say the same about protostack - I think it's
> rather targeted towards the expert than the normal user.
> 
> > We would
> > also like to get rid of KLIPS native crypto code (3des,aes) in favour of the
> > cryptoapi code,
> 
> As soon as some more time appears I want to dig into hashing/compressing with
> cryptoapi...
> 
> > though I think currently would break OCF (as the native crypto
> > code in cryptoapi does not have OCF support)
> 
> Hmmm I thought removing the native code was rather meant as getting rid of the
> included algos themselves, not the whole code base allowing multiple algo
> sources.
> 
> > 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)
> 
> With UML we might be able to test ;-).
> 
> > 
> > >>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?
> 
> Stability issues for example? I guess cryptoapi has a better testing background
> on rare arches than linux OCF.


I would almost say the opposite myself ;-)  OCF has been used primarily in the
embedded space.  It has more miles on it for HW accel. than crypto api.

It doesn't have the mainstream awareness,  but it might be on more devices.


> > >>>>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.
> 
> I'm just proposing it, maybe David can also comment on this? On the other hand,
> I think he told me that when no OCF hardware acceleration is found OCF will use
> cryptoapi as a fallback, correct? Would this also include hardware acceleration
> that can be done by cryptoapi but not OCF or only software?

Yes,  anything crypto API can do OCF can take adavantage of.

Cheers,
Davidm

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