2008/522 EOF of 2001/070 IPsec HW Acceleration support

[Bill Sommerfeld]

On Fri, 2008-08-15 at 00:39 -0700, Garrett D'Amore wrote:
>     * performance -- the "slow path" causes packets to traverse PCI 
> busses 3 times, as noted, and certainly involves more complexity in the 
> paths (notably kcf scheduling of crypto gets involved).

The SCA4000 IPsec offload interface only accelerates 3DES; all the cool
kids are now using AES.  AES in software (not to mention the niagara 2
crypto functional units) on current systems will be faster than 3DES
offloaded through an SCA4000 using this interface and the data will also
make only one traversal of an I/O bus.

IMHO the primary motivation for building IPsec offload in the 2001/070
style would be for assurance, not performance reasons:
 1) to allow sensitive keying material to stay entirely within the
boundary of the cryptographic device 
 2) to allow for clear separation between cleartext and ciphertext.

2001/070 was built purely as an acceleration interface with no
possibility of keeping session keys material out of the hands of the
host processor.

>     * FIPS 140-2 compliance for SCA 4000?  (Not that anyone would be 
> certifying SCA 4000 on post S10 releases)...

can you be more specific about why this might matter?  the 2001/070
interface involves the host IPsec passing raw (unwrapped) keying
material to the driver.

>     * Potential (uncertain!) management considerations for secure key 
> management, although its unclear to me that SCA 4000 ever properly 
> secured IPsec session keys. 

it's quite clear that 2001/070 interface used with IKE and IPsec ESP/AH
required keying material to leave and then reenter the FIPS 140
evaluation boundary of the card.

>   (IKE should be able to use secure storage 
> for public keys via kcf, though.)

More importantly, IKE will continue to be able to use secure storage for
the long-term private authentication/signature keys via kcf/PKCS#11 and
either the SCA4000 or SCA6000 keystore.

						- Bill