1 Analyses and implementation of IPsec protocol in the LTE access network. Rui Fortio email@example.com 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 issuing; 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 I. INTRODUCTION M 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: firstname.lastname@example.org). 3GPP recommends the implementation of Internet Protocol Security (IPsec)   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 2 SecGW. Section VI presents the solution assessment results. Finally section VII presents the concluding remarks. Public Key Infraestrure (PKI) Rede Core LTE Certificate Authority Certificação eNb Certificação SecGW Autenticação Tunel IPSec Rede Segura Rede Insegura eNB Rede de Acesso LTE EPC SecGw 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. eNB Figure 1 - IPsec at LTE MME S1 SETUP REQUEST II. VULNERABILITIES AND RISKS S1 SETUP RESPONSE 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. WCDMA (3G) HLR Backhaul (E1/SDH/ATM) NB UE Backbone (SDH/ATM) RNC MSC/SGSN Core Network Access Network Radio Interface Backbone (SDH/ATM) LTE (4G) X2 S1 IP backhaul UE eNB Radio Interace HSS IMS PCRF IP Backbone EPC (MME+SPGW) 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 . 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 (man-in-the-middle). 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)  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. III. INTERNET PROTOCOL SECURITY (IPSEC) The IPsec protocol allows secure information transfer over IP networks doing data authentication and encryption 3 protection. Figure 4 shows a typical application of IPsec creating a virtual secure network (Virtual Private Network VPN) over an unsecure network. Host IP IP IPsec IPsec Gateway Host IPsec Gateway 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 . 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 message. 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)  and the Simple Certificate Enrollment Protocol (SCEP)  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 4 IPsec protocols but are an important support in enabling IPsec. logical interfaces and SecGW connection over these interfaces. IV. IPSEC IN LTE 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 EUTRAN (LTE Access Network) EPC (LTE Core Network) Uu S1-MME S6a HSS SGi IMS MME UE X2-C S11 X2-U Gx S1-U SGi eNB Signaling Data SPGW PCRF Internet SecGW 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 described. Profile 2 should be used in both phase unless performance degradation. 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 V. SOLUTION ARCHITECTURE 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. 5 Site Switch eNB Site Switch eNB Site Switch Backhaul X Backhaul Y eNB MME Edge Core SecGW Router Router SPGW Distributed Architecture Backhaul X Site Switch MME SecGW Backhaul Y eNB Centralized Architecture 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)  for automatic routing updates. Routers were configured with Virtual Router Redundancy Protocol (VRRP) for grouping redundant routers together into a single virtual . IKE Dead Pear Detection (DPD) for IPsec tunnel redundancy was configured between eNB and SecGW  . Edge Router Core Router SecGW IP Backhaul eNB SPGW Core Router Edge Router SecGW A Site Switch MME OSPF Figure 6 - SecGW Location Edge Router Table 4 shows a comparison of the two architectures and when each should be applied. IPsec Tunnel IPsec Tunnel (redundant) SPGW SecGW B Core Router 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 eNB NMS CA PKI OAM EPC eNB Core Network RAN SecGW Sync Unsecure Zone Sync Servers 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. 6 Switch DHCP/Router NMS CA Backhaul IP eNB 1 2 3 4 5 EPC Core IP SecGW 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. HSS MME User A/service Y » QCI 1 User B/service Z » QCI 2 S11 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.  UE LTE QOS eNB Radio QCI IP Backhaul Internet SecGW SPGW Router S1 QCI IP QOS IPsec QoS IP QoS IP QoS L2 QOS Ethernet QoS Ethernet QoS Ethernet QoS E2E 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). 1 Using AES, values may change for different algorithms 7 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 TWAMP Sender T=1 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. TWAMP Reflector R T=0 S IPSec Tunnel T=3 (eNB) SecGW T=2 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%). VI. SOLUTION ASSESSMENT 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 performance: Two-Way Active Measurement Protocol (TWAMP)  for Latency, Inter Packet Delay Variation and Packets error measurements. 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 laboratory. IPsec Tunnel TWAMP 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 CA HSS Laptop R eNB Reflector IP Core Router Edge Router Site Backhaul Switch PCRF MME Table 8 - Latency FTP Server SecGW Internet Edge Router SPGW Core Router 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.  8 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 . 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 identical. 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.  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. 9 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." VII. CONCLUSION 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 that 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% of 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 10 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. VIII. REFERENCES              3GPP, "TS33.210," [Online]. Available: http://www.3gpp.org/ftp/specs/archive/33_series/33.210/ . [Accessed 01 10 2014]. 3GPP, "TS33.401," [Online]. Available: http://www.3gpp.org/ftp/specs/archive/33_series/33.401/ . [Accessed 01 10 2014]. 3GPP, "23.401 [4.3.10-Functionality for Connection of eNodeBs to Multiple MMEs]," [Online]. Available: http://www.3gpp.org/ftp/specs/archive/23_series/23.401/ . [Accessed 10 01 2014]. b. J. Wannstrom and K. Mallinson, "Heterogeneous Networks in LTE," [Online]. Available: http://www.3gpp.org/technologies/keywordsacronyms/1576-hetnet. IETF, "rfc4306 - Internet Key Exchange (IKEv2) Protocol," [Online]. Available: http://www.ietf.org/rfc/rfc4306.txt. [Accessed 01 10 2014]. IETF, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)," [Online]. Available: http://www.ietf.org/rfc/rfc4210.txt. [Accessed 01 10 2014]. IETF, "draft-nourse-scep-23 - Simple Certificate Enrollment Protocol," [Online]. Available: http://tools.ietf.org/html/draft-nourse-scep-23. [Accessed 01 10 2014]. 3GPP, "TS 33.210 - [5.4.2 Profiling of IKEv2 ]," [Online]. Available: http://www.3gpp.org/ftp/specs/archive/33_series/33.210/ . [Accessed 01 10 2014]. ietf, "rfc2328 - OSPF Version 2," [Online]. Available: http://tools.ietf.org/html/rfc2328. [Accessed 01 10 2014]. ietf, "rfc3768 - Virtual Router Redundancy Protocol (VRRP)," [Online]. Available: Available: http://tools.ietf.org/html/rfc3768. [Accessed 01 10 2014]. IETF, "RFC 3706 - A Traffic-Based Method of Detecting Dead Internet," [Online]. Available: http://www.ietf.org/rfc/rfc3706.txt. [Accessed 01 10 2014]. Juniper, "Understanding Dead Peer Detection," [Online]. Available: http://www.juniper.net/techpubs/en_US/junos12.1x46/to pics/concept/ipsec-dead-peer-detectionunderstanding.html. [Accessed 01 10 2014]. IETF, "RFC 2983 - Differentiated Services and Tunnels," [Online]. Available: https://tools.ietf.org/html/rfc2983. [Accessed 10 01 2014].  IETF, "RFC5357 - A Two-Way Active Measurement Protocol (TWAMP)," [Online]. Available: http://tools.ietf.org/html/rfc5357. [Accessed 01 10 2014].  3GPP, "3GPP TS 23.203 - Table 6.1.7: Standardized QCI characteristics," [Online]. Available: http://www.3gpp.org/ftp/specs/archive/23_series/23.203/ . [Accessed 01 10 2014].  CISCO, "Quality of Service Design Overview," [Online]. Available: http://www.ciscopress.com/articles/article.asp?p=357102 . [Accessed 01 10 2014].
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project