On Wednesday Intel introduced a new LAN controller chip (82559C) and a
companion IPSEC coprocessor (82594ED) that reportedly runs 10/100 Mbit
Ethernet, full duplex, full speed, minimum packet gaps -- with 3DES
IPSEC encryption. Windows 2K will supposedly have builtin support for
it. See:
http://developer.intel.com/design/network/82559c.htm
The controller chip is "almost" compatible with their previous LAN
controllers, so minimal Linux driver rewriting will be needed to use
it. I'm looking forward to getting technical information for the
encryption accelerator, so our Canadian programmers can build
FreeS/WAN support for it. Assuming the programming interface is clean
and we can take good advantage of it, this should increase our already
acceptable 3DES performance on common processors from several megabits
to almost a hundred megabits per second.
More info is at:
http://www.intel.com/network/challenges/security.htm
There's a chart in one of the IPSEC white papers there that shows
Windows 2000 running 98 Mbits/sec without encryption, 32 Mbits/sec with
software 3DES, and 72 Mbits/sec with the accelerator. (These numbers
all look bogus to me -- you can't push 98 mbit/sec through a
100mbit/sec Ethernet, unless you run it full duplex at a 200 mbit/sec
raw data rate, since 10-20% is used by packet headers/trailers/interpacket
spacing/etc. And I've never seen software 3DES run at 32 Mbits/sec;
what processor were they using? The same white paper also incorrectly
says 168-bit encryption is "the highest level allowed commercially by law"!)
The product is currently only available in the US, Canada and Puerto
Rico, due to US export controls. Still, Intel believed that was a big
enough market to make it worth doing, and I think they're right.
My guess is that if Hugh and I hadn't made enough stink about DES
insecurity, and forced the issue of making 3DES the standard cipher
for IPSEC, this chip would've come out supporting single DES rather
than triple DES. As I tried to explain at the time FreeS/WAN
desupported DES, in the long run this protocol will all be done in
circuitry, so why sacrifice long-term security for a short-term
performance advantage. The long run has come sooner than even I
expected.
With the random number generator and now the IPSEC accelerator, Intel
is really bidding to be the preferred hardware supplier for people who
care about security. Now if they'd only let us dump the braindead
insecure Microsoft OS's, by publishing programming specs so we can
access their security hardware from Linux and Unix, real servers
running real loads could use their stuff.
John
