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.
A Simple Scenario

The following listing is used to illustrate how to set up a secure connection between two computers on different LANs. Below, we provide the script file of gouda that sets a secure connection between two systems. gouda is at IP address and reblochon is at IP address

 1: #!/usr/local/sbin/setkey -f
 2: flush;
 3: spdflush;
 5: # AH gouda to reblochon
 6: add ah 1000
 7:         -A hmac-md5 "1234567890123456";
 8: add ah 2000
 9:         -A hmac-md5 "1234567890123456";
11: # ESP gouda to reblochon
12: add esp 1001
13:         -E 3des-cbc "123456789012345678901234"
14:         -A hmac-sha1 "12345678901234567890";
15: add esp 2001
16:         -E 3des-cbc "123456789012345678901234"
17:         -A hmac-sha1 "12345678901234567890";
19: spdadd any -P out IPsec
20:         esp/transport//require
21:         ah/transport//require;
23: spdadd any -P in IPsec
24:         esp/transport//require
25:         ah/transport//require;

For reblochon, we use the same script file with only the following differences on line 19:

19: spdadd any -P in IPsec

and on line 23:

23: spdadd any -P out IPsec

Note the in and out keywords are reversed.

In line 1, the setkey command is invoked. This program inserts or deletes IPsec rules in the kernel. In lines 2 and 3, we use the setkey command to clear all security associations (SA) and security policies (SP), because we want to begin from a clean state.

Before diving into more technical details, we need to become familiar with two basic concepts in IPsec protocol, security association (SA) and security policy (SP). An SA defines the security parameters, for example, the crypto algorithm to be used, to create a secure connection between two systems. An SP, on the other hand, is the security rule defining the security context to be used between the two systems. For example, an SP can specify that we need to use encryption between my desktop and a remote system on the Internet. An SA then is the effective secure connection created between my desktop and that system. Be aware that SAs are unidirectional.

In our scenario, we define two SPs between reblochon and gouda. An SP is defined as:

source | destination | on which kind of traffic to apply the policy (TCP, UDP, port, any) | 
the direction in/out | what to do (IPsec/discard/none) | (esp/ah) / (transport/tunnel) / 
(IP address of both ends of the tunnel) not required in transport mode / require.

For example, these lines:

spdadd any -P out IPsec

declare a security policy stating that any packets coming from and going to should use IPsec on transport mode with ESP and AH functionality.

Now that you defined the policy between your systems, you need to define SAs in order to be able to achieve that policy. You need two SAs for communication, one from gouda to reblochon and one from reblochon to gouda. The two SAs do not need to use the same algorithm. In fact, unlike this example, for better security you should not use the same key for both SAs.

You define a SA as

source | destination | ah/esp | SPI (Security Policy Index) any number but should be unique 
| algorithm and associated secret key. 

For example, these lines:

add esp 1001
         -E 3des-cbc "123456789012123456789012"
         -A hmac-sha1 "12345678901234567890";

define that if you want to use ESP on a packet going from gouda to reblochon, you should use 3DES as the encryption algorithm with the quoted text as the key and SHA1 as the authentication algorithm.

Now, you finally can run the script on both nodes. You can check the status of different SAs established by using setkey -D. If you want to see existing policies on your system, you can use setkey -DP. At the end, to be sure that the traffic between two systems actually is encrypted, you can use Ethereal to monitor the traffic between two nodes. For example, in Figure 1, we show the traffic between two systems exchanging messages containing the "hello world" text. As you see, the message is encrypted between gouda and reblochon.

Figure 1: Ethereal Snapshot Showing Encrypted Communications



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.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot