Subject: Re: new to VPN

From: John Lindal <[email-masked]>
Date: Wed, 29 Jan 2003 11:02:03 -0800

>> Is it true that the hardware VPN solutions are always better,
>> trusted and have higher secure level than software VPN?
>
> I don't think so. AFAIK, hardware VPN solution would just be faster than
> software VPN.

Custom hardware always has the potential to be faster than software running
on standard hardware.  However, standard hardware is now so fast that there
is little reason to bother with custom hardware any longer.  It is possible
to get approx. 20Mb/sec using 256 bit AES on a 1GHz Pentium 3 processor.
(AFAIK, most cheap VPN boxes provide only one or at most a few Mb/sec.)

John

---

From: Paul Koning <[email-masked]>
Date: Wed, 29 Jan 2003 18:22:12 -0500

>>>>> "John" == John Lindal <[email-masked]> writes:

 >>  I don't think so. AFAIK, hardware VPN solution would just be
 >> faster than software VPN.

 John> Custom hardware always has the potential to be faster than
 John> software running on standard hardware.  However, standard
 John> hardware is now so fast that there is little reason to bother
 John> with custom hardware any longer.  It is possible to get
 John> approx. 20Mb/sec using 256 bit AES on a 1GHz Pentium 3
 John> processor.  (AFAIK, most cheap VPN boxes provide only one or at
 John> most a few Mb/sec.)

Perhaps the cheap boxes you looked at are software-based?  Or perhaps
they are limited because they have slow network interfaces?  For
instance, a T1 router or VPN box intended for use with cable modems or
DDSL has no use for multi-megabit performance because the wire isn't
that fast.

High end crypto chips are running now at several gigabits/second, and
it's not hard to find applications that have a use for those sort of
numbers.  (Whether they are willing to pay for the cost of that
hardware is quite another matter, though.)  So yes, the software
implementations are getting faster, but the bandwidth hogs are getting
faster, too.

    paul

---

From: Viswanath Neelavalli <[email-masked]>
Date: Wed, 29 Jan 2003 20:45:11 -0500 (EST)

Hi all,
I have been following this discussion board for over 3 weeks now  and it
has helped me try to keep updated with latest happenings.

I want to seek advice on a problem I am facing at my company.

I am able to establish an L2TP/IPSec VPN connection between 2 Windows2K
Advanced Server machines on the same physical LAN.(i.e. they both have the
same netid). I properly configured one ofthem as the VPN Server and also
made it a Standalone CA for issueing Certifcates. BTW, I am using
certificates for the authentication. I make a Dial-Up-Networking VPN
coneection from the client. In the "Local Security Policy" of both the
machines, I set it to "Secure Server(Require Security)".
When I make the connection..I sniff the packet using Ethereal. I can see
encrypted ESP traffic..fine. But If I try to make a telnet connection
from the client to the server, I can clearly see the text passing thru.

In effect, there dones not seem to be any encryption taking place, or I
dont know if am mis-reading something seriously.

Any prompt pointers or ideas on this will be greatly appreciated..as I am
facing a lot of heat from by boss.

Many thanks in advance.

Best Regards,
Viswanath.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Jan 2003 10:05:19 -0500

>(AFAIK, most cheap VPN boxes provide only one or at most a few Mb/sec.)

If the user of the IPsec technology an individual subscriber then a 
fast PC can do a good job, IF you are willing to devote the processor 
cycles to just encryption. However, this may not always be 
acceptable, e.g., one might want secure communications to take place 
as a background activity with minimal disruption of other tasks one 
is performing on the PC. Additionally, hardware can offer far 
superior security for private keys vs. software, and can offer better 
assurance that data does not bypass IPsec checks.

Of course, if the user for IPsec is an aggregation point such as a 
firewall, then it seems clear that hardware solutions are much faster 
than software on a general purpose processor, and one needs to 
support more than just AES to make a fast IPsec, e.g., there are SA 
establishment costs re DH and RSA, and per-packet lookup for SA 
selection and checking.

Finally, my experience is that hardware is much faster than software 
for these security gateways contexts, not at all consistent with you 
parenthetical comment above.

Steve

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Jan 2003 08:46:37 -0800

John Lindal wrote:
> on standard hardware. 
...

That is highly dependent on what the nature of the configuration -
	1) algorithm
	2) number of concurrent associations
	3) non-security performance

1) For some algorithms, such as DES, hardware can be 10-100x faster than 
software. For others, e.g., MD5, software and hardware have similar speeds.

The former includes bit shift and insertion operations that require 
multiple opcodes on general-purpose processors, but can be implemented 
as a single wire in hardware. The latter is dominated by 32-bit 
additions and word-wide logical operations which are basically what 
general-purpose processors are optimized for.

The latter recapitulates the inboard/outboard protocol processing debate 
of that replays every 7-10 years. Custom hardware can be faster, but 
rarely rides the technology evolution curve as continually as PC CPUs.

2) Key agility can be a dominant issue; custom hardware (e.g., CAMs, 
dedicated SRAM, etc.) can reduce context-switching overhead. This 
advantage helps hardware architectures only for medium-scale numbers of 
keys, e.g., where the keys can be held in the CAM, and there is a 
benefit to having the CAM. Configurations with very few streams or with 
enough to thrash the CAM can defeat the benefit of hardware.

3) a slow I/O subsystem isn't helped by hardware IPsec acceleration
and this problem persists, even for high-end systems. e.g., gig-ether
cards require large amounts of buffering to have reasonable performance, 
  and the OS interrupt overhead must be minimized.

In summary, whether hardware has the potential to be faster depends on 
more than just the added silicon...

Joe

---

From: Paul Koning <[email-masked]>
Date: Fri, 31 Jan 2003 15:19:00 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

 Joe> 1) For some algorithms, such as DES, hardware can be 10-100x
 Joe> faster than software. For others, e.g., MD5, software and
 Joe> hardware have similar speeds.

If you have a software implementation of MD5 that runs at several
gigabits per second, I'd love to see it...

	 paul

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Jan 2003 15:30:53 -0800

> gigabits per second, I'd love to see it...

Well, for grins I dug up the scripts I used to measure MD5 for Sigcomm 
back in 1995. I ran them on the following:

	Dell Precisin 530 PC
	dual XEON 2.4Ghz processors (only 1 of which is used)
	1GB RAMBUS RAM

The Sigcomm paper predicted, on a processor with at least 2-way 
parallelism (e.g., the XEON), that the limit would be:

My measurements of optimized code (as postted at ?? in 1995) are:

	unoptimized (RFC code):		1.03  Gbps +/-0.06
	optimized, main memory:		1.604 Gbps +/-0.008
	optimized, cache memory:	1.627 Gbps +/-0.001

The 3.06 Ghz processors should achieve over 2 Gbps easily (see below). 
That would indeed be multigigabit; this is, IMO, reasonably close. Sure, 
you can have custom hardware do better, but vs. riding the PC CPU curve, 
there isn't much of a win.

FWIW:

In RFC1810 I approximated 2/(3N) bits/second, where N=ns/instruction. 
Ten turns of Moore's law later (7.5 years), it appears that:

	2.4 Ghz XEON = 0.4 ns/inst

	2 / (3 x 0.4) = 1.666 Gbps predicted

	1.627 measured

or roughly 2.4% off... ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Jan 2003 17:09:53 -0800

> My measurements of optimized code (as postted at ?? in 1995) are:

The ?? was supposed to be:

http://www.isi.edu/atomic2/security/md5-opts.html

> Ten turns of Moore's law later (7.5 years), it appears that:

Make that 5 turns ;-) (10 turns of the Internet law of 9 mos).

Joe