[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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 <NG>

       <----------------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--------->
                  <End-End AH between SMN/SGW(N)>


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.


                              <VPN2>        [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 <NG> - - -> 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]