Chapter 11

The main problem we found was that there was a bottleneck in the Linux kernel random number generator. Switching from /dev/random to /dev/urandom increased the set-up rate to 10 tunnels per second, at the risk of being slightly less secure due to not-as-random numbers being used for the Diffe-Hellman calculations.

Note that both versions 1 and 2 of Openswan already use /dev/urandom, which is safe enough for generating the session keys that normally only last for an hour anyway. When the ipsec newhostkey command is used to generate long-term RSA keys, Openswan explicitly uses /dev/random to generate these keys.

If you are using a VIA CPU with the PadLock feature, such as some of the C3 chips and the Nehemia chips, and have compiled the Linux 2.6 kernel with CONFIG_HW_RANDOM support, then you can use these CPUs' hardware random generator. Just set the option USE_HWRANDOM=true in Openswan 2's Makefile.inc and it will use /dev/hw_random instead of /dev/random. You might also be able to use the PadLock's AES or 3DES functions through the Linux kernel CryptoAPI interface, with either NETKEY or KLIPS, but we have not yet researched whether this works and what speed benefits it brings.

There are a few other hardware random devices available on the market, but most seem to be a bit old. They are based on serial or parallel ports, or ISA slots, when PCI or miniPCI slots would be preferable. Some crypto accelerator cards also have hardware random support, but lack Linux support. We have also tried a few USB tokens but these were clearly not suitable for generating more random numbers than their own single key. However, we expect to see various new products and Linux drivers hitting the market in the coming year.

Other Performance-Enhancing Factors

There are a number of other tweaks that can assist in improving performance for Openswan that are not related to the startup time.

Logging to Disk

Depending on the plutodebug= and klipsdebug= settings, you might be logging so much data through syslog that the disk activity actually becomes a big limiting factor. In some benchmarks, we even found the minimal logging (plutodebug=none) to cause a possible bottleneck. A feature is planned to enable a minimal logging level that avoids this bottleneck. Ensure you are using 32-bit I/O on the disk where your logs are written. You can verify this, for /dev/hda in our example, using:

# hdparm -c /dev/hda

/dev/hda:

IO_support = 0 (default 16-bit)

Here the 32-bit IO support is not enabled. Use the following command to enable it:

# hdparm -c 1 /dev/hda

/dev/hda:

setting 32-bit IO_support flag to 1 IO_support = 1 (32-bit)

259