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

RE: ipsec NICs?



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.

   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.

   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
 > 
 > 
 > 
 > 
 > 
 > 


Follow-Ups: References: