Mobile IP and IPSEC

In the first solution, shown in Figure 5, we assume that the mobile host has a fixed home IP address and home agent assignment. The home agent is either in the home access provider's network or at the corporate network that the mobile user wishes to access. In the latter case, a firewall exists and we assume that the access gateway/firewall at the corporate network supports home agent functionality. Mobile IP client software is assumed to be running in the mobile host, while foreign agent software is running at the IWF. Both the home and foreign agents support bidirectional tunneling and enhanced mobile IP mobility agent's functionality as specified by Zao et al.( n15) IPSEC is supported at the firewall/gateway (if one exists) or the home agent (HA). We assume there exists some prior arrangement between the home/ visiting access provider and the corporate network to obtain the shared key information for mutual authentication of the foreign agent and the firewall.Otherwise, a key management protocol such as the IETF's Internet security association and key management protocol (ISAKMP)( n16) is required.

In this solution (shown in Figure 6), we assume that the mobile host is using the foreign agent address as the "care of" address. The foreign agent (FA) indicates via the agent advertisement to the mobile host that it can support IPSEC. For the rest of the description, we assume that a firewall (FW) exists. During the registration procedure, the mobile host sets the "FA/FW IPSEC required" bit in its mobile IP registration request message and sends it to the FA (step 1 in Figure 6). The FA authenticates the message and determines the associated FW (potentially with the help of an authentication server) based on the destination address of the registration request, which is the HA's address (step 2). The FA then builds a secure tunnel between itself and the FW and relays the registration request to the FW (step 3).

Upon receiving the encrypted registration request, the FW decrypts it (step 4) and relays it to the specified HA (step 5). It is assumed that the header of the secured tunnel carries sufficient information for the FW to authenticate the FA. It is also assumed that the key used to decrypt the registration request is unique to each FA. The HA authenticates the mobile host upon receiving the request. If the service request is granted, a registration reply will be sent to the mobile host via the FW (step 6). Next, the FW initiates accounting for the session (step 7). The FW then encrypts and sends the registration reply to the associated FA (step 8). The FA decrypts the registration reply and initiates a local accounting transaction (step 9) before relaying it to the mobile host (step 10).

Once the registration process is over, a mobile IP and IPSEC tunnel is established between the FA and the FW. When data packets from the registered mobile host arrive at the FA, it encrypts them, adds the encapsulating security protocol (ESP) header, and sends them through the secured tunnel to the FW. The FW decrypts the packets and delivers them to the corresponding node (CN) inside the corporate network. All packets sent by the CN to the mobile host will be captured by the HA, encapsulated, and sent to the FW. The FW encrypts them, adds ESP headers, and relays them to the FA. The FA decrypts the packets and delivers them to the mobile host. If end-to-end security is desired, the link between the FA and the mobile host must also be encrypted.

When the mobile host moves from one FA to another, it reregisters with the HA. The hand-off latency is a function of how quickly the mobile host can detect an agent advertisement from the new FA. Of course, link-layer hand-off messages could be used to trigger an agent advertisement from the new FA. Only two messages need to be exchanged between the mobile host and the HA for reregistration, provided new security associations need not be negotiated. Potentially, a minimum of 8 and a maximum of 13 messages are needed for IPSEC operations if we use ISAKMP as the security association and key management protocol. Two local messages may be required if the HA needs to access a local authentication server to verify the mobile's identity. Two more local messages are required at both the FW and the FA for accounting purposes.During handoffs, the tunnel between the new FA and the FW needs to be built; thus, potentially, some data packets may be lost. This loss can be minimized by requiring the mobile and the FAs to support the previous FA notification extension. Upon being notified by the mobile host of the identity of the old FA, the new FA sends a message to the old FA. The old FA then forwards the buffered data to the new FA. The Global System for Mobile Communications (GSM) General Packet Radio Service (GPRS)( n17) specification provides such a packet-forwarding feature.

The advantage of using alternative 1 is that the required software can be easily produced by modifying available off-the-shelf mobile IP and IPSEC codes. The disadvantages of using alternative 1 are as follows:

• Mobile IP mandates mutual authentication between the mobile host and the HA. Currently, it is assumed that security keys and security index parameters are manually configured, since there is no standardized key management scheme for mobile IP at this time.
• There must be a prior arrangement between the home/visiting access provider and the corporate network to obtain the shared secret keys. More than one set of keys may be required for each corporation. If only one set of keys is used, a centralized database must be provided so that all FAs of the serving carrier can access that information.
• The hand-off latency is larger, since the registration path spans across multiple domains.
• Since mobile IP does not address any accounting issues, an accounting mechanism must be furnished via some other means. One may use either cellular digital packet data (CDPD) accounting or the IETF's RADIUS accounting. Typically, it is more cost effective to reuse an existing accounting system. With CDPD accounting, the users look more like traditional wireless subscribers. Otherwise, RADIUS accounting can be used, since it is simple, cheap, and already available in most of the ISP networks.
• Both the FA and the HA need to have publicly routable addresses.
• There is no dynamic HA feature.
• To support private addresses for the mobile host's home address, the mobile host and the HA need to perform double encapsulation. The tunnel between the FA and the HA needs a tunnel identifier to distinguish between mobile hosts that have the same private address.

One drawback of alternative 1 is that the hand-off latency is high. A possible way of reducing it is to implement the FA functionality at the PDSN rather than at the IWF. Mobility between different IWFs can then be managed via wireless access link-layer protocols. In some larger wireless access networks, multiple PDSNs may be available. These multiple PDSNs can be arranged in a hierarchical manner so that a mobile host's movement from one PDSN to another will not always result in a mobile IP reregistration message. This idea is explored in alternative 2, described in the next section.