[Openswan Users] Ideal VPN for this wireless deployment?

[Paul Wouters]

On Sat, 22 May 2004, Ryan Verner wrote:

> I'm currently investigating several VPN solutions for particular
> wireless deployments.  IPSec is probably suited, although confirmation
> from others is something I'd really appreciate.

I have just done a presentation at the BlackHat security conference last week
on this very question. Have a look at my paper, it should be online at
http://www.blackhat.com/

The execsum is:
- Forget protecting the linklayer
- IPsec gives you the posibility to seperate crypto and wireless operations on
  different units.
- IPsec has a proven track record. It is also implemented on most OSses and devices.
- Unlike what vendors claim, IPsec can easily run on their consumer market hardware,
  as we showed by running IPsec on the Linksys WRT54g access point.

> (I'm assuming this project is the logical continuation of FreeS/WAN, now
> that the project has seized?  Is this the best IPSec solution to be
> running on Linux 2.4?)

It is. But you asking a biased party ofcourse.
 
> Currently, I'm using pptpd (poptop) + pptp-linux for most of these
> links.  I toyed with FreeS/WAN back in 2002, and it didn't seem to deal
> with packet loss very well, whereas pptpd did.

I've been running it long before 2002 and didn't experience those problems.
With wireless and GPRS, I have more problems with the underlying link, then the
added IPsec layer.
 
> * Needs to be able to deal with small amounts of packet loss (1%) - that
> is, tunnels remain robust for large periods of time, and don't die
> randomly

Modern Openswan versions have Dead Peer Detection to resolve these issues.

> * Not hugely CPU intensive; i.e. can run tunnels on older Pentium
> machines without having resources fly out the window.

I've run tunnels on a 100Mhz MIPS cpu. Using AES instead of 3DES will give you some
more performance.

> * Crypto doesn't eat up a lot of bandwidth overhead; that is, I don't
> want a 600kb/sec link to turn into a 200kb/sec one :-(

you will have to decide what is more important. Security and privacy, or a factor 3
speed. (Though IPsec does not take up 3x the bandwidth).

> * Linux client/server

check. And windows, and macosx, and bsds, and some PDAs.

> * Crypto is strong enough not to allow trivial cracking.

Then you are pretty much down to IPsec. All the others have either been cracked, or
haven't been around for more then a few months.
 
> Things I'd like, but aren't essential:
> 
> * Can handle many (i.e. 50-100) connections

That is probably more then your wireless can handle. but if you got a bnuch
of wireless AP's, then you can also add a few 1U IPsec servers based on Pentium IV
CPUs.

> * In the case of point->point, can tunnel broadcast stuff directed at
> the subnet

IPsec is not a bridge. If you want to run games, get games that know proper tcp instead
of just broadcasts. If using windows, have proper WINS and/r ActiveDirectory+DNS setup
on your PDC and subnets.

> * Plays with ospfd nicely

I'll let Ken answer this one. I have no experience with ospf.

> * Has Windows / OSX clients - sometimes, clients will want to jump on
> the VPN directly.

check. We deployed "wavesec", our ipsec based wireless solution at BlackHat. We got
people using it with windows, linux and macosx.

> * Encrypts everything within the tunnel, not just the content of
> packets.

Not sure what you mean, but what wavesec does is it establishes a tunnel, and then
sends all packets through this tunnel.

> I realise (I think?) that some IPSec implementations can be tuned for
> higher/lower crypto levels.  Is it possible to run at a lower crypto
> level (so bandwidth is maximised), but 'cycle' the keys or whatever is
> used at particular periods without dropouts?

In IPsec there are mor or less two seperate crypto processes. One is the exchange
of keying information. This happens at the start, and every time the keylife expire, 
usually once an hour. It involves a lot of crypto, and you shouldn't use inferior
protocols for this. It only takes about a second (depending on latency of the link)
anyway and shouldn't cause packet loss within the tunnel anyway.
Then there is the per-packet crypto operation. This is what burns the cpu constantly.
This is where you should make a good choice. 3DES would be the best choice, but is
the most expensive operation. AES is the NSA aproved new standard, and takes a lot less
CPU, but is still considered very safe. DES is a bad choice. It's extremely fast, but
you might as well not run any crypto whatsoever. 

Links you might want to check out:
http://www.blackhat.com/main.html
http://www.wavesec.org/
http://www.xtdnet.nl/paul/blackhat2004/  (My presentation is there temporarily since 
                                    BlackHat's archive seems to be broken at this point)

Paul