Re: Hardware-accelerated IPsec, anyone?

On Tue, Jan 19, 2010 at 04:50:58PM +0100, Hubert Feyrer wrote:
>
>  * hifn(4) - Available in various cards, but also with some warnings in
>    the manpage:
>
>  Support for the 7955 and 7956 is incomplete; the asymmetric crypto facil-
>  ities are to be added and the performance is suboptimal.

At this point I wouldn't use hifn as anything but a random number source.

>  * ubsec(4) - looks promising by the manpage, but I've hardly heared of
>    anyone use them (in contrast to HIFN based boards). Does anyone have
>    a comment e.g. on the BCM58xx based NIAGARA cards sold by
>    InterfaceMasters
>    (http://www.interfacemasters.com/products/SSL_IPSec_cards.html)?

InterfaceMasters is a fantastic company.  We use several of their products
at work and I am very happy with them.

I have one of these exact cards, for my very, very back-burner project of
fixing up the AES support in ubsec.  These chips' AES hardware was
undocumented, but then Broadcom reused the same crypto core in a wireless
SoC which has full documentation.  It's a glaring lack in our driver.

There is a much newer and sexier chip in this product line which we sadly
don't support -- it does multi-Gbps cipher/MAC and has onboard secure
memory for RSA key storage.  In my copious free time... sigh.

>  * n8 / nsp(4) - I couldn't find a manufacturer here, and the driver
>    is not listed in GENERIC (in contast to the above drivers).
>    Not an option as far as I can see - anyone got a vendor for any cards?

I can put you in touch with this manufacturer, who can still supply cards
from old stock.  This hardware is fantastic, the driver somewhat less so.

But the thing about this hardware -- like much newer crypto hardware such
as the Cavium chips (which we also don't have drivers for) -- is that it
is record-oriented.  So it really wants to see full messages of the IKE
or TLS handshake; full ESP/AH (if doing IPsec) packets, etc. and handle
them in one shot.  Used that way even with a fast modern CPU it can
provide large performance benefits.

Our driver has support for those operations and we have full design and
implementation docs and source code to NetOctave's own driver and library
stack which supported them -- the current owner of the IP very generously
open-sourced them -- but nobody has had time to work out how to do this
in NetBSD.  OpenSSL is the largest part of the problem: the OpenSSL
team is basically hostile to any attempts to even discuss fixing their
accelleration abstractions in a way which would make it possible to use
record ops or even accelerators which support HMAC directly!

So, that's sort of the lay of the land, and it's not tremendously pretty.

Thor