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
