Internet Draft Gateway traversal for Mobile IP Dec.17 1996 Internet Engineering Task Force Masahiro Ishiyama INTERNET DRAFT Atsushi Inoue Atsushi Shimbo Toshio Okamoto Toshiba R&D Center Gateway Traversal for Mobile IP using IPSEC primitives draft-ishiyama-gateway-traversal-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstract.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes an approach of security support for Mobile IP protocol. IPSEC and Mobile IP modules are combined and implemented on gateways of all networks and mobile nodes. Each component performs IPSEC packet encryption/authentication, and Mobile IP processing. Using Next-hop negotiation between security gateways, the packet from a mobile node in the visiting network can be delivered to the home network through the security gateways in an authenticated way. This mechanism allows minimal overhead for traversing security gateways, and minimal information to be held on each mobile node. 1. Introduction This memo describes an approach of security support for Mobile IP protocol, in which how the packet sent from a mobile node in the Ishiyama, et al. Expires June 22, 1997 [Page 1] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 visiting network can be delivered to a correspondent host (such as in the home network) through the security gateways is described. This mechanism allows minimal overhead for traversing security gateways, and it allows minimal setup on each mobile node. IPSEC and Mobile IP modules are combined and implemented on gateways of all networks and mobile nodes. Each component performs IPSEC packet encryption/authentication, and Mobile IP processing. Our model of communication in such a system assumes that: - Between the stationary security gateways, the necessary information for constructing security associations to each other is properly maintained. - Using those information on each security gateway, Next-hop negotiation mechanism can be used in order to let the packet go through the security gateways in an authenticated way. - For mobile nodes, necessary information for setting up the communication should be minimized. So, dynamic negotiation procedure between mobile nodes and security gateways are proposed. Section 2 of this draft explains the system configuration for combining IPSEC and Mobile IP protocols. Section 3 describes our model of packet traversal from mobile nodes through the security gateways. In section 4, an implementation example is proposed, including the applicability of IPSEC/Mobile-IP combination depending on the relative location of the mobile node and the correspondent host. The packet format between the system components are also described. In Section 5, the future works for the current implementation is itemized. 2. System configuration Figure 1 shows the proposed system configuration. The system consists of, - Security Gateways (SGW), which perform IPSEC processing, and packet filtering from the mobile nodes if necessary. - Security Mobile Nodes (SMN), which perform IPSEC processing by themselves. SMNs are mobile nodes of Mobile IP protocol, which performs the mobile registration of current location. - Home Agents (HA) defined in Mobile IP [1]. Home Agents are placed on the subnet where SMTs are originally located. In [8], the IPSEC communication between the mobile node and the home network is discussed, assuming that the HA in the home network can handle IPSEC packets by itself. But in this draft, we don't require such IPSEC handling capability on each Home Agent. So, Ishiyama, et al. Expires June 22, 1997 [Page 2] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 only decrypted (plain IP) packet is delivered to Home Agents. The current implementation is Popup mode of mobile IP, so there are no foreign agents in the proposed system now. Supporting foreign agents is a future work. [outside] SMN CH [Home Network] | | [Other site 1] +--------------------+ | | +--------------------+ | +-----------+ | | | | CH +----------+ | | | | | | | | | CH | | | | HA CH SGW0 --- SGW1-------(Internet)--------SGW2---SGW3 | | | | | | | | | SMN | | | +-----------+ CH | | | SMN +----------+ | +--------------------+ | +--------------------+ +---------SGW4---------+ | CH | SMN | | | | | +-------SGW5-------+ | | | | | | | CH SMN | | | +------------------+ | +----------------------+ [Other site 2] Figure 1 System Configuration 2.1 Operation of each system component An SGW is placed on the exit of some network. SGWs can be nested-placed at the exit of inside network, like SGW0, SGW3, and SGW5 in Figure 1. When it receives the IP packet from the host inside the network, it performs IPSEC encryption and authentication on the packet and forward it to the outside. When it receives the IPSEC packet destined to the SGW, it performs IPSEC decryption and authentication on the received packet and forward it to the host or another SGW inside the network. An SMN can perform IPSEC processing by itself. It encrypts/decrypts/authenticates the packet at the endpoint of IPSEC tunnel (VPN). We assume that the SGW/SMN at the endpoint of VPN guarantee the security by IPSEC AH/ESP mechanism. An SMN also acts as a mobile node on Mobile IP protocol. It sends the registration message to the Home Agent in its home network. An HA works as defined in Mobile IP protocol[1]. It captures the packet destined to SMN's home address, performs IP-in-IP Ishiyama, et al. Expires June 22, 1997 [Page 3] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 encapsulation on the packet, then forward it to SMN's current Care-of address. As described above, in this draft, the IPSEC processing capability is not required to HA. Therefore, it receives packet decrypted at the SGW of home network (home-SGW, SGW0 in Figure 1), and the mobile IP encapsulated packet will be encrypted again at the home-SGW and forwarded to the outside. In Figure 1, We call SMN's Home-domain network as "home network". We may call [Other site 1] and [Other site 2] as "visitor network". Also, we call SMN staying inside visitor network as "visiting SMN". "SGW-protected" means that a host is the network at which an SGW is placed, that is, in either "home network" or "visitor network" in Figure 1. 2.2 Addressing rules We assume the following addressing rules for the proposed system in Figure 1. - All SGW-protected networks are private networks. They are managed with their own addressing rules. - No address collision occurs between multiple SGW-protected networks. That is, if an address is given, the position of the host (which SGW is protecting the host) is uniquely determined. - Hosts outside the organization is addresses by global addresses. For the SGWs placed at the boundary to the Internet (SGW1, SGW2, and SGW4 in Figure 1), global addresses are also assigned. 2.3 Assumption for certificate management As for the certificates (encryption/authentication keys) for IPSEC, we assume that each gateway and mobile node can acquire the necessary certificates in some methods. The detailed configuration of Certificate Authority and/or the way of delivering certificates are not discussed in this draft. Once the necessary certificates are acquired, SGW/SMN should keep certificate of frequently communicating hosts in its certificate cache, independently with mobile nodes' mobility registrations. 2.4 Assumption for Position information When an SMN moves out of private network, It have to know necessary information for constructing a VPN path toward at least one Border-SGW in the system. Here Border-SGW is the SGW which is placed at the border between private network and the Internet. In Figure 1, SGW1, SGW2, and SGW4 are the Border-SGWs in the system. Ishiyama, et al. Expires June 22, 1997 [Page 4] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 Also each SGW and SMN have to know all the networks in the system, which is exchanging security information to each other and VPN can be constructed among them. For example, Assume that [Home Network], [Other site 1] and [Other site 2] in Figure 1 are exchanging security information to each other and the VPNs can be constructed among these networks. These networks are defined to be VPN-routable. SGWs/SMNs can distinguish whether a given address belongs to such VPN-routable network or not. The case when some of the networks are not VPN-routable is discussed in 3.4. When an SMN moves around IP network and communicate with IPSEC and mobile IP autonomously , (1) at least one Border-SGW information, and (2) VPN-routable network information have to be registered to that SMN before it moves out. This VPN-routable network information is implemented, for example, by maintaining data which express the association between SGW and its protecting address set. As described in 2.2, all SGW-protected networks are uniquely addressed. So, if an address is given, we can uniquely determine one SGW which protects that address. This SGW look up is also used for determining current location of SMN and CH (Section 4). 3. Issues for Secure Mobile IP communication 3.1 Communication model In our communication model, a VPN path is configured from a SMN to its correspondent host (CH), along which multiple SGWs is placed (Figure 2). Each SGW is properly maintained by the system administrator of each network, and the security policy for the SGW is subject to the policy of the network. So, packet filtering rule for an SGW might be determined by the site system administrator regarding the site's policy. Each SGW knows other SGWs and its protecting hosts. Also each SGW may know the mobile nodes. The only assumption about SGW's filtering rule is that even though once an SGW rejects a packet, if the SGW negotiates with the sender of that packet and the packet with negotiation information is delivered to that SGW again, it will let the packet go through. Therefore, if the SMN goes into a visitor network and tries to communicate with a host outside the visitor network, it have to negotiate with the SGW at the exit of the network in order to let the packet go through the SGW. Ishiyama, et al. Expires June 22, 1997 [Page 5] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 +---+ +----+ +----+ +----+ +------+ +----+ |SMN+---->+SGW1+-->+SGW2+-->+SGW3+-- ....... --->+SGW(N)+---->+ CH | +---+ +----+ +----+ +----+ +------+ +----+ Figure 2 The VPN path with SGW/SMN In [9], a method for authenticated firewall traversal is introduced. In the method, when a packet sent from mobile node reaches a firewall, the firewall returns ICMP administration message to the mobile node. Then the negotiation between the mobile node and the firewall which rejects the packet, such as cookie exchange, is performed. After that, the packet from the mobile node can pass the firewall with authentication information attached on the packet. If we use this method on our model, the returning of ICMP message and the negotiation for SGW will be repeated N times in order to arrive at CH. Even though the negotiation with the SGWs along the path is successfully completed, N independent negotiated information (Authentication header/AH, for example) have to be appended to the packet like, +-----+-----+-... +-------+-----+-----+---------------+ |AH(1)|AH(2)| |AH(N-1)|AH(N)| ESP | Inner IP data | +-----+-----+-...-+-------+-----+-----+---------------+ Here, AH(i) means authentication header for negotiating between SMN and SGW(i). This huge authentication headers attached to the packet might degrade the total system performance. In general, a packet need to be checked on each stage of SGW for security concern. However, if we can assume that all SGWs are stationary hosts, and are properly maintained by the system administrators of the networks, that is, the security information for setting up VPN between each other is registered in advance, an SGW can perform negotiation using the shared information with the previous/next stage of SGW. This negotiation method can control the packet traversal of SGWs. If the packet is allowed to go through the previous stage of SGW and the negotiation between the previous stage of SGW and this SGW is valid, the packet is allowed to go through this SGW also. This negotiation method between two SGW along the VPN path is called "Next-hop negotiation". In order to perform Next-hop negotiation efficiently, SGWs can maintain routing information for other components in the system. If the destination address of a packet is given, we can easily look up the Next-hop SGW with the registered routing information. Ishiyama, et al. Expires June 22, 1997 [Page 6] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 In Figure 2, we assume that SGW1, SGW2, ...., SGW(N) are stationary nodes, and all the necessary information for VPN routing and necessary certificates are correctly maintained by the system administrators. Therefore, when each SGW receives a packet, it can distinguish the Next-hop SGW from the destination address in the packet. Here we assume that authentication with AH between two nodes are used for Next-hop negotiation. When the packet from a mobile node reaches SGW1, the Next-hop AH (AH12) with the Next-hop SGW2 is appended to the packet and forwarded to SGW2. Next at SGW2, the MAC value for AH12 is checked. If it is valid, then the Next-hop AH is replaced by AH23 (for SGW2 and SGW3) and forwarded to SGW3. On each SGW along the VPN path, the Next-hop AH will be replaced and finally, the packet will reach SGW(N). As long as the packet goes through stationary SGWs which is correctly setup by the administrators, and if the Next-hop AH is correctly appended to the packet, failure message (such as ICMP administration message in [9]) from SGWs will not be returned to the mobile node. Also, the packet format is always, +-------+------+-----+---------------+ |next-AH|end-AH| ESP | Inner IP data | +-------+------+-----+---------------+ and never becomes larger. 3.2 Handling Packets from the Mobile Nodes As a mobile node (SMN) moves around on the IP network dynamically, we cannot expect the SMN's location and setup the necessary information in advance. Rather it might be better to limit the registered information on the SMN before moving as minimal as possible. And in general, just after an SMN is reconnected to IP network on the visitor site, the SMN cannot understand the environment around it. Therefore, when an SMN moved into a visitor network and start the communication, it have to follow an procedure, by which it can capture necessary information in order to construct communication path to the outside the visitor network (especially to the SMN's home network). In the model on Figure 2, consider the case the mobile node (SMN) connected at the visitor network tries to communicate with CH in the home network through multiple SGWs. Ishiyama, et al. Expires June 22, 1997 [Page 7] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 When an SMN is reconnected, it does not even know that there are SGWs (SGW1, ..., SGW(N)) along the path toward CH. So, the only thing SMN can do first is to send a ordinary IP packet to the CH, and see what happens at the SGWs. In our model of packet traversal from SMN to home network, we assume the following: - When the packet from SMN reaches the first SGW without Next-hop negotiation between SMN and the SGW, failure message (such as ICMP Security Failures Message[7]) is returned to the SMN - On the endpoint of VPN, if the home SGW detect that the packet is from the SMN but End-End negotiation is done by another SGW, then it distinguish that packet as invalid and returns failure message. Here we assume that authentication (AH) between two nodes are used for Next-hop/End-End negotiation. When the IP packet reaches the first SGW (SGW1), it detects that the packet is from visiting SMN and illegal (by checking the source address), and returns failure message to the SMN. With this failure reply, the SMN negotiates the key for Next-hop AH, computes/attaches Next-hop AH, and resends the packet to SGW1. Here the packet is authenticated but not encrypted yet. When SGW1 receives this packet, it tries to construct VPN with SGW(N) at the home network of SMN. That means, SGW1 becomes the end of VPN, so the End-End AH is computed between SGW1 and SGW(N), and the packet is encrypted. Then, SGW1 relays the packet with Next-hop AH for Next-stage SGW (SGW2) attached to the packet. Finally the packet reaches SGW(N). Then Next-hop AH with previous stage SGW(N-1) is checked and IPSEC processing is done. Here SGW(N) detects, - The contents of IPSEC is from the SMN which was originally in its network. - But the End-End AH is negotiated with another SGW (SGW1). and this conflicts with the policy and SGW(N) returns failure message to the SMN. When SMN receives this failure message, then it performs IPSEC processing by itself. It processes End-End AH with SGW(N) by itself. And using the Next-hop AH key for SGW1 (previously acquired). SMN puts Next-hop AH and sends to SGW1 again. In this case, SGW1 works just the same as other SGWs along the VPN, that is, checks/replaces the Next-hop AH and forward the packet to SGW2. This packet will successfully traverse the SGWs and reach SGW(N) at the VPN endpoint. These step is depicted as follows. The notation is the same as that of Section 4. Ishiyama, et al. Expires June 22, 1997 [Page 8] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 Step1: Failed at SGW1 because of lack of Next-hop AH [IP] SMN SGW1 SGW(N) CH --------------->X <--------------- [Failure] Step2: Failed at SGW(N) because of inconsistency between packet contents and End-End AH [IP+NextAH] [IP+endAH] SMN SGW1 SGW(N) CH -NNNNNNNNNNNNNNN-EEEEEEEEEEEEEEEEEEEEEEEEE->X <----------------EEEEEEEEEEEEEEEEEEEEEEEEE--- [Failure] Step3: Succeed in constructing VPN through SGW(N) [IP+AH] [IP+AH] [IP] SMN SGW1 SGW(N) CH -NNNNNNNNNNNNNNN NNNNNN NNNNNN NNNNNNNN -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE---------> 3.3 Handling packets from SMNs outside the organization The scheme in the previous section describes the cases when SMN moves into SGW-protected networks (organizations), and communicate with other networks (such as home network) through the SGW placed on the exit of that network. As SMNs can perform IPSEC and Mobile IP processings by itself, it can also move to the IP connection point on the Internet outside the specific organization (where not protected by SGWs). In such a case, the necessary information for constructing a VPN path toward at lease one SGW placed on the boundary of VPN reachable organization (Border-SGW) have to be installed on the SMN before it moves outside. This is because we assume that once the packet reaches an SGW on the VPN-routable network, the SGW knows all the VPN routing information to deliver the packet toward the CH in the SGW-protected network. So, when the Border-SGW receives the IPSEC packet from outside SMN, it decrypts the packet and checks the destination CH address. And the Border-SGW reencrypts the packet with the correspondent-SGW (which protects CH). The packet is then delivered Ishiyama, et al. Expires June 22, 1997 [Page 9] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 through new VPN from Border-SGW to correspondent-SGW. In some cases, there will be redundant IPSEC route from SMN to CH via the Border-SGW, but it can be optimized with the negotiation with SMN, Border-SGW and correspondent-SGW. For example, in Figure 3, the SMN is outside of the organization, and assume that CH is in Site-1. Both Site-1 and Site-2 are SGW-protected network and VPN-routable. And assume that SMN only knows the Border-SGW2. In such a case, if SMN want to communicate with CH, SMN have to construct VPN2 toward SGW2 first. Once the VPN2 is established, SGW2 can route the packet toward SGW1-protected CH with IPSEC between SGW2 and SGW1. If outside SMN knows the Border-SGW of CH's network (SGW1), or route optimization is done to eliminate the redundant routing via SGW2, SMN can communicate directly with CH through SGW1 as [optimized] in Figure 3. In section 4.5.7, the protocol example of such a case is explained. [optimized] ++<========SMN....... [Site-2] // <1> : [Site-1] +----------------+ // : +----------------+ | |// :..> | | | SGW2====>====>====>====>====>SGW1 CH | | | <2> | | +----------------+ +----------------+ Figure 3 SMN outside the organization 3.4 SMN talking from a network lacking Next-hop information The discussion in the previous sections assume that all SGW-protected networks are VPN-routable, that is, any pair of SGWs are exchanging information for constructing VPN. But in some case, SMN might move to the network, where VPN is not constructed to other network because of its site policy. This situation occurs when an SMN moves into a network, which is not familiar with the SMN's home network. Figure 4 shows such an example. Here the policy of Site-1 is that SGW1 does not exchange security information for constructing VPN with other SGWs. When SMN moves into Site-1, it can understand that it is not in the VPN-routable network using the its position information described in 2.4. Ishiyama, et al. Expires June 22, 1997 [Page 10] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 [Site-1] [VPN Network] +-------------+ +------------------------+ | | | +-----------+ | | | | | | | | SMN---->SGW1------->(Internet)-------->SGW2--->SGW1--->CH | | | | | | | | | | | +-----------+ | +-------------+ +------------------------+ Figure 4 SMN in VPN unreachable network SMN in Site-1 first tries to construct VPN to its Border-SGW (SGW2 in Figure 4). This is just the same as discussed in 3.3. When the IPSEC packet (toward SGW2) reaches SGW1, the failure message is returned and the negotiation between SMN and SGW1 is performed. Then SMN sends the packet with Next-hop AH again, and the packet goes through SGW1 and reaches SGW2. In some cases, after entering to the VPN network protected by SGW2, the packet will reach SGW3 inside the VPN network and is rejected there. Then SGW3 returns failure message to SMN. At this time, SMN recognizes that the VPN endpoint is not SGW2, but SGW3. Then SMN processes the packet for VPN endpoint SGW3, with Next-hop AH for SGW2 and SGW1 appended. This packet goes through SGW1 and SGW2, and reaches SGW3 successfully. The packet format delivered from SMN to CH is as follows: Step1: Failed at SGW1 because of lack of Next-hop AH SMN SGW1 SGW2 SGW1 CH -EEEEE->X (--EEEEEEEEEEEEEEEEE--->) (End/End for SMN/SGW2) <-------- [Failure] Step2: Reached to SGW2, but failed at SGW3 SMN SGW1 SGW2 SGW3 CH NNNNNNNN -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE------------->X NNNNNNNNNNNNN <--------EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE- [Failure] Ishiyama, et al. Expires June 22, 1997 [Page 11] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 Step3: Succeed in constructing VPN through CH SMN SGW1 SGW2 SGW3 CH NNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-------------> The sequence above shows that, if SMN moves into VPN-unroutable network, the step-by-step negotiation like [9] is necessary for securely delivering the packet from the SMN. 3.5 Communication with CH outside the organization If the correspondent host (CH) of SMN is not in SGW-protected network, SMN cannot communicate with IPSEC. Therefore, SMN communicates with the CH either of the following way, depending on the CH's attribute. - If it is guaranteed that CH is reachable from SMN's home network, SMN can use Mobile IP, but without IPSEC, though this is not recommended for security reason. - If the reachability of CH from SMN's home network is not guaranteed, SMN uses its Care-of address and directly communicate with CH by usual IP, though this is not recommended for security reason. If SMN is in the SGW-protected network the Care-of address is translated to a global address at the SGW of that network. Or if SMN can use a proxy in the home network, it works as follows. 3.5.1 Communication through the proxy at home network On many sites, the Internet access is controlled through proxies. When the SMN communicate through a proxy in the home network, it constructs VPN tunnel with home-SGW first. Through this tunnel, the SMN communicate with the proxy securely by IPSEC. Then at the proxy, the necessary processing (such as address translation) is done, then the packet goes out through VPN between SGWs. For the packet on the reverse direction, it is delivered to the proxy at home network through VPN between SGWs. Then from the proxy to SMN outside, the packet goes on mobile IP routing, via Home Agent (Figure 5). Ishiyama, et al. Expires June 22, 1997 [Page 12] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 [SMN] (home)| ^^ | (8) || (1)VPN btwn SMN/Proxy | ++=====++ (7)IP-in-IP | || (3) toward ------> | VV (2) VPN btwn Proxy/SGW1 CH [HA]<------[SGW1/Proxy]=========================>[SGW2]------->[CH] (6) Mobile | <========================= <------- IP | (5) VPN btwn SGW1/Proxy (4) reply | from CH Figure 5 Communication through the proxy in the home network 3.6 Implementation issues Next-hop negotiation is typically implemented by authentication between two security nodes (Next-hop authentication). The authentication is done just the same way as usual IPSEC processing. That is, in order to let the packet pass through the next stage of SGW, each SGW put Next-hop authentication header for the two SGWs ahead of the packet. The next stage of SGW checks the Next-hop AH for authenticating the sending SGW, and if the MAC value is valid, then it is allowed to go through. As current implementation of SGW/SMN uses SKIP [5] for key management protocol, typical packet format with Next-hop AH is as follows: +-----+-------+----+-----+-------+----+-----+---------------+ | IP1 | SKIP1 | AH | IP2 | SKIP2 | AH | ESP | Inner IP data | +-----+-------+----+-----+-------+----+-----+---------------+ <----------> <----------------> Next-hop End-End authentication authentication/encryption Here Next-hop AH is used only for negotiated packet traversal on SGWs. So, the point is two SGWs (or SGW and SMN) share common information (Next-hop-AH keys) on the authentication processing. Data integrity checking is not the purpose of Next-hop authentication. That means, the MAC computation can be omitted, for example, only partial data, such as IP/SKIP/AH/ESP header portion can be used for MAC computation in order to reduce the overhead. This format is one typical example. In some cases, depending on the security policy of each site, another form of Next-hop negotiation can be introduced. For example, if the site policy does not allow encrypted packets which cannot be decrypted on any host in the network, Next-hop encryption can be used instead of End-End encryption. Ishiyama, et al. Expires June 22, 1997 [Page 13] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 4. Implementation Example In this section, we will summarize the current status of our implementation, including the packet format for mobile IP registration and data transmission. 4.1 Abbreviations and Notation of Figures HA: Home Agent CH: Correspondent Host SGW: Security Gateway SMN: Security Mobile Node AH: Authentication Header (Defined in [3]) ESP: Encapsulating Security Payload (Defined in [4]) SKIP: Simple Key management for Internet protocol proposed in [5]. Also means SKIP header in the packet format. NSID: Name Space Identifier (specified in [5]) MKID: Master Key Identifier (specified in [5]) The notation in packet transmission figures means the following: @: Relaying Mobile IP packets by HA MMMMMMMM:Tunneling with IP-in-IP [2] EEEEEEEE:Tunneling with SKIP/AH/ESP (End/End IPSEC) NNNNNNNN:Tunneling with SKIP/AH (Next-hop IPSEC) When encapsulation is done, lower protocol is encapsulated by upper ones, for example, MN CH EEEEEEEEEEEEEEEEEEEEEEEEEE --MMMMMMMMMMMMMMMMMMMMMMMMMM--> means that IP-datagram from MN to CH is encapsulated with Mobile IP protocol (IP-in-IP) and then the result datagram is encapsulated by End/End IPSEC. 4.2 Classifying the Mobile IP operation First, the operation is classified whether SMN/CH is SGW-protected or outside. Here CH is a stationary host. Communication mode between SMN and CH is classified as the table below. The position of SMN/CH can be determined by watching home agent advertisement message and looking up host position information described in 2.4. Ishiyama, et al. Expires June 22, 1997 [Page 14] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 CH position | SGW-protected | outside SMN position | | ----------------+--------------------+----------------------------- SGW-protected |<1>VPN through SGW |<3>Usual (mobile) IP | See 4.5 | See 3.5 ----------------+--------------------+----------------------------- outside |<2>VPN through SMN |<4>Usual (mobile) IP | See 4.5 | See 3.5 For the case that CH is outside (<3> and <4>), SMN talks with CH as described in 3.5. That is, if CH's reachability from the SMN's home network is not guaranteed, SMN have to talk directly with CH using its Care-of address and usual IP (though it is not recommended). If CH's reachability from SMN's home network is guaranteed, SMN can use Mobile IP without IPSEC. For case <3>, if SMN is using private managed address, it might be translated at the SGW, or if SMN uses proxy in the home network, SMN first constructs VPN to the home network, then the proxy delivers the packet to/from CH, as described in 3.5.1. [outside] SMN CH [Home Network] | | [Other site 1] +----------------+ | | +----------------+ | | +--------+----+-+ | CH1 | | SMN CH0 | | | | | | SGW0----+ Internet +----SGW1 | | HA | | | | SMN | | | +---+-----------+ | | +----------------+ | +----------------+ +-----SGW2-----+ | | | | | CH2 SMN | +--------------+ [Other site 2] Figure 6 System Configuration for the current implementation If we assume the system configuration like Figure 6, VPN through SGW/SMN (case of <1> and <2>) is classified depending on the relative position of SMN/CH/HA as follows: Ishiyama, et al. Expires June 22, 1997 [Page 15] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 CH's position| SMN's | other site| SMN's position | Home | 1 | -------------------+---------+------------+ Home Network | (1) | (2) | -------------------+---------+------------+ Other 1(CH's Home) | (3)* | (4)* | -------------------+ +------------+ Other 2 | | (5)* | -------------------+---------+------------+ Outside | (6)* | (7)* | -------------------+---------+------------+ * means SMN's IPSEC module is used for VPN The protocols for each case will be examined in 4.5. 4.3 SKIP NSID/MKID Consideration Current implementation uses SKIP as its key management protocol. In section 4.5, the packet format including SKIP header is described. For the NSID/MKID for SMNs, NSID value 1 (IPv4 address) is assigned, and MKID is set as SMN's home address. This NSID/MKID specification is introduced in [8], and the MKID is used for looking up the SMN's security association. The SMN's home address is used because even after SMN has moved, the same entity can be referenced. 4.4 Mobile IP Registration The registration of the Care-of address for SMN is done as Mobile IP registration protocol[1]. With the registration, HA can maintain the mapping table between the SMNs and corresponding care-of addresses. In accordance with the security policy for the visitor site, visiting SMN's outbound packet have to be checked by SGW of visitor site with Next-hop AH. [Protocol Image] SMN SGW1 (Network) SGW0 HA <1> -EEEEEEEEE - - -> registration request <2> <--------- Failure message NNNNNNN NNNNNNNNNNNNNNNNNNN --EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------> registration request <3> <4> NNNNNNNNNNNNNNNNNNN <-EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------- registration reply <5> Ishiyama, et al. Expires June 22, 1997 [Page 16] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 If the registration request from SMN cannot go through SGW1 at the Visitor network, the SGW traversal described in 2.3 is used. After SGW1 returns Failure message (such as ICMP Security Failures Message[7]), SMN resend the registration request with Next-hop AH for SGW1 ahead of the packet. The packet format is as follows: [Packet Format] <1> (The first registration request from SMN) IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst = NSID(0) EndAH+ESP Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr) <2> (Failure message from SGW1) IP Hdr:(Src=SGW1 addr, Dst=SMN c/o addr) <3> (The second registration request from SMN) IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) NextAH:(SMN/SGW1) IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW0) Inner IP Hdr:(Src=SMN c/o addr, Dst=HA addr) <4> (Request Packet from SGW1 to SGW0) IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH:(SGW1/SGW0) IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP(SMN/SGW0) Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr) <5> (Reply Packet from SGW0 to SGW1) IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(0), Dst = NSID(0)) NextAH(SGW0/SGW1) IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr2:(Src=NSID(0), Dst = NSID(1)/MKID(SMN home addr)) EndAH+ESP(SGW0/SMT) Inner IP Hdr:(Src=HA addr, Dst=SMN c/o addr) 4.5 Data communication Also for data communication, we assume that the Next-hop AH check is necessary for the outbound packet from visiting SMN. Ishiyama, et al. Expires June 22, 1997 [Page 17] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 4.5.1 Both SMN/CH are in Home Network [Protocol image] SMN CH0 --------> (Usual IP communication) <-------- 4.5.2 SMN is in Home Network, CH is in Other site (Site 1) [Protocol image] SMN SGW0 SGW1 CH1 <1> --------EEEEEEEEEEEEEEEEEEEEEEEE-------> (Usual VPN between SGWs) <2> <-------EEEEEEEEEEEEEEEEEEEEEEEE-------- [Packet Format] <1> Packet from SGW0 to SGW1 IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP(SGW0/SGW1) Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) <2> Packet from SGW1 to SGW0 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP(SGW1/SGW0) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 4.5.3 SMN is in Other site (Site 1), CH is in Home Network [Protocol image] SMN SGW1 (Network) SGW0 HA CH0 <1> <2> NNNNNN NNNNNNNNNNNNNNNNNNNNNNN -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-------------> <3> NNNNNNNNNNNNNNNNNNNNNNN EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-@----- [Packet Format] <1> Packet from SMN to SGW1 IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) NextAH(SMN/SGW1) IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr),Dst=NSID(0)) EndAH+ESP(SMN/SGW0) Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) Ishiyama, et al. Expires June 22, 1997 [Page 18] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 <2> Packet from SGW1 to SGW0 IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH(SGW1/SGW0) IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP(SMN/SGW0) Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) <3> Packet from SGW0 to SGW1 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH(SGW0/SGW1) IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr) 4.5.4 Both SMN/CH are in the same Other site (Site 1) [Protocol image] SMN CH1 SGW1 (Network) SGW0 HA -------> <1> -------EEEEEEEEEEEEEEEEEE------->@ <2> | NNNNNNNNNNNNNNNNNN | EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ SMN CH1 SGW1 (Network) SGW0 HA [Packet Format] <1> Packet from SGW1 to SGW0 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP:(SGW1/SGW0) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) <2> Packet from SGW0 to SGW1 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH:(SGW0/SGW1) IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) EndAH+ESP:(SGW0/SMN) IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) Ishiyama, et al. Expires June 22, 1997 [Page 19] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 4.5.5 SMN is in Other site (Site 1), CH is another Other site (Site 2) [Protocol image] SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA <1> <2> NNNNN NNNNNNNNNNNNNNN -EEEEEEEEEEEEEEEEEEEEEE------> +<----- | <3> +-EEEEEEEEEEEEEEEEEEEEEE------>@ <4> | NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN | EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA [Packet Format] <1> Packet from SMN to SGW1 IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) NextAH:(SMN/SGW1) IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW2) Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr) <2> Packet from SGW1 to SGW2 IP Hdr1:(Src=SGW1 addr, Dst=SGW2 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH:(SGW1/SGW2) IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr) SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW2) Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr) <3> Packet from SGW2 to SGW0 IP Hdr:(Src=SGW2 addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP:(SGW2/SGW0) Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr) <4> Packet from SGW0 to SGW1 IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr1:(Src=NSID(0), Dst=NSID(0)) NextAH:(SGW0/SGW1) IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) EndAH+ESP:(SGW0/SMN) IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr) Ishiyama, et al. Expires June 22, 1997 [Page 20] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 4.5.6 SMN is outside, CH is in Home network [Protocol image] SMN (Network) SGW0 HA CH0 <1> -EEEEEEEEEEEEEEEEEEEEEEEEEEEEE--------------> <2> EEEEEEEEEEEEEEEEEEEEEEEEEEEEE <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM--@<----- [Packet Format] <1> Packet from SMN to SGW0 IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW0) Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr) <2> Packet from SGW0 to SMN IP Hdr:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) EndAH+ESP:(SGW0/SMN) IP Hdr2 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr) 4.5.7 SMN is outside, CH is in Other site (Site 1) If outside SMN only knows Border-SGW of its home network (SGW0), the data transmission is done as follows. [Protocol image] SMN (Network) SGW1 CH1 (Network) SGW0 HA <1> -EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE--> <2> | <-EEEEEEEEEEEEEEEEEEE--+ | +-------> +<------ | <3> +-EEEEEEEEEEEEEEEEEEEEEE------->@ <4> | EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ SMN (Network) SGW1 CH1 (Network) SGW0 HA [Packet Format] <1> Packet from SMN to SGW0 IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW0) Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) Ishiyama, et al. Expires June 22, 1997 [Page 21] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 <2> Packet from SGW0 to SGW1 IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP:(SGW0/SGW1) Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) <3> Packet from SGW1 to SGW0 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP:(SGW1/SGW0) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) <4> Packet from SGW0 to SMN IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) EndAH+ESP(SGW0/SMN) IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) If outside SMN knows the Border-SGW of CH1's network, or route optimization is done to eliminate the redundant routing via SGW0, the data transmission is done as follows. [Protocol image] SMN (Network) SGW1 CH1 (Network) SGW0 HA <1> -EEEEEEEEEEEEEEE-------> +<------ <2> +-EEEEEEEEEEEEEEEEEEEEEE------->@ <3> | EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V <-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+ SMN (Network) SGW1 CH1 (Network) SGW0 HA [Packet Format] <1> Packet from SMN to SGW1 IP Hdr:(Src=SMN c/o addr, Dst=SGW1 addr) SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0)) EndAH+ESP:(SMN/SGW1) Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr) <2> Packet from SGW1 to SGW0 IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(0)) EndAH+ESP:(SGW1/SGW0) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) Ishiyama, et al. Expires June 22, 1997 [Page 22] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 <3> Packet from SGW0 to SMN IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr) SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr)) EndAH+ESP(SGW0/SMN) IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr) Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr) 5. Future works 5.1 Route Optimization consideration [10] specifies the route optimization for Mobile IP, assuming that the mobile nodes, correspondent hosts and the mobility agents keeps the binding caches, and based on the information kept in the binding caches, the optimized route is determined. However, this method forces the ordinary corresponding hosts of the special support for the Mobile IP, we don't use this. Instead, we are planning the route optimization, in which the necessary information is held/exchanged only on each SGW and SMN. The purpose of this route optimization is not only avoiding redundant routing caused by mobile IP but also avoiding redundant decryption/encryption on the Border-SGW, described in 3.3. In the case of 3.3, if SMN accomplishes VPN towards the CH via one of the Border-SGW. Once it is confirmed that the CH is directly routable from the SMT, the route can be optimized. With this optimization, redundant IPSEC processing (decryption/re-encryption) at the Border-SGW will be skipped and the overhead of data transmission will be reduced. The implementation and evaluation of this route optimization is a future work. 5.2 FA mode consideration When there are foreign agents in the system, the packet is processed in the home network, (1) first IP-in-IP encapsulation at HA, (2) then IPSEC encapsulation at home-SGW. But when the packet is delivered to the visitor network, the decrypted packet have to be passed to FA first, and it conflicts the processing order in the home network. The possible solutions are: - home SGW remove the outer IP header (destined to SMN's Care-of address put by HA), process the packet with IPSEC, and put the removed IP header again outer of IPSEC processed packet. - home SGW caches mobility information and acts as proxy HA, and it encapsulates the packet in IPSEC first and Mobile IP next order. - Of course if HA/FA processes IPSEC by themselves (like proposed in Ishiyama, et al. Expires June 22, 1997 [Page 23] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 [8]), there are no such issues of processing order. 6. Security Considerations This entire document addresses security concerns. The security of the proposal in this draft completely depends upon IPSEC standard. Also for treating visiting mobile node properly, the security policy of each organization have to be configured and maintained properly. When a mobile node goes outside the organization and communicate to the Internet directly, proper mechanism for protecting the mobile node itself, such as packet filtering, is of course need to be supported. Acknowledgements Ideas in this document have benefited from discussions with Mark Lomas, Tom Markson, Rich Skrenta, Vipul Gupta, and Gabriel Montenegro. References [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1996. [3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [4] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995 [5] A. Aziz, T. Markson, H. Prafullchandra. Simple Key-Management For Internet Protocols (SKIP), (I-D draft-ietf-ipsec-skip-07.txt), August 14, 1996 [6] A. Aziz, T. Markson, H. Prafullchandra, R. Skrenta, G. Caronni. Certificate Discovery Protocol, (I-D draft-ietf-ipsec-cdp-01.txt), June 6, 1996 [7] P. Karn, W.A. Simpson. ICMP Security Failures Messages. (I-D draft-simpson-icmp-ipsec-fail-02.txt), April 1996 [8] G. Montenegro, V. Gupta. Firewall Support for Mobile IP, (I-D draft-montenegro-firewall-sup-00.txt), September 13, 1996 [9] M.C. Richardson. Authenticated Firewall Traversal with IPsec, (I-D draft-richardson-ipsec-aft-00.txt), April 1996 [10] D.B. Johnson, C. Perkins. Route Optimization in Mobile IP, (I-D draft-ietf-mobileip-optim-04.txt), February 1996 Author's Address Masahiro Ishiyama Toshiba Corporation, R&D Center 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 Ishiyama, et al. Expires June 22, 1997 [Page 24] Internet Draft Gateway traversal for Mobile IP Dec.17 1996 Email : masahiro@isl.rdc.toshiba.co.jp Atsushi Inoue Toshiba Corporation, R&D Center 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 Email : inoue@isl.rdc.toshiba.co.jp Atsushi Shimbo Toshiba Corporation, R&D Center 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 Email : shimbo@isl.rdc.toshiba.co.jp Toshio Okamoto Toshiba Corporation, R&D Center 1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan Phone : +81-44-549-2238 Email : oka@isl.rdc.toshiba.co.jp Ishiyama, et al. Expires May 1997 [Page 25]