end-to-end security across wired-wireless networks for mobile users

15

Click here to load reader

Upload: scott

Post on 20-Feb-2017

219 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: End-to-End Security Across Wired-Wireless Networks for Mobile Users

This article was downloaded by: [Umeå University Library]On: 07 October 2014, At: 14:51Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Information Systems SecurityPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/uiss19

End-to-End Security Across Wired-Wireless Networksfor Mobile UsersDr. Sherali Zeadally a , Nicolas Sklavos b , Moganakrishnan Rathakrishnan c & Scott Fowler da Network Systems Laboratory, Department of Computer Science and InformationTechnology , University of the District of Columbia , Washington, DC, USAb University of Patras , Patras, Greecec Dow Jones and Company , South Brunswick, NJ, USAd Adaptive Communications, Networks Research Group, Aston University , Birmingham, UKPublished online: 27 Nov 2007.

To cite this article: Dr. Sherali Zeadally , Nicolas Sklavos , Moganakrishnan Rathakrishnan & Scott Fowler (2007) End-to-End Security Across Wired-Wireless Networks for Mobile Users, Information Systems Security, 16:5, 264-277, DOI:10.1080/10658980701747252

To link to this article: http://dx.doi.org/10.1080/10658980701747252

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

Page 2: End-to-End Security Across Wired-Wireless Networks for Mobile Users

264

AbstrAct  Recent advances in mobile computing and wireless commu-nication technologies are enabling high mobility and flexibility of anytime, anywhere service access for mobile users. As a result, network connections of such users often span over heterogeneous networking environments con-sisting of wired and wireless networking technologies. Both network het-erogeneity and user mobility make the securing of data transmission over heterogeneous networks challenging and complex. In this paper, we focus on the challenge of providing secure end-to-end network transmissions to wireless mobile users. To minimize service interruption during ongoing secure sessions of mobile users, we present the design and implementation of an approach based on the well-known Internet Protocol Security (IPSec) standard. We conducted a performance evaluation of our implementation using a Voice over IP (VoIP) application over an actual network testbed. Our empirical performance results demonstrate a packet loss improvement of 17% to 34% (for various VoIP packet sizes) and a handoff delay improvement of almost 24% validating the high efficiency of our proposed approach.

1. IntroductIon

Security has become a critical issue in the design and deployment of networks. In particular, network security has attracted a lot of attention in recent years. The threats of data modification and eavesdropping of wireless data communications continue to increase. Today, many business, govern-ment, military, and educational applications use the Internet to communi-cate among employees, business partners, suppliers, customers, and others. However, using the Internet often involves data transmissions over public and private networks. To protect the confidentiality, integrity, and authen-ticity of the data, network security methods are usually employed. Secure Sockets Layer (SSL) is one popular network security protocol that runs at the application level and is most used to protect HTTP transactions. SSL can only be used by TCP-based applications. In addition, applications need to be modified to run over SSL, making its deployment impractical for many legacy and future applications.

Another widely used technology that has been deployed as an alterna-tive to leased lines for building private networks is Virtual Private Network

Address correspondence to Dr. Sherali Zeadally, Network Systems Laboratory, Department of Computer Science and Information Technology, University of the District of Columbia, Washington DC, 20008 E-mail: [email protected]

Address correspondence to Dr. Sherali Zeadally, Network Systems Laboratory, Department of Computer Science and Information Technology, University of the District of Columbia, Washington DC, 20008 E-mail: [email protected]

End-to-End Security Across Wired-Wireless Networks for Mobile Users

sherali Zeadally

Network Systems Laboratory, Department of Computer Science and Information Technology, University of the District of Columbia, Washington DC, USA

nicolas sklavos

University of Patras, Patras, Greece

Moganakrishnan rathakrishnan

Dow Jones and Company, South Brunswick, NJ, USA

scott Fowler

Adaptive Communications Networks Research Group, Aston University, Birmingham, UK

Information Systems Security, 16:264–277, 2007Copyright © Taylor & Francis Group, LLCISSN: 1065-898X print/1934-869X onlineDOI: 10.1080/10658980701747252

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 3: End-to-End Security Across Wired-Wireless Networks for Mobile Users

265 End-to-End Security Across Wired-Wireless Networks for Mobile Users

(VPN) technology. VPN combines two networking concepts, namely virtual networking and private networking. A virtual network is typically con-structed over another network (such as the Internet) and allows geographically distributed users to inter-act with each other. Private networking provides data protection and confidentiality among hosts. To construct a VPN, a tunneling protocol is needed to establish a tunnel (uses cryptographic methods on transmitted data) that will provide users of that tun-nel a secure connection (as if they were commu-nicating on a private network). Common tunneling protocols include Point-to-Point Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), and IP Security (IPSec). The widespread acceptance and deployment of IP-based communications have led to IP-based VPNs such as IPSec to become the most popular IP-based security technology. In contrast to SSL (which requires modification of applications and only works with TCP), IPSec is completely trans-parent to user applications and allows any protocol (such as TCP, UDP, ICMP, SNMP, HTTP) running over IP to be secured without any modifications.

The rest of the paper is organized as follows. Section 2 provides some background information on IPSec. In section 3, we discuss related research efforts. Section 4 summarizes the main contributions of this work. In section 5, we describe the design and implementation of our proposed approach to enable end-to-end security for mobile hosts across wired-wireless networks. Section 6 presents a performance evaluation of our proposed approach. Finally, in sec-tion 7, we present some concluding remarks.

2. bAckground on IPsec

IPSec is a collection of protocols, authentica-tion, and encryption mechanisms designed to pro-vide end-to-end secure data transmission at the network layer for IP-based communications. IPSec provides security to IP and upper layer protocols. It was first designed for IPv6 but was later ported to work with IPv4 stacks. IPSec provides a solution for secure tunneling to ensure authenticated and encrypted network data flows. It enables hosts to select the required security protocols and determine the algorithm(s) to be used for encryption (Elkeelany et al., 2002).

The core of the IPSec suite of protocols includes the Authentication Header (AH) protocol, Encapsu-lating Security Protocol (ESP), and the Internet Key Exchange (IKE) protocol (Kent & Atkinson, 1998a):

The Authentication Header (AH) protocol provides authentication, and lets communicating parties verify that data was not modified in transit and that it genuinely came from its apparent source.The Encapsulating Security Protocol (ESP) pro-vides authentication, encryption or both. By pro-viding encryption, ESP secures the IP datagram against eavesdropping during transit.The IKE protocol provides the secure exchange of keys. It allows communicating parties to negoti-ate methods of secure communication such as the type of encryption and authentication algorithms acceptable for use. IKE also handles the initial authentication and key exchange and all future keys exchanges for the given session.

IP-level security services support authentication, confidentiality, and key management. Authentica-tion verifies the sender and confirms that the packet has not been altered; confidentiality is provided by encryption. Key management deals with the secure exchange of keys. Given an IP packet, the AH proto-col places a new header after the original IP header. This new header carries information used to confirm origin authentication and data integrity, but it does not provide for encryption of the original packet (data confidentiality). ESP provides data confidenti-ality by encrypting the original packet.

The Authentication Header (defined in RFC 2402 (Kent & Atkinson, 1998b)) provides support for data integrity and authentication of IP packets (see Figure 1). AH provides authentication of the payload and the packet header and protects against replays with the use of sequence numbers, but does not provide confidentiality (encryption).

All fields of AH are authenticated but not encrypted. The next header field indicates the higher level protocol following the AH. The payload length field is an 8-bit field specifying the size of AH in 32-bit words. The reserved field is for future use and is currently set to zero. The Security Parameter Index (SPI) identifies a set of security parameters to use for this connection. The sequence number increases for each packet sent with a given SPI for the purposes

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 4: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 266

of keeping track of the order in which packets go, and for making sure that the same set of param-eters is not used for too many packets. Finally the authentication data is the actual digital signature for the packet. It is same as the one used in the ESP authentication data field. IPSec authentication uses Keyed-Hashing for Message Authentication (HMAC) (Krawczyk, Bellare, & Canetti, 1997) combined with Message Digest algorithm (MD5) (Rivest, 1992) or Security Hash Algorithm (SHA-1) (NIST 2007).

ESP, defined in RFC 2406 (Kent & Atkinson, 1998c), provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. ESP authentication is provided by the combination of the data origin authentica-tion and connectionless integrity services, which are optional. Anti-replay, also optional, may only be used if the data origin authentication is employed. The ESP has six fields. The first two fields are not encrypted but are authenticated.

The Security Parameter Index (SPI) is an arbitrary 32-bit number that specifies to the device receiv-ing the packet the group of security protocols the sender is using for communication—the algo-rithm, the keys, and their length (see Figure 2).The Sequence Number is a counter that increases each time a packet is sent to the same address using the same SPI. It indicates the number of packets sent with the same group of parame-ters. The sequence number provides protection against replay packets in which an attacker copies a packet and sends it out of sequence to confuse communicating nodes.The payload data is the actual data being carried by the packet.The padding field ranges from 0 to 255 bytes of data. It allows for the fact that certain types of encryption algorithms require the data to be a multiple of certain number of bytes—to con-fuse sniffers trying to estimate how much data is transmitted.

Next Header Payload Length Reserved

Security Parameter Index (SPI)

Sequence Number Field

Authentication Data

FIgure 1  Format of an Authentication Header (AH) packet

Security Parameter Index (SPI)

Sequence Number Field

Payload Data

Padding

Pad Length Next Header

Authentication Data

FIgure 2  Format of an ESP packet

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 5: End-to-End Security Across Wired-Wireless Networks for Mobile Users

267 End-to-End Security Across Wired-Wireless Networks for Mobile Users

The Pad Length field specifies the amount of pay-load padding.The Next Header field, similar to a normal IP Header field, identifies the type of data carried.The Authentication Data is an optional field in the ESP. It contains an Integrity Check Value (ICV) (a digital signature), computed over remaining part of the ESP excluding the authentication field itself. The authentication is calculated on the ESP once encryption is completed.The Payload Data, Padding, Pad Length and Next Header fields are all encrypted.

Encryption in ESP is done using an encryption algorithm called 3DES (Triple Data Encryption Stan-dard) in Cipher Block Chaining (CBC) Mode (Mad-son & Doraswamy, 1998).

To ensure successful and secure communication with IPSec, the IKE (Harkins & Carrel, 1998) proto-col which is a combination of the Internet Security Association Key Management Protocol (ISAKMP) (Maughan, Schertler, & Schneider, 1998) and the Oakley Key Determination Protocol perform a two-phase negotiation.

IPsec Modes of operation

IPSec has two modes of operation: the Transport mode and the Tunnel mode. The Transport mode provides upper layer (Transport Layer) protection and applies to a pair of peer hosts. In this mode the traffic travels directly to the destination (other peer). In Tunnel Mode a tunneled IP protection is pro-vided that can be either host to host or via gateways

in which traffic have to pass through a gateway to access ultimate destination. The tunnel mode pro-tects the original IP header and reveals only the IP address of the IPSec gateway machine whereas in transport mode only the payload is encrypted leav-ing the original IP header unprotected (Godber & DasGupta, 2002).

Figure 3 shows that in the tunnel mode, IPSec AH constructs another IP Header (IPH2) for the IP address of the destination gateway. In the trans-port mode, the original IP Header (IPH1) is not protected.

In the case of the ESP protocol (Figure 4), we have an ESP trailer inserted after the payload data and before the ESP authentication data.

It is worth noting that IPSec offers secure support for both wired and wireless networks and provides both authentication and encryption. Unlike other security protocols (such as Secure Sockets Layer (SSL) which uses TCP) IPSec enables the sending and receiving of cryptographically protected pack-ets of any kind (e.g., TCP, UDP, ICMP) without any modification (Alshamsi & Saito, 2005). No changes to user-level applications are required when using IPSec. In addition, IPSec provides two kinds of cryp-tographic services confidentiality and authenticity or authenticity only. IPSec can protect any protocol running above IP over any medium.

3. relAted reseArch eFForts

Itani and Kayssi (Itani & Kayssi, 2003) present an end-to-end security solution that was developed in

Transport Mode

IPH1 AH TCP Data

Tunnel Mode

IPH2 AH IPH1 TCP Data

IPH1: IP Header 1 IPH2: IP Header 2 AH: Authentication Header TCP: Transmission Control Protocol

FIgure 3  Transport Mode and Tunnel Mode of the AH protocol

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 6: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 268

J2ME for mobile computing users. The solution pro-posed provides authentication and confidentiality for transmissions between a mobile device and an application server. The confidentiality is supported by the AES algorithm. However, one deficiency of their approach is that it does not support message integrity and non-repudiation.

Windson et al. (2004) implemented a system called MobiS designed to support secure application development for mobile devices. MobiS supports confidentiality and data integrity. In addition MobiS allows the configuration of cryptographic and its robustness is directly related to the combination of the cryptographic algorithms used as well as the size of cryptographic key. However, MobiS also does not support authenticity and non-repudiation.

The Extensible Authentication Protocol (EAP) (Blunk & Vollbrecht, 1998) provides a standard method for transporting multi-protocol datagram over point-to-point links. EAP also defines an exten-sible Link Control authentication method, as well as an Encryption Control Protocol (ECP) to negotiate data encryption and a Compression Control Protocol (CCP) used to negotiate compression methods. EAP is a general protocol for PPP authentication, which sup-ports multiple authentication mechanisms. It is a PPP extension that provides support for additional authen-tication methods within PPP. It does not select a spe-cific authentication mechanism at link control phase, but postpones this until the authentication phase. This allows the authenticator to request more infor-mation before determining the specific authentication

mechanism. This also permits the use of a back-end server (such as the RADIUS), which actually imple-ments the various mechanisms while the PPP authen-ticator performs the authentication exchange.

The Transport Layer Security (TLS) (Dierks & Allen, 1999) protocol provides privacy and data integrity between two communicating applications. The main benefit of TLS is that it is application-level protocol. Wireless terminals are authenticated to the RADIUS server rather than to the Access Point. Once authenticated with the RADIUS server, the wireless terminal gets access to the wireless network. Packets exchanged between the wireless terminal and the Access Point are encapsulated as EAPOL (EAP over LAN encapsulation in IEEE 802.1x frames) (IEEE, 2001) packets. EAP is a wrapper for encapsulation for multi-round-trip authentication methods (Ma & Cao, 2003). The basic idea is that the wireless ter-minal and the RADIUS server perform the authen-tication by exchanging EAP packets which the Access point device simply lets through. The data sent from the wireless terminal to the Access Point can be encrypted using the Temporal Key-Integrity Protocol (TKIP). Hence both the authentication and data transmission are secure with this approach. TLS works fine in a pure wireless environment but when a wireless mobile terminal is communicating with a host residing on a wired network through the Access Point, the network data transmission is secure (with TLS) only from the mobile terminal to the Access Point. Data from the access point to the host on the wired network is not secure. Hence, with

Transport Mode

Tunnel Mode

IPH1

IPH2

ESP H

ESP H

TCP

IPH1

Data ESP T ESP AUTH DATA

TCP Data ESP TESPH AUTH DATA

IPH1: IP Header 1 IPH2: IP Header 3 ESP H: Encapsulating Security Protocol Header

TCP: Transmission Control Protocol ESP T: Encapsulating Security Protocol Trailer

FIgure 4  Transport Mode and Tunnel Mode of the ESP protocol

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 7: End-to-End Security Across Wired-Wireless Networks for Mobile Users

269 End-to-End Security Across Wired-Wireless Networks for Mobile Users

TLS, another secure protocol is required for secure transmission on the wired part of the network. This makes TLS inadequate as an end-to-end secure pro-tocol spanning over both wired-wireless networks.

In the case of the wired Internet, Secured Sock-ets Layer (SSL) (Frier, Karlton, & Koscher, 1996) is the most widely used security protocol. SSL is an application-layer protocol that provides encryption, source authentication, and integrity protection of application data over insecure public networks. The protocol requires a reliable bidirectional byte-stream service typically provided by TCP, which also guar-antees that there is no duplication or loss. SSL is composed of the following protocols:

the Handshake protocol, used to perform authentication and key exchanges;

the Change Cipher Spec protocol, used to indi-cate the chosen keys that would be used;

the Alert protocol, used for signaling errors and session closure; and

the Application Data protocol, which transmits and receives data.

Gupta et al. (Gupta and Gupta, 2001) proposed an end-to-end architecture that exploits SSL. However, their proposed solution only secures HTTP transac-tions and some other applications running over TCP. All other applications (e.g., Voice over IP) using UDP cannot be used with SSL given that the latter does not support UDP.

The Session Initiation Protocol (SIP) (Rosenberg et al., 2002) is an application-layer control protocol that can initiate, modify, and terminate interactive communication sessions between users. The Session Description Protocol (SDP) (Handley & Jacobson, 1998) is normally used for describing multimedia sessions. SDP assists in the advertisement of confer-ence sessions and transfer of the relevant conference setup information to prospective participants.

SIP establishes sessions by invitations during which session descriptions are used to negotiate a set of compatible media types to be shared among par-ticipants. SIP messages use the Multi-purpose Inter-net Mail Extensions (MIME) standard. SIP includes mechanisms for securing MIME contents to ensure end-to-end integrity and confidentiality, as well as mutual authentication (Galvin, Murphy, Crocker, & Freed, 1995; Housley, 1999; Ramsdell, 1999). Secure MIME (S/MIME) supports authentication for end

users and SIP servers by S/MIME certificates and signatures. S/MIME provides confidentiality for SIP messages. It is also possible to use S/MIME to pro-vide some form of integrity and confidentiality for SIP header fields. However, securing the header fields is much more difficult and complicated.

Umschaden et al. (2003) have proposed a solu-tion that enables end-to-end security of the Session Descriptor Protocol (SDP) together with firewall tra-versal. According to their proposal, the end-user autho-rizes a security proxy server to encrypt SDP traffic on behalf of users. The proxy determines the security capabilities of the receiving party and encrypts SDP traffic for a peer SIP proxy server in the receiving domain. In addition, a one-hop security mechanism such as the Transport Layer Security (TLS) must be used between the User Agent (UA) and its security proxy. Using the Middlebox Communications (MID-COM) protocol, each proxy can dynamically request NAT bindings for an address translation between an IPv4 private address and an IPv4 public address. To enable this solution, Umshaden et al. extended the SIP specification with a new SIP header field: Encr-Src and a new response code: 610 (Potential Security Breach) (Umschaden, Stadler, & Miladinovic, 2003). Encr-Src is used to help a UA to authorize the security proxy server to encrypt the SIP message on behalf of the user. If any potential security breach, relevant to this security mechanism occurs, code 610 is used to indicate to the end user the type of breach that has occurred. This solution relies on S/MIME for authen-tication and security proxies for integrity and confi-dentiality for SDP messages. One serious limitation of Umschaden’s solution is that it does not consider how to secure the MIDCOM protocol limiting the ability to provide an end-to-end secure solution.

4. contrIbutIons oF thIs Work

End-to-end security solutions should a) run trans-parently over wireless-wireless domains and b) be designed and developed to support user mobility and minimize disruption of services while a mobile user roams. It remains a significant challenge to achieve these goals. Past efforts on secure network transmissions work either only within a pure wireless environment or a pure wired environment. In addi-tion, many of these past research efforts also suffer

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 8: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 270

from large handoff delays when users move. Based on our discussions in the related research efforts sec-tion above, we argue that the protocol best suited for wired-wireless domains is the IP Security (IPSec) pro-tocol. However, a serious deficiency with the IPsec protocol is the high handover delays incurred during user mobility. Such high handover delays are particu-larly unsuitable for many delay-sensitive applications such as those involving video and voice. We pres-ent the design and implementation of an approach, based on IPSec that minimizes service interruption and maintains end-to-end network secure transmis-sion even while the mobile user roams around. We empirically evaluate the performance of our pro-posed IPSec-based approach over a real network tes-tbed using a Voice over IP (VoIP) user application.

5. Ike-bAsed APProAch For end-to-end secure netWork 

connectIvIty Across  WIred-WIreless netWorks

Past Approaches to support secure Mobility

IP layer security solutions have been designed primarily for fixed networks (Barton et al., 2002).

When a mobile user roams, it obtains a new IP address from the new wireless network, and as a result it restarts a new IPSec connection. As shown in Figure 5, initially the mobile host is connected to the stationary host via the wireless network 1 through an established IPSec connection. When the mobile host moves from the original wireless network (wire-less network 1) to a new wireless network (wireless network 2) the IPSec tunnel that exists between the mobile host and stationary host is broken. Once the mobile host receives an IP address from the new wireless network (wireless network 2), a new IPSec tunnel is re-established between the mobile host and stationary host.

Qu and Srinivas (2002) proposed a secure wireless virtual private network based on IPSec. The authors discussed how IPSec enables end-to-end security for communication between a mobile host on a wireless network and a stationary host residing on a wired network. However, the authors did not consider the case of how to maintain secure network connectiv-ity for mobile hosts. Mobile IP (Perkins, 1996) uses tunnels to support mobility. However, deployment of trusted foreign agents in various networks is still impractical (Mink, Pahlke, Schafer, & Schiller, 2000). The use of IPSec tunnels with Mobile IP introduces additional overheads caused by double tunneling (Binkley & McHugh, 1998), which puts a burden on

Stationary Host

Mobile Host

Wireless Network 1 Wireless Network 2

Mobile HostMobile Host moving from one wireless network

to another

IPSec Tunnel

New IPSec Tunnel

FIgure 5  Mobile host is connected to the stationary host through an IPSec tunnel

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 9: End-to-End Security Across Wired-Wireless Networks for Mobile Users

271 End-to-End Security Across Wired-Wireless Networks for Mobile Users

resource-constrained networks and devices. Zao and Condell (1997) proposed the use of IPSec tunnels for Mobile IP tunnels without introducing double tun-neling. However, their approach requires the com-plete re-establishment of IPSec tunnels when the mobile host moves to a new network introducing high handoff delays and packet losses. Danzeisen and Braun (2001) proposed another approach that integrates Mobile IP and IPSec where IPSec tunnels are established between a mobile host and a corpo-rate firewall. Their proposed architecture also suf-fers from overheads caused by double tunneling and tunnel re-establishments delays.

Many of the past approaches discussed above have proposed design architectures to support secure roaming of mobile users by combining IPSec with Mobile IP along with various mechanisms to manage keys and other security parameters. Such approaches suffer from high overheads (due to dou-ble tunneling) and introduce high delays caused by the re-establishment of IPSec tunnels.

Kivinen and Tschofenig (2006) recently proposed extensions to the Internet Key Exchange (IKE) Proto-col version 2 (IKEv2) to improve the management of IKE and IPSec Security Associations for multi-homed hosts (with multiple IP addresses) and/or for IPSec hosts whose IP addresses change over time because of mobility. We explore this approach by design, implementation, and evaluation in this work.

design and Implementation of IPsec-based Approach

Internet Key Exchange (IKE) Negotiation for IPSec Security Associations

It is worth pointing out that, in contrast to past research efforts addressing the issue of end-to-end security for mobile users, our approach focuses on optimizing the IPSec protocol (by exploiting rather than integrating a new technology for mobility (such as Mobile IP) with IPSec. The main goal of our approach is not only to maintain end-to-end security with user mobility but also to minimize the impact of such mobility on IPSec tunnels established.

IKE performs a two-phase operation to establish an IPSec tunnel: the phase 1 exchange, also known as the Main Mode Exchange, and the phase 2

exchange, also known as the Quick Mode Exchange (Kaufman & Perlman, 2000).

The phase 1 exchange assumes each of the two parties involved in the exchange has an identity (IP address) by which the other side knows them, and associated with that identity is some sort of secret that can be verified by the other side. This secret might be a preshared secret key or the private por-tion of a key-pair. Phase 1 does mutual authentication based on that secret, and establishes a session key that is used to protect the remainder of the session. The phase 1 exchange happens once (and before any phase 2 exchanges) and allows subsequent set-ting up of multiple phase 2 connections between the same pair of nodes. The phase 2 exchange relies on the session key established in phase 1 to do mutual authentication and establishes a phase 2 session key that is used to protect all the data in the phase 2 Security Association (SA).

Phase 1 (Main Mode) Exchange

The Main Mode Internet Key Exchange (IKE) negotiation (shown in Figure 6) establishes a secure channel, known as the Internet Security Association and Key Management Protocol (ISAKMP) Security Association (SA), between the two computers. The ISAKMP SA is used to protect security negotiations. The Main Mode negotiation determines a specific set of cryptographic protection suites, exchanges keying material to establish the shared secret key, and authenticates computer identities. During the Main Mode phase, three two-way exchanges occur between the initiator and the receiver:

First exchange: the algorithms and hashes used to secure the IKE communications are agreed upon when matching IKE SAs in each peer.Second exchange: uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and passes nonces (random numbers sent to the other party) to prove each other’s identity.Third exchange: verifies the other side’s identity. The identity value is the IPSec peer’s IP address in encrypted form. The main outcome of main mode is the matching of IKE SAs between peers to provide a protected pipe for subsequent secure

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 10: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 272

ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange, the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA, and the shared secret key values for the encryption algorithms. The IKE SA for each peer is bi-directional.

In the first two-way exchange, the hosts exchange their authentication and encryption methods such as the Hash-based Message Authentication Code Mes-sage-Digest algorithm 5 (HMAC-MD5) and the triple Data Encryption Standard (3DES). The Diffie-Hell-man key exchange is performed in the second two-way exchange. IP addresses are exchanged between the two hosts in their encrypted form between the two hosts in the third two-way exchange after which the IKE SA (keying channel) is finally established.

Phase 2 Quick Mode Exchange

The Quick Mode IKE negotiation (shown in Figure 7) establishes a secure channel between two hosts to protect data. Since this phase involves the estab-lishment of SAs that are negotiated on behalf of the IPSec service, the SAs created during Quick Mode are called IPSec SAs. During the Quick Mode phase, keys are refreshed, or if necessary, new keys are generated. A protection suite that protects specific IP

traffic is also selected. The Quick Mode phase is not considered a complete exchange because it relies on a Main Mode Exchange.

The IKE phase 2 exchange performs the follow-ing functions:

Negotiates IPSec SA parameters protected by an existing IKE SA;establishes IPSec SAs;periodically renegotiates IPSec SAs to ensure security; andoptionally performs an additional Diffie-Hellman exchange.

The Quick Mode exchange occurs after IKE has established the secure tunnel in phase 1. It negotiates a shared IPSec policy, derives the shared secret key used for the IPSec security algorithms, and estab-lishes the IPSec SAs. During the Quick Mode phase, nonces are exchanged to prevent replay attacks. The Quick Mode exchange is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires.

Implementation of Proposed IKE-based Approach for Secure Mobility

In the case of IKE phase 2, the hosts exchange Secu-rity Association information that contains the agreed encryption and hashing algorithms as well as the

DES: Data Encryption Standard HMAC: Hash Message Authentication Code MD5: Message Digest Algorithm 5

IKE : Internet Key Exchange SA: Security Association

Host AHost B

IKE SA Queueing Channel

IKE Phase 1

3 DESHMAC- MD5

DIFFIE-HELLMANIP ADDRESS

3 DESHMAC- MD5

DIFFIE-HELLMANIP ADDRESS

FIgure 6  Main Mode Exchange (Phase 1)

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 11: End-to-End Security Across Wired-Wireless Networks for Mobile Users

273 End-to-End Security Across Wired-Wireless Networks for Mobile Users

identification payload that describes the traffic (e.g., IP addresses, TCP ports) that is to be protected and a Nonce payload. An IPSec SA is finally set up using the agreed algorithm and key to encrypt the data.

When a mobile host changes it network point of attachment, it often obtains a new IP address for the new network attachment point using either stateful address configuration techniques or via the stateless address auto-configuration mechanism. In contrast to past proposed approaches discussed above, our goal in this scenario (where the mobile host com-municates across the wired-wireless network with the stationary node (residing on the wired portion of the network)) is to enable the mobile host and the stationary host to continue to use the existing SAs for the already established IPSec tunnel with-out having to set up a new IKE SA. To achieve this goal, we also perform a two-phase negotiation to

establish the IPSec SA. While setting up the IKE SA, the mobile host provides a list of addresses to the stationary host so that the IPSec SAs need not be re-established when the mobile host changes its IP address.

In the first two-way exchange, the mobile host and the stationary host (residing on the wired net-work) negotiate their authentication and encryption methods, namely HMAC-MD5 and 3DES. The Diffie-Hellman key exchange is performed in the second two-way exchange. In the third two-way exchange, each host verifies the other host’s identity. The iden-tity value is the IPSec peer’s IP address in encrypted form. The mobile host sends the list of IP addresses that it will potentially use in the future to the station-ary host in encrypted form (as shown in Figure 8). It is worth noting that the IP address used for the mobile host at the time of the IKE SA establishment

Host AHost B

IKE SA Data Channel

IKE Phase 2

Security Association Security Association

IKE : Internet Key Exchange SA: Security Association

FIgure 7  Quick Mode Exchange (Phase 2)

Mobile HostIKE SA (Keying Channel)

IKE Phase 1

3 DESHMAC-MD5

DIFFIE-HELLMANLIST OF IP ADDRESSES

Stationary Host

3 DESHMAC-MD5

DIFFIE-HELLMANLIST OF IP ADDRESSES

DES: Data Encryption Standard HMAC: Hash Message Authentication Code MD5: Message Digest Algorithm 5

IKE : Internet Key Exchange SA: Security Association

FIgure 8  Proposed IKE Exchange Using a List of IP Addresses

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 12: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 274

is the preferred address, while the IP addresses specified are the alternate IP addresses. The mobile host has only one IP address at any time. The phase 2 exchange of our approach is identical to the origi-nal phase 2 IKE exchange.

In the case of the original phase 1 (Main Mode) exchange, when the IP address of the mobile host changes, both phases of IKE are repeated to re-establish the IPSec tunnel. As a result, both the IKE SAs and IPSec SAs are completely re-estab-lished every time the mobile host roams from one network to another and changes its IP address. With our proposed approach, when the mobile host changes its IP address to the one specified in the list of IP addresses (specified in the third two-way exchange of Phase 1 Main Mode Exchange), existing IKE SAs and IPSec SAs can be used with-out re-establishing them. Although the tunnel is set up again with our approach, the set up time is lower compared to the original IKE since only the IP address update is required for the SAs without re-establishing them and repeating the first two phases of IKE.

6. PerForMAnce evAluAtIon  oF ProPosed  

IPsec-bAsed APProAch

experimental testbed and Measurement Procedures

The experimental testbed used in our performance evaluation measurements is depicted in Figure 9. We used one laptop, an Intel Mobile Pentium 4 1.8 GHz processor and 512 MB RAM, as the mobile host. For the stationary host we used a desktop equipped with a 1.8 GHz Intel Xeon processor and 512 MB RAM. We used a VoIP application program in all our tests. The VoIP client and VoIP server software runs on the mobile host and on the stationary host (con-nected to the wired network).

We used the IPSec implementation from the open source project FreeS/WAN (Gilmore, 2007, Oct. 15). FreeS/WAN uses regular IKE to establish IPSec SAs. To implement our approach, we modified the FReeS/WAN source code. For VoIP measurement tests, we transmitted VoIP packets from the mobile

host to the stationary host using an 802.11b wireless local area network (and a Linksys access point) and a wired local area network running at 100 Mbits/s. Voice recording and encryption were done at the server. Voice decryption and playback were done at the mobile host. We IPSec protocol in tunnel mode for the tests conducted.

Initially an IPSec tunnel is established through wireless access point A (shown in Figure 9) between the mobile host and the stationary host. The mobile host is moved away from the access point and at some point the IPSec tunnel established is broken. Once the mobile host obtains a new IP address, a new IPSec tunnel is established through the wire-less access point B from the mobile host to the sta-tionary host. We measured the following metrics using various VoIP packet sizes (ranging from 64-352 bytes):

1. Packet loss: the number of packet loss during handoff.

2. Handoff delay (in microseconds): this is the time difference between arrival time of the last packet at the receiver using the old IPSec connection and the arrival time of the first packet received using the new IPSec connection (using a VoIP packet size of 128 bytes).

3. The time taken (in seconds) to create an IKE SA and an IPSec SA were also measured (using a VoIP packet size of 126 byes).

We conducted the above set of tests and mea-sured the three metrics using the original (unmodi-fied) IKE method. We also conducted a second set of tests and measured the three metrics again with our proposed approach (using a supplied list of IP addresses).

experimental results and Performance Analysis

Packet Loss During Handoff

The packet loss results shown in Figure 10 show that with our approach we obtained a 17-34% improvement (lower) packet loss (as shown in Table 1) compared to the original IKE method for the various packet sizes used. The reason for the

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 13: End-to-End Security Across Wired-Wireless Networks for Mobile Users

275 End-to-End Security Across Wired-Wireless Networks for Mobile Users

lower packet loss with our approach is because with regular IKE, during handoff when the mobile host changes its IP address, the old IPSec tunnel is bro-ken and a new IKE SA and IPSec SA are re-estab-lished to during the establishment of the new IPSec tunnel between the mobile and stationary host. In

Mobile Host SENDER(Recording and Encryption)

Mobile Host moving

from one wireless network

to another

IPSec Tunnel Break

Wireless Access Point B

Wireless Access Point A

New IPSec TunnelFormation

Stationary Host RECEIVER(Decryption and Playback)

FIgure 9  Experimental Testbed to Evaluate the Impact of Proposed Approach

contrast, with our approach once the mobile host changes its IP address to the new one, the old IPSec tunnel is broken and a new IPSec tunnel is set up between the mobile and stationary host without re-establishing the IKE SA and the IPSec SA. In this case, we update only the IP address for the SAs but

tAble 1  Improvement in packet loss with our proposed approach compared to the original IKE approach

Packet size (bytes) 64 96 128 160 192 224 256 288 324 356

Percentage improvement (%) with new approach 28 28 27 20 17 24 19 24 31 34

05001000150020002500300035004000

64 96 128 160 192 224 256 288 320 352Payload (bytes)

Nu

mb

er o

f V

oIP

pac

ket

s lo

st

IKE Our Approach

FIgure 10  Variation of the Number of VoIP Packets Lost During Handoff from Wireless Access Point A to Wireless Access Point B

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 14: End-to-End Security Across Wired-Wireless Networks for Mobile Users

Zeadally, Sklavos, Rathakrishnan, and Fowler 276

everything else (from the encryption algorithm to the keys used) remains the same.

Handoff Delay

The inter-arrival packet delays for different pack-ets are shown in Figure 11. We obtained a handoff delay of 18.83 seconds with the original IKE method and 14.25 seconds with our proposed approach, a handoff delay improvement of about 24%. This handoff delay reduction is again because both the IKE SA and IPSec SA are not re-established with the new IPSec tunnel (compared to the original IKE approach where both the IKE SA and IPSec SA need to be re-established with a new IPSec tunnel).

We obtained 2.27 seconds and 1.14 seconds for the time taken to perform the IKE SA and the IPSec SA, respectively, for the original IKE approach. We did measure these values for our approach since these operations are not repeated during handoff. However, we did measure the time taken by IKE SA and IPSec SA operations during the initial tun-nel establishment (i.e., the time taken to set up the

IPSec tunnel between the mobile host and the sta-tionary host for the first time). The results are shown in Table 2.

We observe from Table 2 that our proposed approach takes 0.59 seconds more to create the IKE SA and the IPSec SA (total time of 3.58 seconds) dur-ing the establishment of the first IPSec tunnel com-pared to the time taken by the original IKE approach (total time of 4.17 seconds). The slightly higher time taken is mostly likely due to the time and overhead involved in exchanging the list of IP addresses with the stationary host during the setting up of the first IPSec tunnel.

7. conclusIon

In the past few years, we have witnessed an explo-sive growth in wireless networking technologies that are increasingly being used as extensions to the wired Internet. Another important trend is the high mobil-ity of users along with important requirements such as secure service access anywhere, anytime. Many security protocols have been designed, implemented,

0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

16000000

18000000

20000000

1

24

47

70

93

11

6

13

9

16

2

18

5

20

8

23

1

25

4

27

7

30

0

32

3

34

6

36

9

39

2

41

5

43

8

46

1

48

4

Packet Number

Inte

rarr

iva

l p

ac

ke

t d

ela

y

(mic

ros

ec

on

ds

)

IKE Our Approach

FIgure 11  Inter-arrival Packet Delays with IKE and Our Approach During Handoff

tAble 2  Time taken to create the IKE SA and the IPSec SA for the original IKE approach and for our proposed approach during the first IPSec tunnel establishment

IPSec OperationsTime Taken (seconds)

(using original IKE approach)Time Taken (seconds)(using our approach)

IKE SA 2.32 2.68IPSec SA 1.26 1.49Total time taken 3.58 4.17

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014

Page 15: End-to-End Security Across Wired-Wireless Networks for Mobile Users

277 End-to-End Security Across Wired-Wireless Networks for Mobile Users

and evaluated for wired networks. Similarly, several security protocols have also been deployed for wire-less local area networks. However, as we discussed earlier, many of these protocols fail to deliver end-to-end security when deployed over wired networks connected to wireless networks. Moreover, such security protocols are often not optimized to deliver optimal end-to-end secure performance with user mobility. For the various reasons discussed earlier in this paper, we argue that IPSec is the best candidate for end-to-end security for heterogeneous networking environments composed of wired-wireless networks. However, the basic IPSec protocol suffers from high handoff latency and packet loss during user mobility when IPSec tunnels are broken and re-established frequently. We proposed an approach (based on the IPSec protocol) that minimizes handoff delay and packet loss for mobile users roaming across hetero-geneous wired-wireless networks. We demonstrated the efficiency of our proposed approach with empiri-cal performance results.

reFerences

Alshamsi, A., and Saito, T. (2005). A Technical Comparison of IPSec and SSL, Proceedings of 19th IEEE International Conference on Advanced Information and Networking Applications, Vol. 2, pp. 395–398, Taipei, Taiwan, March 2005.

Barton, M., Atkins, D., Lee, J., Narain, S., Ritcherson, D., Tepe, K., and Wong, K. (2002). Integration of IP Mobility and Security for Secure Wireless Communications, IEEE International Conference on Com-munications, Vol. 2, pp. 1045–1049.

Binkley, J., and McHugh, J. (1998). The Portland State University Secure Mobile Networking Project.

Blunk, L., and Vollbrecht, J. (1998). PPP Extensible Authentication Pro-tocol, RFC 2284, IETF.

Dierks, T., and Allen, C. (1999). The TLS Protocol, RFC 2246, IETF.Danzeisen, M., and Braun, T. (2001). Secure MobileIP Communication,

Proceedings of Workshop on Wireless Local Networks, 26th Annual IEEE Conference on Local Computer Networks, pp. 586–593, Tampa, FL, November 2001.

Elkeelany, O., Matalgah, M., Sheikh, P., Thaker, M., Chaudhry, G., Medhi, D., and Qaddour, J. (2002). Performance Analysis of IPSec protocol: Encryption and Authentication, Proceedings of the IEEE International Conference on Communications, Vol 2(28), 1164–1168.

Frier, A., Karlton, P., and Koscher, P. (1996). The SSL Protocol Version 3.0, Netscape Communications Corporation.

Galvin, J., Murphy, S., Crocker, S., and Freed, N. (1995). Security Mul-tiparts for MIME: Multipart/Signed and Multipart/Encrypted, RFC 1847, IETF, October.

Gilmore, J. (2007, October 15). Linux FreeS/WAN Project. Retrieved October 15, 2007, from http://www.freeswan.org/

Godber, A., and DasGupta, P. (2002). Secure Wireless Gateway, Pro-ceedings of the ACM Workshop on Wireless Security, Atlanta, GA, September 2002.

Gupta, V., and Gupta, S. (2001). Securing the Wireless Internet, IEEE Communications Magazine, Vol. 39(12), 68–74.

Handley, M., Jacobson, V. (1998). SDP: Session Description Protocol, RFC 2327, IETF, April.

Housley, R. (1999). Cryptographic Message Syntax, RFC 2630, IETF.Harkins, D., and Carrel, D. (1998). Internet Key Exchange, RFC 2409,

IETF.IEEE. (2001). P802.1X/D11 Standards for Local and Metropolitan Area

Networks: Standard for Port based Network Access Control.Itani, W., and Kayssi, A. (2003). J2ME End-to-End security for M-Com-

merce., IEEE Wireless Communications and Networking, Vol. 3, 2015–2020.

Kaufman, C., and Perlman, R. (2000). Key Exchange in IPSec: Analysis of IKE, IEEE Internet Computing, Vol. 4(6), 50–56.

Kent, S., and Atkinson, R. (1998a). Security Architecture for the Internet Protocol, RFC 2401, IETF.

Kent, S., and Atkinson, R. (1998b). IP Authentication Header, RFC 2402, IETF.

Kent, S., and Atkinson, R. (1998c). IP Encapsulating Security Payload, RFC 2406, IETF.

Kivinen, T., and Tschofenig, H. (2006). Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol, IETF, RFC 4621.

Krawczyk, H., Bellare, M., and Canetti, R. (1997). HMAC: Keyed-Hash-ing for Message Authentication, RFC 2104.

Ma, Y., and Cao, X. (2003). How to use EAP-TLS Authentication in PWLAN Environment, Proceedings of the International Conference on Neural Networks and Signal Processing, Vol. 2, pp. 1677–1680.

Madson, C., and Doraswamy, N. (1998). The ESP DES-CBC Cipher Algo-rithm with Explicit IV, RFC 2405.

Maughan, D., Schertler, M., and Schneider, M. (1998). Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, IETF.

Mink, S., Pahlke, F., Schafer, G., and Schiller, J. (2000). Towards Secure Mobility support for IP Networks, Proceedings of International Con-ference on Communication Technology. WCC-ICCT 2000, Vol. 1, pp. 555–562.

NIST. (2007). FIPS PUB 180-1: Secure Hash Standard, April 1995. Retrieved October 15, 2007, from http://www.itl.nist.gov/fipspubs/ fip180-1.htm

Perkins, C. (1996). IP Mobility Support, RFC 2002, IETF, October.Qu, W., and Srinivas, S. (2002). IPSec-based Secure Wireless Virtual Pri-

vate Network, IEEE Proceedings MILCOM, Vol. 2, pp. 1107–1112.Ramsdell, B. (1999). S/MIME Version 3 Message Specification, RFC

2633, IETF, June.Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J.,

Sparks, R., Handley, M., and Schooler, E. (2002). SIP:Session Initia-tion Protocol, RFC 3261, IETF, June.

Rivest, R. (1992). The MD5 Message-Digest Algorithm, RFC 1321, IETF.Umschaden, K., Stadler, J., and Miladinovic, I. (2003). End-to-End Secu-

rity for Firewall/NAT Traversal within the SIP, IETF.Windson, V., Bringel, F., Katy, M., Carlos, G., Javam, C., and Rossana, A.

(2004). MobiS: A Solution for the development of Secure Applica-tions for Mobile Device. Vol. 3124, LNCS, Springer, In: Telecommuni-cations and Networking–ICT 2004, Fortaleza, Brazil.

Zao, J., and Condell, M. (1997). Use of IPSec in MobileIP, IETF.

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

14:

51 0

7 O

ctob

er 2

014