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

RE: ipsec NICs?

Mike,

DES/3DES has a characteristics that makes them HW friendly and not SW
friendly. Using Moore's law, it is easy to see that at least for the next
few years, 100Mb/s and more so, 1Gb/S or faster, can significantly benefit
from HW accelerators. I guess Henry's comment below, mentions that T3 will
be the limit of the commodity CPUs (when fully consumed) and I agree.

As for the number of SA supported. I can see 2 classes of NICs - Server and
Client. On a server NIC, the # of SA supported should be higher (range of
x00 or even x000). I concur with your analysis as for the best memory
location for storing that many SAs. Hence, the right scheme should be memory
on the NIC, where value (i.e. number of SA supported on board) correlates
with price. Even larger number of SAs might be required for backbone devices
and there the cost of additional memory on the NIC may be well justified. 

Residential Telephony -  assuming 64kb/S per connection, 100Mb/S supports
1600 connections (1Gb/S = ~16,000. not to mention vocoders with lower BW per
call). If IP based telephony devices, will follow the traditional PBX line
density (10,000 lines) for scalability reasons, and may have several NICs
for reliability (99.999...), the security enabled NICs will need to support
SA numbers in x00 to x000 range.

As for the client - what would you consider "high fan out"? The number of
E-MAil or other app-servers is normally below 10 per client. As for
residential Telephony, I suspect the SAs are setup as part of the call setup
and are tear down when the call is over (assuming End2End SA). Hence the #
of SA is small again.

thx

Uri


-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Tuesday, March 07, 2000 5:48 PM
To: Elzur, Uri
Cc: Henry Spencer; Michael Helm; ipsec@lists.tislabs.com
Subject: 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
 > 
 > 
 > 
 > 
 > 
 >