Building and Installing Openswan

Racoon is not as well tested as Pluto. Ralf Spenneberg, an IPsec consultant from Germany, has carried out extensive testing on various IKE daemons, and found several large holes in Racoon that have been present in the Racoon code for many years.

Apparently Racoon also has a tendency to forget established SAs, causing a lot of unnecessary re-key events. This would also complicate large scale deployment.

Isakmpd

Isakmpd originally comes from OpenBSD, and is not really used on Linux although a Debian port exists. There is some sparse information available if you use a search engine such as Google, but we do not know of any large scale isakmpd deployment on Linux.

More Reasons to Pick Pluto

Pluto is the default IKE daemon in Debian, SuSE, Mandrake, Gentoo, and all Linux-based embedded solutions we have encountered. Red Hat and Fedora distributions are still using Racoon, though Pluto is available for those distributions too.

Configuring Racoon is explained in Chapter 8. We will assume the Openswan IKE daemon will be used. Otherwise, you would not be reading this book.

Choosing the Kernel IPsec Stack

A more difficult choice is that of the IPsec kernel stack. There are currently three IPsec stacks in use, the most widely deployed being KLIPS. The upcoming alternative is the NETKEY stack, which is currently included in the 2.6 kernel. NETKEY is a rewrite from scratch of KAME. NETKEY can be used with the traditional KAME userland tool Racoon, which has been ported to Linux and is called ipsec-tools. The third commercially deployed stack is the USAGI stack, a patched KLIPS stack that adds IPv6 support to the IPsec code and was mostly used by SuSE Linux, Germany's biggest Linux distribution.

There are a few other obscure IPsec stacks out there, but these are mostly scientific experiments or personal hobby projects, and have not gotten any large scale deployment or extensive scrutiny from the Open Source community. They should clearly not be used for production environments where money or lives are at stake.

KLIPS, the Openswan Stack

KLIPS was the first available IPsec stack for Linux. Early versions ran on Linux 2.0, and the latest version runs on anything between 2.2 and 2.6. It is the only Linux IPsec stack that has been in use for over a year; in fact, it has been in use for over five years. It has a very strong solid reputation in the IPsec community, and was considered the de facto interop test platform by many commercial vendors. If KLIPS didn't talk to your proprietary IPsec hardware, you had done something wrong.

KLIPS got a major rewrite between FreeS/WAN version 1.99 and version 2.x. Some of its functions had grown far too big and were re-factored. The 2.x code also introduced the regression testing system. Every single feature of KLIPS was tested in a nightly regression test suite. The 2.x version was also the base for Openswan 2.x.

50

Chapter 3

ipsecX Interfaces

Since KLIPS pre-dates the netfilter code in the Linux kernel, it had to find another way to hook into the kernel and the network stack. The solution creates virtual devices, the ipsecX devices, and applies a routing trick to send packets into these virtual devices. The advantage is that the flow of packets is very clear. An encrypted packet comes in on the ethX device. It is detected that this is an IPsec packet, and it is sent to the KLIPS code to be processed. KLIPS decrypts the packet, and puts the decrypted packet on the ipsecX device. Thus the packet traverses all the Linux iptables (or ipfwadm /ipchains on older kernels) once per interface, allowing separate firewall rules to be made for the encrypted and the decrypted packet. This makes writing firewall rules very easy and is considered to be one of KLIPS' major features.

First Packet Caching

Another important feature is the caching of network packets for which it is known that an IPsec tunnel needs to be created. Because of this caching, tunnels can be easily brought up and down without any packet loss. Now packet loss in general is not much of a problem, but losing the first few packets will give you a substantial delay. If you are at home, and fire up the website of your company's internal web server, you do not want to always wait ten seconds while your packets are dropped because your first browser packet triggered the IPsec negotiation, which is still being negotiated as your browser sends more packets that are just being dropped.

Proper packet caching is essential for Opportunistic Encryption, where IPsec tunnels are set up on the fly depending on the received packets, as we will discuss later in Chapter 6.

Path MTU Discovery

Another feature of KLIPS is that it supports full Path MTU discovery (RFC 1191). Path MTU discovery describes a method for determining the Maximum Transmission Unit of a packet.

In the early days of the Internet, a lot of strange non-standard devices or communication lines were used to hook up machines. Some of them were as slow as 300 baud. Buffers to store network packets would be small, so some devices had to send a lot of small packets instead of fewer bigger packets. Of course mainframes had far less problems with big packets, and didn't want to send lots of smaller ones. Competing technologies in the LAN, such as token ring, Ethernet, DECnet, LAT, and other technologies such as serial cables, all had a different standard packet size that could be received and transmitted. The packet size was not as uniform as it is today, when most people use 1500 byte Ethernet frames.

Path MTU discovery finds the largest packet size that can be handled by all the intermediary routers between two computers. The initiating computer will start sending small packets, but once they are received correctly on the other side, will increase its packet size incrementally. At some point, either that other end, or a machine in the middle that is just relaying the packets on, will get a packet it cannot send further because it is too big. It will drop the packet and send a notification back to the sending host. This is an ICMP 'Destination Unreachable' packet which contains a message saying "Datagram Too Big". The sending computer will receive that ICMP packet, read the 'Next-Hop MTU' value, and use that (smaller) packet size instead. If the path between the two computers changes, and another hop in the chain can't receive a certain size packet, the same process will start again with that host. And just once in a while, the sending computer will increase

51

Building and Installing Openswan

the packet size just in case the limiting computer in the middle has vanished.

Firewalls and Path MTU

Unfortunately, in January 1997, the Internet was hit by something that came to be known as the Ping of Death. A bug in the networking code for processing certain incoming packets, most notably ICMP ping request packets, could crash the operating system. This bug was found in the reference code for fragmentation handling, code that had been copied into a wide range of commercial and open source operating systems. Almost all operating systems were affected: Sun, Microsoft, Novell, HP, Digital, SCI, IBM, some BSDs, and Linux.

Since these ping packets are a type of ICMP packet, a lot of system administrators decided to block all types of ICMP packets. And since Path MTU discovery depends on the ICMP Destination Unreachable packet, it was broken when these packets were dropped by the Internet at large. This is the main reason that IPv6 no longer implements Path MTU discovery. But since most computers on the Internet are now connected by ethernet, this limitation does not cause too many problems. At least, that was true until the commercial battle for broadband access began.

A lot of technologies were rolled out for broadband, and most of them worked by tunneling packets one way or another. The complexity of cable and DSL networks and their tunneling mechanisms, such as Microsoft's PPTP, PPPoE (A hack to pretend ethernet is just like an analog phone line), PPPoA (similar, involving ATM instead of ethernet), and various other types of tunneling protocols used by ISPs introduced a lot of tunnels within tunnels. Suddenly, packet size became variable again, and Path MTU discovery once more became an important issue. VPNs are used to connect two remote ends of the Internet. These connections will travel through many ISP networks, often a consumer-grade cable or DSL network. Therefore, broken Path MTU discovery greatly impacts on IPsec connections. Unfortunately, NETKEY does not support this properly.

KLIPS' Downside

KLIPS is not included in the official Linux kernel. As such, many people automatically dislike or distrust KLIPS. Often, the system administrator is already trying something new, IPsec, and does not want to make things any harder than they are already, for instance by having to add code and build their own custom kernel. Compiling KLIPS into your kernel has been made very easy, however, so don't be too quick to discard it as an option. Remember that KLIPS has been in use for about ten years and has proven itself to be extremely stable. NETKEY on the other hand is brand new. It looks very promising, but it hasn't seen large scale deployment yet.

That said, you might not have a choice. KLIPS has no IPv6 support, and unless you are willing to run the unmaintained SuSE version of KLIPS, you will need to use NETKEY if you need IPv6.

Another drawback of KLIPS is that routing hack to receive packets from the kernel. On a KLIPS machine, you can see routes going into ipsecX devices. If these routes are deleted or vanish, packets are no longer being processed by KLIPS. This happens mostly in scenarios where the physical interface is changed, for instance if a PC card or USB network device is added or removed from the system. However it also happens when PPP or PPTP sessions restart, which can happen regularly on DSL or GPRS connections. Most of this can be addressed using custom updown scripts. In the future, these kind of hotplug devices should be better supported.

52