Openswan - IPsec on Linux for the Future

In 1997, John Gilmore (Sun employee #5, and one of the founders of Cygnus) started the FreeS/WAN (Free, Secure Wide Area Network) to create an IPsec stack for Linux. John's political agenda hindered the project throughout it's entire lifetime, with issues like 'no US code would be accepted' and posts from US citizens with patches were ignored in order to keep the codebase 'US free', due to US Cryptographic export regulations at the time.

FreeS/WAN provided an stable, secure IPsec stack on Linux for the 2.0, 2.2, 2.4 and now 2.6 series kernels.

In September of 2000, Ken Bantoft forked FreeS/WAN 1.99 into the 'Super FreeS/WAN' tree, and merged all outstanding major patches (including ones from US citizens). This package quickly became the most popular IPsec on Linux package for Kernels 2.2 and 2.4, and made it's way into many other projects (WOLK, LEAF/bering, etc...) and several commercial distributions (Astaro, ImageStream, NIT to name a few).

As mid 2.5 kernels came out, it emerged that another IPsec stack was being written, led by David Miller from RedHat. David, along with a few others had always been in conflict with the FreeS/WAN project. Their view was that there is no way code that can't be maintained by US citizens would ever go into the Linux Kernel, so they needed something different.

At the time, US citizens could not export cryptographic code. It was a very serious issue at the time, however most were unaware of it. As such, many said that David Miller could not write the code, nor could he maintain it.

The turning point was the Bernstein case (funded in part by John Gilmore and several other via both the FSF, and the EFF). The Bernstein case was not a win - the US government settled out of court. The result is the current BXA "notify us" system, which many US developers think is a win. Is it? Gilmore thinks it is not, that that they are seriously imperiling themselves. Time will tell, as more and more Open Source software contains cryptographic code, and is being exported daily.

David Miller, Derek Atkins and a few others chose to port the various pieces of the USAGI IPsec stack (as they have IPsec for IPv6), *BSD's Kame + Racoon codebase to Linux. The kernel portion was merged late in the 2.5 Kernels, and is now included in 2.6. The userland tools, now known as ipsec-tools contain setkey and racoon – the SPD manipulation tool, and the IKE daemon.

In mid-April 2004, the FreeS/WAN project was declared over, with 2.06 being the final release. At least 2 new projects have been started based on recent FreeS/WAN code - Openswan and Strongswan. Both share the same heritage, and have nearly identical features - this collection of IPsec stacks that use Pluto as the IKE daemon are collectively referred to as *swan.

One interesting thing that FreeS/WAN 2.06 contains is an implementation of KLIPS for the 2.6 Kernel, so perhaps KLIPS will become more of an option for 2.6 users.

*swan users are used to having a virtual network device provided by KLIPS. All IPsec traffic is passed through these 'ipsec#' interfaces. This was quite useful for many purposes, a few of which are listed here:

The 2.6 implementation does not have a virtual network device, meaning some additional work is needed to do firewalling and debugging, and many of the tricks and hacks no longer work.

Another area of major difference is the location of the SPD (Security Policy Database). In KLIPS, the SPD lookups are after the routing process, which is why many networking tricks (like pointing network routes to ipsec0) work. This is commonly known as the 'Bump in the stack' technique, as you insert your code into the networking stack and interrupt *all* traffic to see if it is IPsec related, and the process as required.

Patrick McHardy is currently developing some new netfilter code for the 2.6 Kernel which deals with firewalling IPsec packets much differently. This will allow administrators to 'hook' into the IPsec process much better, and allow better control of IPsec traffic. It will also fix the NAT issues identified earlier, by changing the path of IPsec traffic within the network stack.

From one of Patrick's posts, explaining how netfilter+ipsec patches feed the packets back into the PRE/POST Routing chains:

for them (-m policy --pol ipsec).

Patrick's code basically catches IPsec packets and sends them back through the netfilter process after they've been encrypted or decrypted. During this 2nd pass, they can be mangled/NAT'd/etc... like normal packets.

KLIPS for Kernel 2.6 was released in the final version of FreeS/WAN, 2.06. It remains to be seen if this work will be integrated into either of the *swan forks, or the Kernel itself. As the project is officially over, there are no longer restrictions preventing US citizens from working on the code.

NAT-Traversal is the name given to a set of IETF drafts (on the way to becoming an RFC) that permits IPsec peers to tunnel traffic through devices that do NAT. Essentially, it permits both peers of an IPsec tunnel to detect if there are one (or more) NAT devices in between them, and then switch to tunneling ESP packets into UDP packets. One major benefit of this is that it allows IPsec traffic to pass through a NAT device without any additional configuration of the NAT device.

NAT-T has been tested on many different networks, including GPRS providers, various WiFi hotspots as well as broken ISPs.

Mathieu Lafon from Arkoon Network Security wrote the original NAT-Traversal implementation for FreeS/WAN, which included a patch for the 2.2 and 2.4 kernels to deal with the ESPinUDP packet handling. This portion of NAT-T has to be handled in the kernel IP stack, somewhat like this:

udp.c:

if(is_esp_header_inside(udp_packet)) {

esp_packet = strip_udp_header(udp_packet);

process_esp_packet(esp_packet);

}

The patch for 2.4 was never accepted, but in 2.6 a similar but incompatible version was put into the kernel.

Currently, only Openswan (thanks to Herbert Xu's patches) and Racoon (v0.3, released 2004-04-14) currently support NAT-Traversal on the 2.6 Kernel.

PKI (Public Key Infrastructure) is starting to regain momentum, as more companies spend money on security. As such, technologies like X.509 Digital Certificates and SmartCards are becoming more commonplace. While X.509 support for IPsec has been around for a few years, recently support for SmartCards has been added to *swan, and Strongswan now even supports OCSP (Online Certificate Status Protocol – RFC 2560). Some of this technology is not yet standardized, but work is being done by the PKI for IPsec working group, and RFC's are expected this year.

IPsec on Linux is here to stay, and users now have 2+ choices for how to secure their networks. The only major question remaining is, will this speed up the adoption of IPsec?

IPsec has been notoriously difficult to setup in comparison to other technologies such as SSL, WEP, LEAP and other proprietary solutions. While some work has been done on this, it still needs much attention. Currently, all IPsec configuration is done via editing of text files for the IKE daemons – and those files aren't simple. Work needs to be done to simplify this, and GUI tools are sorely lacking.

In recent years, IPsec has primarily been deployed to connect networks together, and then to connection remote users to these networks. The fast adoption of 802.11 wireless ethernet standard has opened a whole new field of deployment for IPsec. With both mainstream wireless encryption methods (WEP, &LEAP) having been proven insecure, and tools released to help script kiddies speed up their attacks, the best solution still remains IPsec over wireless. Yet nearly all vendors of Wireless AP's and Gateways still don't ship IPsec enabled devices. Those that do, do it only on the external interface, so you can setup a tunnel to another site, but not between your laptop and the AP.

Luckly, wireless security seems to be an area of focus for 2004, and many vendors are preparing secure wireless gateways. Hopefully IPsec will be deployed in more locations, leading to safer, more secure networking.