Loading
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.
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.
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 Size | Bandwidth without IPsec | Bandwidth with IPsec |
|---|---|---|
| 1KB | 10905KB | 5157KB |
| 2KB | 10832KB | 5222KB |
| 4KB | 10827KB | 5305 KB |
| 8KB | 10811KB | 5263KB |
| 16KB | 10814KB | 5345KB |
| 32KB | 10729KB | 5374KB |
Table 2. Results from Netio UDP Benchmark
| Packet Size | Bandwidth without IPsec | Bandwidth with IPsec |
|---|---|---|
| 1KB | 11479KB | 4806KB |
| 2KB | 11244KB | 4320KB |
| 4KB | 11698KB | 4985KB |
| 8KB | 11714KB | 5116KB |
| 16KB | 11725KB | 5152KB |
| 32KB | 11743KB | 5271KB |
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.
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.
- « first
- ‹ previous
- 1
- 2
- 3
______________________
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- RSS Feeds
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Ahh, the Koolaid.
2 hours 36 min ago - git-annex assistant
8 hours 36 min ago - direct cable connection
8 hours 59 min ago - Agreed on AirDroid. With my
9 hours 9 min ago - I just learned this
9 hours 13 min ago - enterprise
9 hours 43 min ago - not living upto the mobile revolution
12 hours 34 min ago - Deceptive Advertising and
13 hours 10 min ago - Let\'s declare that you have
13 hours 11 min ago - Alterations in Contest Due
13 hours 12 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
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.
Developer Poll
Comments
Re: Benchmarks for Native IPsec in the 2.6 Kernel
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
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
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
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
I wonder if any of the 64-bit processors would be more efficient at the encryption algorithms?
64-bit performance
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
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
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
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
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
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
> 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
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
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
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
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
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
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.
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
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
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
I just want to know if there are lib functions for upper applications calling.