Overhead Issues for Local Access Points in IPsec enabled VPNs
John Ronan, Paul Malone, Mícheál Ó Foghlú
Telecommunications Software Systems Group (TSSG)
Waterford Institute of Technology, Ireland.
Email: {jronan, pmalone, mofoghlu}@tssg.org
implications of using IP security (IPsec)[5] to achieve this
Abstract
goal. This, in turn, brought about a more detailed
investigation as it became apparent that there were scalability
Virtual Private Networks (VPNs) use the Internet or other
issues involved. The results of this work will feed directly into
network service as a backbone to provide a secure
the decision making process of the Agent Based SRM
connection across a potentially hostile WAN. Such security
(Service Resource Management) system in TORRENT.
guarantees provide the motivation for VPN deployment. This
security does, however, come at a performance cost brought
2. Context
about by the increased processing overhead. This paper
presents an investigation into these overheads. In particular,
2.1
TORRENT Overview
this investigation will consider the server side overhead for
VPN deployments and seek to establish a relationship
Among the expected outputs of the IST supported
between this overhead and the number of clients being
TORRENT project is a testbed providing for residential,
serviced.
multi-service access networks. This testbed (Figure 1) will
allow the project to demonstrate the benefit of intelligent
control, both for the customer and for the network operators
Index Terms—Communication System Security,
Cryptography.
and service providers.
An important additional need is to optimise the bandwidth
1. Introduction
utilisation in existing access and core networks, while at the
same time meeting a user’s requirements in an optimal
he results of this work comes from several different VPN
Tscenarios which have been tested, measured and
user control window
service &
?subscribe,
resource management
analysed. The tests were performed on IPv4 and IPv6
?stop, start
?modify/adjust
networks and results were collected for several client
?QoS
network topology / status
enumerations in both IPv4 and IPv6 control scenarios in
addition to the IPv6 enciphered scenarios. Two different
core
Linux kernel versions were used, firstly a vanilla or stock
network
home
kernel[1] and secondly the USAGI[2] kernel which replaces
distribution system
the entire IPv6 stack with its own, more standards conformant
access
network
version.
core
network
residential
The results will demonstrate a relationship between the
gateway
local
access point
number of clients connected to a Local Access Point [3] (LAP
– essentially a ‘smart’ router which sits between the access
Figure 1 - TORRENT Architecture
network and the core network) and the load placed upon the
manner. These requirements include Quality of Service
LAP. From this it should be possible to define limits to the
(QoS), security, cost, and availability.
number of clients that each LAP is capable of servicing while
guaranteeing QoS requirements.
2.2
Motivation for IPsec deployment
This work has evolved from an investigation within the
It was proposed early in the TORRENT project lifecycle to
TORRENT IST [4] project where it was deemed desirable to
integrate IPv6 as the transport protocol and IPsec as a service
offer a service which consisted of a secure communications
for securing the data between the RG and the LAP. It was
channel between a Residential Gateway (RG) and a LAP. In
understood that there would be performance implications
time, this led to an evaluation of the performance
arising from this, which were not quantified at the time. The

---

work presented here is a result of a desire within TORRENT
between two hosts, generally used to secure the traffic
to gain an understanding of these performance implications.
of the upper layer protocols.
• Tunnel Mode SA: This is a security association in an
3. IPsec Protocol Suite
IP-in-IP tunnel, generally used in connecting to
IPsec is the security architecture for the Internet Protocol
security gateways.
(IP). This protocol is applicable to both IPv4 and IPv6. The
architecture is defined in [5] and addresses the following 4
3.3
Key Management
elements:
IPsec mandates support for two separate methods of
cryptographic key and SA management: manual and
A. Security Protocols: Authentication Header (AH) [6]
automatic.
and Encapsulating Security Payload (ESP)[7].
• Manual Key Management: This is the simplest form of
B. Security Associations: Definition, management and
key management and involves each IPsec connection to
processing.[8]
be configured manually on both hosts. While this is
suitable in small static situations, it is unsuitable in
C. Key Management: The Internet Key Exchange (IKE)
larger deployment scenarios due to scalability
[8],[9],[10],[11].
problems.
D. Algorithms: Requirements of the authentication and
• Automatic Key and SA Management: Larger
encryption algorithms.
deployment scenarios call for an Internet-standard,
scalable and automated SA and key management
3.1
Security Protocols
protocol. This is provided by Internet Key Exchange
(IKE). IKE is required to allow for use of anti-replay
Traffic Security is provided by two security protocols:
features of AH and ESP and to facilitate on-demand
•
creation of SAs.

The Authentication Header protocol [6] provides
connectionless integrity and data origin authentication.
There is also an optional anti-replay service available.
3.4
Algorithms
The IPsec protocol suite does not define the authentication
• The Encapsulating Security Payload protocol [7]
and encryption algorithms used in implementations. These
potentially provides two types of security service. The
are defined in individual RFCs per algorithm. Algorithms
first being confidentiality via encryption and limited
used in these tests were:
traffic flow confidentiality. The second type is
DES [12]
connectionless integrity, data origin authentication and
AES [13]
an anti-replay service.
HMAC-MD5 [14]
Either of these protocols can be applied alone or in
4. The WIT IPv6 IPsec Testbed
combination, thus providing the desired level of security. The
To perform the tests required to examine the performance of
IPsec security protocols are represented by headers that
the various IPsec scenarios, a testbed was set up. All hosts
appear before the IP header in the IP packet.
were interconnected using a Cisco 2924 Ethernet switch
using their own isolated VLAN.
3.2
Security Associations
A logical view of this testbed configuration is shown in
The security protocol headers do not contain information
Figure 2. This view shows all six test machines configured
pertaining to the cryptographic algorithms and the associated
with IPv4 and IPv6 addresses. From a physical viewpoint, the
parameters. These representations are achieved through the
testbed has at its core a Flextel WebVision 4012 (identical to
transmission of a Special Parameter Index (SPI). This index
the TORRENT LAP), which provides 12 multipurpose slots
combined with the destination IP addresses and the type of
each of which can take processor cards or I/O carrier cards.
protocol header (AH or ESP) determines the parameters of
Four of processor blades acted as hosts for the testbed. Each
the IPsec processing.
of these processor blades was equipped with dual Pentium III
These parameters of a unidirectional security service are
850Mhz processors, 512 MB RAM and an Intel Ethernet Pro
represented by a Security Association (SA). There are two
100 network card integrated onto the motherboard. The other
types of SAs:
two hosts used in the testbed consist of two Dell PIII 500Mhz
• Transport Mode SA: This is a security association
desktop machines with 100Mbit 3Com 3c905 Network Cards.

---

aragorn
5. The Tests and the Test Scenarios
IPv4 - 10.37.200.3
IPv6 - fec0::1:10:37:200:3/64
Performance tests were organised as follows:
Host aragorn acted as the netperf server. This was invoked
using the following command:
aragorn:#netserver -6
Where the –6 option enables IPv6 performance testing.
gandalf
theoden
IPv4 - 10.37.200.2
IPv4 - 10.37.200.24
IPv6 - fec0::1:10:37:200:2/64
IPv6 - fec0::1:10:37:200:3/64
Scripts were written which ran Netperf User Datagram
Protocol (UDP)[19] and Transmission Control Protocol
(TCP) [20] stream tests. Each test was 4 minutes in length
and was performed 3 times. The content of these scripts is
bilbo
frodo
IPv4 - 10.37.200.26
IPv4 - 10.37.200.4
IPv6 - fec0::1:10:37:200:26/64
IPv6 - fec0::1:10:37:200:4/64
#!/bin/sh
#TCP Stream test
time=240
./netperf -H aragorn.tssg.org -t TCP_STREAM -C -c -l $time
./netperf -H aragorn.tssg.org -t TCP_STREAM -C -c -l $time
./netperf -H aragorn.tssg.org -t TCP_STREAM -C -c -l $time
sam
IPv4 - 10.37.200.5
Listing 1: Netperf TCP Stream test script
IPv6 - fec0::1:10:37:200:5/64
Figure 2 - Testbed configuration
#!/bin/sh
4.1
Software
#TCP Stream test
time=240
Each host was configured with the following software:
./netperf -H aragorn.tssg.org -t UDP_STREAM -C -c -l $time
./netperf -H aragorn.tssg.org -t UDP_STREAM -C -c -l $time
./netperf -H aragorn.tssg.org -t UDP_STREAM -C -c -l $time
Operating System:
SuSE Linux 8.0 [15]
Listing 2: Netperf UDP Stream test script
Kernel Version:
‘Vanilla’ Linux Kernel 2.4.19 [1]
shown in Listing 1 and Listing 2.
USAGI Linux Kernel 2.4.19 [2]
The purpose was to establish relationships between the
In order to reduce the variables, we chose the 2.4.19 kernel
performance overhead in the server (aragorn) and the
as it was a relatively recent kernel and the USAGI stable
number of clients being served. With this in mind, the above
Release 4, dated October 7 2002, which is based on this
tests were first run sequentially on 1 client (gandalf), then on
kernel.
2, 3, 4 and finally, all 5 clients.
The test start times were set up on each client using the
Network performance Benchmarking:
standard unix job scheduler cron. All hosts times were
Netperf version 2.2.pl2 [16]
synchronised to a local time-server using the netdate utility.
Having searched for tools to do throughput testing that
This test set was repeated for each of the following
included metrics for CPU utilisation and also had IPv6
scenarios:
support. Netperf seemed to suit our needs after it had been
patched with the KAME IPv6 patch [17].
5.1.1
Control Scenario: IPv4
IPsec Software:
Protocol
IPv4
The USAGI kernel and all its supporting utilities were
IPsec
No
compiled and installed as per the USAGI documentation.
Kernel
Vanilla 2.4.19
Pluto, the IKE daemon had to be patched [18] to allow for
USAGI 2.4.19
automatic usage of the AES algorithm as manual keying
Bandwidth Limited
None
proved problematic.
This scenario (IPv4 tests with no IPsec VPN deployed) was

---

used as a guide to throughput and overhead figures.
TCP Throughout
5.1.2
Control Scenario: IPv6
Protocol
IPv6
100
IPsec
No
90
80
Kernel
Vanilla 2.4.19
70
USAGI 2.4.19
60
Bandwidth Limited
None
Vanilla IPv4
Mbit / sec
50
USAGI IPv6
This scenario was used as a guide to throughput and
40
IPsec-des IPv6
30
overhead for IPv6 with no IPsec VPN deployed.
IPsec-aes IPv6
20
10
5.1.3
IPsec Scenario 1: IPv6
0
1
2
3
4
5
Protocol
IPv6
Number of Clients
IPsec
SA
Transport Mode
Auth
HMAC-MD5
Enc
3des-cbc
Kernel
USAGI 2.4.19
Figure 3 - TCP Throughput
Bandwidth Limited
None
TCP Overhead
This scenario provided results for throughput and overhead
for IPv6 tests with IPsec VPNs deployed using the 3des-cbc
100
algorithm for encryption.
90
80
5.1.4
IPsec Scenario 2:IPv6
70
60
Protocol
IPv6
% CPU
Vanilla IPv4
50
IPsec
SA
Transport Mode
Utilisation
USAGI IPv6
40
IPsec-des IPv6
Auth
HMAC-MD5
30
IPsec-aes IPv6
20
Enc
aes-cbc
10
Kernel
USAGI 2.4.19
0
Bandwidth Limited
None
1
2
3
4
5
Number of Clients
This scenario provided results for throughput and overhead
for IPv6 tests with IPsec VPNs deployed using the AES
algorithm for encryption.
Figure 4 - TCP Overhead
6. Results
Notes on the results:
UDP Throughput
The results for IPv4 and IPv6 throughput with no
encryption for both vanilla and USAGI kernels were
100
extremely close (less than 1%), so for clarity they will not be
90
80
shown here.
70
60
Vanilla IPv4
MBits / sec
50
USAGI IPv6
40
IPsec-3des IPv6
30
IPsec-aes IPv6
20
10
0
1
2
3
4
5
Number of Clients
Figure 5 – UDP Throughput

---

[3] E. Scharf, P. Hamer, K. Smparounis, W. Payer, J. Ronan, M.
UDP Overhead
Crotty, “An Intelligent Integrated Approach to Multi-service
Residential Access Networks”, Journal of the Communications
100
Network, July-September 2002
90
[4] TORRENT (Technology for a Realistic End User
80
Access Network Test-bed), IST-2000-25187.
70
http://www.torrent-innovations.org
60
% CPU
[5] S. Kent and R. Atkinson, “Security Architecture for the Internet
Vanilla IPv4
50
Utilisation
USAGI IPv6
Protocol,” Internet Engineering Task Force, RFC 2401,
40
IPsec-3des IPv6
November 1998.
30
IPsec-aes IPv6
[6] S. Kent and R. Atkinson, “IP Authentication Header,” Internet
20
10
Engineering Task Force, RFC 2402, November 1998.
0
[7] S. Kent and R. Atkinson, “IP Encapsulation Security Payload,”
1
2
3
4
5
Internet Engineering Task Force, RFC 2406, November 1998.
Number of Clients
[8] D. Maughan, M. Schertler, M. Schneider, and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", Internet Engineering Task Force, RFC 2408,
November 1998.
Figure 6 – UDP Overhead
[9] H. Orman, "The OAKLEY Key Determination Protocol",
Internet Engineering Task Force, RFC 2412, November 1998.
Firstly, before analysing the results, it should be noted that
[10] D. Piper, "The Internet IP Security Domain of Interpretation for
results could not be obtained for 4 and 5 client connections
ISAKMP", Internet Engineering Task Force, RFC 2407,
using UDP. These tests were attempted several times and
November 1998.
their failure is currently being investigated.
[11] D. Harkins, and D. Carrel, "The Internet Key Exchange (IKE)",
Internet Engineering Task Force, RFC 2409, November 1998.
Looking at Figure 3 it can be seen that enciphering the link
[12] C. Madson and N. Doraswamy, “The ESP DES-CBC Cipher
with AES and using HMAC-MD5 for authentication does not
Algorithm with Explicit IV”, Internet Engineering Task Force,
reduce the throughput of the clients appreciably. AES is
RFC 2405, November 1998.
markedly superior to DES in this case.
[13] S. Frankel, S. Kelly and R. Glenn, “The AES Cipher Algorithm
Looking at Figure 4 it can be seen that the load induced by
and Its Use With IPsec”, Internet Engineering Task Force,
the AES algorithm seems to maintain a relatively constant
Internet draft, December 2002.
[14] C. Madson and R Glenn, “The Use of HMAC-MD5 within
level of 60%, except in the case of a single client. This would
ESP and AH”, Internet Engineering Task Force, RFC 2403,
seem to indicate that the bottleneck, in this case, is the
November 1998.
network card and not the processor.
[15] SuSE, Linux Distribution, http://www.suse.com
The results are similar for AES with UDP traffic, but it can
[16] Netperf, A Network Performance Benchmark, Available:
be seen from Figure 5 (at least up to and including 3 clients)
ftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/netper
that DES throughput falls dramatically once more than one
f-2.2pl2.tar.gz
[17] The KAME Project, http://www.kame.net/
client is involved, which indicates that the server is being
[18] USAGI IPv6 IPsec AES enhancement patch, Available:
overworked. This is borne out by Figure 6, which shows the
http://www002.upp.so-net.ne.jp/h-
DES CPU utilisation approaching 100% when more than one
yamamo/ipv6/usagi/ipsec.html
client is involved.
[19] J. Postel, “User Datagram Protocol”, Internet Engineering Task
Force, RFC 768, August 1980
[20] Defence Advanced Research Projects Agency, “Transmission
Control Protocol”, Internet Engineering Task Force, RFC 793,
7. Conclusion
September 1981.
After applying the above tests the conclusions can be
drawn that the AES algorithm performs more efficiently than
its predecessor, DES, on similar hardware. Hence, IPsec
could be deployed as an encryption and authentication service
in the TORRENT architecture, without hitting any significant
performance bottlenecks, if the algorithms deployed are AES
for encryption and HMAC-MD5 for authentication.
References
[1] The Linux Kernel Archives, Available: http://www.kernel.org
[2] USAGI UniverSAl PlayGround for Ipv6) Kernel, Linux IPv6
Development Project. Available: http://www.ipv6.org

---