Simple Mobility Support for IPsec Tunnel Mode Byoung-Jo "J" Kim, AT&T Labs-Research, [email protected] Srividhya Srinivasan, Georgia Institute of Technology, [email protected]

Abstract— Many corporate employees (those commonly known as road warriors) often access the resources in protected corporate intranets, while working remotely, through IPsec tunnels between their corporate VPN (Virtual Private Network) gateway and their remote hosts. With the proliferation of Wireless LANs, 3G wireless networks, and mobile workers, it becomes highly desirable for remote hosts to be able to move among multiple networks (IP subnets) freely, even across different air interface technologies. Currently, IPsec does not support this movement without breaking and re-establishing of IPsec tunnels. Re-establishing IPsec tunnels could cause disruptions to applications currently running across the tunnels, in addition to incurring the overhead of a 3 to 6 roundtrip handshake for a new tunnel establishment. One solution could be to run IPsec tunnels over MobileIP to enable mobility. However, that is inefficient due to the double tunneling, which is especially an issue for resource-limited wireless networks. We explore modifying an IPsec implementation to enable mobility without compromising security and without incurring tunnel-re-establishment at handoff. We do not intend to address the general issue of secure mobility support for the Internet. Instead, we focus on a single scenario of VPN remote access via IPsec ESP-only tunnel mode in IPv4, which has a large commercial application of the secure remote access of corporate intranets. Our approach is to change the tunnel endpoint IP address of the mobile host at the IPsec VPN gateway via a secure signaling, which is possible with minor modifications to how IPsec operates. To this end, we modified FreeS/WAN v1.8, an open-source implementation of IPsec. We remove the dependence of identifying a Security Association on the outerheader destination address so that the same security parameters can be used even in the new network. Two new private messages are added to ISAKMP (Internet Security Association and Key Management Protocol) to enable the required signaling to update new tunnel endpoint addresses. Our approach neither compromises the security of IPsec, nor requires changes to the existing IPsec standard, preserving interoperability with mobility-unaware hosts and gateways. We describe a working implementation of these modifications, discuss the performance of this approach, and compare with the standard IPsec and IPsec over MobileIP.

I. INTRODUCTION IPsec [1] is becoming a widely accepted way to secure communications over the Internet. IPsec is designed to be flexible, accommodating various operational scenarios. One of the important scenarios for IPsec is to provide secure remote access to corporate intranets for those often-called “road warriors”; corporate employees

who need to access resources in protected corporate intranets while working remotely or traveling. IPsec tunneling mode [1] is often used for such a scenario where an IPsec tunnel is formed between a remote host and a VPN (Virtual Private Network) gateway so that ordinary IP packets can be securely transferred between the remote host and the corporate intranet to which the VPN gateway is connected. With the deployment of 3G (the third generation) cellular networks and the proliferation of WLAN’s, it is likely that remote hosts will be capable of using multiple networks of same or different wireless access technologies. In this case, it is highly desirable to be able to move IPsec VPN tunnels between different networks without breaking and re-establishing them. When IPsec tunnels are broken and re-established, applications currently running across the tunnels are likely to be disrupted or encounter errors, since operating systems usually represent IPsec tunnels as virtual interfaces which appear being down when the current tunnel is broken. In addition, IPsec requires up to six roundtrips of signaling to setup a new pair of tunnels, which is problematic for resource-constrained wireless networks and for long multi-hop paths. Tunnel re-establishment also complicates “make before break” handoffs, unless multiple pre-established tunnels are used with proper routing table updates. However, with dynamically assigned IP addresses for most access networks, maintaining multiple preestablished tunnels is also difficult in practice. Traditionally, IP-level mobility is addressed with MobileIP [2], which uses a tunnel itself to handle mobility. MobileIP running in a co-located FA mode is better suited for the remote access scenario of out interest, since deploying trusted FA in wide varieties of networks is still impractical [7]. However, running IPsec tunnels over MobileIP is inefficient due to the double tunneling [6] which is especially an issue for resource-constrained wireless networks. In [8], the use of IPsec tunnels for some of MobileIP tunnels is proposed. Though there was no double tunneling, this proposal employed re-establishing IPsec tunnels after a mobile host moves into a new network. In [9], another approach to integrate MobileIP and IPsec is described, where an IPsec tunnel is used between a mobile host and a corporate firewall/gateway in which a mobility tunnel to a MobileIP HA (Home Agent) is established. Again, double tunneling and tunnel re-establishments still introduce overheads. In summary, the above approaches have tried to address the general problem of secure IP mobility by fully integrating MobileIP and IPsec with various mechanisms to manage keys and other security

parameters. The inefficiency introduced due to the integration, e.g., double tunneling or IPsec tunnel reestablishment, are not of critical concern or are sometimes unavoidable, given the scope of the goal that is the general secure IP mobility support. Our work differs from these previous works in that we only focus on the limited scenario of mobile remote access to corporate intranets. Moving the endpoints of IPsec tunnels to the new wireless network that the remote host is moving into, is more efficient and a straightforward way to support mobility for this commercially important remote access scenario. In this paper, we describe our implementation of a support for mobility for IPsec tunneling mode for IPv4. We do not intend to address the general issue of secure mobility support for the Internet, which is in progress in IETF [8] and in several other technical forums. Instead, we concentrate on the scenario of remote access via IPsec ESPonly tunnel mode in IPv4 and show that it is secure and simple to modify an existing IPsec implementation to support mobility for this scenario. It is achieved by enabling updates of tunnel endpoint IP addresses via a secure signaling between a remote host and an IPsec VPN gateway. In the following sections, we briefly describe the scenario setup. Then, our modifications for IPsec mobility made to an open-source IPsec implementation, FreeS/WAN [3] are described. Some discussions on several aspects of our approach are presented followed by a conclusion. II. SCENARIO SETUP Figure 1 shows the test network that we use to emulate the remote access scenario. The gateway is connected to two networks, one “internal” corporate network, and another “external” network, e.g. the Internet. The external network is then connected to two additional routers (Router A and B), which in turn connect to two separate network A and B. The mobile host is then connected to both A and B network, simultaneously or one at a time. Mobility is then emulated by switching between the two networks. We do not directly address the issues of network detection and IP address configuration when mobile hosts move into a new network. These issues are common to any IP-level mobility solutions, and are not discussed in this paper due to space limits. Nonetheless, most approaches to the problem can be used with our approach. The remote mobile host is currently in Network A (possibly a WLAN). The mobile host initiates the setup of an IPsec tunnel to the corporate gateway using an IP address valid for Network A. Two tunnels (one for each direction) are set up when all signaling is finished. Later in time, the mobile host enters Network B (possibly a 3G cellular network) and must perform a handoff of its tunnels before or at the moment when it loses its wireless connection to Network A so that on-going communication over the current tunnels is uninterrupted.

III. REQUIRED MODIFICATIONS AND THEIR IMPLEMENTATION Due to the limited space, we assume the some familiarity of IPsec from readers [1,3,10,11,12]. We modified FreeS/WAN v 1.81 [3], an open-source implementation of IPsec for the Linux. RedHat 5.2 with the kernel version 2.2.14 is used with FreeS/WAN. There are four modifications required to achieve our goals. These modifications are not specific to FreeS/WAN, although the last modification has a minor aspect specific to FreeS/WAN. A. Removing Dependence on tunnel outer destination address for locating SA RFC2401 [10] describes that a SA (Security Association) is identified by a triple consisting of SPI (Security Parameter Index), IP destination address (of the outer header of a tunnel), and a security protocol identifier (AH or ESP). The IP destination address can be a unicast, multicast, or broadcast address. If a tunnel endpoint is changed to a new IP address (e.g., obtained via DHCP or IPv6 automatic address configurations), as a mobile host moves into a new network, then the correct SA cannot be identified according to the rules in the RFC, since the destination address is different. This will break the current tunnel if nothing is done. However, the dependency of SA on IP destination address is not necessary for unicast tunnels, but only needed to handle IPsec multicast and broadcast .(which are rarely used in practice.). All unicast tunnels to the mobile’s network interface are bound to have the same IP address, the address of the mobile host at its current network. Thus, SPI is the major parameter to use to identify different tunnels for unicast1 (along with the protocol identifier that may be same for many tunnels.). To make these cases handled properly, SPI is chosen by the destination host of an IPsec connection, according to RFC2409, so that SPI’s can be unique for tunnels with the same destination address. In fact, it is trivial to ensure that SPI is unique system-wide in a host, which we implemented in our FreeS/WAN modification, so that SPI alone can identify SA’s. This does not require any changes in the IPsec standard and preserves normal interoperability with other IPsec hosts and gateways without mobility support. An IPsec implementation identifies connections through SAID (Security Association ID), which is a 1

For multicast, the tunnel destination address must be used together with SPI to correctly identify a multicast tunnel. This case can be easily handled as an exception instead of having a general rule of including the tunnel destination address for tunnel identification, since multicast addresses are easily distinguished by their ranges. If the tunnel destination address is a multicast address, then that address is used in conjunction with SPI and protocol type to locate the correct SA. If not, only SPI and protocol type are used. This change in implementation does not need a similar change in other mobility-unaware hosts, thus preserving interoperability. Nonetheless, multicast is not used in the scenario considered in this paper.

function of the SPI, destination address and the protocol used. The first step was to remove the dependence of tunnel identification from the destination address, except if the destination address is multicast. FreeS/WAN uses a hash table for mapping SAIDs to SA data structures. When a new tunnel is set-up, a SA is created and it is assigned an SAID. A hash table is used in order to retrieve the appropriate SA for a particular SAID. This hash table uses the SPI, the tunnel destination address and the protocol as SAID inputs and produces pointers to the corresponding SA. Since the destination address should no longer be used to identify the tunnel, the routines for this table were modified not to use the destination address while creating and retrieving an SA. This also allows “make before break” handoff. Correct SAID’s can be identified for packets arriving via either IP network connection A or B, and as a result, any packets in-flight via the old network can be still correctly handled while handoff is being performed to the new network. Outside of mobility support, our modification also allows multiple IPsec tunnels with different destination addresses to use a single SA, enabling multi-homing for load balancing or redundancy, without the additional burdens of creating and maintaining multiple tunnels and corresponding SA’s. (possibly with some additional signaling.)

UPDATE-REPLY (message type 9999) repeats this information and informs the actions taken at the gateway, i.e., UPDATE-SUCCEEDED, meaning all future IPsec traffic will be directed to the new address.2 Such messaging can be extended later to include necessary messages or fields for the use of multiple tunnels in one direction, lifetime control of old and new tunnels, future handoff notification, etc. This signaling approach remains protected by an existing SA, similarly as other types ISAKMP or IKE messages.3 We added these new message types in FreeS/WAN to invoke appropriate changes using the modifications described in the previous sections.

B. Changing tunnel endpoint address in SA The security associations are stored in the Security Associations Database (SAD). The initial values for the parameters of a security association are derived from a configuration file during tunnel setup and include the tunnel destination address of particular tunnels. In FreeS/WAN, the database is a part of the Linux kernel and these values do not change until a re-keying is done. Especially, there is no need in the regular IPsec for changing tunnel destination addresses of existing SAD entries. In a mobility-enabled IPsec, SAD at the gateway needs to be updated as a mobile host moves so that packets are tunneled to the current IP address of the mobile host. A modification was made in the FreeS/WAN code set to enable updates of the destination IP addresses of existing SAD entries.

IV. DISCUSSIONS

C. Secure signaling for endpoint address update When the mobile host moves into a new network, it is the mobile host’s responsibility to inform the gateway of its new address so that the gateway can update its SAD and forward future packets to the new address. Our approach is to use the ISAKMP (Internet Security Association and Key Management Protocol) “information exchange messages” as defined in IPsec RFC2408 [11]. We temporarily use a private NOTIFY message type (9998 and 9999) for our test implementation for sending tunnel address update messages and corresponding confirmations. For our simple implementation, a NOTIFY TUNNEL-ADDRESSUPDATE (message type 9998) contains the SPI of the tunnel to be updated, the old tunnel endpoint address, the new tunnel endpoint address, and a sequence number that uniquely identifies the message. The TUNNEL-ADDRESS-

D. Route Updates The routing table of the mobile host needs to be updated as existing IPsec tunnels need to be sent through a new network. This involves a simple script to update the related routes for IPsec tunnels. Specifically for the FreeS/WAN version used in our implementation, an additional information, “Nexthop” needs to be updated as well. Nexthop is the IP address of the first hop router to send IPsec packets to for a particular tunnel. An ARP is performed for this IP address, so that the MAC address of the new Nexthop can be used for outgoing packets.

A. Security Implications We do not believe our modifications introduce any new security issues to IPsec. The new signaling is protected the same way as other standard IPsec related signaling. The removal of the dependence of tunnel destination addresses for locating correct SA’s does not change the operation of IPsec hosts as long as SPI’s are created uniquely within a host for all inbound connections for unicast. If there are only unicast connections, this modification has no difference to the regular IPsec operations. B. Performance Implications Our modifications enable mobility for IPsec for the remote access scenario. Here, we briefly compare our approach with “IPsec over MobileIP” and “IPsec tunnel reestablishment at handoff” in the remote access scenario in terms of tunnel overheads and signaling delays. Since IPsec over MobileIP is applicable to more general scenarios than our approach, it is used just as a reference point, not a direct comparison. 2

In fact, the confirmation reply can be implicit, if there is already data traffic to be sent to the mobile host via the tunnel. When the mobile host receives the first IPsec packet via the new network, it can be sure the update message was successfully delivered and processed. 3 In IKE (Internet Key Exchange)[12] and ISAKMP, the identification of SA’s for ISAKMP or IKE messages use cookies rather than destination addresses, which does not require any modifications to support mobility.

The initial tunnel setup process is identical to standard IPsec, where we assume the mobile host is not in the process of handoff. This may be slightly limiting, since in theory, IPsec over MobileIP should be able to perform initial IPsec tunnel setup during a handoff, assuming during which there is no excessive packet loss. Under this limitation, the initial tunnel setup should require 3 to 6 round trips (total for two tunnels, one for each direction, depending on the IKE (Internet Key Exchange)[12] modes and options) between the VPN gateway and the mobile host, the same as normal IPsec tunnel setup. IPsec over MobileIP needs MobileIP registration performed before the IPsec tunnel setup, requiring typically one additional roundtrip in the co-located FA mode, in addition to IPsec tunnel setup. IPsec over MobileIP has one more IP header (40 bytes) compared to our approach whose packet structure is identical to that of IPsec ESP tunnels.4 Depending on the packet size, this can be a substantial overhead over wireless links. Some VPN implementations use 100 to 400 byte packets, perhaps overly conservatively, due to the uncertainty of path MTU (Maximum Transmission Unit) sizes in the Internet. In such cases, the performance impact of the 40 byte overhead of IPsec over MobileIP can be substantial, especially if the quality of the wireless link in use is poor. As mentioned earlier, detecting the mobile host’s movement into a new IP subnet, obtaining access rights to the new network, and configuring wireless interfaces for the new network are common issues to any IP level mobility solutions. Although this paper does not address those issues, our approach can use any solutions developed for MobileIP and the operation is independent of the handoff mechanisms. During handoff, IPsec over MobileIP uses MobileIP signaling, since IPsec is shielded from mobility issues. Without packet losses, the signaling should usually take one roundtrip for both IPsec over MobileIP and our approach. Thus, handoff delays for our approach and MobileIP are similar, except processing delay difference for different protocol updates, i.e., MobileIP secure binding update vs. tunnel address update using secure ISAKMP messages, which should be minor even in moderate performance hosts. Compared to other approaches that reestablish IPsec tunnels upon handoff [6, 8, and 9] which require 3 to 6 roundtrips, our approach needs only one roundtrip for the remote access scenario considered in this paper. Considering that the roundtrip delays in the Internet, especially with a wireless access in the path, can vary from 10s of msec to 100s of msec, the factor of 4 to 6 advantage of the proposed approach in the IP layer handoff alone can significantly improve the performance of various applications during handoff. For real-time delay performance of a large backbone network, refer to [13].

In summary, our approach has a smaller overhead than IPsec over MobileIP by avoiding double tunneling, and a lower mobility update delay than IPsec reestablishment at handoff by avoiding breaking IPsec tunnels during handoff. Our approach trades the general applicability of other approaches for the above advantages and simple implementation for the particular scenario of IPsec tunnel remote access C. Interoperability Implications Our modifications to IPsec implementations do not cause any interoperability issues, i.e., if either party of an IPsec communications does not have the mobility support, they can still communicate using normal IPsec, albeit without mobility. They will either have to run IPsec over MobileIP, or re-establish IPsec tunnels each time a handoff occurs, which may break running applications and data flows. V.

Although we do not address the general issue of secure mobility support for the Internet, we show that the commercially important scenario of the mobility support for IPsec VPN-based remote access can be achieved with a few simple modifications to existing IPsec implementations. Our approach does not involve running IPsec over MobileIP, avoiding double tunneling and MobileIP signaling. Our approach enables IPsec tunnels to change their tunnel endpoints securely with minimal signaling. This is achieved by removing the dependency of tunnel destination address for locating SA without affecting the normal IPsec operations, and adding two messages to ISAKMP to communicate the address changes of mobile hosts, prompting proper updates to SAD. We described a working implementation of these modifications made to FreeS/WAN IPsec for Linux. Its performance aspects are discussed compared to IPsec tunnel re-establishment and IPsec over MobileIP in terms of header and signaling overhead. VI. ACKNOWLEDGEMENT The authors would like to thank John Denker, Hui Luo, and John Ioannidis for their help and valuable discussions on the subject. VII. REFERENCES [1] [2] [3] [4] [5] [6] [7]

4

Depending on the encapsulation method of choice, the overhead can be smaller (minimal encapsulation) or larger (Generic Routing Encapsulation).

CONCLUSION

[8]

IPsec, http://www.ietf.org/html.charters/ipsec-charter.html MobileIP, http://www.ietf.org/html.charters/mobileip-charter.html FreeS/WAN, http://www.freeswan.org Charles Perkins, David Johnson, “Mobility Support for IPv6”, MOBICOM ’96, pp. 27 – 37 John Zao, et al., “A public-key based secure Mobile IP”, Wireless Networks, vol. 5, pp. 373-390, J.C. Baltzer, 1999 The Portland State University Secure Mobile Networking Project, http://www.cs.pdx.edu/research/SMN/ Stefan Mink, et al., “Towards Secure Mobility Support for IP Networks”, Communication Technology Proceedings, 2000. WCC ICCT 2000, Volume: 1, 2000 J. K. Zao, M. Condell, “Use of IPsec in MobileIP”, http://www.ietf.org/proceedings/98aug/I-D/draft-ietf-mobileip-ipsecuse-00.txt

[9]

[10] [11] [12] [13]

Marc Danzeisen, Torsten Braun, “Secure Mobile IP Communication”, Workshop on Wireless Local Networks at the 26th Annual IEEE Conference on Local Computer Networks (LCN'2001), Nov., 2001 S. Kent, R. Atkinson, RFC 2401, “Security Architecture for the Internet Protocol,” http://www.ietf.org/rfc/rfc2401.txt, Nov., 1998 D. Maughan, et al., RFC 2408, “Internet Security Association and Key Management Protocol (ISAKMP),” http://www.ietf.org/rfc/rfc2408.txt, Nov., 1998 D. Harkins, D. Carrel, RFC 2409, “IKE: Internet Key Exchange,” http://www.ietf.org/rfc/rfc2409.txt “AT&T Global IP Current Network Performance,” http://ipnetwork.bgtmo.ip.att.net/current_network_performance.shtm l

Router A

IPsec Tunnel Pair A

Corporate Intranet

Internal Network Interface

External Network Interface

Network A

Hub Mobile Host

IPsec VPN Gateway IPsec Tunnel Pair B

Router B Figure 1: Network Setup for IPsec Mobility Implementation

Network B