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