[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ipsec NICs?



Michael Thomas writes:
> 
> Elzur, Uri writes:
>  > Several examples might be Enterprise LAN with 100Mbs (and more in the
>  > future), Servers with 100/1G or backbone resident devices. Pls note that
>  > when a CPU is overloaded with Enc/Dec or Auth that overcome its power, it
>  > will not only neglect other application but might also bring the network
>  > connection to a grinding slow speeds.
> 
>    Then you wait for Moore's law to catch up?
> 
>    After years of watching the best intentioned
>    accelerators being consumed by brute force and
>    ignorance (eg faster main CPU's), I tend to 
>    agree with Henry's comment below -- though there's
>    usually a window when such beasts are at least
>    plausible.

Our crypto accelerator chips are providing over 155Mbps
3DES/SHA throughput today at $65 list price.  Plus, they
include Public Key acceleration, RNG and a security CPU
on-chip... so there's a pretty good value vs. consuming
the cycles on an expensive Pentium.

> 
>    What I want to know is whether the current crop
>    of accelerators can handle tens of thousands of
>    simultaneous SA's, all with low but bursty
>    output. I'm not sure where the accelerators
>    keep the SA context, but if it's actually in
>    the accelerator itself that's an awful lot of
>    RAM. If it's on the bus, I'd be concerned about
>    bus contention with the main CPU.

I'm not sure about the other accelerators on the market,
but our ADSP 2141 can support up to 2^32 simultaneous
SA's (we have one customer doing over 100,000).  We 
allow you to store them either in local memory connected
to our chip, or in host PCI memory.  As you point out,
there is a performance concern when we have to pull them
across the PCI bus, but for moderate performance systems,
that can be offset by the desire to share system memory.

Of course, the other issue that hasn't been mentioned in
this thread is the potential for much greater security
(protection of Keys and algorithm integrity) with a
specialized crypto co-processor.  With the 2141, you 
don't have to worry about leaking a plaintext key since
the chip will never let a 'Red key' out.  It will only
return an encrypted 'Black key' to the application.

Bob

(See: http://www.ire.com/OEM/dsp.htm )

> 
>    BTW, this situation is common with high fan out
>    client based systems which want to maintain
>    medium term to indefinite SA's to a server -- like
>    residential telephony. Since crypto is the
>    exception instead of the norm on the net today,
>    this may be the tip of the iceburg.
> 
> 	    Mike
> 
>  > 
>  > thx
>  > 
>  > Uri Elzur
>  > uri.elzur@intel.com                   
>  > 
>  > 
>  > 
>  > -----Original Message-----
>  > From: Henry Spencer [mailto:henry@spsystems.net]
>  > Sent: Monday, March 06, 2000 3:05 PM
>  > To: Michael Helm
>  > Cc: ipsec@lists.tislabs.com
>  > Subject: Re: ipsec NICs?
>  > 
>  > 
>  > On Sun, 5 Mar 2000, Michael Helm wrote:
>  > > Is there anyone keeping track of vendors' ipsec-friendly
>  > > NICs & other networking cards? ... think it's necessary to put
>  > > at least some crypto support for this set of standards
>  > > on the hardware in order for it to be practical on a wide
>  > > scale.
>  > 
>  > Why?  The commodity processors (200MHz Pentiums and the like) currently
>  > being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a
>  > software-unfriendly algorithm if there ever was one -- and MD5 at several
>  > megabits per second.  (I'm talking about measured end-to-end data rates
>  > with real protocols, mind you, not theoretical calculations.)  High-end
>  > consumer-market processors with software-optimized algorithms should take 
>  > this up into the T3 range.
>  > 
>  > These standards are practical on cheap, commodity computers right now.
>  > Only people with very fat pipes have a real need for crypto hardware.
>  > 
>  >                                                           Henry Spencer
>  >                                                        henry@spsystems.net
>  > 




References: