On Fri, Feb 16, 2001 at 09:27:37PM -0600, KJ & JC Salchow wrote:
> There are Rainbow cards which do bulk encryption, the reason most people
> don't utilize them is because the bulk encryption is generally RC4 which is,
> by design, built to be fast and efficient as a software implementation -
> whereas the RSA encryption used in the asymetric key exchange is fast and
> efficient in straight hardware. If you look at the stages of SSL, the bulk
> encryption is not difficult or processor intensive - it's essentially a
> onetime pad cipher - which equates to simple substitution cipher with a
> unique key at least as long as the message to avoid repitition. This is not
> tough - programmatically or processor wise. That's what makes PGP such a
> great system - it uses the RSA for the transmission of the onetime pad
> cipher and then uses that to perform bacis substitution. Yes, I know this
> is a little simplified, but its accurate enough to argue the impact of bulk
> encryption on the processor. If it weren't for the asymetric key exchange -
> the part everyone is off loading - SSL would have almost no impact on the
> machine.
I spoke to Rainbow recently and they indicated that bulk encryption was
not available in their products. But that might have changed. I am
aware of efforts to produce hardware bulk encryption by other vendors.
>
> As to handling more than 200 conn/s - I've never seen an F5 box that I've
> worked on or supported at more than 54% processor utilized no matter what
> they were doing. Most of the real work on the BIG-IP revolves around
> memory, not processor - and when compared to the other "general purpose
> processors" I'd much rather have the F5's Pentium III than the ones used by
> Alteon, Cisco or Foundry. Which brings us back to the SMP. With v4.0 F5
> will be on the "unified" BSD kernel which will support SMP. And I'm sure
> I'd rather have dual PIII 890's than anything anyone else has. I also
> question the 100% processor utilization because most people will test their
> SSL tps by doing nothing but flooding a box with NEW SSL sessions - NEW
> sessions means NEW keys which are offloaded to the Rainbow card. I have a
> hard time believing that the F5 box hits 100% utilization doing nothing buy
> handing off SSL handshakes.
>
Recently, I did this very thing in our lab. I was able to get about 210
conn/sec, at which point the CPU is saturated.
The load client I used was http_load compiled with OpenSSL. It does not
cache or reuse sessions, so each request is a new one. The file
requested was less than 1k.
I am a fan of the BIG-IP, but the SSL solution is not appropriate for
every site. A separate dedicated group of SSL boxes is much more
scalable. Of course F5 makes those too.
Eric
This archive was generated by hypermail 2b30 : Tue Feb 20 2001 - 13:07:59 EST