Beruflich Dokumente
Kultur Dokumente
1. INTRODUCTION
Traditionally, many organizations have implemented a
security policy with most of the security in the perimeter
of networks. It is often assumed that the internal network
is secure and that no malicious traffic will originate from
inside the private network. If an attacker has access to a
host on the internal network, it is often possible to connect
directly to other hosts on the network. By adding security
measures at the individual host level, additional security is
achieved. Firewalls provide additional protection from
hosts on the network, but an attacker on the network
might be able to in personate a genuine host that the target
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 claim to be and that they have the correct
authorization to communicate with specific hosts on the
network. An added bonus of using IPsec is that the traffic
may be encrypted as well, providing confidentiality in
addition to authentication and authorization. This makes
it possible to communicate between sites over the Internet
without risking exposure of the data transmitted.
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 the two sites.
This way hosts in other parts of the networks are unable to
read or modify the data being sent between hosts in the
private network. The problem with this is the single point
of failure, as well as a potentially high load on the
2. SECURITY SOLUTIONS
LAYER
IN THE
TRANSPORT
3. RELATED
WORK
IMPLEMENTATIONS
OF
IPSEC
Page 90
4. EVALUATED SOLUTIONS
After investigating the requirements on the system and the
various options available from IPsec implementations,
some options were evaluated. The configuration
possibilities as well as the technical feasibility was
evaluated for each option.
Attribute Certificates: The first option that was
evaluated was to use Attribute Certificates to add an
attribute to a host for each group it belongs to. This would
remove the need for every host to know about each host it
should be able to connect to beforehand. However, current
IPsec implementations has little or no support for
Attribute Certificates. The certificates could not be sent as
part of the initial negotiation and had to be available on
the other end point beforehand instead. Additionally, due
to the nature of the Linux IPsec stack, it was not possible
to have multiple rules applying on a single network and
choose which rules to apply based on the provided
Attribute Certificates. To make it a reasonable solution,
support for fetching Attribute Certificates during
negotiation would have to be added to an IPsec
implementation. This would require studying and
modifying the source code of an existing implementation
and might require maintaining a patched version of the
implementation unless the code is accepted into the
mainline source code. It has not been investigated if the
IPsec RFCs have room for Attribute Certificate
transmission during the key exchange phase of IPsec.
5. CONFIGURATION TOOLS
After initial performance testing, an in-house tool for
configuring IPsec was developed. This tool started off with
copying the functionality used from Simple-VPN and 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 generate the IPsec
connection configuration for a host, given a list of peers it
should be able to communicate with. A prototype was
developed that reads this list of hosts from a JSON file
and outputs a strongSwan configuration file. To generate
the full mesh of connections for all hosts, a script was
written that transferred a list of hosts to a set of lists with
all other hosts listed as peers to every host in the JSON
format used by the prototype.
Page 91
6. RESULTS
To verify the network performance when using IPsec,
transfer speed was measured using the tool iperf [4]. One
gibibyte of data was sent in a TCP connection and the
time to send this data was measured to calculate available
bandwidth both with and 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 the average
round trip time. Long term testing was also run to verify
stability of the IPsec software implementation. This
involved a set of hosts simulating a production
environment while others involved in this research were
monitoring the behaviour of the hosts.
Single Site Transfer Speeds
7. CONCLUSION
REFERENCES
[1]
Debian
Project.
Official
website.
http://www.debian.org
[2] Niels Ferguson and Bruce Schneier. A cryptographic
evaluation of IPsec. Technical report, Counterpane
Internet Security, Inc, 2000.
[3] Steve Friedl. An illustrated guide to IPsec.
http://www.unixwiz.net/techtips/iguide-ipsec.html,
[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.linuxkvm.org, Retrieved 2011-06-22.
[8] Thomas Lange. FAI Project official website. http://faiproject.org, Retrieved 2011-06-22.
[9] M Li. Policy-based IPsec management. IEEE
NETWORK, 17(6):3643, NOVDEC 2003.
[10] D. McDonald, C. Metz, and B. Phan. PF_KEY Key
Management API, Version 2. RFC 2367
(Informational), July 1998.
[11] Bill Nottingham, Brian Buesker, Christophe Saout,
Kimmo Koivisto, and Ralf Spenneberg. IPsec tools
homepage. http://ipsec-tools.sourceforge.net,.
[12]
Openswan.
Openswan
wiki.
http://wiki.openswan.org.
Page 93
Page 94