Benchmarks for Native IPsec in the 2.6 Kernel

The new native IPsec implementation for 2.6.x kernels greatly improves the security of Linux systems.

IPsec is an addition to IP protocol that allows authentication and encryption of IP datagrams. It is defined in detail in IETF RFCs 2401, RFC 2402, RFC 2406 and RFC 2407 (see Resources). IPsec can be used to secure a rather wide range of scenarios; one of its best-known usages is creating virtual private networks (VPNs). A VPN is a secure, private tunnel between two sub-networks using encrypted communication over the Internet.

FreeS/WAN has been the main IPsec implementation for Linux for a long time. Unfortunately, FreeS/WAN has never been integrated into the Linux kernel itself. Instead, the new native kernel IPsec implementation is based on the KAME project, a part of the UNIX/BSD family.

The USAGI project used the BSD code from the KAME project as a base for integrating IPsec into the Linux kernel. KAME's user-space tools, specifically setkey and Racoon, have been ported to Linux by the IPsec-tools Project (see Resources).

In this article, we implement a simple scenario of setting up a secure connection between two Linux systems, reblochon and gouda. We explain different IPsec user-land tools and how to use them to set up a secure connection between two systems. At the end, we present our benchmarks and discuss them.

What You Need to Install

To use IPsec, you need a kernel that supports IPsec protocols and user-land tools that allow key management and key exchange. These keys are used for different cryptographic algorithms.

For Linux kernels 2.5.47 and higher, IPsec support is a part of the kernel itself. However, this support is not enabled by default. If you have a Linux distribution such as Suse 9.1 or Fedora Core 2, it already comes with a 2.6 kernel and IPsec is enabled by default. If you use some other Linux distribution, for example, Fedora Core 1, you need to install a 2.6.x version of the kernel--the higher the better. This new kernel must be compiled with the following options enabled. Go to Device drivers -> Networking support -> Networking options to enable:

  • PF_KEY sockets

  • IP: AH transformation

  • IP: ESP transformation

  • IP: IPComp transformation

  • IPsec user configuration interface

You also must include all the cryptographic algorithms you plan to use for your IPsec setup.

On the user-land side, the only thing you need is setkey and Racoon, which are part of the IPsec-tools Project (see Resources). The installation of these tools is straightforward: download the source code and proceed as usual with configure, make and make install commands. There even might be a precompiled package for your distribution of choice.

Setting Up a Secure Connection

You can use IPsec in two modes, transport or tunnel. Briefly, transport mode is used to secure host-to-host communications, and tunnel mode is used to tunnel securely site-to-site communications. In transport mode, a special header for ESP and AH is added to the normal IP header. In tunnel mode, the IP packet of transport mode with an ESP and AH header is encapsulated in a normal IP packet. That way, the ESP and AH header is not visible directly to routers that might discard a packet with unknown options.

IPsec can be configured in different ways. Here are three ways to configure an IPsec secure connection between two hosts:

  • Shared Secret Keys: Start with a shared key on two nodes. Upon initialization of a secure connection between two nodes, this common shared secret is used for specified encryption or authentication algorithms. Using shared keys is the easiest way to configure but it also is less secure, as the shared secret most probably is contained in a configuration or script file on both machines. Also, if you do not change your keys often, it is possible that someone could capture enough packets to be able to retrieve the key.

  • Pre-Shared Key: In this mode, you need to run Racoon. Its functionality is similar to the shared secret key. The only difference is Racoon uses the pre-shared key as a seed to negotiate a complete key and periodically change that key.

  • X.509 Certificate: The most secure method to manage keys securely is to use the X.509 certificate. This solution requires access to a trusted certification authority (CA); otherwise, you need to set up your own CA. IPsec configuration in this case is not much more complicated, but interactions with a trusted certificate might be a problem.

In our simple scenario, we are more interested in discussing IPsec implementation performance rather than secure connection issues. So here we discuss the configuration of shared and pre-shared keys only.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

UGH. This benchmark is .. worthless.

Next time someone does this, please test a realistic cypher. No one would use 3des on a pc platform for high speed encryption. AES would be a good choice (a good benchmark would test a couple of the options Linux provides)..

Also the packet sizes were not useful. Internet average packet size is something like 400 bytes... Additionally, it's useful to see how well the system would perform with minimum sized packets... so you know how the link will last through a DOS attack.

Anyone have links to a real test?

(btw- With freeswan + AES + compression I was saturating 100mbit ethernet with a P3 1.4gig system)

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

Regarding the packet size, here we should consider the packets exchanged inside a VPN connection, we don't talk about accessing Inetrnet at large with http dominated traffic. But I believe that you are right that the benchmarking with smaller than 1k packets can be very useful.
Actually, we wanted to use a well known benchmark software in order to avoid discussions about the validity of the benchmark software itself and netio people did not consider small packet sizes. I'll forward your comments on the size of the packets to netio people.

My 2 cents on DOS, if you mean a DOS attack on any end of the VPN tunnel, from my experience, Linux is pretty resitent to IP layer DOS attacks with or without IPSec. If you mean from inside the corporate to another end of the VPN, yes it comes back to what I mentioned on packet size.


Re: Benchmarks for Native IPsec in the 2.6 Kernel

undefined's picture

you show ethereal looking at encrypted traffic, but how about unencrypted traffic before it enters the tunnel? that would be useful for debugging application and network problems that are separate from ipsec, but are carried across ipsec.

what about writing firewall rules that only allow port 80 traffic across the encrypted connection?

those are things that can't be done until the native kernel ipsec implementation includes virtual interfaces. those are things that both freeswan and openswan support in 2.4 kernels.

we've taken a step backwards as far as usefulness is concerned.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

regarding firewall rules and virtual interfaces, i suggest you take a look at this document.

it is entirely possible although not as easy as with virtual interfaces.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

I wonder if any of the 64-bit processors would be more efficient at the encryption algorithms?

64-bit performance

Michael Richardson's picture

A 64-bit processor will do no better at ciphers than a 32-bit processor, given the same memory bandwidth.

Processors are sufficiently fast that essentially all latency is due to memory bandwidth, given AES. Maybe a 64-bit processor would run 3des
at the same speed as AES, but it would put out more watts doing that.

Of course, many 64-bit systems have more memory bandwidth, but not all of them.

64bit performance

Anonymous's picture

As an indication, here my setup and numbers:

box1: dual 1.4Ghz Opteron, 64bit gentoo, 43% si on one processor,
cat /dev/zero | nc -l -p 4567

box2: pentium-m 2.0Gz, 32bit gentoo, 58% si
nc dualopteron 4567 > /dev/null

algo: AES, vanilla linux kernel 2.6.9
network: gigabit over two switches

speed, avg 26MB/s (megabyte per second)

Pathetic performance

Anonymous's picture

First you have to compare the quote performance figures with performance of the selected cipher on the same hardware.

In any case modern computers should be able to saturate 100Mbps link with IPsec or without, and should be rather close to saturating 1Gbps link too.

Further you should also consider evaluating scalability - i.e. whether there is a slowdown if, say, a thusand tunnels are maintained simultaneousely.

Re: Pathetic performance

Anonymous's picture

Do you mean that you know of any other __software only__ ipsec implementation that can achieve close to 100 Mbps? On Linux or on Windows? Can you give more details?

Regarding scalability, you're right that it will be very useful to evaluate scalability. We hope to be able to give more on that in future work.


Re: Pathetic performance

Anonymous's picture

I worked with a commercial cross-platform IPsec implementation once, the throughput on the tunnel was only 10 to 30 percent worse than the throuput of the cipher itself.

Safenet Inc for one has an oem package for Linux.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

3des is very slow, AES is faster and there is also an optimized assembly implementation for Pentiums in recent 2.6 kernels .

AH doesn't really serve much purpose, most people will want to just use the ESP authentication alone.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

> AH doesn't really serve much purpose, most people will want to just use the ESP authentication alone.

Actually it has a purpose. If transport keys are derived from public/private key pairs (this makes a lot of sense), ESP alone will block unauthorized reading only. An attacker is still able to insert bogus packets without AH.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

Except that he'd have to have the session key, right? Which will be uhhh.. difficult to achieve in practice.

Or am I missing something?

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

Editor, the last sentence above the conclusion needs some editing. Do you want to say that absolute bandwidth is high or that is a lower but still high enough?


Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

Actually, we meant that the bandwidth is still high enough to be used in most applications.


Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

I suppose 100 Mbit cards are used within the network where the bandwidth is measured. This is a shame, because it means the bandwidth without IPSec is limited to a little more than10 Mbyte/sec.

To measure the performance hit of IPSec, it would be better to use a 1 Gbit network.


Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

AFAIK, IPsec is suposed to be used to create secure connections on top of an unsecure connection; usually that means internet. I can not think of any use for IPsec between two machines with a 1Gb connection between them.

Thus, IMHO, these benchmaks should have been performed on slower connections, more similar to real-world use. It would be much more informative to me knowing if IPsec slows down a connection running over ADSL.

Re: Benchmarks for Native IPsec in the 2.6 Kernel

Anonymous's picture

Actually, perhaps the notation used was not clear enough. We used capital B for bytes. Therefore the measures are on Mega Bytes and not Mega _bits_ .

Regarding 1 Gbit network, that could be useful, though in my understanding the restricting factor here is not the network as the most we can achieve with IPSec is under 5000 MBytes/sec which is under 100 Mbits/sec network capacity. Am I missing something?


Missing the comparison.

jafo's picture

Yes, the thing you're missing is in your comparison. You say that IPsec is giving about half the performance of an unencrypted connection, when the unencrypted connection seems to be limited by the network bandwidth where the encrypted one is limited by (I presume) CPU.

You'd probably want to just drop the comparison, because the useful information is how it performed, not how it performed in comparison with unencrypted over a high speed line. A friend and I transferred an ISO in 20 seconds the other day, for a rate of around 33MB/sec (probably limited by the discs on our laptops), so in that case it's more like 7x slower with encryption.

To answer the question about why would you encrypt gigabit. I can think of a few. First of all, not all public networks are low-speed. If you are hosting a security-sensitive set of systems at a third-party, ARP-poisoning the switch can allow third-parties to intercept the traffic.

Another case is how I have my home network set up. I run all my traffic to my home network over a tunnel to my firewall/gateway box, encrypted. I bridge that tunnel with the home network, so I get the same IP no matter where I go. I can access my printer and other devices at home when I'm away, printing invoices, etc... For convenience, I use that setup whether I'm at home or not, and when I'm at home and have large files to transfer I'll connect to my 100mbps wired network. With OpenVPN, I get around 7MB/sec (the firewall is a pretty old box). I could work around that with some tricks depending on whether I am at home or away, shutting down that one OpenVPN tunnel when I'm at home and just using a local address. This way is just easier.



Anonymous's picture

IPsec has a bad security record (being complex), see

OpenVPN works great on Linux and Windows. The tarball has .spec file
included for rpm-based systems. Use the 2.0 beta, it's quite stable.

Yes, IPsec has a security

Anonymous's picture

Yes, IPsec has a security record. Well documented. Yes, it is a bit
more complex than OpenVPN. But, it also has more than one implementation. OpenVPN is the Microsoft of security protocols.

OpenVPN, being obscure, has a less well known record of security flaws.

It's also trivially is susectable to denial of service attacks.

I just want to know if there

panky's picture

I just want to know if there are lib functions for upper applications calling.