BSDCan2016 - v1.1.24a
BSDCan 2016
The Technical BSD Conference
| Speakers | |
|---|---|
|
George Neville-Neil |
|
Jim Thompson |
| Schedule | |
|---|---|
| Day | Talks #2 - 11 June - 2016-06-11 |
| Room | DMS 1110 |
| Start time | 13:30 |
| Duration | 01:00 |
| Info | |
| ID | 727 |
| Event type | Lecture |
| Track | Plenary |
| Language used for presentation | English |
Through the Wire
Measurement and Improvement of a software based IPsec implementation
The FreeBSD operating system has had at least two software based implementations of the IPsec protocols since they were first standardized in the 1990s. The original IPsec code came from the KAME project, along with IPv6, and later, a faster version of IPsec was added in parallel. The two code bases were merged into what is currently present in FreeBSD to this day. As part of our continuing longitudinal study of the performance of the network subsystems we have turned out attention to IPsec, looking at both the performance of the overall framework as well as the performance of more recent encryption and authentication protocols such as AES-GCM. Utilizing the native performance tool set on FreeBSD, including hwpmc(4) and DTrace we have tracked down various bottlenecks within the system and propose changes to clear them.
For this talk we will cover a baseline and two cryptographic implementations of the Advanced Encryption Standard (AES) Galois Counter Mode (GCM) that are a part of the IPsec subsystem in FreeBSD. We show the base performance of the system, the overhead induced by software crypto and the performance gain from hardware assisting instructions. Along the way we demonstrate how we do the measurements and what they mean for the system overall.
For the current study we looked at the performance of the IPsec framework with three different configurations, while using the same network topology. In each test we ran multiple trials using the iperf3 program to generate single as well as parallel streams of packets between a source and a sink across a VPN tunnel. Our variables were the encryption and authentication algorithms used as well as whether or not specialized cryptographic instructions were enabled on the CPU.