FreeS/wansong [LWN.net]

March 3, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

The FreeS/WAN project is winding down after five years. For those unfamiliar with the project, FreeS/WAN was created by John Gilmore, who has contributed more than his share to the Internet era. He helped create the "alt" newsgroups, co-founded the Electronic Frontier Foundation and Cygnus Solutions (now part of Red Hat), and has contributed to a number of other important projects.

FreeS/WAN was designed to provide a Secure Wide Area Network (S/WAN), and has been widely used to deploy IPSec Virtual Private Networks (VPNs). But Gilmore was looking to go beyond VPNs with FreeS/WAN and to push the concept of Opportunistic Encryption (OE). The idea behind OE was to provide software that would encrypt packets, without intervention from the user, when communicating with machines that support encryption. Using OE, a FreeS/WAN machine would automatically create an ad hoc Virtual Private Network (VPN) when encryption was available at both ends, and send data in the clear when encryption was not available. Either way, the operation would be transparent to the user. Gilmore was optimistic that OE would offer the "fax effect" for encryption:

As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it. Instead of "virtual private networks" we have a "REAL private network"; we add privacy to the real network instead of layering a manually-maintained virtual network on top of an insecure Internet.

Gilmore wanted to secure 5% of Internet traffic against passive wiretapping by 1999, and eventually all communications on the net. Perhaps someday FreeS/WAN, or similar software, will drive widespread adoption of encrypted communications. But users have been slow to utilize FreeS/WAN for OE, even within the Linux community. FreeS/WAN has been popular for setting up VPNs, but OE just hasn't caught on in a big way. This is one of the FreeS/WAN project's stated reasons for quitting:

Nine months after the release of FreeS/WAN 2.00, OE has not caught on as we'd hoped. The Linux user community demands feature-rich VPNs for corporate clients, and while folks genuinely enjoy FreeS/WAN and its derivatives, the ways they use FreeS/WAN don't seem to be getting us any closer to the project's goal: widespread deployment of OE. For its part, OE requires more testing and community feedback before it is ready to be used without second thought. The project's funders have therefore chosen to withdraw their funding.

Gilmore also wanted to challenge U.S. crypto export regulations with FreeS/WAN, and barred U.S.-based developers from contributing code to the project. While there have been some small victories, including the U.S. government's retreat in the Bernstein case (which Gilmore was heavily involved in), the ability to export strong cryptography from the U.S. is far from guaranteed:

After the watershed Bernstein case, US export regulations were relaxed. Since then, many US companies have exported strong cryptography, without seeming restriction other than having to notify the Bureau of Export Administration for tracking purposes.

This comfortable situation has perhaps created a false sense of security. The catch? Export regulations are not laws. The US government still reserves the right to change its export regulations on short notice, and there is no facility to challenge them directly in a court of law. This leaves the US crypto community and US Linux distributions in a position which seems safe, but is not legally protected -- where the US government might at any time *retroactively* regulate previously released code, by prohibiting its future export. This is why FreeS/WAN has always been developed outside the US (in Canada and in Greece), and why it has never (to the best of our knowledge) accepted US patches.

It probably shouldn't be surprising, then, that FreeS/WAN suffered from lack of community support. The decision to exclude U.S.-based developers from working on FreeS/WAN meant that many kernel developers, including Linus himself, would be unable to contribute to the project. But while U.S.-based developers were barred from contributing to FreeS/WAN, they were not barred from working on other implementations of IPSec. The 2.6 kernel now includes an IPSec implementation of its own, negating the need for an add-in implementation like FreeS/WAN.

Though the FreeS/WAN project is ending, the situation is not as dramatic as it sounds. No open source application is dead if the community does not wish it so, and FreeS/WAN will live on for some time after the last official release. The FreeS/WAN team plans to push out at least one more release, including changes to allow its use with the 2.6 kernel series. Openswan, a fork of the FreeS/WAN project, seems poised to continue development where FreeS/WAN leaves off.

Linux users are not being left out in the unencrypted cold. The code remains, and development of IPSec VPNs for Linux continues without a hitch. At some point, we may even realize Gilmore's goals of a fully-encrypted Internet.

(Log in to post comments)

Confusing sentence

Posted Mar 4, 2004 3:55 UTC (Thu) by roelofs (guest, #2599) [Link]

"... without seeming restriction other than having to notify ..."

Restricted?

Read it as "... without any apparent restrictions beyond the requirement to notify ..."

Greg

Confusing sentence

Posted Mar 4, 2004 7:19 UTC (Thu) by zonker (subscriber, #7867) [Link]

Well, it was a direct quote so I couldn't change it... but it does make sense the way it's written (at least it made sense to me...).

Confusing sentence

Posted Mar 6, 2004 1:23 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

It looks wrong if you take "seeming" to be a verb. But it's an adjective here. The base clause is, "without restriction," which sounds fine. "Seeming" modifies "restriction." If you use the more common synonym "apparent" for "seeming," you can see more clearly how to parse the sentence: "without apparent restriction..."

IPSEC has two pieces!

Posted Mar 4, 2004 10:00 UTC (Thu) by gurulabs (subscriber, #10753) [Link]

There is the in kernel IPSec stack, and then there is the userland IKE daemon.

The only time you don't need an IKE daemon is if you are doing 'manual keying'. Which is fine for lab or little tests, but nobody deploys real-world VPN deployments without IKE.

Free/SWAN had two pieces
* Klips - in kernel stack
* pluto - userland IKE daemon

Pluto is BY FAR superior to any IKE daemon out there and lives on in the OpenSWAN project.

Guess what, Pluto can work with either the "klips" kernel code OR the native 2.6 kernel IPSEC. The FreeBSD/NetBSD KAME and the OpenBSD isakmpd IKE deamons blow major chunks compared to Pluto.

The most featureful, powerful and future proof deployement approach is to use Pluto WITH the 2.6 kernel! Even Red Hat is working with the OpenSWAN folks to get Pluto as part of Fedora (maybe even FC2).

It does a huge diservice to repeate the inane blathering "The 2.6 kernel now includes an IPSec implementation of its own, negating the need for an add-in implementation like FreeS/WAN."

Impossible to configure

Posted Mar 4, 2004 13:47 UTC (Thu) by miah (subscriber, #639) [Link]

In a way this is freeswans fault. They did some things to help improve security that made the software more imcompatible with other ipsec implementations. Eg non single des support, no x509 support. Those two things have caused so many issues with getting freeswan to 'work' with other software. Other things are not their fault though. One example being user auth for ipsec (like secure I'd logins for vpn users). Many commercial vendors use ietf dratfs (of which there are several different incompatible versions) for auth, some create their own 'standard'.

I think they should have spent a little more time making it work flawlessly on different distros, and worked on compatibility rather than OE. OE is a nice idea, but I'd rather just have working ipsec first. I've used freeswan for various projects for years now, its sad to see it go, but hopefully openswan changes things now. Maybe now I can submit patches.