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.

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.

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.

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.

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.

> 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.

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.

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?

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.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.