[Openswan dev] IPsec HW Offload Engine support

David McCullough david_mccullough at au.securecomputing.com
Thu Jun 8 10:30:10 CEST 2006


Jivin remy.gauguey at mindspeed.com lays it down ...
> Thanks a lot.
> 
> I've checked out the git tree, and after a first look, it sounds far 
> easier to integrate a full packet IPsec hw offload engine than on 
> 26sec....
> I've seen that this is part of the ocf-linux "todo list" and that the 
> SafeNet SafeXcel is able to do this ESP/AH processing too... (but not yet 
> supported :-()
> My plan is to add an additional field (ocf_full_pkt_proc) in the struct 
> ipsec_sa  (like ocf_in_use flag) which would be initialized according to 
> crypto driver capabilities (in ipsec_ocf_sa_init()) 
> Then according to this flag we could skip some part of code in the IPsec 
> state machine functions.

The code is sort of setup to do this already so you don't need a
ocf_full_pkt_proc flag.  All you need to do is request full processing
earlier in the state machine,  and if you get it,  skip to the next
relevant state.

You can see how this is done for ESP/AH combined processing versus doing
them one at a time.

Basically the first state in the state machine that can request a full
ESP/AH combined request does so,  then updates next_state as required.

Have a look in:

	ipsec_xmit_encap_select
	ipsec_xmit_cont
	ipsec_rcv_decap_cont

you can see how the next_state can be manipulated to continue/skip
processing as required,

> Maybe you've already started to work on this...

No,  only thought about it so far.

> In anycase, any comment/suggestions would be appreciated ...

Others are also working on full descapulation support,  so it's always a
chicken and eggs thing.  Personally I would get a cipher/hash driver
going for my hardware first,  the reaccess where this is at then.

There will be a speed up for full packet decapsulation over crypto
offloading,  but it will not be as big as the benefit of of the crypto
acceleration,

Cheers,
Davidm


> David McCullough <david_mccullough at au.securecomputing.com>
> Sent by: David McCullough <davidm at snapgear.com>
> 31/05/2006 12:56
>  
>         To:     remy.gauguey at mindspeed.com
>         cc:     dev at openswan.org
>         Subject:        Re: [Openswan dev] IPsec HW Offload Engine support
> 
> 
> 
> Jivin remy.gauguey at mindspeed.com lays it down ...
> > Hello,
> > 
> > I'm currently working on a CPE SoC based on ARM11 with an IPSec offload 
> > engine.
> > This engine performs crypto operations (cipher + digest) but also ESP/AH 
> 
> > protocols offload (ESP/AH header and trailer insertion, IPv4 (only) 
> header 
> > modification...).
> > This engine manages SA database, with TTL and anti-replay checks.
> > I'm currently working on the integration of this HW accelerator into the 
> 
> > 26sec (based on a patch written for 3Com crypto NICs : 
> > http://oss.sgi.com/archives/netdev/2005-01/msg00360.html ), but I would 
> > like to know how feasible would it be to integrate such a IPSec Offload 
> > Engine into OpenSwan KLIPS architecture.
> > It sounds like to me the IPsecX interface would allow to do this easier 
> > than on 26sec...
> > 
> > Any ideas or comments are welcome
> 
> Have a look at:
> 
>                  http://ocf-linux.sourceforge.net/
> 
> There is also a publicly available GIT tree for 2.6 with Openswan and
> OCF fully integrated.
> 
>                  http://git.openswan.org/public/scm/klips.git#ocf_v2.6.16
> 
> It should be really easy to add an OCF driver for the cipher/digest
> portions,  from there the state machine is already close to what will be
> needed for ful packet processing and is something that is being worked
> on/discussed.
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 
> 734352815
> Secure Computing - SnapGear  http://www.uCdot.org 
> http://www.cyberguard.com
> 
> 

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com


More information about the Dev mailing list