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

Now, you certainly can understand why this type of configuration is less secure. Keeping a system secure with secret keys in clear text in a configuration file is not practical. But don't worry, the people behind IPsec have thought about it and have come up with a protocol to negotiate keys and set up secure connections automatically. This functionality is implemented by Racoon. With Racoon, you do not need to specify any SAs; you need to specify only the SP. Racoon dynamically defines the SAs, and of course, you need to configure Racoon. The Racoon daemon runs on UDP port 500, which means that your firewall rules should not block this port on your system. We are not going into the details of setting up Racoon here, but refer to the HOWTO listed in Resources for more information.

Benchmark Results

We used Netio benchmarking software to test the new native IPsec implementation on a 2.6.7 kernel. We used two Pentium IV 2.2GHz machines with 512MB of memory. Netio measures the throughput of a network by way of TCP and UDP and different packet sizes. We established a secure connection using transport mode with the encryption algorithm 3DES (key size = 192 bits) and SHA1 for integrity checks. You can see the results in Table 1 for TCP and in Table 2 for UDP.

Table 1. Results from Netio TCP Benchmark

Packet SizeBandwidth without IPsecBandwidth with IPsec
1KB10905KB5157KB
2KB10832KB5222KB
4KB10827KB5305 KB
8KB10811KB5263KB
16KB10814KB5345KB
32KB10729KB5374KB

Table 2. Results from Netio UDP Benchmark

Packet SizeBandwidth without IPsecBandwidth with IPsec
1KB11479KB4806KB
2KB11244KB4320KB
4KB11698KB4985KB
8KB11714KB5116KB
16KB11725KB5152KB
32KB11743KB5271KB

We can see that IPsec diminishes by half the throughput of a TCP or UDP connection. Although the absolute bandwidth still is high--worst case is 4.3MB/sec--it is enough for most applications.

Conclusion

The new native IPsec implementation has a user-friendly interface to enable users to set up secure connections easily among different Linux systems. The results of our tests show that even though there is need for some improvements with regards to the stability of the implementation, the performance of the new native IPsec implementation makes it a good candidate for use by SOHOs as well as mid-sized enterprises. The new Linux IPsec implementation pushes Linux farther along the path to becoming a natural choice for many security needs of SOHOs and mid-sized companies.

Vincent Roy and Makan Pourzandi work at the Open Systems Lab at Ericcson Canada.

______________________

Comments

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.

Makan

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.

Makan

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?

Frodo

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.

Makan

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.

Frodo

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?

Makan

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.

Sean

OpenVPN

Anonymous's picture

IPsec has a bad security record (being complex), see
http://www.giac.org/practical/GSEC/Charlie_Hosner_GSEC.pdf

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.
http://openvpn.sourceforge.net/

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.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState