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

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

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

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]

Abstract  Recent advances in mobile computing and wireless communication 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 consisting of wired and wireless networking technologies. Both network heterogeneity 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, government, military, and educational applications use the Internet to communicate 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 authenticity 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 alternative to leased lines for building private networks is Virtual Private Network 264

(VPN) technology. VPN combines two networking concepts, namely virtual networking and private networking. A virtual network is typically constructed over another network (such as the Internet) and allows geographically distributed users to interact 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 tunnel a secure connection (as if they were communicating 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 transparent 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 wiredwireless networks. Section 6 presents a performance evaluation of our proposed approach. Finally, in section 7, we present some concluding remarks.

2. Background on IPSec IPSec is a collection of protocols, authentication, and encryption mechanisms designed to provide 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). 265

The core of the IPSec suite of protocols includes the Authentication Header (AH) protocol, Encapsulating 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) provides authentication, encryption or both. By providing encryption, ESP secures the IP datagram against eavesdropping during transit. ⦁ The IKE protocol provides the secure exchange of keys. It allows communicating parties to negotiate 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. Authentication 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 protocol 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 confidentiality 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 32bit 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

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

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

of keeping track of the order in which packets go, and for making sure that the same set of parameters 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 authentication 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. Zeadally, Sklavos, Rathakrishnan, and Fowler

The Security Parameter Index (SPI) is an arbitrary 32-bit number that specifies to the device receiving the packet the group of security protocols the sender is using for communication—the algorithm, 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 parameters. 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 confuse sniffers trying to estimate how much data is transmitted. ⦁

266

Transport Mode

IPH1

TCP

AH

Data

Tunnel Mode

IPH2

IPH1: IP Header 1

Figure 3 

AH

IPH1

IPH2: IP Header 2

Data

AH: Authentication Header

TCP: Transmission Control Protocol

Transport Mode and Tunnel Mode of the AH protocol

The Pad Length field specifies the amount of payload 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 Standard) in Cipher Block Chaining (CBC) Mode (Madson & Doraswamy, 1998). To ensure successful and secure communication with IPSec, the IKE (Harkins & Carrel, 1998) protocol 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 twophase 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 provided that can be either host to host or via ­gateways 267

TCP

in which traffic have to pass through a gateway to access ultimate destination. The tunnel mode protects the original IP header and reveals only the IP address of the IPSec gateway machine whereas in transport mode only the payload is encrypted leaving 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 transport 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 packets 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 cryptographic 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

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

Transport Mode

IPH1

ESP H

TCP

ESP H

IPH1

Data

ESP T

ESP AUTH DATA

Tunnel Mode

IPH2

IPH1: IP Header 1

TCP

IPH2: IP Header 3

TCP: Transmission Control Protocol

FIGURE 4 

Data

ESP T

ESPH AUTH DATA

ESP H: Encapsulating Security Protocol Header ESP T: Encapsulating Security Protocol Trailer

Transport Mode and Tunnel Mode of the ESP protocol

J2ME for mobile computing users. The solution proposed 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 extensible 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 supports multiple authentication mechanisms. It is a PPP extension that provides support for additional authentication methods within PPP. It does not select a specific authentication mechanism at link control phase, but postpones this until the authentication phase. This allows the authenticator to request more information before determining the specific ­authentication Zeadally, Sklavos, Rathakrishnan, and Fowler

­ echanism. This also permits the use of a back-end m server (such as the RADIUS), which actually implements the various mechanisms while the PPP authenticator 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 terminal and the RADIUS server perform the authentication 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 268

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 protocol spanning over both wired-wireless networks. In the case of the wired Internet, Secured Sockets 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 guarantees 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 indicate 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 transactions 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 conference 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 participants. SIP messages use the Multi-purpose Internet 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 269

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 provide 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 solution that enables end-to-end security of the Session Descriptor Protocol (SDP) together with firewall traversal. According to their proposal, the end-user authorizes 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 (MIDCOM) 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: EncrSrc 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 authentication and security proxies for integrity and confidentiality 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 transparently 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 addition, many of these past research efforts also suffer

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

Stationary Host IPSec Tunnel Wireless Network 2

Wireless Network 1

New IPSec Tunnel

Mobile Host

FIGURE 5 

Mobile Host moving from one wireless network to another

Mobile Host

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

from large handoff delays when users move. Based on our discussions in the related research efforts section above, we argue that the protocol best suited for wired-wireless domains is the IP Security (IPSec) protocol. However, a serious deficiency with the IPsec protocol is the high handover delays incurred during user mobility. Such high handover delays are particularly unsuitable for many delay-sensitive applications such as those involving video and voice. We present the design and implementation of an approach, based on IPSec that minimizes service interruption and maintains end-to-end network secure transmission even while the mobile user roams around. We empirically evaluate the performance of our proposed IPSec-based approach over a real network testbed 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). Zeadally, Sklavos, Rathakrishnan, and Fowler

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 (wireless 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 connectivity 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 270

resource-constrained networks and devices. Zao and Condell (1997) proposed the use of IPSec tunnels for Mobile IP tunnels without introducing double tunneling. However, their approach requires the complete 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 corporate firewall. Their proposed architecture also suffers 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 double 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) Protocol 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

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 portion 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 setting 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 ⦁

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 271

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

IKE Phase 1

IKE SA Queueing Channel Host A

Host B 3 DES HMAC- MD5 DIFFIE-HELLMAN IP ADDRESS

3 DES HMAC- MD5 DIFFIE-HELLMAN IP ADDRESS

DES: Data Encryption Standard

HMAC: Hash Message Authentication Code

SA: Security Association

IKE : Internet Key Exchange

FIGURE 6 

MD5: Message Digest Algorithm 5

Main Mode Exchange (Phase 1)

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 Message-Digest algorithm 5 (HMAC-MD5) and the triple Data Encryption Standard (3DES). The Diffie-Hellman key exchange is performed in the second twoway 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 establishment 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 Zeadally, Sklavos, Rathakrishnan, and Fowler

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 following functions: Negotiates IPSec SA parameters protected by an existing IKE SA; ⦁ establishes IPSec SAs; ⦁ periodically renegotiates IPSec SAs to ensure security; and ⦁ optionally 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 establishes 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 Security Association information that contains the agreed encryption and hashing algorithms as well as the 272

IKE Phase 2

IKE SA Data Channel Host A

Host B Security Association

Security Association

SA: Security Association

IKE : Internet Key Exchange

FIGURE 7 

Quick Mode Exchange (Phase 2)

IKE Phase 1

IKE SA (Keying Channel) Mobile Host

Stationary Host

3 DES HMAC-MD5 DIFFIE-HELLMAN LIST OF IP ADDRESSES

DES: Data Encryption Standard

3 DES HMAC-MD5 DIFFIE-HELLMAN LIST OF IP ADDRESSES

HMAC: Hash Message Authentication Code

IKE : Internet Key Exchange

FIGURE 8 

SA: Security Association

Proposed IKE Exchange Using a List of IP Addresses

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 communicates 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 without having to set up a new IKE SA. To achieve this goal, we also perform a two-phase negotiation to 273

MD5: Message Digest Algorithm 5

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 network) negotiate their authentication and encryption methods, namely HMAC-MD5 and 3DES. The DiffieHellman 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 identity 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 stationary 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

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

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 original 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 reestablish the IPSec tunnel. As a result, both the IKE SAs and IPSec SAs are completely re-established 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 twoway exchange of Phase 1 Main Mode Exchange), existing IKE SAs and IPSec SAs can be used without 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 (connected 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 Zeadally, Sklavos, Rathakrishnan, and Fowler

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 wireless access point B from the mobile host to the stationary host. We measured the following metrics using various VoIP packet sizes (ranging from 64352 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 measured the three metrics using the original (unmodified) 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 1734% 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 274

Wireless Access Point B

New IPSec Tunnel Formation

Mobile Host SENDER (Recording and Encryption)

Wireless Access Point A

Mobile Host moving from one wireless network to another

FIGURE 9 

Stationary Host RECEIVER (Decryption and Playback)

IPSec Tunnel Break

Number of VoIP packets lost

Experimental Testbed to Evaluate the Impact of Proposed Approach

4000 3500 3000 2500 2000 1500 1000 500 0

64

96

128

160

192

224

256

288

320

352

Payload (bytes)

IKE

FIGURE 10  TABLE 1 

Our Approach

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

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

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 broken and a new IKE SA and IPSec SA are re-established to during the establishment of the new IPSec tunnel between the mobile and stationary host. In 275

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 reestablishing the IKE SA and the IPSec SA. In this case, we update only the IP address for the SAs but

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

484

461

438

415

392

369

323

346

300

277

254

231

208

185

162

139

93

116

70

47

24

1

Interarrival packet delay (microseconds)

20000000 18000000 16000000 14000000 12000000 10000000 8000000 6000000 4000000 2000000 0

Packet Number IKE

FIGURE 11  TABLE 2 

Our Approach

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

 ime taken to create the IKE SA and the IPSec SA for the original IKE approach and T for our proposed approach during the first IPSec tunnel establishment

IPSec Operations

Time Taken (seconds) (using original IKE approach)

Time Taken (seconds) (using our approach)

IKE SA IPSec SA Total time taken

2.32 1.26 3.58

2.68 1.49 4.17

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

Handoff Delay The inter-arrival packet delays for different packets 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 tunnel establishment (i.e., the time taken to set up the Zeadally, Sklavos, Rathakrishnan, and Fowler

IPSec tunnel between the mobile host and the stationary 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) during the establishment of the first IPSec tunnel compared 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 explosive growth in wireless networking technologies that are increasingly being used as extensions to the wired Internet. Another important trend is the high mobility of users along with important requirements such as secure service access anywhere, anytime. Many security protocols have been designed, ­implemented, 276

and evaluated for wired networks. Similarly, several security protocols have also been deployed for wireless local area networks. However, as we discussed earlier, many of these protocols fail to deliver endto-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 heterogeneous wired-wireless networks. We demonstrated the efficiency of our proposed approach with empirical 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 Communications, 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 Protocol, 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 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, RFC 1847, IETF, October.

277

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, Proceedings 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-Commerce., 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-Hashing 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 Algorithm 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 Conference 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 Private 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 Initiation 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 Security 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 Applications for Mobile Device. Vol. 3124, LNCS, Springer, In: Telecommunications and Networking–ICT 2004, Fortaleza, Brazil. Zao, J., and Condell, M. (1997). Use of IPSec in MobileIP, IETF.

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