Using End-to-End IPsec for Secure Inter- and Intrasite

Network Communication

J O N A S S U N D B E R G

Master of Science Thesis Stockholm, Sweden 2011

Using End-to-End IPsec

for Secure Inter- and Intrasite Network Communication

J O N A S S U N D B E R G

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2011 Supervisor at CSC was Stefan Nilsson Examiner was Stefan Arnborg TRITA-CSC-E 2011:088 ISRN-KTH/CSC/E--11/088--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

Abstract

In this thesis, secure communication between many com-puters connected by an untrusted network is discussed.IPsec solves this by sending data with added authentica-tion by public key cryptography and optional encryption.

One problem that occurs when many hosts are involvedis how to define, distribute and enforce a policy for securecommunication in the network. Some earlier research intothis is presented as well as how it relates to the project.

A tool to generate IPsec configuration files was devel-oped. By grouping hosts by the services they provide, se-curity policies can be defined for each service instead of ona host-by-host basis. The grouping and policy is then usedto generate IPsec configurations to set up point-to-pointconnections between each pair of hosts that should be ableto communicate securely.

Some testing with regards to performance and stabilityis done. There were several stability issues during testing,showing the difficulty in configuring IPsec correctly. How-ever, later configuration updates have fixed these issues,making IPsec stable enough for trial use in production withcareful monitoring.

Sammanfattning

IPsec mellan slutnoder för säker

nätverkskommunikation inom och mellan

interna nätverk

I den här rapporten diskuteras säker kommunikation mel-lan ett stort antal datorer anslutna genom ett oskyddatnätverk. IPsec löser detta genom att lägga till autentise-ring med asymmetrisk kryptografi och valbar kryptering.

Ett problem när ett stort antal datorer ska kommunice-ra säkert är hur man ska definiera, distribuera och tillämpaen säkerhetspolicy som specifierar hur säker kommunika-tion ska tillämpas i nätverket. Tidigare forskning relateradtill detta presenteras med koppling till projektet som hargenomförts.

För att lösa detta har ett verktyg för att generera kon-figurationsfiler för IPsec tagits fram. Genom att dela in da-torer efter vilka tjänster de tillhandahåller kan man definie-ra en säkerhetspolicy efter vilka tjänster som tillhandahållsistället för direkt för varje dator. Den här gruppindelningenoch policyn kan sedan användas för att generera konfigura-tionsfiler för IPsec där varje dator får en direkt anslutningtill varje annan dator den ska kunna kommunicera med.

Viss testning har genomförts där prestanda och stabili-tet hos IPsec har undersökts. Under testningen upptäcktesett antal stabilitetsproblem, vilket visar att IPsec är svårtatt konfigurera korrekt. Senare uppdateringar i konfigura-tionen har dock åtgärdat dessa fel och IPsec anses varastabilt nog för småskalig driftsättning i produktion medutökad övervakning.

Contents

1 Introduction 1

1.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Scope Limitations . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Terminology and Abbreviations . . . . . . . . . . . . . . . . . . . . . 3

2 Background 5

2.1 Security Solutions in the Transport Layer . . . . . . . . . . . . . . . 52.2 Introduction to IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Systems Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Related Work 8

3.1 IPsec Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.1 strongSwan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 Openswan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.3 IPsec-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 IPsec Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1 Simple-VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Defining Policies for IPsec . . . . . . . . . . . . . . . . . . . . 9

4 Evaluated Solutions 11

4.1 Attribute Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Opportunistic Encryption . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Configuration File Generation . . . . . . . . . . . . . . . . . . . . . . 124.4 Selecting a Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Configuration Tools 13

5.1 Group Based Access Control . . . . . . . . . . . . . . . . . . . . . . 135.2 Distribution of Configuration Files . . . . . . . . . . . . . . . . . . . 135.3 Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6 Results and Conclusions 15

6.1 Single Site Transfer Speeds . . . . . . . . . . . . . . . . . . . . . . . 156.2 Cross-Site Transfer Speeds . . . . . . . . . . . . . . . . . . . . . . . . 156.3 Connection latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.4 Small Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176.5 System Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186.6 Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Recommendations and Future Research 19

7.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bibliography 20

Chapter 1

Introduction

1.1 Outline

This thesis will discuss some problems with securing communication between a largenumber of hosts at multiple locations. The rest of Chapter 1 will explain what theproblem is and set up the conditions for the project.

In Chapter 2, current Transport Layer solutions to the problem will be presented.IPsec and the systems that have been used for testing the proposed solutions willalso be introduced.

In Chapter 3, there will be a short introduction to the various IPsec imple-mentations for Linux as well as some discussion on previous work related to thisproject.

The three solutions that were evaluated during this project will then be discussedin Chapter 4, followed by further discussion about the selected solution in Chapter5.

Finally, Chapter 6 will discuss the testing done during the project and the resultsfrom these while some recommendations regarding IPsec and future research in thearea will be presented in Chapter 7.

1.2 Problem Definition

When two or more sites are connected in a single network such as the Internet,Virtual Private Network (VPN) gateways are often used to send data between thetwo sites. This way hosts in other parts of the networks are unable to read or modifythe data being sent between hosts in the private network.

The problem with this is the single point of failure, as well as a potentially highload on the gateways. The single point of failure can be avoided with redundantgateways, but this would increase the complexity of the system if a failover shouldbe possible without connection interruption.

Another issue is that many internal server networks focus their security measuresonly against attacks originating from outside the internal network. Firewalls seldom

1

CHAPTER 1. INTRODUCTION

prohibit traffic from hosts inside the protected network.A solution to both these issues would be to deploy Internet Protocol security

(IPsec) between all individual hosts in the network. This way, all communication hasto originate from authenticated sources. It also makes it possible to encrypt traffic,either between any pair of hosts or only when two hosts communicate between sites.

The problem with deploying IPsec is that it is complicated to set up and manageon a larger scale. The complexity makes it easy to make mistakes during configu-ration that could lead to severe consequences such as service outages or sensitivedata leaking to unauthorized users.

It might be possible to reduce the complexity in setting up and managing IPsec.Many hosts in a network might provide the same services. These hosts shouldprobably have similar security policies. To aid in configuration, it would be usefulto have a way of defining security policies for a specific service and translate this tosecurity policies for each individual host involved.

1.2.1 Scope Limitations

To limit the scope of the project, only IPsec deployment directly between hosts willbe considered. IPsec gateways are outside the scope of the project.

As the systems affected are similar, a single IPsec implementation will be usedand interoperability between IPsec implementations will not be an issue for thisproject.

For most IPsec deployments, some kind of public key infrastructure is used.It is assumed that any such infrastructure is already in place and setting up thatinfrastructure will not be covered by the project.

1.3 Project Goals

To facilitate IPsec deployment, a goal of the project is to specify a way to definesecurity policies for services and to generate security policies for each host given thelist of services that the host provides.

1.4 Research Questions

These are some questions that this project has tried to answer:

• How can IPsec be deployed in a larger network with separation between un-related parts of the network?

• What implications would an IPsec deployment have on the following:

– system load

– throughput

– latency

2

CHAPTER 1. INTRODUCTION

– reliability

– maintenance

• How can we ensure that no private IP traffic will be sent in plain text?

1.5 Requirements

To test using IPsec and various suggested solutions, a set of networked computersrunning Linux are required. These must have network connectivity both within asingle site as well as across sites for different testing scenarios.

1.6 Terminology and Abbreviations

DNSSEC

Domain Name System Security Extensions, a set of extensions to the DNSstandards that add authentication and integrity to DNS lookups.

ESP

Encapsulating Security Payload, a protocol that is part of the set of IPsecstandards. It is used to transmit IP packets with confidentiality, integrity andauthentication.

FAI

Fully Automatic Installation, a system for unattended installation of DebianGNU/Linux.

IKE

The Internet Key Exchange protocol is used in most IPsec deployments foragreeing on common algorithms and keys used in further communication.

IPsec

The Internet Protocol Security protocol suite. It provides authentication andencryption for IP packets.

JSON

JavaScript Object Notation is a language for human-readable data represen-tation.

Puppet

Puppet is an open source tool for configuration of servers. Changes in config-uration are published by the puppetmaster server and are pushed to or pulledby the puppet slaves.

RFC

Request for Comments. RFCs are technical documents specifying standards,

3

CHAPTER 1. INTRODUCTION

best practices and other information regarding internet protocols. They arepublished by IETF, the Internet Engineering Task Force.

TLS

Transport Layer Security is a protocol for secure communication. It is oftenused on top of TCP for securing data sent on a TCP connection and is usedfor VPN services.

VPN

Virtual Private Network is a concept where computers can communicate se-curely over a non-secure network. It uses security measures like IPsec or TLSto provide secure communication between the nodes in the network.

X.509

X.509 is a set of standards for a public key infrastructure with cryptographickeys, ownership certificates and certificate authorities.

4

Chapter 2

Background

Traditionally, many organizations have implemented a security policy with mostof the security in the perimeter of networks. It is often assumed that the internalnetwork is secure and that no malicious traffic will originate from inside the privatenetwork. If an attacker has access to a host on the internal network, it is oftenpossible to connect directly to other hosts on the network.

By adding security measures at the individual host level, additional security isachieved. Firewalls provide additional protection from hosts on the network, butan attacker on the network might be able to inpersonate a genuine host that thetarget will communicate with.

To mitigate this, authentication and authorization with IPsec can be added.This way a host is required to provide proof that they are, in fact, who they claimto be and that they have the correct authorization to communicate with specifichosts on the network.

An added bonus of using IPsec is that the traffic may be encrypted as well, pro-viding confidentiality in addition to authentication and authorization. This makesit possible to communicate between sites over the Internet without risking exposureof the data transmitted.

2.1 Security Solutions in the Transport Layer

IPsec is not the only solution for this problem. Another popular choice is usingTransport Layer Security (TLS) to fulfill security requirements. However, TLSrequires changes to the services running on the servers.

To use TLS, one could add security to each service running on the hosts. Thisrequires modification of every single service where the provided security is required,adding a prohibitive cost for adding and supporting security implementations ev-erywhere.

Another TLS based solution would be to add a separate address space for thevirtual private network and tunnel traffic through a separate VPN application. Thisincreases routing complexity, adds another address for each host and increases the

5

CHAPTER 2. BACKGROUND

amount of domain name configuration.

2.2 Introduction to IPsec

IPsec is a set of protocols for securing the transmission of IP datagrams [3, 5]. Theprotocol resides in the Internet Layer, in contrast to the application layer that TLSresides in. By residing in the Internet Layer, applications can be protected withouthaving to implement the security measures themselves. This keeps the necessarychanges in the hosted applications to a minimum.

To communicate securely, the hosts need a key for the encryption method used.This key can either be distributed beforehand or calculated by the two hosts whenthey set up the connection. If keys are precalculated, each host will have to receivea key for each other host with which it is supposed to communicate with. To avoidthis, a public and private key pair is generated for each host instead. These canthen be used to negotiate an encryption key for a single session by using a methodof key exchange. The most commonly used protocol for key exchange in IPsec isthe Internet Key Exchange protocol (IKE).

Figure 2.1. The structure of an IPsec ESP packet. Figure source: http://commons.

wikimedia.org/wiki/File:Ipsec-esp.svg

To actually send data, each IP packet transmitted is put inside an ESP packetas seen in Figure 2.1. ESP adds a cryptographic checksum and optional encryptionto each IP datagram separately, allowing authentication and confidentiality for thecommunication.

2.3 Systems Overview

The system targeted in this project consists of hundreds of servers in multiple datacenters located in both Europe and North America. These are all connected by inter-nal networks within the sites and the connections between sites are routed throughthe Internet. All involved hosts are running Debian GNU/Linux [1]. Some hostsare virtual machines running on top of a Linux Kernel-based Virtual Machine [7].

Initial setup of the hosts are done with Fully Automated Install (FAI) [8] andconfiguration changes are distributed using both FAI and Puppet [14]. These are twotools for remote installation and configuration of computer systems. To facilitateupdates through Puppet, a public key infrastructure using X.509 certificates isavailable.

6

CHAPTER 2. BACKGROUND

Several services are running on the network. These services are often distributedand load balanced over multiple hosts and individual hosts may run more than oneservice. The network is distributed over a number of sites. Some services areavailable at all sites while some others only exist in a subset of the sites. Allcommunication between the sites is transmitted over the Internet.

In addition to the services used for the production system, services for logging,monitoring, backup and remote shell access are running on all hosts.

7

Chapter 3

Related Work

3.1 IPsec Implementations

A native IPsec stack called NETKEY is available in the Linux kernel. This is theIPsec stack used by all major IPsec implementations for Linux. The public keyinfrastructure and configuration of IPsec is handled by separate implementationsinterfacing with the kernel.

There are three major IPsec implementation that interface with NETKEY.These are strongSwan, Openswan and IPsec-Tools.

3.1.1 strongSwan

strongSwan was forked from the earlier and now defunct FreeS/WAN IPsec im-plementation for Linux. It provides the IKEv2 daemon Charon for key exchangeand can also interoperate with the earlier Pluto for IKEv1. Documentation forstrongSwan is good and is available online [17].

strongSwan focuses on a core set of features and on security and stability. Manymore advanced features such as interoperability with non-standard IPsec implemen-tations are left out.

3.1.2 Openswan

Openswan is another fork of FreeS/WAN. There is documentation available on-line [12], but it is less comprehensive than the documentation for strongSwan. Asof May 2011, it has not been updated since 2007, making it an unreliable source ofinformation.

Compared to strongSwan, Openswan includes more features and additional usecases that strongSwan leaves out. This includes support for Opportunistic Encryp-tion and interoperability with a wide variety of non-standard IPsec implementations.

8

CHAPTER 3. RELATED WORK

3.1.3 IPsec-Tools

IPsec-Tools is a Linux port of the IPsec tools from KAME, an implementation orig-inally made for various BSD distributions. It uses its own IKE daemon Racoon [11].

The original IPsec-Tools implementation of Racoon does not support IKEv2,but there is a fork of the project with added IKEv2 support, called Racoon2 [13].

3.2 IPsec Configuration

One of the problems that have hindered IPsec deployment is that configuring IPsecproperly requires a significant time investment to be able to understand all settingsentirely and there is a risk that a misconfigured IPsec implementation might be lesssecure than intended [2].

3.2.1 Simple-VPN

Srivatsan, Johnson and Bellovin have implemented a tool, Simple-VPN [15, 16], thatprocesses a simple configuration language in order to generate the configurationfiles to set up IPsec. These configuration files can be generated for strongSwan,Openswan and Racoon.

Instead of leaving all configuration to the user, reasonable default values areselected automatically by Simple-VPN. This makes it possible to generate configu-ration files for IPsec over an entire network from a single manually edited file. Italso reduces the risk of misconfiguration of IPsec.

By removing complexity, IPsec features have naturally been removed from theend user as well. Some of these removed features might be required in this project’suse case, such as allowing a single host to be part of multiple private networkssimultaneously. Similarily, there is no option to selectively encrypt traffic dependingon port numbers or IP addresses involved in the individual connections.

3.2.2 Defining Policies for IPsec

To separate unrelated parts of the network from each other, it would be helpful tobe able to define a policy with this in mind. Ordinarily, IPsec configuration is doneon a host-by-host basis. There have, however, been some research into definingpolicies on a higher level.

Li notes [9] that manual configuration of individual nodes is complex and proneto errors. A policy-based management system is introduced that defines a policyfor a specific role and defines the policy for a host from the applicable roles for thatspecific host.

To distribute the policies, Li uses a policy server. The individual clients querythis server and generate the appropriate IPsec configuration files from the reply theyget. This server then pushes updates to the associated hosts whenever a policy ischanged.

9

CHAPTER 3. RELATED WORK

Yin and Wang proposed [18] a solution where policies are defined for each ap-plication running on the hosts. They then use what they call an application policyengine to generate the fine-grained IPsec rules to implement the application policy.

This solution provides a transparent way to add security to applications andworks without changing the IPsec or IKE implementations. They instead use thePF_KEY protocol [10] to add security associations to the policy database. Theirperformance tests show that IPsec can provide end-to-end security to legacy appli-cations with performance comparable to other security measures.

10

Chapter 4

Evaluated Solutions

After investigating the requirements on the system and the various options avail-able from IPsec implementations, some options were evaluated. The configurationpossibilities as well as the technical feasibility was evaluated for each option.

4.1 Attribute Certificates

The first option that was evaluated was to use Attribute Certificates to add anattribute to a host for each group it belongs to. This would remove the need forevery host to know about each host it should be able to connect to beforehand.

However, current IPsec implementations has little or no support for AttributeCertificates. The certificates could not be sent as part of the initial negotiation andhad to be available on the other end point beforehand instead. Additionally, dueto the nature of the Linux IPsec stack, it was not possible to have multiple rulesapplying on a single network and choose which rules to apply based on the providedAttribute Certificates.

To make it a reasonable solution, support for fetching Attribute Certificatesduring negotiation would have to be added to an IPsec implementation. This wouldrequire studying and modifying the source code of an existing implementation andmight require maintaining a patched version of the implementation unless the codeis accepted into the mainline source code. It has not been investigated if the IPsecRFC:s have room for Attribute Certificate transmission during the key exchangephase of IPsec.

4.2 Opportunistic Encryption

Opportunistic Encryption is a method for fetching IPsec keys for a recipient server.By adding reverse DNS entries with the encryption keys for each host, the hostscan look up the recipient’s keys before sending packets to it. This relies on thesecurity of DNS lookups, which can be protected with regular IPsec or DNSSECconnections to a reliable DNS server.

11

CHAPTER 4. EVALUATED SOLUTIONS

After investigating this option, it appeared as if the support for OpportunisticEncryption has declined in the last couple of years. The support in strongSwan wasbadly maintained and only available for IKEv1 [A. Steffen, personal communication,2011-02-28]. Opportunistic Encryption has better support in Openswan, but thelack of updated documentation makes it difficult to assess the current status ofthe support for it. Opportunistic Encryption support was not mentioned in thedocumentation for Racoon2.

4.3 Configuration File Generation

Another option that was evaluated was to use an existing IPsec implementationand generate persistent point-to-point connections for each pair of hosts that aresupposed to be able to communicate with each other. The concept of groups willthen only be visible in the input files to the software and will not be visible in thefinal IPsec configuration on the individual hosts.

This option has the advantage of using existing implementations and only addinga utility to simplify the process of configuration. The majority of testing of the IPsecimplementations is done on the simpler point-to-point mode this would use, whichwould reduce the need for testing.

However, some hosts might be authorized to connect to a large set of otherhosts on the network and persistent point-to-point connections to every one of themmight put a larger load on the hosts or the IPsec implementations. Because of this,performance and load testing will still be required to be confident in this solution.

4.4 Selecting a Solution

After evaluating the three options, it was decided to do initial performance testingof strongSwan with a slightly modified version of Simple-VPN [16] to verify thatgenerating configuration files would be a reasonable solution. After verification, aseparate configuration utility – with support for ordering hosts into groups – wasdeveloped.

12

Chapter 5

Configuration Tools

After initial performance testing, an in-house tool for configuring IPsec was devel-oped. This tool started off with copying the functionality used from Simple-VPNand was later expanded with an added concept that hosts provides a set of services.

The first step in building a configuration tool was to implement a way to generatethe IPsec connection configuration for a host, given a list of peers it should be ableto communicate with. A prototype was developed that reads this list of hosts froma JSON file and outputs a strongSwan configuration file.

To generate the full mesh of connections for all hosts, a script was written thattransferred a list of hosts to a set of lists with all other hosts listed as peers to everyhost in the JSON format used by the prototype.

5.1 Group Based Access Control

Having a full mesh IPsec setup with persistent connections between every pair ofhosts is not scalable to larger deployments. The security level is also reduced ifhosts are allowed to communicate with unrelated machines on the network.

To remedy this, the concept of groups is introduced to the tools. All hosts aregiven lists of groups that they belong to and each group has a list of groups thathosts belonging to the group should be able to communicate with. These lists arethen used to generate the necessary configuration files for strongSwan.

5.2 Distribution of Configuration Files

To distribute the configuration files and make sure that no communication is sentin plain text, the IPsec implementation has to be integrated with administrationand monitoring tools.

Puppet is a tool to centralize the configuration of machines. When using Puppet,machines run the Puppet client software and use this to communicate with thepuppetmaster, a central server where all configuration can be set. The puppetmasterthen updates all client machines when configuration files change.

13

CHAPTER 5. CONFIGURATION TOOLS

By generating all configuration files and adding these to the puppetmaster, allIPsec configuration can be distributed to the individual hosts from a single point.This makes it possible to change policy and be sure that all hosts are updated withconfiguration files reflecting this policy change within the update interval used forPuppet.

5.3 Network Monitoring

IPsec by itself does not provide any way to avoid sending data in plain text. Inorder to make sure that no traffic that should be IPsec protected will be sent inplain text instead, machines must run packet filtering firewalls to handle this.

A firewall can identify packets that are related to IPsec and use regular firewallfiltering on these packets. For packets sent without IPsec protection, the firewallcan be used to log or block this traffic.

While deploying IPsec to a new host, logging but still allowing non-IPsec trafficwill allow verification that IPsec is running without disturbing the traffic flow. Thiscan, however, only be done if services are not sending sensitive data across a publicnetwork.

14

Chapter 6

Results and Conclusions

To verify the network performance when using IPsec, transfer speed was measuredusing the tool iperf [4]. One gibibyte of data was sent in a TCP connection and thetime to send this data was measured to calculate available bandwidth both withand without IPsec. The transfer speeds presented below are with single connections.Results for multiple parallel connections were comparable.

To measure how much the latency of the connections are affected by IPsec,the ping tool was used to send one hundred ICMP echo requests and measure theaverage round trip time.

Long term testing was also run to verify stability of the IPsec software imple-mentation. This involved a set of hosts simulating a production environment whileothers involved in the project were monitoring the behaviour of the hosts.

6.1 Single Site Transfer Speeds

The tests began with testing connections in a single site with a switched networkbetween participating hosts. The results are available in Figure 6.1.

There was a significant reduction in maximum throughput. This might slowdown services requiring high bandwidth for optimal performance.

6.2 Cross-Site Transfer Speeds

One of the major reasons for encrypting network traffic is to be able to send con-fidential data across unprotected networks such as the Internet. To allow for this,throughput benchmarks with and without IPsec were run between data centers inEurope and North America.

As seen in Figure 6.2, the reduction in throughput is less noticable when theoverall capacity is reduced and higher latencies are introduced. This is an indicationthat the host performance was limiting the throughput for same-site communication.

15

CHAPTER 6. RESULTS AND CONCLUSIONS

Single connection Multiple connections

0

200

400

600

800

1000 937 939

321 304

Same−site throughput

IPsec off IPsec on

Thro

ughp

ut

(Mbit/

s)

Figure 6.1. Transfer speeds with and without IPsec with a single TCP connection.

Single connection Multiple connections

0

100

200

300

400

159

345

121

191

Cross−site throughput

IPsec off IPsec on

Thro

ughp

ut

(Mbit/

s)

Figure 6.2. Transfer speeds with communication between separate sites.

6.3 Connection latency

ICMP echo requests were sent to measure the latency of the connection with andwithout IPsec, as seen in Figures 6.3-6.4.

Within a single site, all network traffic is switched directly between hosts, makingthe higher latency clearly visible in tests. The actual latencies are, however, stillvery small.

Moving to a cross-site latency test between Europe and North America, theincrease in latency is measurable but for all purposes irrelevant.

16

CHAPTER 6. RESULTS AND CONCLUSIONS

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.2

0.33

Same−site latency

IPsec off IPsec on

Av

erag

e la

ten

cy (

ms)

Figure 6.3. Connection latency with communication within a single site.

0

20

40

60

80

100

120103.43 105.22

Cross−site latency

IPsec off IPsec on

Av

erag

e la

ten

cy (

ms)

Figure 6.4. Connection latency with communication between Europe and North

America.

6.4 Small Packets

Many network services have very small packet sizes for both requests and replies.To test this, an in-house HTTP testing tool was used to generate a large amount ofrequests against a key-value service with an HTTP interface. The service receivesa HTTP GET request with a specific key and replies with the value correspondingto that key.

The results, as seen in Figure 6.5, show that there was a slight reduction innumber of requests handled per second.

17

CHAPTER 6. RESULTS AND CONCLUSIONS

0

1000

2000

3000

4000

5000

6000

7000

8000

6682

5670

Key−value service performance (same−site)

IPsec off IPsec on

Req

ues

ts p

er s

econ

d

Figure 6.5. Results from performance testing with small packets.

6.5 System Load

During the performance testing, the system load was monitored for any changes. Itwas detected that a single CPU core was running on full load during the transferspeed tests.

Single-threaded cryptography operations was suspected to be the cause of theslower transfer speeds identified when IPsec was active. Work has been done to addmulti-threaded support for cryptography operations in the Linux kernel [6], but itis still marked as an experimental feature. Using this support for IPsec might affectthe throughput performance positively.

6.6 Stability

During testing, it was noticed that security associations sometimes failed to negoti-ate new encryption key and the IPsec daemon failed to reestablish a secure tunnelbetween hosts. When an error occured, all traffic between involved hosts – includ-ing plaintext communication – was stopped, interrupting any service communicatingbetween the two hosts.

The errors were caused by misconfigurations and misunderstandings of IPsecand the IKE implementation used, highlighting the difficulties noted by Fergusonand Schneier [2]. Additional testing indicates that these issues have been resolvedwith later updates to configuration files.

18

Chapter 7

Recommendations and Future Research

7.1 Recommendations

The initial testing with throughput benchmarks showed a significant reduction inthroughput. Depending on the services communicating over IPsec, this might posea problem. For services limited more by processing power and latencies than rawnetwork throughput it should be less of an issue.

The stability issues seen during testing show that misconfiguration can haveserious consequences. Careful consideration and thorough testing will be requiredwhen changing these configurations to avoid any stability issues.

7.2 Future Research

To reduce the throughput limit that the speed of a single CPU core puts on theconnection, the recent addition of parallelized cryptography operations in the Linuxkernel [6] is an interesting option. Further research into using this and the effectson the performance might be worthwhile.

The configuration utility developed in this project only supports end-to-endconnections. Some devices might not support using the configuration generated bythis tool and some might not have any IPsec support whatsoever. To allow theseto communicate with IPsec, support for gateway configurations could be added tothe tools.

19

Bibliography

[1] Debian Project. Official website. http://www.debian.org, Retrieved 2011-06-22.

[2] Niels Ferguson and Bruce Schneier. A cryptographic evaluation of IPsec. Tech-nical report, Counterpane Internet Security, Inc, 2000.

[3] Steve Friedl. An illustrated guide to IPsec. http://www.unixwiz.net/

techtips/iguide-ipsec.html, Retrieved 2011-06-23, August 2005.

[4] Iperf. Official website. http://iperf.sourceforge.net, Retrieved 2011-06-22.

[5] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301(Proposed Standard), December 2005. Updated by RFC 6040.

[6] Steffen Klassert. Parallel crypto/IPsec v7. Linux Kernel Mailing List. http://

lkml.org/lkml/2009/12/23/30, Retrieved 2011-06-22, December 2009.

[7] Linux KVM. Official website. http://www.linux-kvm.org, Retrieved 2011-06-22.

[8] Thomas Lange. FAI Project official website. http://fai-project.org, Re-trieved 2011-06-22.

[9] M Li. Policy-based IPsec management. IEEE NETWORK, 17(6):36–43, NOV-DEC 2003.

[10] D. McDonald, C. Metz, and B. Phan. PF_KEY Key Management API, Version2. RFC 2367 (Informational), July 1998.

[11] Bill Nottingham, Brian Buesker, Christophe Saout, Kimmo Koivisto, and RalfSpenneberg. IPsec tools homepage. http://ipsec-tools.sourceforge.net,Retrieved 2011-06-22.

[12] Openswan. Openswan wiki. http://wiki.openswan.org, Retrieved 2011-06-22.

[13] The Racoon2 Project. Official website. http://www.racoon2.wide.ad.jp,Retrieved 2011-06-22.

20

BIBLIOGRAPHY

[14] Puppet Labs. Official website. http://www.puppetlabs.com, Retrieved 2011-06-22.

[15] Shreyas Srivatsan, Maritza Johnson, and Steven M. Bellovin. Simple-VPN.http://simple-vpn.sourceforge.net, Retrieved 2011-06-22.

[16] Shreyas Srivatsan, Maritza Johnson, and Steven M. Bellovin. Simple-VPN:Simple IPsec configuration. Technical Report CUCS-020-10, Departmentof Computer Science, Columbia University, http://mice.cs.columbia.edu/

getTechreport.php?techreportID=1433, July 2010.

[17] strongSwan. strongSwan user documentation. http://wiki.strongswan.org/

projects/strongswan/wiki/UserDocumentation, Retrieved 2011-06-22.

[18] Heng Yin and Haining Wang. Building an application-aware IPsec policy sys-tem. IEEE/ACM Trans. Netw., 15:1502–1513, December 2007.

21

TRITA-CSC-E 2011:088 ISRN-KTH/CSC/E--11/088-SE

ISSN-1653-5715

www.kth.se