Analyses and implementation of IPsec protocol in the LTE access

Analyses and implementation of IPsec protocol in the LTE access
Analyses and implementation of IPsec protocol
in the LTE access network.
Rui Fortio
Abstract— The security vulnerabilities present in the LTE
access network, resulting from a simplified flat architecture and
the use of unsecure IP transport network, encourage the
introduction of the Internet Protocol Security (IPsec). IPsec is a
protocol suite for data authentication, integrity and encryption
protection through procedures and cryptographic algorithms.
The presented work aims to evaluate the introduction of IPsec
in the LTE access network. For this purpose, it was studied and
analyzed the impact in the LTE architecture and performance,
concluding that:
a) The introduction of IPsec has impact on the network
architecture. The authentication and encryption processes are
computationally quite demanding, requiring the introduction of a
dedicated element in the network, the Security Gateway
(SecGW), to terminate IPsec tunnels and protect LTE core side;
b) eNB certificate-based authentication, using digital signature
with asymmetric keys, requires implementations of a Public Key
Infrastructure (PKI) for SecGW and eNB public keys certificate
c) The overhead introduced by IPsec, requires transport
network optimization to maintain the quality of service, avoid
fragmentation and minimize performance degradation.
According to the study conclusions, it was proposed solution
for the network architecture. The proposed solution was
implemented and evaluated, in a laboratory environment, in two
different methods. In the TWAMP evaluation, the IPsec network
solution tested in laboratory, had marginal impact on network
performance, but considered quite acceptable taking in to
account the added value in network security and in the carried
services. In the end-user experience tests, no differences were
detected in the network performance.
Index Terms— LTE, IPsec, Security, Performance, QoS
obile operators are introducing the fourth generation
network (4G/LTE). The main goal is provide high data
rates, support multimedia and real-time services on a single
network. These requirements are achieved simplifying the
network architecture, using end-to-end IP technology and
introducing heterogeneous radio networks. This concept
expose LTE network to new security risk within their own
infrastructure never exit before.
Rui Fortio Author is an Electrical and Computer Engineering student, at
IST (e-mail:
3GPP recommends the implementation of Internet Protocol
Security (IPsec) [1] [2] and the introduction of a Security
Gateway (SecGW) with the aim of protecting the LTE core
network (Evolved Packet Core-EPC) and traffic from possible
attacks originated in eUTRAN (eNBs and backhaul IP)
A. Motivation
The IPsec protocol is widely used to implement security in
computer networks and Internet. However, the introduction in
the mobile access networks, more precisely in LTE, is recent
and has challenges unusual in traditional fixed IP networks.
LTE aims to provide broadband services and real-time
services. Currently Release 8 offers 300Mbps downlink and
75Mbps uplink throughput rates, supports voice (VoLTE),
Video (Interactive, Streaming and Broadcasting) and
Interactive online games. To provide services differentiation,
LTE implements Quality of Service (QoS) policies based in
data transfer capacity, latency, latency variation (jitter) and
transmission errors admitted in each service. With IPsec
introduction is theoretically expected lower network efficiency
due to protocol overhead and higher latencies due to the use of
quite processing demanding algorithms for data authentication
and encryption.
Besides performance degradation, there is also a network
complexity increase, with the SecGW introduction, the
architecture needs to be redesigned to meet high availability
requirements. IPsec uses public key certificates for mutual
peer authentication. The eNB and SecGW public key need to
be renewed and certified periodically. To address that, a
Public Key Infrastructure (PKI) and auto enrolment protocols
like SCEP and CMPv2 needs to be implemented. Figure 1
shows an overall diagram for IPsec implementation.
B. Goal
This paper intends to analyze the impact of IPsec
introduction in LTE access network, propose and test an
architecture solution in laboratory.
C. Paper organization
The rest of the paper is organized as follows. Section II
describes LTE Access Network vulnerabilities and risks.
Section III briefly describes IPsec and the relevant
cryptography concepts. Section IV, proposes some case
scenarios and configuration for IPsec in LTE network. Section
V presents the final solution architecture with IPsec and
SecGW. Section VI presents the solution assessment results.
Finally section VII presents the concluding remarks.
Public Key
Core LTE
Tunel IPSec
Rede Segura
Rede Insegura
Rede de
Acesso LTE
B. eNB configuration and authentication
Other LTE vulnerability is the “S1 interface setup” between
the eNB and the EPC. In 3G, NB needs to be configured in
RNC by a system administrator before placed in service.
There is a kind of “manual authentication" in the network. In
LTE, the eNB and MME work as client/server and the setup
process is fully automatic with no administrator intervention.
To do a registration in MME, the eNB only needs to know the
MME IP, the network ID and the Tracking Area Code (TAC).
This information can be easily obtained with a network
analyzer and used later in eNB emulators to attack EPC with
overloading requests or eavesdropping data. Figure 3 shows
the two messages exchanged between the eNB and the MME
for S1 establishment.
Figure 1 - IPsec at LTE
LTE brings powerful benefits to operators and customers.
However, it has vulnerabilities and introduces new security
threats. In the next section a brief comparison is made between
LTE (4G), WCDMA (3G) technologies respecting access
network security. It is considerate Access Network the base
station, backhaul and radio controllers. Figure 2.
Core Network
Access Network
Radio Interface
LTE (4G)
IP backhaul
Radio Interace
IP Backbone
Access Network
Core Network
Figure 2 - LTE Network versus 2G/3G
A. Flat network architecture
LTE has a simplified and flat architecture with no radio
controller element (RNC) as in 3G networks. Unlike 3G
networks, where Base Station (NB) links to Radio Network
Controller RNC, in LTE base station (eNB) are directly
connected to the LTE core (Evolved Packet Core- EPC). EPC
is directly exposed and vulnerable to attacks from eNBs or any
transmission network equipment. This becomes even more
critical in “EPC in pool” architecture. For redundancy and
load balancing proposes, eNBs can connect to multiple
Mobility Management Entity (MME) and S-PGW (Serving
Gateway/PDN Gateway) simultaneously [3]. In additionally,
for handover efficiency proposes eNBs are connected among
them over X2 interface. This full-meshed network has a high
risk of Denial of Service (DOS) attacks from a single
compromise eNB,
Figure 3 - S1 Setup
C. User plane data protection in S1
Another risk, resulting from LTE architecture, is the traffic
protection between the User Equipment (UE) and EPC. In 3G
network the user plane traffic is encrypted from the UE to the
RNC. In the LTE network there is no RNC, thus the user plane
data is encrypted between the UE and the eNB (air interface)
and sent in “clear text” from eNB to the S/PGW. This may
result in eavesdropping and traffic malicious manipulation
D. Unsecure IP transport network
Legacy transport networks, based in TDM/ATM, used in
3G networks, doesn´t meet the LTE needs. Modern
MetroEthernet networks, based in fiber and microwave, are
more efficient and have lower cost per bit, encouraging
operators to adopt these IP networks as preferential transport
network. By nature IP networks are insecure (data protection
is done in upper layers when needed), TDM/ATM networks
were closed and complex networks, therefore technically more
difficult to understand and attack. IP networks are an open and
well known protocol.
E. Heterogeneous network
The growth of subscribers and traffic on LTE network is
changing cellular planning paradigm. Besides the use of
traditional macro cells to cover outdoor areas, small and femto
cells (HeNB) [4] are being introduced to expand the capacity
and enhance the coverage. For this purpose, eNB installation
will be done in unsafe places (public or private) and over
Internet or unsecure transmission, facilitating unauthorized
access to network infrastructure.
The IPsec protocol allows secure information transfer over
IP networks doing data authentication and encryption
protection. Figure 4 shows a typical application of IPsec
creating a virtual secure network (Virtual Private Network VPN) over an unsecure network.
Figure 4 - IPsec VPN
IPsec is a set of protocols defined in Internet Engineering
Task Force (IETF) standards, has two transfer modes,
Transport Mode and Tunnel Mode and two transfer protocols,
Authentication Header (AH) and Encapsulating Security
Payload (ESP). There is a third protocol, Internet Key
Exchange Protocol (IKE) for peer authentication proposes.
1) Transfer Mode
Transport Mode protects the payload of the IP packet,
giving protection to higher level layers. Tunnel Mode protects
whole IP packet by tunneling it. The Transport mode is used
to establish secure connections between hosts. The Tunnel
mode is most used to create Virtual Private Networks (VPN)
between two gateways or between a gateway and a host.
2) Transfer Protocols
Authentication Header (AH) and Encapsulating Security
Payload (ESP) are data secure transfer protocols. AH is used
to provide data origin authentication, integrity, and anti-replay
protection. The ESP provides confidentiality (encryption) in
addition to all the features offered by the AH protocol. Both
protocols may be employed in transport mode or tunnel mode.
3) Internet Key Exchange Protocol (IKE).
IKE is a component of IPsec protocol used for mutual peers
authentication (e.g. eNB and SecGW), security parameters
negotiation and for establishing and maintaining Security
Associations (SAs). An IPsec SA specifies security properties
that are recognized by communicating peers [5].
B. Cryptography in IPsec
IPsec uses cryptographic security standards to protect
communications. This section aims to provide a brief
introduction to the cryptography IPsec related.
1) Symmetric Encryption
In symmetric encryption there is only one secret key shared
by the two entities. The same secret key is used for data
encryption and decryption in both directions. IPsec use
symmetric encryption for confidentiality (encryption).
Advanced Encryption Standard (AES) and Data Encryption
Standard (DES) are symmetric algorithms example. IPsec/IKE
use Diffie-Hellman key agreement method to exchange
symmetric cryptographic keys.
2) Asymmetric Encryption
In asymmetric encryption each entity has a key pair (public
key and private key). One key is used to encrypt and another
to decrypt. The private key is known only by the owning
entity, while the corresponding public key is freely distributed
by the other system entities. The key pair is mathematically
related, but it is computationally infeasible obtain the private
key from the public key. Thus, any entity may send
information securely by encrypting the data with the
recipient's public key, because only it can decrypt the received
3) Hash functions
Hash functions are another important element in
cryptography. The hash function generates a fixed-length
value (hash value or message digest) from a data set. IPsec use
keyed-hash message authentication code (HMAC) like MD5
and SHA for data integrity and origin authentication.
4) Digital signature
A digital signature is a hash value encrypted with the sender
private key. The entity that receives the message, use the
sender public key to decrypt, validating the data integrity and
origin authentication. RSA (Rivest, Shamir, Adleman)
algorithm can be used for digital signature.
5) Public Key Infrastructure (PKI)
Asymmetric key encryption is compromised if the public
key true owner isn’t assured. The Public Key Infrastructure
(PKI) aims to address this issue through the existence of a
third trustable entity, accepted by all parts of the system, the
Certificate Authority (CA). The CA binds a public key to the
true owner through a public key certificate.
6) Public key digital certificate
Certificate is a digital document that binds an entity
(subject) to a public key through a CA digital signature. In
PKI any entities have a pair of public-private key and the
corresponding public key certificate. CA itself has a pair of
keys and the public key certificate. CA certificates are used by
entities to verify other entities and their own certificates. IPsec
supports X.509 Public Digital Certificate. Certificates are used
in IPsec/KE for peer identity authentication.
7) Public key certificate automatic renewal
The process to get and renewal the public key certificate
from CA can be automatic or manual. In a system, like LTE,
involving thousands of entities (eNB) is mandatory to have
automatic mechanisms for certificates managing. The
Certificate Management Protocol (CMP) [6] and the Simple
Certificate Enrollment Protocol (SCEP) [7] are protocols used
for digital X.509 certificates automatic renewal. The SCEP is
a widely used due is simplicity relative to CMP. The CMPv2
is more secure, enabling pre-installed vendor certificate for
first network contact authentication. CMP and SCEP aren´t
IPsec protocols but are an important support in enabling IPsec.
logical interfaces and SecGW connection over these
A. IPsec configuration in LTE
IPsec is a complex protocol with different applications.
Setting up a configuration depends on the aim and features
supported by each peer. The required performance and
security is also subject matter. This section proposes a
reference configuration for IPsec when applied to the LTE
network. In a standard way it must be configured as follows
-Tunnel Mode, protection of whole IP packet (VPN)
-IKEv2 peer authentication with x.509 certificates
-ESP protocol with data origin authentication, integrity,
confidentiality and anti-replay protection.
Tables below show two possible profiles for different security
levels, profile 1 (minimum security/best performance) and
profile 2 (recommend security/lower performance). Table 1
shows IKE SA proposal for phase 1 and Table 2 shows IPsec
SA proposal for phase 2.
Table 1 - IKE Authentication profile
Table 2 - IPsec profile
(LTE Access Network)
(LTE Core Network)
Figure 5 - LTE Network with SecGW
2) Scenario B - protection of EPC;
This scenario is a compromise between security,
performance and costs. The major goal is protect the core
network. All traffic is authenticated, but encrypted only in
control plane (S1-MME and X2-C). The network does not
guarantee the data user confidentiality, leaving this option,
like fixed networks, for user’s application (e.g. HTTPS, SSH,
etc.). Because higher volume (user plane traffic) isn´t
encrypted, lower processing capacity in the eNB and SecGW
is needed, meaning less investment in the network. In this
scenario more IPsec tunnel profiles will be needed.
3) Scenario C - protection of EPC (low cost solution);
The aim of this scenario is protected the core network at the
lowest cost. All traffic is authentication, but encryption isn’t
performed. Table 3 presents a summary of the 3 scenarios
Profile 2 should be used in both phase unless performance
B. Scenarios
Considering factors as performance, security and costs. In
this section is proposed and analyzed three different scenarios
for IPsec implementation in a LTE network.
Table 3 - Protection Scenarios
1) Scenario A - protection of EPC and traffic;
In this scenario, all traffic carried in the access network is
authenticated and confidentially protected. S1, X2 interfaces
are protected in the control plane (signaling) and user plane
(data). EPC is fully protected because all the traffic is
authenticated. The user plane traffic (S1-U and X2-U)
represents the majority of traffic volume, the encryption
requires more processing capacity in the eNB and SecGW.
This may impact the network performance or require a large
investment in processing capacity. In terms of complexity is
the simplest scenario, since all traffic is treated equally, it can
be carried by only one IPsec tunnel. Figure 5 show LTE
In this chapter is analyzed the necessary network modification
for IPsec introduction.
A. SecGW network location
SecGW is placed between the EPC and eNBs for IPsec
tunnels terminations and EPC protection. As shown in Figure
6, SecGW location LTE could be centralized, near EPC, or
distributed along the eNBs. The decision must take into
account factors like SecGW capacity, resiliency and
redundancy, maximum X2 latency allowed and many other
factors backhaul infrastructure related.
Backhaul X
Backhaul Y
Backhaul X
Backhaul Y
least, for single failure. This solution has greater flexibility in
capacity expansion but is more complex to manage and may
introduce higher latency because the traffic is distributed
randomly without considering node distance.
Figure 7 shows active-passive solution implemented in lab.
SecGW and Core Router implement dynamic routing
protocols (e.g., OSPF) [9] for automatic routing updates.
Routers were configured with Virtual Router Redundancy
Protocol (VRRP) for grouping redundant routers together into
a single virtual [10]. IKE Dead Pear Detection (DPD) for
IPsec tunnel redundancy was configured between eNB and
SecGW [11] [12].
Figure 6 - SecGW Location
Table 4 shows a comparison of the two architectures and when
each should be applied.
IPsec Tunnel
IPsec Tunnel (redundant)
Figure 7 - shows active / passive solution
Table 4 - Architecture
B. SecGW Redundancy
Telecom networks must be designed to provide high service
availability. Equipment supports small internal failures and
planned maintenance intervention, but in a severe or total
failure of an element, the service should be transferred to a
second redundant element. There are different solutions to
implement geographic redundancy.
1) Active-Passive Cluster
Active-Passive cluster consists of two elements, but only
the active element is processing traffic. The passive element
doesn´t handle traffic, but is synchronized with the active
element. If the active element fails, the standby element takes
over the active role. This is the simplest and easiest
redundancy configuration to implement and operate, but has a
disadvantage of having only one element processing traffic.
2) Active-Active Cluster
Similar to the first case, but in this mode both elements are
processing and sharing the traffic load between them. This
solution has the same capability as Active-Passive, but
improves the performance because, in normal operation, the
traffic load is balanced between the two elements. It is a more
complex solution to deploy and manage.
3) Pool
In this configuration there is a set (or pool) of n elements
sharing the load. The dimensioning should be calculated, at
C. Security Zones
For security and routing reasons the LTE network should be
segmented into routing contexts (VPN) and security zones.
SecGW should create 4 security zones as shown in Figure 8.
-Access Network (eNB and backhaul)
-Core network (EPC)
-Network management and operation of the eNB (OAM)
-Synchronization Network
Unsecure Zone
Secure Zone
Figure 8 - Security Zones
The SecGW should separate the unsecure Radio Access
Network VPN from other the VPNs. Traffic originated in
eNBs have access to the other VPN via IPsec authentication
and authorized access in the SecGW firewall or Access
Control List (ACL).
D. NBs Integration and Authentication in the Network
LTE can easily reach thousands of eNB in service. To
manage that, eNB authentication in SecGW should be
automatized. The proposed process is schematized in Figure 9
and described in detail below.
Switch DHCP/Router
Backhaul IP
L2 Connectivity
L3 Connectivity (IP)
Public key certificate request
IKE Certificate-based authentication
IPsec tunnel (authenticated and encrypted Data)
Figure 9 - eNBs Network Integration and Authentication
E. Quality of Service
The LTE network intends to be a single transport network
for all types of services. Services such as voice, video, internet
browsing or email will compete for network resources. The
voice is an example of a service with some tolerance to
transmission errors, but very sensitive to latency and latency
variation. Conversely, email service is undemanding in terms
of latency, but require low error rate. Thus, LTE needs to have
mechanisms to manage their own resources and meet the
Quality of Service (QoS) required by each type of service.
This section will analyze how QoS is implemented in LTE
network and propose adaptations for IPsec introduction.
1) QoS in Ethernet/IP Network
The basic principle behind QoS mechanisms in Ethernet/IP
network is the packet classification and marking. The
classification and marking is based on each service
requirements, that way, all equipment chain (routers, switches,
firewalls) can, for instance in case of congestion, decide what
traffic should have priority (lower latency) or the last to be
dropped (fewer errors). This is accomplished by marking the
Differentiated Services Code Point (DSCP) field in the
Network Layer and Priority bits (P-bits) in the Ethernet Layer.
User A/service Y » QCI 1
User B/service Z » QCI 2
1. Ethernet Connectivity: eNB establishes layer 2 connectivity
in the network, obtaining the MAC address from a co-located
backhaul switch.
2. IP Connectivity (layer 3). eNB may obtain the IP, the
default route IP, CA IP and SecGW IP Through Dynamic Host
Configuration Protocol (DHCP)
3. Public key certification. After establishing IP connectivity
and before contact the SecGW, the eNB should request the
public key certificate to the CA.
4. eNB authentication in SecGW. After obtain the certificate,
eNB is qualified to be authenticated in SecGW and establish
the IPsec tunnel.
5. Over IPsec tunnel, eNB contacts the Network Management
System (NMS) to get the configuration and parameterization.
After configuration, the eNB contact MME for service
establishment. The X2 connections towards neighbor’s eNBs
should be set automatically as specified by NMS.
2) QoS in LTE with IPsec
The LTE adds another level of QoS with the introduction of
QoS Class Identifier (QCI). The QCI is a value defined by
type of service and/or user, and determines the IPsec packet
behavior between EPC and User Equipment. The QoS
assigned to a particular service or user is propagated from the
Home Subscriber Server (HSS) or Policy and Charging Rules
Function (PCRF) to the eNB and EPC. These elements should
have the ability to map the QCI to DSCP/P-Bit values
allowing IP backhaul (routers, switches, firewalls, etc) process
the data properly, managing queues and bandwidth. Figure 10.
In tunnel mode, IPsec encrypts the original IP header
between the eNB and SecGW, making impossible to read the
DSCP in backhaul. To overcome this, IPsec borders elements
(i.e. SecGW and eNB) should copy the original IP header
DSCP to the IPsec header in order to maintain the desired
QoS. Another possible solution is to have different tunnel per
QoS. [13]
Radio QCI
IPsec QoS
Ethernet QoS
Ethernet QoS
Ethernet QoS
End-to-End QoS
Figure 10 - QoS end-to-end
F. IPsec overhead
The overhead introduced by IPsec, increase the IP packets
size and may result in network performance degradation. In
this section is calculated the overhead rate introduced by IPsec
and the size of the Maximum Transmit Unit (MTU) to avoid
fragmentation and packet discards.
Table 5 - LTE and IPsec overhead
Table 5 compares LTE overhead with and without IPsec. It is
assumed 1460 bytes of user payload (standard value
configured in a PC), protocol ESP in tunnel mode with AES
encryption algorithm. In scenario “without IPsec” the
minimum Ethernet MTU to avoid fragmentation is 1558 and
encapsulating the factor is 7%. In “with IPsec” scenario the
MTU is 16311 and the overhead factor is 12%.
The overhead factor was calculated with optimal payload of
1460 bytes. To reach a more realistic overhead factor, should
be consider the LTE traffic profile, like Internet MIX (IMIX).
Using AES, values may change for different algorithms
IMIX is the size and percentage of small, medium and large
transiting the network. Table 6 .
A. TWAMP Tests
TWAMP methodology is based on sending probe packets
from “sender-twamp” server to a “reflector-twamp” at eNB
and collecting time measurements in four points. Figure 12
Table 6 - IMIX
Applying IMIX profile in Table 6 and calculating a weighted
average size of packets we reach a more accurate overhead
factor. Table 7 shows the overhead factor introduced by the
protocol stack for the IMIX profile and for an average package
of 400 bytes.
IPSec Tunnel
Figure 12 - TWAMP measurements
Measurements are taken in four points:
T = 0, probe frame departure time at sender;
T = 1, probe frame arrival time at eNB reflector;
T = 2, probe frame departure time at reflector eNB;
T = 3, probe frame arrival time at sender.
Table 7 - Overhead rate
Considering average package of 400 bytes, the LTE overhead
rate is 0.25 (25%) and considering additional IPsec
encapsulation (LTE + IPsec) is 0.43 (43%).
This chapter presents the results of IPsec performance
analysis. For this purpose a comparative approach was done
between the network scenario 'without IPsec' and 'with IPsec',
and two different methodologies were used to evaluate the
Two-Way Active Measurement Protocol (TWAMP) [14]
for Latency, Inter Packet Delay Variation and Packets error
End-to-end tests, using end-user sw applications, in order to
assess the user experience, TCP throughput, Round Trip Time
(RTT), UDP throughput and errors.
Figure 11 shows the test scenario implemented in the
IPsec Tunnel
Probe packet of 84 and 1400 bytes were used to collect
experimental measurements for IPsec e no IPsec scenarios.
The following process were used for experimental data
collection process:
-Tests duration: 2h
-Packet Rate: 10 packets per second (pps)
-Sampling Period: 30 s
-Number of samplers: 300 samples/s (10 pps * 30 s)
-Calculation of the Minimum, Median and Maximum at
each sampling period of 30s (300 packets)
-Tables below presents the average of the 8 highest values
of the Minimum, Maximum and Median.
1) Latency
Observing the outcome in Table 8, with IPsec introduction
the median latency value increased 104% in the downlink
(DL) and 108% in uplink (UL) for small packets (84 bytes).
For large packets (1400 bytes) increased 89% in DL and 83%
in UL. The maximum latency values increased 100% in DL
and 70% in UL for small packets and 100% DL and 68% UL
for large packets.
TWAMP Sender
Site Backhaul
Table 8 - Latency
Figure 11- Test scenario
Despite the high increase of median and maximum values, the
absolute median values are below 0.74 ms and the maximum
latencies are always less than 1 ms. Suitable values for LTE
backhaul where the end-to-end latency should be less than 50
ms for real-time games and 100 ms for voice. [15]
2) Latency Variation
Table 9 shows latency variance median values obtained in the
four scenarios2.
Figure 13 - TCP Throughput
Table 9 - Latency Variation
In 84 bytes packet size scenario, the IPsec introduction
increases the median of latency variance by 114% in downlink
and 14% in uplink. In 1400 bytes scenario, IPsec increases
117% the median of latency variance in downlink and 14% in
uplink. The increase in IPsec scenario is justified with SecGW
the introduction and the encryption and decryption processing.
In both scenarios there a higher increase in the downlink than
in the uplink, but absolute downlink values remains below the
uplink. The main conclusion is that all measured values are
very low regarding the reference values. Based on laboratory
tests, Cisco says that values below 30 ms are acceptable for
voice over IP [16].
As shown in Figure 13, there is a slight throughput decrease in
IPsec scenario, but after increase MTU size from 1500 to 1631
to avoid fragmentation (see IPsec overhead section), the
results obtained “with IPsec” and “without IPsec” are
2) Latency (RTT) Estimation
In this test it was performed 100 pings (with different packet
sizes: 64, 128, 256, 512, 1024, 1500, 1631, 1700 byte) from
client PC towards Server. Outcome measurements like
Average, Standard Deviation, and ICMP loss are shown in
Table 10 for IPsec and no IPsec scenario.
3) Packet Loss
No loss, duplicated or disordered packets were detected in
downlink and uplink. This is a normal outcome for a good
network IP performance.
B. User Experience Tests
This section aims to provide the test results achieved to
evaluate the quality of service perceived by user when IPsec is
introduced. For this purpose software application like File
Transfer Protocol (FTP, IPerf and Ping were used.
1) TCP Throughput Estimation
Using a FTP tool it was done an asynchronous upload and
download of a 1,5Gbytes file.
Table 10 - ICMP (ping) tests
As presented in Figure 14 and Figure 15, the probability
density functions are quite similar for both scenarios. Best
results was achieved for ping of 64 bytes (default value),
worsening with larger packages. The maximum latency value
is under 30 ms (latency = RTT/2). LTE end-to-end latency
should be less than 50 ms for real-time games and 100 ms for
voice. [15]
Figure 14 - RTT PDF (without IPsec)
2 Regardless IPsec use, variance latency at downlink is much lower than
uplink. Theoretically these values should have same order of magnitude and
during lab tests wasn’t found any reason for such difference. Some hypothesis
may be considered, as equipment misconfiguration or a lower processing
capacity in the eNB reflector-twamp (SW building-in) than in sender-twamp
with dedicated HW. Nevertheless these values was set has a base line.
Figure 15 - RTT PDF (with IPsec)
3) UDP Throughput and Errors Estimation
To assess throughput and packet error rate over UDP it was
used IPerf tool. It was send 100 Mbit/s from server to PC for
different packet size. Table 11 shows the results for “no IPsec”
and Table 12 shows test results for IPsec.
Table 11 - Without IPsec
Table 12 - With IPsec
All test cases had end-to-end packet loss, but in neither case it
is detected packet loss in the eNB, SecGW or in any other
element of the IP network. Analyzing the PC CPU load it can
be concluded that packet loss is due to limitations in the PC.
There is also packet rate limitation in server with small
packets, thus the maximum transfer rate (100 Mbit/s) was
achieved in only with packets size 1024, 1470, and 1700 bytes
(tests 5, 6 and 7). Despite test scenario limitations, it may be
conclude that the user experience in UDP based services is the
same "with IPsec" and "without IPsec."
The simplified LTE network architecture and the use of
unsecure IP backhaul in access network expose LTE core
network and traffic to new security threats. Unlike his 3G,
LTE is inherently more vulnerable to attacks from access
network infrastructure (Base Station and IP backhaul). 3GPP
recommends the introduction of IPsec and Security Gateway
to restore the security levels. However, this solution could
have major impact in LTE network design and performance.
A. IPsec configuration
This paper propose solutions for IPsec implementation.
Considering LTE vulnerabilities and 3GPP recommendation it
was recommend three scenarios for IPsec implementation,
taking into account such factors as performance, security and
cost. IPsec allows several different configurations, but in LTE
IPsec should work in tunnel mode (VPN) with ESP protocol
implementing data origin authentication, integrity, anti-replay
protection and confidentiality. eNB identity authentication
should be done by IKEv2 protocol using public key
certificates. IPsec are enabled to use modern cryptographic
algorithms, such as AES for symmetric encryption, SHA-1 for
data authentication and integrity, and x.509 certificates (RSA
digital signatures) for eNB authentication.
B. Architecture changes
IPsec implementation involves changes in network
architecture and requires introduction of the SecGW node.
SecGW can be integrated in a centralized way (closer to the
core network) or distributed (closer to the eNB), depending on
its capacity, the number of connected eNB and the backhaul
performance. To maintain network high availability,
redundancy solutions must be employed.
In addition to the IPsec tunnels establishment and eNBs
authentication, SecGW must have firewall functionality
creating different security zones and controlling the incoming
and outgoing traffic. LTE networks can reach tens of
thousands of eNBs, pre-shared-keys authentication is less
secure and has no scalability for huge networks. Certificatebased authentication should be used, but this solutions requires
PKI implementation. eNB certificated should be renewed
periodically and automatically using SCEP or CMP protocols
C. Solution Performance
According to the study findings, it was proposed a solution
for the network architecture network. The proposed solution
was implemented and evaluated in the laboratory, concluding
1) It is necessary to adapt the QoS policy and ensure SecGW
and eNB does the proper QoS "translation" between 'IPsec'
and 'no IPsec' boundary zones. It is also necessary to increase
the MTU in the eNB, backhaul and SecGW to avoid
fragmentation and the resulting performance degradation.
2) IPsec performance impact is dependent on the traffic profile
(IMIX) considered. At least it is expected to have 12%
overhead, but it can reach 43% if an average packet of 400
bytes is considered.
Two different methods were used for performance
evaluation. 1) TWAMP protocol for network performance
assessment and 2) Software application tools for end-user
experience assessment.
TWAMP tests revealed minimal impact on network
performance, which is acceptable considering the added value
in security network and services. In software application tests,
no differences were detected in the service performance.
In summary, the present work concluded that the IPsec
implementation is mandatory to restore the security levels in
the LTE access network. IPsec is a complex protocol and
implies major changes in the network architecture, but this
work presented solutions to minimize this impact and maintain
the best network performance. Further work should be done
for real time service assessment (voice and gamming) and test
the solution in a live and loaded environment.
3GPP, "TS33.210," [Online]. Available:
. [Accessed 01 10 2014].
3GPP, "TS33.401," [Online]. Available:
. [Accessed 01 10 2014].
3GPP, "23.401 [4.3.10-Functionality for Connection of
eNodeBs to Multiple MMEs]," [Online]. Available:
. [Accessed 10 01 2014].
b. J. Wannstrom and K. Mallinson, "Heterogeneous
Networks in LTE," [Online]. Available:
IETF, "rfc4306 - Internet Key Exchange (IKEv2)
Protocol," [Online]. Available: [Accessed 01 10
IETF, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)," [Online].
Available: [Accessed
01 10 2014].
IETF, "draft-nourse-scep-23 - Simple Certificate
Enrollment Protocol," [Online]. Available: [Accessed
01 10 2014].
3GPP, "TS 33.210 - [5.4.2 Profiling of IKEv2 ],"
[Online]. Available:
. [Accessed 01 10 2014].
ietf, "rfc2328 - OSPF Version 2," [Online]. Available: [Accessed 01 10
ietf, "rfc3768 - Virtual Router Redundancy Protocol
(VRRP)," [Online]. Available: Available: [Accessed 01 10
IETF, "RFC 3706 - A Traffic-Based Method of
Detecting Dead Internet," [Online]. Available: [Accessed 01 10
Juniper, "Understanding Dead Peer Detection," [Online].
pics/concept/ipsec-dead-peer-detectionunderstanding.html. [Accessed 01 10 2014].
IETF, "RFC 2983 - Differentiated Services and
Tunnels," [Online]. Available: [Accessed 10 01
[14] IETF, "RFC5357 - A Two-Way Active Measurement
Protocol (TWAMP)," [Online]. Available: [Accessed 01 10
[15] 3GPP, "3GPP TS 23.203 - Table 6.1.7: Standardized
QCI characteristics," [Online]. Available:
. [Accessed 01 10 2014].
[16] CISCO, "Quality of Service Design Overview,"
[Online]. Available:
. [Accessed 01 10 2014].
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF