Potential Applications of IPsec in Next Generation Networks

IPsec is one of the most secure technologies nowadays. It is used in almost all institutions that are concerned with protecting their communications. Although IPsec is not a very hard set of protocols to understand and use, once you get into its details and try to understand how it works, what is its applicability and what are its limitations, you will find yourself surrounded by mathematics, cryptography and network protocol design challenges. Because IPsec is not just another “encryption” protocol. It is actually an entire stack of protocols, ranging from negotiation protocols, to authentication protocols, to access network technologies, tunnelling protocols, PKI availability, routing and last, but not least, a good deal of cryptography. Companies use IPsec to securely connect their branches to the headquarters or between each other, over the Internet. Just the same, the remote workers have the possibility to securely access their data located at their work place premises no matter where they are. One of the most important aspects of this technology is its authentication role. By itself, IPsec does not provide network authentication. The authentication role of this stack of protocols is reserved for the IKE procedures. Currently at version 2, IKE has managed to simplify the authentication process of a peer and at the same time has managed to increase the security of this process. One of the latest additions to these authentication procedures is the support for mobile subscriber authentication. This functionality is achieved by incorporating the UMTS-SIM and UMTS-AKA key exchange protocols, useful in the NGN world.

way of achieving the security agreement between the IPsec aware devices is to dynamically negotiate the session information between the IPsec peers.This method has the advantage of dynamic keying, but it may also be susceptible to man-in-the-middle attacks in the first phases of the negotiation.The generic protocol employed to do the negotiation is called ISAKMP (Internet Security Association and Key Management Protocol), represented most commonly by the IKE (Internet Key Exchange) protocol, which has reached its second version.When discussion the use-cases that can take place in an IPsec environment, the IPsec peers may find themselves in one of these two scenarios: one is called site-to-site and the other one is called remote-access.These two scenarios both refer to the situation where the IPsec computation takes place either between two security gateways or between a security gateway and a stand-alone unit (laptop, pda, smartphone...) called roadwarrior; this scenario is also called dial-up vpn by some security vendors.There is a separate case where the IPsec peers want to transmit information between each-other in a secure manner, but without the use of an external service provider (as it is a security gateway).This case is called transport mode.

IPsec architecture and traffic logic
The main components of the IPsec architecture are the following: a. the Policy Agent: this component has the responsibility of negotiating the IPsec cryptographic parameters; these parameters refer to traffic identifiers (also called traffic selectors) that are input as a tuple in the Security Policy Database b. the Security Policy Database(SPD): this component is a database (considering it as a stand-alone database implementation or part of an operating system kernel); it consists of tuples that represent the traffic selectors of an IPsec agreement: the IP addresses or the subnet which the traffic to be secured belongs to, or, for some of the IPsec equipment on the market, it may also contain port numbers in order to identify the traffic c. the Security Association Database(SAD): this component is a database as well (standalone or part of a kernel implementation); it contains the IKE and IPsec security parameters that are negotiated: cryptographic algorithms, authentication information and identification information Tuples in both databases are indexed and retrieved at run-time via their index, called SPI (Security Parameter Index), a value transmitted at run-time in each IPsec packet, in order for the receiver to select the proper tuple for decryption of the packet.The traffic logic flow of an IPsec use-case is the following: the Policy Agent is the one to start the IKE negotiation process, which consists of two phases (for each IKEv1 and IKEv2 protocols).
The output of the Phase 1 is called ISAKMP SA(Security Association).The output of the Phase 2 is called IPsec SA.The IPsec processing engine adds a new layer of transformation for the actual network traffic; the engine is integrated to the TCP/IP stack of the system and it is called when a particular IP or a layer 4 segment matches the conditions for IPsec.Depending on each implementation, there may be available the configuration of different keys per traffic direction or a single set of keys for each IPsec tunnel.Also, there are ways to configure the Policy Agent to function based on the policy configured for that equipment (policy-based tunnelling), or to be triggered by a route utilization (route-based tunnelling).

Secure tunnel negotiation
In order to securely establish a dynamic IPsec tunnel, the ISAKMP -IKE protocol is used, whether its version 1 or version 2. In the notations above, the "i" refers to the initiator of the IPsec negotiation, while the "r" refers to the responder of the IPsec negotiation offer.The first four messages can be assimilated as Phase 1 of the IKEv2, and the last two messages as Phase 2 of the IKEv2.Nevertheless, at tunnel establishment time, only the first four messages appear in the negotiation, as usually the information provided by the last two messages is comprised in messages 3 and 4. The last 2 messages are used for the re-keying process.

Secure data transmission
After having established the secure parameters to be employed in order to protect the transmission of the data, two protocols can be used to achieved this security, either separate or both at the same time.These protocols are AH (RFC 4302) and ESP (RFC 4303).AH protocol number is 51 and the purpose of this protocol is to ensure protection against replay attacks, due to the integrity check and sequencing it employs.AH method makes a hash of the entire IP packet (both headers and data payload) and adds this has value to the packet sent over the wire.The only fields not taken into consideration when computing the hash value are the ones that are expected to change when routing occurs in a normal network: TTL, TOS, CRC etc.The ESP protocol number is 50 and this method encrypts the data using the material and algorithms negotiated earlier.ESP only encapsulates the payload.

Authentication and Identification
Two of the most important aspects of the IPsec negotiation are the authentication and identification.Not only do they perform two important functions (authenticating the IPsec peers to each other and identifying the peers to each other), but they are a crucial point for interoperability between different IPsec implementations.Not all networks worldwide happen to use exactly the same equipment as IPsec peers, so interoperability issues arise in many situations.RFC 2409 defines only two types of authentication available for IKEv1: PSK (pre-shared key) and digital certificates/RSA, while RFC 4306 for IKEv2 defines four authentication types: PSK, RSA, DSS and EAP (Extensible Authentication Protocol).The way these options are combined it is a totally different discussion.Most of the site-to-site implementations use a symmetrical authentication scheme (both peers use the same type of authentication for the tunnel being established).On the other hand, the remote-access scenarios many times use a hybrid authentication scheme, where the security gateway authenticates to the road-warriors via a digital certificate, while the clients are authenticated via a password.At the same time, if we are discussing IKEv2, where the EAP method is available, there are many more ways of authentication of the road-warriors.
Configuring PSK on devices is many time straight forward.The RSA configuration tends to be more difficult, as it assume the existence of a PKI infrastructure.As an example, on Strongswan, by default, there is a dedicated directory where the root certificates should reside (/etc/ipsec.d/cacerts).In /etc/ipsec.d/certs the administrator should copy the IPsec certificates for the local machine.All these files paths may be changed from a configuration file (/etc/ipsec.conf).The certificates are usually supplied in pem format, but they can also be parsed in der format (this option is default for Windows CA servers) and the administrator can convert a certificate from one format to another using a tool like openssl.When exporting a certificate generated on the CA, both the public and the private keys are downloaded (because the csr file has been directly generated on the CA).In this case, the format presented is PKCS12.From PKCS12, the administrator is able to extract both the public key (in a digital certificate) and the private key, in separate files.
from DER to PEM format: openssl x509 -inform DER -in local.cer-outform PEM -out local.pemfrom PKCS12 to PEM format: openssl pkcs12 -in myFile.p12-out cert.pem-clcerts -nokeys IOS, JunOS or StokeOS network operating systems usually keep the certificate information in their non-volatile memory.
The next step after achieve peer authentication is the proper identification of the peers to each other.This step is very important and it is also very important that the identities of the peers are not disclosed to unauthorized parties.This is one reason why Aggressive Mode method, which does not provide Identity Protection, is no longer included in IKEv2.RFC 2407 identifies the syntax for the identification variables in IKEv1, and RFC 4306 describes this syntax for IKEv2.The identification payload types for IKEv1 are the following: ID_IPv4_ADDR, ID_FQDN, ID_USER_FQDN, ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, IP_IPV6_ADDR_RANGE, ID_DER_ASN1_DN, ID_DER_ASN1_GN, ID_KEY_ID, and the ones for IKEv2 are the following: Identification is one of the major aspects when it comes to interoperability issues, especially when the administrator has to configure a particular type of identification mechanism which is not supported on the peer equipment.Strongswan for instance accepts ID_IP_ADDR (and ID_IP_ADDR_SUBNET for IKEv1), both v4 and v6, ID_FQDN, as in the certificate.The file also permits the configuration of an ID_ASN1_DER_CN, where the administrator can enter the entire subject of the certificate or only certain fields.conn connection1 left=192.168.0.1 right=192.168.0.2 leftid="C=RO, ST=Romania, L=Bucharest, O=Company, OU=Department, CN=DebianTest/emailAddress=debian@test.com" rightid="C=US, ST=California, L=Calabasas, O=Company, OU=Department, CN=Test1" Other equipment has a more or less similar way of defining this set of parameters.
A particular case is IEKv2-EAP.This protocol is described by RFC 3748 and it supports the following internal EAP methods: MD5, TLS, SIM, AKA etc.While MD5 is a simple protocol that can be implemented locally on the IPsec peer, TLS, SIM or AKA usually require an external Radius server, like ACS, FreeRadius or NPS.This is not a mandatory condition, but it is a good practice to have the authentication server separated from the IPsec peer.TLS can be used for almost any type of connection and it may also only authentication the server to the client, as per the TLS specifications.SIM protocol was defined for authentication in 2G networks, used for proving the GSM Subscriber Identity of the client to the 3G access network; this protocol is described in RFC 4186.EAP-AKA (Authentication and Key Agreement) has been defined for authentication of the 3G subscribers to the 3G networks which have a Radius server.Further on, the EAP-AKA is the preferred method of the 4G network authentication procedures, when the mobile equipment to be authenticated is a non-native 4G equipment.LTE uses the native AKA procedure for authenticating the native 4G handset, using the AAA proxy for mobile devices connecting from WiFi or WLAN areas.
An example of an EAP-SIM and EAP-AKA users as they are defined in a FreeRadius implementation is described below.user1 Auth-Type := EAP, EAP-Type := EAP-TLS, Password == "p@ssw0rd" eapsim1 Auth-Type := EAP, EAP-Type := SIM EAP-Sim-RAND1 = 0x201112131415161718191a1b1c1d1e1f, EAP-Sim-SRES1 = 0xd2d2d3d4, EAP-Sim-KC1 = 0xa0a2a2a3a4a5a6a7, eapaka1 Auth-Type := EAP, EAP-Type := AKA EAP-Sim-AUTN = 0xa0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0, EAP-Aka-IK = 0xb0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0, EAP-Aka-CK = 0xc0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0, EAP-Sim-RES = 0xd0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0, EAP-Sim-RAND = 0xe0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0, As for the moment, the IPsec technology is mature enough and considered stable.Improvements have been made to IKEv2 to support a large range of scenarios.What is of interest in this paper is how much of IPsec can actually be used in the Next Generation Networks, with emphasis on 4G-SAE, the mobile technology that has the greatest area of attention at the moment.We can use IPsec in a peer-to-peer manner for providing hop-byhop security between core network elements, but we should be able to learn a lot from its authentication and negotiation stages in order to secure the 4G access level, which is of bigger interest due to the large number of devices that will try to connect, as well as due to the large number of connectivity and mobility scenarios employed (Wang, 2008).
There are multiple studies regarding the security of the IPsec, and specially the IKE protocols.One of them (Cremers, 2011) identifies the following vulnerabilities: Reflection attack on IKEv1 Main Mode with digital signatures or pre-shared keys, Reflection attack on IKEv1 Quick Mode, Reflection attack on IKEv1 Main Mode with public key encryption, Authentication failure on IKEv1 Aggressive Mode with digital signatures, Authentication failure on IKEv1 Main Mode with digital signatures that does not require selfcommunication, Reflection attack on IKEv2 phase 2 exchange.Another important aspect of the IPsec protocol is the computational overhead, described in detail in (Xenakis, 2006).The factors taken into account are the encryption type and the authentication mechanism, and the resultants reflect in the system throughput, total delay and rate increase of the protected data.(Shue, 2007) Overall, the throughput overhead is larger than the overhead brought in by upper layer security protocols, like SSL or TLS, but the security offered by IPsec is also higher and the protocol can tunnel and secure a larger variety of traffic protocols than SSL or TLS can.

4G and services networks technologies
4G is the next generation network technology at the moment.4G is a generic term that defines a set of features and capabilities for a radio network, as well as for quality of service, mobility and services provided to the customer.It is not strictly related to a particular technology.It has been declared that both WiMAX and LTE are considered 4G technologies.WiMAX is being standardized by the WiMAX forum, being developed from the 802.16 family of wireless standards.The 802.16 is also being called fixed WiMAX and was published in 2001.In 2005, the 802.16e family was deployed, called mobile WiMAX.In 2011, there have begun to appear implementations of 802.16m.At the same time, the 3GPP forum also worked on improving the UMTS technology, which is considered a 3G generation.This is how the LTE (Long Term Evolution) technology came into existence.LTE is considered a 4G technology and it proposes an all-IP network, simplifying the access level of the network, as well as providing support for higher transmission rates due to improvements on the radio side and dynamic or seamless handover to both 3G networks, as well as to non-3GPP networks, like WiMAX or WLAN.Both 4G technologies are aiming at providing a simple and transparent access to the services network, for their subscribers.One example of services network is the IMS (IP Multimedia Subsystem), developed by 3GPP.IMS supports a large area of services, from simple data, voice and video to sms, mms, push-to-talk, conferencing and presence.A different approach to connecting to an IMS network is the direct access to Internet, where the services accessed may be the same ones as accessed from a wireless connection, without being provided in a unified manner, as in IMS.There is also possible an intermediary solution, where the services network is only referring to the Application Servers (AS) part of the IMS, overlooking the call session functions (Plewes, 2007;Sayyad, 2011).
From now on, the paper will provide a short introduction into the 3GPP LTE technology and discuss the security issues that appear at the access layer of this architecture (Kowtarapu, 2009).We will see what decisions the 3GPP forum has made in terms of protocols to use, their advantages and vulnerabilities and investigate how we can use the lessons learnt from our experience with IPsec.

3GPP LTE architecture and services network
The 4G-LTE architectures comprises two main components: the radio access network and the EPC (Evolved Packet Core).The radio access network is the eNodeB(the antenna) and the radio medium.The core network contains multiple devices, with roles in signaling, authentication, routing, providing quality of service and so on.The following elements are the most common devices located in the LTE core network (TS 23.203,TS 23.401,TS 29.274,TS 33.401): a. MME (Mobility Management Entity): it deals with user registration to the network, signalling and mobility management; it can be partially assimilated with the SGSN (Serving GPRS Support Node) from the UMTS architecture, with two major differences: the MME, unlike the SGSN, only does signalling, and, unlike SGSN, additionally has a management position towards the antennas; the MME connects to the database that holds the subscriber authentication information, having a very important role in the user authentication; in 3G, the RNC (Radio Network Controller) had the dedicated function of antenna management; b.SGW (Serving Gateway): unlike the MME, this entity does both signalling and traffic plane and it is responsible for routing data traffic to a particular set of radio cells (called Tracking Areas); c. PGW (Packet Data Network Gateway): this component is the one connecting the access network (LTE network) to the services network (IMS, Internet, Intranet etc); it is also one of the QoS enforcement points, together with the antenna; the PGW is connected to the database that holds the subscriber information; this entity may be assimilated to the 3G GGSN (Gateway GPRS Support Node) (Good, 2007); d.PCRF (Policy Charging and Rules Function): the policy database holding the subscription information material (Yang, 2011); e. HSS (Home Subscriber Server): the database holding information about the mobile equipment identity and credentials; The picture below is a schematic representation of a typical 4G network (TS 29.061), where the access side is done via native 4G environment, as well as via 3G and non-3GPP media.
The antenna is the first point of contact of the user to the LTE network.The mobile equipment connects to the network, identifies this network and upon the user signalling to the network, the LTE starts the authentication process.The entities involved in this process are the mobile equipment, as one of the authentication peers (the client), the HSS, as the second authentication peer (the server), the MME as the authenticator and the eNB, as a sort of authentication relay.The MME is the one requesting the UE (User Equipment) its identity information, when downloading credentials from the HSS, in order to start the authentication process and secure key establishment with the mobile.The protocol used for this process is AKA (in native 4G and 3G) and EAP-AKA for the non-3GPP access.Once the authentication is complete, there take place several keys determination, based on mathematical functions defined by 3GPP.The key hierarchy is different for each case: 3G.4G and non-3GPP.In the 4G case, there are keys for securing and/or authenticating both signalling and data-plane traffic flows, unlike 3G, where only the data-plane was secured.Also, there are specific requirements on how to assure a safe interoperability function between these types of access levels.For instance, the handover from a 4G network to a 3G network is simpler and does not require additional cryptographic computation, while the handover from a 3G network to a 4G network is more cumbersome.In order to achieve authentication for the non-3GPP devices, one or more 3GPP-AAA servers are needed and a ePDG (Evolved Packet Data Gateway).This ePDG entity is the other end of the authentication scenario, the peer the mobile connects to for authentication (Guo, 2010).Roaming is an aspect with importance when it comes to security (authentication, authorization as well as accounting and charging).Generically, there are three types of roaming: home routed traffic (the PGW is located in the home network), local breakout with home operator's application functions only (the PGW is located in the visited network, but the services the user accesses are provided by its home network, as it is the example of using an e-mail service) and local breakout with visited operator's application functions only (the PGW is in the visited network as well, but the visited network also provides the services in this case, having a roaming agreement with the home network, in order for that; the home network only serves at assuring the authentication of the user and the policy verification).
Independent of the details of implementation of the access network, the PGW ultimately connects the UE to an APN (Access Point Name) via the SGi interface, an IP-based logical interface.The APN is the services network, no matter the actual format of this network: Internet, Intranet, IMS etc.The typical case considered in this paper is the IMS network.In this case, the PGW connects to the P-CSCF equipment of the IMS core.
The centre of the IMS functionality is the CSCF (Call Session Control Function), provided via three different logical entities: a Proxy (P-CSCF), an Interrogating unit (I-CSCF) and a Serving unit (S-CSCF).The P-CSCF is the first point of contact in the IMS network, staying always in the SIP signalling path and being able to do traffic inspection, SIP header compression (SigComp) and secure tunnelling to the UE: this is the entity the mobile IMSaware handset establishes and IPsec session with.The P-CSCF can also do media-plane QoS enforcement.The S-CSCF is responsible for registration, message inspection and for selecting the AS (Application Server) that is to serve the subscriber.Assigning a particular S-CSCF to a certain subscriber is the task of the HSS, which is interrogated by the I-CSCF to provide this information.Just as for the 4G network, the IMS relies on the existence of HSS and PCRF databases.The standards move towards a more intimate and efficient integration of the 4G and IMS networks.

Security aspects
The security aspects in such a complex environment are many and complex.3GPP has defined five security levels in order to separate the areas that are somehow independent of each other (TS 33.203).
a. Network Access Security: this area deals with granting access to the (core) network only to those users that prove their identity, that identity matching a network's registered user, with valid authentication credentials and with a subscription that allows services to be delivered to this user; b.Network Domain Security: this area deals with the secure interoperation between the Evolved Packet Core (EPC) network entities; this security is described by the protocols involved in securing the communications between EPC nodes: IPsec (recommended by Specs to take place within an operator's premises) and TLS (usually for inter-operator secure communications); c.User Domain Security: this area deals with the secure access to the mobile stations; d. d.Application Domain Security: this area is concerned with how to secure the communication between the applications that reside on the user's mobile device and the core network application servers; as a layer 7 application, this area may implement a large variety of security structures; e. Visibility and Configurability of Security: this is an informational area, for the user; the subscriber must have constant access to the information concerning the security features available on his device, whether or not they are functioning properly and whether or not they are required for the secure operation of a certain service When it comes to access to the 4G network, there are two aspects that threaten the security of the model.These aspects are related to the EPS-AKA procedures and there are the lack of identity protection at the first Initial Attach to the network (where the user must send its IMSI over the air, unencrypted) and the lack of the PFS (Perfect Forward Secrecy) property of the AKA algorithm.Sending the IMSI over the air is a problem only for the very first Attach Request, because the subsequent requests are done using a temporary global identity (GUTI).
This attach request message is sent by the UE to the MME; this request may be a TAU (Tracking Area Update), procedure mandatory when moving between areas of radio cells.
When the new MME receives this message, it retrieves the identity of the previous MME from the message, and contacts this previous MME.In the message, the new MME requests the IMSI for the GUTI it provides.This way, under the fair assumption that the connection between MMEs is secured (via IPsec for instance), the IMSI identity of the UE is protected.
With regards to the services network, there are a lot of vulnerabilities, some related directly to the security capabilities of the SIP and RTP protocols, while some other to the network design, authentication, authorization and user profile.ETSI has developed the TVRA model in order to organize a table of security vulnerabilities description.The table below proposes a summary of the VoIP networks vulnerabilities, organized on the TVRA model (Edwards 2007;Karopoulos, 2010;VoIPSA, 2011).Along with the list of vulnerabilities, there are organizations that discuss these security issues in more details and also present the current status of the security tools available for assessing the level of security of this type of networks (Plewes, 2007).

4G GAA security solution
The 3GPP forum defines a generic authentication scheme, named GAA (Generic Authentication Architecture), which as two main components: the component responsible for authentication via shared secrets, GBA (Generic Bootstrapping Authentication) and the component responsible for authentication via digital certificates, SSC (Support for Subscriber Certificates).There are six entities as defined by the GAA: HSS, BSF, NAF, ZnProxy, SLF and UE.The figure below describes an authentication scenario where the UE is located in roaming, and there is a third, untrusted, network between the visited and the home network.The HSS is the database holding the USS (User Security Settings).It has the purpose of mapping the USS to one or more private user identities, which in IMS is called IMPI (IP Multimedia Private Identity).An example of USS is the GUSS (GBA User Security Settings), which may contain the following parameters: type of UICC, lifetime of the subscriber's key, timestamp etc.The BSF (Bootstrapping Server Function) has the role to authenticate the UE, via the AKA method.Before that, it communicates to the HSS in order to download AV (Authentication Vector) parameters used to derive the keying material for AKA.A native 4G handset should support discussion EPS-AKA with the BSF.The NAF (Network Application Function) is a generic server that the UE tries to connect to.The BSF derives the Ks_NAF key and sends it to the NAF.The UE also generates also a Ks_NAF key.For this procedure to function properly, the BSF should have connectivity to the NAF the user connects to.The BSF should keep a list of NAFs and a list of groups of NAFs, in order to be able to identify at any given moment which NAF should be chosen if an application-specific USS appears.(Aiash, 2010; Keromytis, 2010) The ZnProxy appears in the roaming cases, and it may be a stand-alone device or part of the functionality of an existing device, like the visited NAF, visited AAA server or an application server.This entity has the role of locating the user's home BSF device.In cases where there are multiple HSS databases, the SLF (Subscriber Location Function) is the entity queried by the BSF in order to locate the HSS containing the authentication information.The following steps describe the bootstrapping procedure: For the VoIP networks, there can be used up to five different security mechanisms: digest, TLS, IPsec-IKE, IPsec-man and IPsec-3gpp, the latter being specified by 3GPP.This end-toend security mechanism should not be influenced by the handover scenarios.This is because the local security association between the UE, the MME and eNB are refreshed during handover and/or TAU procedures, while the "application" security associations are maintained.This assumption holds as long as the UE is attached to a particular PGW.If the UE detaches, there is no guarantee it will get the same IP the next time it attaches and even in that case, the IPsec tunnel is torn down.
In the NAT scenarios, the issues that impact the wireline IPsec are the same in the NGN case.
The mobile device has to follow specific steps to get authenticated in the 4G network.Similar or totally different steps must be taken to authenticate to each services network.The process for 4G is EPS-AKA or EAP-AKA.In the IMS network it can authenticate via IMS-AKA and secure the traffic via TLS or IPsec.But, because IMS is a special kind of services network, being closely described by 3GPP in conjunction with the access network, some part of the security weight already established can be used to secure the access to the services network.The following scheme tries to lessen the cryptographic and message exchange burden of the UE to IMS authentication process, by using the PGW as an authentication proxy.This happens because the PGW is the closest 4G entity to the IMS network.It should be in direct connection to the P-CSCF.The PGW unpacks both the signaling GTPv2-c packets as well as the GTPv1-u data-plane packets that arrive on the S5/S8 interface.Being at the edge of the 4G network, it is also able to inspect the content of these message or forward packets that match some particular criteria (port number, protocol number, ToS value etc) to a separate, dedicated, inspection entity.It is fairly simple to identity the IMS SIP packets (for instance by the port number, usually 5060).In the classic model, the SIP packets would simply be forwarded to the P-CSCF, as the PGW (GGSN) has no specific IMS-aware functionality (Vintilă, 2011).
In the proposed scheme, before the Initial Attach procedure, the UE selects 'p' and 'g' primes non-null and a secret 'a', then uses these values to derive value A from the Diffie-Hellman procedure: A=g^a mod p. Then the UE inserts value A, p and g (or only A if p and g are somehow agreed upon from a pre-configured setting), then adds them to the PCO (Protocol Configuration Options) IE in the Attach Request message to the MME, PCO IE that propagates to the PGW in the Create Session Request message.This entity looks at the values received and computes value B=g^b mod p, where b is its key.After it verifies that the UE is valid and sends it an IP (or an empty IP, if it is to be configured later dynamically), and includes also the B value in the PCO from the Create Session Response.The response gets back to the UE in the Attach Accept message.At this moment, the UE and the PGW derive a common Diffie-Hellman key K, which they can use as a symmetrical encryption key or as a master key to derive further key for securing traffic between them.The UE sends the SIP Register message and includes its secret key SIP-K, encrypted with K.This message arrives at the PGW.
The P-CSCF discovery procedure follows next, while the PGW acts on behalf of the UE during the IMS authentication.If the authentication is successful, the PGW will announce the UE (via a 200 OK message) that the UE is connected to the IMS core.Fig. 6.Proposed scheme Although it saves only a few messages, this scheme has the main advantage of decreasing both the network load, as well as the cryptographic computation on the UE.One of the disadvantages of this scheme is that the cryptographic computation actually increases in the beginning, due to the DH procedure.The advantage is that the DH key can be used as a master key for further exchanges and this key remains valid for duration of the attach.
Another disadvantage is that the model produces small functionality changes in the UE functionality.The SIP implementation will need to store the secret key in a dedicated header.This should not be a great impediment in the implementation of this feature, as the SIP protocol is highly flexible and there is no 100% agreed implementation in the industry, at this moment.Another advantage is that the IMS model, being relatively mature and stable, is not needed to implement this mode.The internal IMS-AKA procedure remains unchanged.The PGW replies to the 401 Unauthorized message; it verifies the AUTN, computes the RES and replies to P-CSCF.A secondary benefit is the generation of a secret key which can be used as a master key to derive cryptographically resistant session keys for later use. www.intechopen.com

Conclusion
IPsec is considered one of the most secure protocols in the Internet.It is being successfully used in securing traffic all over the Internet, in the wireline technologies.Whether the use case involves companies trying to secure traffic between their branches or trying to assure a secure remote connection for its mobile workers, the IPsec is one of the preferred protocols.IPsec is a complex set of protocols, and none of the solutions right now on the market actually implement all of it.This situation leads to many incompatibility cases between different IPsec implementations.Nonetheless, IPsec is widely implemented and the differences in implementation many times constitute market differentiators.
As it is so popular in wireline technologies, industry and researchers investigate ways to implement IPsec or parts of it in the wireless technologies, as well, in order to export its benefits to the telecommunications world.Protocols used in IPsec are already implemented in technologies like WiMAX and UMTS: AKA, used as an EAP method in IPsec -IKEv2 authentication procedures.In 4G, the 3GPP forum looks into the EAP-AKA procedure for authenticating mobile handsets that attach to the 4G network from non-3GPP access radio networks.3GPP also makes use of the IPsec in the IMS security: IPsec-3GPP, negotiated not via IKE, but via SIP signaling.Other IPsec alternatives appear as IPsec-man and IPsec-IKE in the SIP negotiation, along with digest and TLS.
The examples provided using open-source implementations in tools like OpenIMSCore, Strongswan or FreeRadius demonstrate how the IPsec protocols can be configured.
Although different security equipment producers provide alternative configuration methods, the overall input aspect is similar, according to the purpose served.Adapting IPsec onto mobile devices would mean a significant work on improving its computational overhead and also some of the security aspects.One idea would be to use elliptic curve cryptography, used already in IPsec, but not implemented extensively in the industry so far.
The model proposed in this paper does a very short incursion in a scenario where the PGW, a very powerful device of the LTE core network, takes up part of the cryptographic burden of the authentication process of a mobile device to an IMS network.There is no doubt IPsec has gained a powerful sit in the NGN world and there are to be expected many improvements that address the shortcomings of its implementation in the mobile world.

Fig. 2 .
Fig. 2. GBA simplified architecture Version 1 is considered less safe than version 2, where multiple security vulnerabilities where covered by safer implementation.IKEv1 is considered more difficult to implement.IKEv1 is described in RFC 2409 and it is currently implemented by all the major security equipment providers.Both IKEv1 and IKEv2 negotiate the IPsec SA in two phases.Phase 1 in IKEv1 can be accomplished in two separate and incompatible flows.One of them is referred to as Main Mode and it has 6 messages (or 3 exchanges), and the second one is called Aggressive Mode and it consists of 3 messages.Phase 2 of IKEv1 is referred to as Quick Mode and it has 3 messages.
-HDR ISAKMP SAi Proposal -request sent by the Initiator of the tunnel to the Responder, containing the encryption and authentication algorithms -HDR ISAKMP SAr Response -response sent by the Responder, containing its available encryption and authentication methods -HDR DH KEi, Ni -message identifying the Diffie-Hellman group and keying material, as well as the Initiator nonce -HDR DH KEr, Nr -same as the previous message, but identifying the Responder's capabilities -HDR IDi, Hashi -authenticates the Initiator's Identity -HDR IDr, Hashr -authenticates the Responder's Identity Because the 5th and 6th messages are preceded by the exchange of cryptographic information and DH groups, the identities exchanged by them are already encrypted; this makes Main Mode exchange referred to as providing Identity Protection.This protection if identity does not happen for Aggressive Mode, where the phase 1 of IKEv1 has only 3 messages: -ISAKMP SAi Proposal, DH KEi, Ni, IDi -request sent by the Initiator, containing cryptographic information, Diffie-Hellman material, a nonce and the Identity of the Initiator -in clear -ISAKMP SAi Response, DH KEr, Nr, IDr, Hashr -same as the proposal, but with the Responder's information -HDR Hashi2 -the Initiator's hash Phase 1 is followed by Phase 2, also called Quick Mode.The purpose of this exchange is to negotiate the traffic selectors and the cryptographic information for the actual data-plane encapsulation.This traffic is referred to as non-ISAKMP by RFC 2409.