Sie sind auf Seite 1von 6

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org


Volume 5, Issue 1, January - February 2016
ISSN 2278-6856

Secure network communication using IPSec


Sridevi
Assistant Professor, Dept.of Computer Science, KU Dharwad.

Abstract: In this paper, secure communication between


many computers connected by an untrusted network is
discussed. IPsec solves this by sending data with added
authentication by public key cryptography and optional
encryption. One problem that occurs when many hosts are
involved is how to define, distribute and enforce a policy for
secure communication in the network. A tool to generate
IPsec configuration files was developed. By grouping hosts by
the services they provide, security policies can be defined for
each service instead of on a host-by-host basis. The grouping
and policy is then used to generate IPsec configurations to set
up point-to-point connections between each pair of hosts that
should be able to communicate securely. Some testing with
regards to performance and stability is done. There were
several stability issues during testing, showing the difficulty in
configuring IPsec correctly. However, later configuration
updates have fixed these issues, making IPsec stable enough
for trial use in production with careful monitoring.

Keywords: IPSec, internet, secure, cryptography, public


key, etc...

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

Volume 5, Issue 1, January February 2016

gateways. The single point of failure can be avoided with


redundant gateways, but this would increase the
complexity of the system if a failover should be possible
without connection interruption.
Another issue is that many internal server networks focus
their security measures only against attacks originating
from outside the internal network. Firewalls seldom
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 has to 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
manage on a larger scale. The complexity makes it easy to
make mistakes during configuration that could lead to
severe consequences such as service outages or sensitive
data 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 should probably have similar security policies.
To aid in configuration, it would be useful to have a way
of defining security policies for a specific service and
translate this to security policies for each individual host
involved.
To facilitate IPSec deployment, a goal of this research is
to specify a way to define security policies for services and
to generate security policies for each host given the list of
services that the host provides. To test using IPSec and
various suggested solutions, a set of networked computers
running Linux are required. These must have network
connectivity both within a single site as well as across
sites for different testing scenarios.

2. SECURITY SOLUTIONS
LAYER

IN THE

TRANSPORT

IPsec is not the only solution for this problem. Another


popular choice is using Transport Layer Security (TLS) to
fulfil security requirements. However, TLS requires
changes to the services running on the servers. To use
TLS, one could add security to each service running on
the hosts. This requires modification of every single
service where the provided security is required, adding a
prohibitive cost for adding and supporting security
implementations everywhere. Another TLS based solution
would be to add a separate address space for the virtual
private network and tunnel traffic through a separate VPN
Page 89

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org
Volume 5, Issue 1, January - February 2016
ISSN 2278-6856
application. This increases routing complexity, adds
another address for each host and increases the amount of
domain name configuration. IPsec is a set of protocols for
securing the transmission of IP datagrams [3, 5]. The
protocol resides in the Internet Layer, in contrast to the
application layer that TLS resides in. By residing in the
Internet Layer, applications can be protected without
having to implement the security measures themselves.
This keeps the necessary changes 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 when they set up the connection. If keys are pre
calculated, each host will have to receive a key for each
other host with which it is supposed to communicate with.
To avoid this, a public and private key pair is generated
for each host instead. These can then be used to negotiate
an encryption key for a single session by using a method
of key exchange. The most commonly used protocol for
key exchange in IPsec is the Internet Key Exchange
protocol (IKE)

Figure 1: The structure of an IPSec ESP packet


To actually send data, each IP packet transmitted is put
inside an ESP packet as seen in Figure 1. ESP adds a
cryptographic checksum and optional encryption to each
IP datagram separately, allowing authentication and
confidentiality for the communication. These are all
connected by internal networks within the sites and the
connections between sites are routed through the Internet.
All involved hosts are running Debian GNU/Linux [1].
Some hosts are virtual machines running on top of a
Linux Kernel-based Virtual Machine [7]. Initial setups of
the hosts are done with Fully Automated Install (FAI) [8]
and configuration changes are distributed using both FAI
and Puppet [14]. These are two tools for remote
installation and configuration of computer systems. To
facilitate updates through Puppet, a public key
infrastructure using X.509 certificates is available. Several
services are running on the network. These services are
often distributed and load balanced over multiple hosts
and individual hosts may run more than one service. The
network is distributed over a number of sites. Some
services are available at all sites while some others only
exist in a subset of the sites. All communication 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.

Volume 5, Issue 1, January February 2016

3. RELATED
WORK
IMPLEMENTATIONS

OF

IPSEC

A native IPsec stack called NETKEY is available in the


Linux kernel. This is the IPsec stack used by all major
IPsec implementations for Linux. The public key
infrastructure and configuration of IPsec is handled by
separate implementations interfacing with the kernel.
There are three major IPsec implementation that interface
with NETKEY. These are strongSwan, Openswan and
IPsec-Tools.
StrongSwan: StrongSwan was forked from the earlier and
now defunct FreeS/WAN IPsec implementation for Linux.
It provides the IKEv2 daemon Charon for key exchange
and can also interoperate with the earlier Pluto for IKEv1.
Documentation for strongSwan is good and is available
online [17]. StrongSwan focuses on a core set of features
and on security and stability. Many more advanced
features such as interoperability with non-standard IPsec
implementations are left out.
Openswan: Openswan is another fork of FreeS/WAN.
There is documentation available online [12], but it is less
comprehensive than the documentation for strongSwan.
As of May 2011, it has not been updated since 2007,
making it an unreliable source of information. Compared
to strongSwan, Openswan includes more features and
additional use cases that strongSwan leaves out. This
includes support for Opportunistic Encryption and
interoperability with a wide variety of non-standard IPsec
implementations.
IPsec-Tools: IPsec-Tools is a Linux port of the IPsec tools
from KAME, an implementation originally 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.1 IPsec Configuration
One of the problems that have hindered IPsec deployment
is that configuring IPsec properly requires a significant
time investment to be able to understand all settings
entirely and there is a risk that a misconfigured IPsec
implementation might be less secure than intended [2].
Simple-VPN: Simple-VPN [15, 16], that processes a
simple configuration language in order to generate the
configuration files 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 are selected automatically by
Simple-VPN. This makes it possible to generate
configuration files for IPsec over an entire network from a
single manually edited file. It also reduces the risk of
misconfiguration of IPsec. By removing complexity, IPsec
features have naturally been removed from the end user as
well. Some of these removed features might be required in
this research use case, such as allowing a single host to be
part of multiple private networks simultaneously.
Similarily, there is no option to selectively encrypt traffic

Page 90

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org
Volume 5, Issue 1, January - February 2016
ISSN 2278-6856
depending on port numbers or IP addresses involved in
the individual connections.
Defining Policies for IPsec : To separate unrelated parts
of the network from each other, it would be helpful to be
able to define a policy with this in mind. Ordinarily, IPsec
configuration is done on a host-by-host basis. However,
some research into defining policies on a higher level. Li
notes [9] that manual configuration of individual nodes is
complex and prone to errors. A policy-based management
system is introduced that defines a policy for a specific
role and defines the policy for a host from the applicable
roles for that specific host. To distribute the policies, Li
uses a policy server. The individual clients query this
server and generate the appropriate IPsec configuration
files from the reply they get. This server then pushes
updates to the associated hosts whenever a policy is
changed. Yin and Wang proposed [18] a solution where
policies are defined for each application running on the
hosts. They then use what they call an application policy
engine to generate the fine-grained IPsec rules to
implement the application policy. This solution provides a
transparent way to add security to applications and works
without changing the IPsec or IKE implementations. They
instead use the PF_KEY protocol [10] to add security
associations to the policy database. Their performance
tests show that IPsec can provide end-to-end security to
legacy applications with performance comparable to other
security measures.

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.

Volume 5, Issue 1, January February 2016

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 hosts can look up the recipients keys before
sending packets to it. This relies on the security of DNS
lookups, which can be protected with regular IPsec or
DNSSEC connections to a reliable DNS server. After
investigating this option, it appeared as if the support for
Opportunistic Encryption has declined in the last couple
of years. The support in strongSwan was badly maintained
and only available for IKEv1 [6]. Opportunistic
Encryption has better support in Openswan, but the lack
of updated documentation makes it difficult to assess the
current status of the support for it. Opportunistic
Encryption support was not mentioned in the
documentation for Racoon2.
Configuration File Generation: Another option that was
evaluated was to use an existing IPsec implementation and
generate persistent point-to-point connections for each
pair of hosts that are supposed to be able to communicate
with each other. The concept of groups will then only be
visible in the input files to the software and will not be
visible in the final IPsec configuration on the individual
hosts. This option has the advantage of using existing
implementations and only adding a utility to simplify the
process of configuration. The majority of testing of the
IPsec implementations is done on the simpler point-topoint mode this would use, which would reduce the need
for testing. However, some hosts might be authorized to
connect to a large set of other hosts on the network and
persistent point-to-point connections to every one of them
might 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.
Selecting Solution: After evaluating the three options, it
was decided to do initial performance testing of
strongSwan with a slightly modified version of Simple
VPN [16] to verify that generating configuration files
would be a reasonable solution. After verification, a
separate configuration utility with support for ordering
hosts into groups was developed.

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

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org
Volume 5, Issue 1, January - February 2016
ISSN 2278-6856
Group Based Access Control: Having a full mesh IPsec
setup with persistent connections between every pair of
hosts is not scalable to larger deployments. The security
level is also reduced if hosts are allowed to communicate
with unrelated machines on the network. To remedy this,
the concept of groups is introduced to the tools. All hosts
are given lists of groups that they belong to and each
group has a list of groups that hosts belonging to the
group should be able to communicate with. These lists are
then used to generate the necessary configuration files for
strongSwan.
Distribution of Configuration Files: To distribute the
configuration files and make sure that no communication
is sent in plain text, the IPsec implementation has to be
integrated with administration and 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 the
puppet master, a central server where all configuration
can be set. The puppet master then updates all client
machines when configuration files change. By generating
all configuration files and adding these to the puppet
master, all IPsec 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 with configuration files reflecting this policy
change within the update interval used for Puppet.
Network Monitoring: IPsec by itself does not provide any
way to avoid sending data in plain text. In order to make
sure that no traffic that should be IPsec protected will be
sent in plain text instead, machines must run packet
filtering firewalls to handle this. A firewall can identify
packets that are related to IPsec and use regular firewall
filtering on these packets. For packets sent without IPsec
protection, the firewall can be used to log or block this
traffic. While deploying IPsec to a new host, logging but
still allowing non-IPsec traffic will allow verification that
IPsec is running without disturbing the traffic flow. This
can, however, only be done if services are not sending
sensitive data across a public network.

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

Volume 5, Issue 1, January February 2016

The tests began with testing connections in a single site


with a switched network between participating hosts. The
results are available in Figure 2. There was a significant
reduction in maximum throughput. This might slow down
services requiring high bandwidth for optimal
performance.
Cross-Site Transfer Speeds
One of the major reasons for encrypting network traffic is
to be able to send confidential data across unprotected
networks such as the Internet. To allow for this,
throughput benchmarks with and without IPsec As seen in
Figure 3, the reduction in throughput is less noticeable
when the overall capacity is reduced and higher latencies
are introduced. This is an indication that the host
performance was limiting the throughput for same-site
communication.

Figure 2: Transfer speeds with and without IPsec with a


single TCP connection.

Figure 3: Transfer speeds with communication between


separate sites.
Connection latency
ICMP echo requests were sent to measure the latency of
the connection with and without IPsec, as seen in Figures
4 and 5. Within a single site, all network traffic is
switched directly between hosts, making the higher
latency clearly visible in tests. The actual latencies are,
however, still very small. Moving to a cross-site latency
test, the increase in latency is measurable but for all
purposes irrelevant.

Figure 4: Connection latency with communication within


a single site.
Page 92

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org
Volume 5, Issue 1, January - February 2016
ISSN 2278-6856
IKE implementation used, highlighting the difficulties
noted [2]. Additional testing indicates that these issues
have been resolved with later updates to configuration
files.

7. CONCLUSION

Figure 5: Connection latency with cross-site latency test


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 of
requests against a key-value service with an HTTP
interface. The service receives a HTTP GET request with
a specific key and replies with the value corresponding to
that key. The results, as seen in Figure 6, show that there
was a slight reduction in number of requests handled per
second.

The initial testing with throughput benchmarks showed a


significant reduction in throughput. Depending on the
services communicating over IPsec, this might pose a
problem. For services limited more by processing power
and latencies than raw network throughput it should be
less of an issue. The stability issues seen during testing
show that misconfiguration can have serious
consequences. Careful consideration and thorough testing
will be required when changing these configurations to
avoid any stability issues. To reduce the throughput limit
that the speed of a single CPU core puts on the
connection, the recent addition of parallelized
cryptography operations in the Linux kernel [6] is an
interesting option. Further research into using this and the
effects on the performance might be worthwhile. The
configuration utility developed in this project only
supports end-to-end connections. Some devices might not
support using the configuration generated by this tool and
some might not have any IPsec support whatsoever. To
allow these to communicate with IPsec, support for
gateway configurations could be added to the tools.

REFERENCES
[1]

Figure 6: Results from performance testing with small


packets.
System Load
During the performance testing, the system load was
monitored for any changes. It was detected that a single
CPU core was running on full load during the transfer
speed tests. Single threaded cryptography operations was
suspected to be the cause of the slower transfer speeds
identified when IPsec was active. Work has been done to
add multi-threaded support for cryptography operations in
the Linux kernel [6], but it is still marked as an
experimental feature. Using this support for IPsec might
affect the throughput performance positively.
Stability
During testing, it was noticed that security associations
sometimes failed to negotiate new encryption key and the
IPsec daemon failed to re-establish a secure tunnel
between hosts. When an error occurred, all traffic between
involved hosts including plaintext communication was
stopped, interrupting any service communicating between
the two hosts. The errors were caused by
misconfigurations and misunderstandings of IPsec and the

Volume 5, Issue 1, January February 2016

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

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org
Volume 5, Issue 1, January - February 2016
ISSN 2278-6856
[13] The Racoon2 Project. Official website.
http://www.racoon2.wide.ad.jp.
[14]
Puppet
Labs.
Official
website.
http://www.puppetlabs.com.
[15] Shreyas Srivatsan, Maritza Johnson, and Steven M.
Bellovin.
Simple-VPN.
http://simplevpn.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, Department of
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.
[18] Heng Yin and Haining Wang. Building an
application-aware IPsec policy system.IEEE/ACM
Trans. Netw., 15:15021513, December 2007.

Volume 5, Issue 1, January February 2016

Page 94

Das könnte Ihnen auch gefallen