[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 RFC 2356

Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                                  V. Gupta
                                                  Sun Microsystems, Inc.
                                                      September 13, 1996

                     Firewall Support for Mobile IP
                  draft-montenegro-firewall-sup-00.txt

Status of This Memo

   This document is a submission to the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   either to the author, or to the mobile-ip@SmallWorks.COM mailing
   list.

   Distribution of this memo is unlimited.

   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-abstracts.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

   The Mobile IP specification establishes the mechanisms that enable a
   mobile host to maintain and use the same IP address as it changes
   its point of attachment to the network. Mobility implies higher
   security risks than static operation, because the traffic may at
   times take unforeseen network paths with unknown or unpredictable
   security characteristics. The Mobile IP specification uses
   cryptographic techniques to authenticate the parties involved in the
   registration protocol. However, it makes no provisions for securing
   data traffic.  The mechanisms described in this document allow a
   mobile node out on a public sector of the network to negotiate
   access past a SKIP firewall, and construct a secure channel into its



Montenegro               Expires March 18, 1997                 [Page 1]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   home network.


1. Introduction

   This document specifies what support is required at a firewall to
   allow Mobile IP [1] hosts access into a private network from the
   Internet.  For example, a company employee could attach his/her
   laptop to some Internet access point by:

      a)   Dialing into a PPP/SLIP account on an Internet service
           provider's network.

      b)   Connecting into a 10Base-T or similar LAN network available
           at, for example, an IETF terminal room, a local university,
           or another company's premises.

   Notice that in these examples, the mobile node's relevant interface
   (PPP or 10Base-T) is configured with an IP address different from
   that which it uses "normally" (i.e. at the office). Furthermore, the
   IP address used is not necessarily a fixed assignment. It may be
   assigned temporarily and dynamically at the beginning of the session
   (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).

   The following discussion assumes a network configuration consisting
   of a private network separated by a firewall from the general
   Internet or public network.  The systems involved are:

      Private Network

           A protected network separated from the Internet by hosts
           enforcing access restrictions (firewalls).

      Public Network

          The Internet at large. Hosts are able to communicate with each
          other throughout the public network without firewall-imposed
          restrictions.

      Mobile Node (MN)

          Its permanent address falls within the range of the private
          network. The user may remove the system from its home
          network, and connects it to the Internet at another point.
          The mechanisms outlined in this discussion render this
          mobility transparent:  the mobile node continues accessing
          its home network and its resources exactly as if it were
          still within it.  Notice that when the mobile node leaves its



Montenegro               Expires March 18, 1997                 [Page 2]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


          home network, it may migrate both within and outside of the
          private network's boundaries. As defined by Mobile IP [1], a
          mobile node uses a care-of address while roaming.

      Pop-up

         A mobile node whose care-of address is an address associated
         to one of its own interfaces. This address may be a temporary
         address acquired dynamically (e.g. by means of DHCP or PPP's
         IPCP), or through manual intervention. It may also be a
         permanent address assigned to one of the mobile node's
         interfaces (e.g. a permanent PPP address).  Since pop-ups do
         not require a separate foreign agent, they can operate in
         foreign nets that lack Mobile IP support.

      Home Agent (HA) for the mobile node

         Serves as a location registry and router as described in the
         Mobile IP IETF draft.

      Foreign Agent (FA)

         Serves as a registration relayer and care of address for the
         mobile node as described in the Mobile IP IETF draft.

      Correspondent Host (CH)

         A system that is exchanging data packets with the mobile
         node.  Its communication with the mobile node does not change
         regardless of the latter's current point of attachment to the
         network.

      Firewall (FW)

         The system (or collection of systems) that enforces access
         control between the private network and the general Internet.
         It may do so by a combination of functions such as application
         gatewaying, packet filtering and cryptographic techniques.

   The mechanisms described in this document allow a mobile node out on
   a public sector of the network to negotiate access past a SKIP
   firewall, and construct a secure channel into its home network.
   This enables it to communicate with correspondent hosts that belong
   to the private network, and, if bi-directional tunnels are used,
   with external hosts that are reachable when the mobile node is at
   home.

   This document does not address the scenarion in which the mobile



Montenegro               Expires March 18, 1997                 [Page 3]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   node attempts to access its private network, while within another
   private network.

   Sections 2 and 3 provide an overview of the environment being
   considered and the restrictions it imposes.  Sections 4 examines
   firewall technologies. Section 5 discusses the best mode of
   operation of the participating entities from the point of view of
   Mobile IP.  Section 6 discusses possible configuration for the
   secure channel.  Finally, packet formats are the topic of of
   sections 7 and 8.


2. Mobility without a Firewall

   Suppose the mobile node is roaming throughout the general Internet,
   but its home network is not protected by a firewall. This is
   typically found in academic environment as opposed to corporate
   networks.

   This works as prescribed by Mobile IP [1]. The only proviso is that
   the mobile node would most probably operate as a pop-up instead of
   using a separate foreign agent's care-of address.  This is because,
   at least in the near term, it is far more likely to be able to
   secure a temporary care-of-address than it is to find a foreign
   agent already deployed at the site you are visiting. For example:

   -   Internet Service Provider (ISP): pre-assigns customers IP
       addresses, or hands them out dynamically via PPP's address
       negotiation.

   -   IETF terminal room: typically pre-assigns addresses for your use

   -   other places would probably offer DHCP services


3. Restrictions imposed by a Firewall

   The firewall imposes restrictions on packets entering or leaving the
   private network. Packets are not allowed through unless they conform
   to a filtering specification, or unless there is a negotiation
   involving some sort of authentication.

   Another restriction is imposed by the separation between private
   addresses and general Internet addresses. Strictly speaking, this is
   not imposed by a firewall, but by the characteristics of the private
   network. For example, if a packet destined to an internal address
   originates in the general Internet, it will probably not be
   delivered.  It is not that the firewall drops it. Rather, the



Montenegro               Expires March 18, 1997                 [Page 4]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   Internet's routing fabric is unable to process it. This elicits an
   ICMP host unreachable packet sent back to the originating node.

   Because of this, the firewall must be explicitly targeted as the
   destination node by outside packets seeking to enter the private
   network. The routing fabric in the general Internet will only see
   the public address of the firewall and route accordingly.  Once the
   packet arrives at the firewall, the real packet destined to a
   private address must be recovered.


4. Two Firewall Options: Application relay and IP Security

   Before delving into any details, lets examine two technologies which
   may provide firewall support for mobile nodes:

   -   application relaying or proxying, or
   -   IP Security

   To understand the implications, let's examine two specific schemes
   to accomplish the above: SOCKS version 5 and SKIP.


4.1 SOCKS version 5 [5]

   There is an effort within the authenticated firewall traversal WG
   (aft) of the IETF to provide a common interface for application
   relays.

   The solution being proposed is a revised specification of the SOCKS
   protocol. Version 5 has been extended to include UDP services as
   well.  The SOCKS solution requires that the mobile node -- or
   another node on its behalf -- establish a TCP session to exchange
   UDP traffic with the FW. It also has to use the SOCKS library to
   encapsulate the traffic meant for the FW. The steps required by a
   SOCKS solution are:

   -   TCP connection established to port 1080 (1.5 round trips)

   -   version identifier/method selection negotiation (1 round trip)

       -   method-dependent negotiation. For example, the
           Username/Password Authentication [6] requires 1 round trip:

           1. client sends a Username/Password request
           2. FW (server) responds

           The GSS-API negotiation [7] requires at least 3 round



Montenegro               Expires March 18, 1997                 [Page 5]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


           trips:

           1. client context establishment (at least 1 round trip)
           2. client initial token/server reply (1 round trip)
           3. message protection subnegotiation (at least 1 round trip)

   -   (finally) SOCKS request/reply (1 round trip)

   This is a minimum of 4 (6 with GSS-API) round-trips before the
   client is able to pass data through the FW using the following
   header:

      +----+------+------+----------+----------+----------+
      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
      +----+------+------+----------+----------+----------+
      | 2  |  1   |  1   | Variable |    2     | Variable |
      +----+------+------+----------+----------+----------+

   Bear in mind that the above must be done each time the mobile
   registers a new care-of address. In addition to this inefficiency,
   this scheme requires that we use UDP to encapsulate IP datagrams.
   There is at least one commercial network that does this, but it is
   not the best solution.

   This header contains the relay information needed by all parties
   involved to reach those not directly reachable.


4.2 SKIP [4]

   Alternatively, traffic from the mobile node to the firewall could be
   encrypted and authenticated using a session-less IP security
   mechanism like SKIP. This obviates the need to set up a TCP session
   just to exchange UDP traffic with the firewall.

   A solution based on SKIP is very attractive in this scenario, as no
   round trip times are involved before the mobile node and the
   firewall achieve mutual trust: the firewall can start relaying
   packets for the mobile node as soon as it receives the first one.
   This, of course, implies that SKIP is being used with AH [10] so
   that authentication information is contained in each packet.
   Encryption by using ESP [9] is also assumed in this scenario, since
   the Internet at large is considered a hostile environment.  An ESP
   transform that provides both authentication and encryption could be
   used, in which case the AH header need not be included.

   The firewall and the mobile node must both be previously configured
   with the authenticated Diffie-Hellman public values for each other.



Montenegro               Expires March 18, 1997                 [Page 6]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   Strictly speaking, they could obtain them in real-time, using any of
   the mechanisms defined by the SKIP protocol (online certificate
   directory service or certificate discovery protocol). However, in
   order to avoid round-trip times, it is preferable to manually
   distribute each other's public keys to the the mobile node and the
   SKIP firewall.  This is part of the administrative process of
   enabling a mobile node to roam in the general Internet. Home agents
   and the firewall must also have access to each others public keys.

   There are other proposals besides SKIP to achieve IP layer
   security.  However, they are session-oriented key management
   solutions, and typically imply negotiations spanning several
   round-trip times before cryptographically secure communications are
   possible.  In this respect they raise similar concerns to those
   outlined previously in the discussion on SOCKS-based solutions.
   Others have arrived at similar conclusions regarding the importance
   of session-less key management for Mobile IP applications [12].

   Another advantage of SKIP is its support for nomadic applications.
   Typically, two hosts communicating via a secure IP layer channel use
   the IP source and destination addresses on incoming packets to
   arrive at the appropriate security association. The SKIP header can
   easily supersede this default mechanism by including the key ID the
   recipient must use to obtain the right certificate.  The access
   control entry for a nomadic host at a SKIP firewall is a so-called
   "nomadic" entry, which is filtered by key ID, instead of by IP
   source address, as is the usual case. It basically translates to
   "allow access from "any IP source address" if "keyID=<fixed
   value>".  Incoming packets MUST have an AH header, so that after
   properly authenticating them, the firewall establishes a "current
   address" for the nomadic host.  This information determines which
   key should be used when encrypting outgoing packets [13].

   Notice that this supports Mobile IP, because the mobile node always
   initiates contact, so the SKIP firewall always has a chance to learn
   the "current address" to use when encrypting an outgoing packet.

   However, this precludes the use of simultaneous bindings by a mobile
   node.  At the firewall, the last Registration Request sent by the
   mobile node replaces the association between its permanent address
   and any prior care-of address. In order to support simultaneous
   bindings the firewall must be able to interpret Mobile IP
   registration messages.

   If in addition to registration messages, the firewall understands
   the Mobile IP encapsulation process, it is possible to use Unsigned
   Diffie-Hellman public values [14]. Doing so greatly reduces SKIP's
   infrastructure requirements, because there is no need for a



Montenegro               Expires March 18, 1997                 [Page 7]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   Certificate Authority. Of course, for this to be possible the
   principals' names MUST be securely communicated.

   Section 7.2.2 discusses another advantage of making the firewall
   understand Mobile IP packet formats.

   In what follows we assume a SKIP-based solution.


5. Supporting Mobile IP: Agents and Mobile Node Configurations

   The Mobile IP protocol specifies two ways that a mobile node can
   register a mobility binding with its home agent, depending on which
   address it uses as its tunnel endpoint:

      a)   an address advertised for that purpose by the foreign agent

      b)   an address belonging to one of the mobile node's interfaces
           (i.e. pop-up operation).

   From the firewall's point of view, the main difference between these
   two cases hinges on which node prepares the outermost encrypting
   encapsulation.  The firewall must be able to obtain the public keys
   of the node that creates the outermost SKIP header in an incoming
   packet. This is only possible to guarantee in case "b", because the
   mobile node and the firewall both belong to the same administrative
   domain. The problem is even more apparent when the mobile node
   attempts a registration request. Here, the foreign agent is not just
   a relayer, it actually examines the packet sent by the mobile node,
   and modifies its agent services accordingly. In short, assuming the
   current specification of Mobile IP and the current lack of trust in
   the internet at large, only case "b" is possible. Case "a" would
   require an extension (e.g. a "relay" registration request), and
   modifying code at the home agent, the firewall and the foreign
   agent.

   Assuming that the firewall offers a secure relay service (i.e.
   decapsulation and forwarding of packets), the mobile node can reach
   addresses internal to the private network by encapsulating the
   packets in a SKIP header and directing them to the firewall.

   Therefore, It is simplest to assume that the mobile node operates as
   a pop-up.


6. Supporting Mobile IP: Secure Channel Configurations

   The mobile node participates in two different types of traffic:



Montenegro               Expires March 18, 1997                 [Page 8]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   Mobile IP registration protocol and regular data. For the sake of
   simplicity, the following discussion evaluates different secure
   channel configurations by examining the initial registration request
   sent by the mobile node to its home agent.

   Assuming the mobile node operates as a pop-up, it can talk directly
   to the firewall.  The latter is able to reach the home agent in the
   private network. Also, the firewall must be able to authenticate the
   mobile node.

   The following channel configurations assume the mobile node is
   operating in pop-up mode. The region between the HA (home agent) and
   the FW (firewall) is a private network. The region between the FW
   and the MN (mobile node) is the outside or public network.


6.1 Option 1: Encryption only Outside of Private Network

   HA            FW                        MN
                  <=====================>  SKIP (AH + ESP)
    <----------------------------------->  Data path

   The traffic is only encrypted between the mobile node out on the
   general Internet, and the firewall's external interface. This is
   minimum required. It is the most desirable configuration as the more
   expensive encrypted channel is only used where it is necessary: on
   the public network.


6.2 Option 2: End-to-End Encryption

   Another possible configuration extends the encrypted tunnel through
   the FW:

   HA            FW                        MN
    <===================================>  SKIP (AH + ESP)
    <----------------------------------->  Data path

   This limits the FW to perform a simple packet relay or gatewaying
   function. Even though this could be accomplished by using the proper
   destination NSID in the packet, in practice it is probably
   unrealizable. The reason is that this alternative is probably not
   very popular with computer security personnel, as the authentication
   functions are now being carried out by the HA, whose security is
   potentially much weaker than the FW operated by computer security
   personnel.





Montenegro               Expires March 18, 1997                 [Page 9]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


6.3 Option 3: End-to-End Encryption, Intermediate Authentication

   A third alternative is to allow the FW to be party to the security
   association with the mobile node for *authentication* purposes only
   (AH header), and then forward the encrypted packet (ESP hdr) to the
   HA.

   HA            FW                        MN
                  <+++++++++++++++++++++>  SKIP authentication
    <===================================>  SKIP encryption
    <----------------------------------->  Data path

   The SKIP specification refers to this as "Intermediate
   Authentication with End-to-End security using SKIP" [4]:

        "Using SKIP, intermediate authentication of end-to-end
        protected IP traffic MAY be realized, if participating
        principals can share their long-term private keys with the
        intermediate node. This may not be desirable if the long-term
        keys belong to individual users, because of privacy related
        concerns,..."

   Whereas Option 2 above is probably not agreeable to security and
   system administration personnel, option 3 is unsavory to the end
   user.


6.4 Option 4: Encryption Inside and Outside
   HA            FW                        MN
    <============><=====================>  SKIP (AH + ESP)
    <----------------------------------->  Data path

   Traffic is encrypted on the public as well as on the private
   network. On the public network, encryption is dictated by a security
   association between the mobile node and the firewall.  On the
   private network, it is dictated by a security association between
   the home agent and the firewall.


6.5 Choosing a Secure Channel Configuration

   A potential problem in both options 2 and 3 is that their end-to-end
   channel components assume that the mobile node and the home agent
   have reachability to each other. This is generally not the case, as
   the Internet routing fabric may not have routes to addresses that
   belong to private networks, and the private routing fabric may
   ignore how to route to public addresses -- or doing so may be
   administratively restricted.  Therefore, it is necessary for packets



Montenegro               Expires March 18, 1997                [Page 10]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   to be addressed directly to the firewall, and indirectly -- via some
   tunneling or relaying capability -- to the real destination on the
   other side of the firewall.

   Options 1 and 4 are essentially equivalent. The latter may be
   considered overkill, because it uses encryption even within the
   private network, and this is generally not necessary. What is
   necessary even within the private network is for the home agent to
   add an encapsulation (not necessarily encrypted) so as to direct
   datagrams to the mobile node via the firewall. How this
   encapsulation is achieved is the difference between options 1 and
   4.  Option 4 uses SKIP, while option 1 uses a cleartext
   encapsulation mechanism.  This is obtainable by, for example, using
   IP in IP encapsulation [2], or by use of a currently undefined null
   transform in the SKIP header.

   Options 1 and 4 are mostly interchangeable, except in pathologically
   paranoid private networks. For example, option 1 allows a malicious
   node operation from within the private network to launch a chosen
   plaintext attack, by sending data through the firewall.

   In the interest of being conservative, in what follows we assume
   option 4 (i.e. traffic is encrypted on the general Internet, as well
   as within the private network.

   Since the firewall is party to the security associations governing
   encryption on both the public and private networks, it is always
   able to inspect the traffic being exchanged by the home agent and
   the mobile node. If this is of any concern, the home agent and
   mobile node could set up a bi-directional tunnel [8] and encrypt
   it.


7. Mobile IP Registration Procedure with a SKIP Firewall

   When roaming within a private network, a mobile node sends
   registration requests directly to its home agent. On the public
   Internet, it MUST encapsulates the original registration request in
   a SKIP packet destined to the firewall.  The mobile node MUST
   distinguish between "inside" and "outside" addresses. This could be
   accomplished by a set of rules defining the address ranges.
   Nevertheless, actual installations may present serious difficulties
   in defining exactly what is a private address and what is not.
   Because of this, errors in judgement are to be expected.
   Accordingly, the firewall SHOULD be configured such that it will
   still perform its relaying duties even if they are unnecessarily
   required by a mobile node with an inside care-of address.




Montenegro               Expires March 18, 1997                [Page 11]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   Upon arriving at a foreign net and acquiring a care-of address, the
   mobile node must first -- before any data transfer is possible --
   initiate a registration procedure. This consists of an authenticated
   exchange by which the mobile node informs its home agent of its
   current whereabouts (i.e. its current care-of address), and receives
   an acknowledgement. This first step of the protocol is very
   convenient, because the SKIP firewall can use it to dynamically
   configure its packet filter.

   The remainder if this section shows the packet formats used.
   Section 7.1 discusses how a mobile node sends a Registration Request
   to its home agent via the SKIP firewall. Section 7.2 discusses how
   the home agent send the corresponding Registration Reply to the
   mobile node.


7.1. Registration Request from the Mobile Node to the Home Agent via
     the SKIP Firewall

   The mobile node arrives at a foreign net, and using mechanisms
   defined by Mobile IP, discovers it has moved away from home. It
   acquires a local address at the foreign site, and composes a
   registration request meant for its HA.  It must decide whether this
   packet needs to be processed by SKIP or not.

   This is not a simple rule triggered by a given destination address.
   It must be applied whenever the following conditions are met:

      a)   the mobile node is using a care-of address that does not
           belong to the private network (i.e. the mobile node is
           "outside" its private network), and

      b)   either of:

           b1)   the source address of the packet is the mobile node's
                 home address, or

           b2)   the source address of the packet is the care-of
                 address and the destination address belongs to the
                 private network

   Since the above conditions are mobility related, it is best for the
   Mobile IP function in the node to evaluate them, and then -- using a
   special API -- request the appropriate security services from SKIP.

   The SKIP module must use the firewall destination address and the
   firewall's certificate in order to address and encrypt the packet.
   It encrypts it using SKIP combined with the ESP [9] protocol and



Montenegro               Expires March 18, 1997                [Page 12]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   possibly the AH [10] protocol.  The SKIP header's NSID fields
   indicate that the Master Key-ID for the source is that of the mobile
   node's home address, even though the packet's source address
   corresponds to the care-of address -- an address whose corresponding
   public key is unknown to the firewall.

   The SKIP Firewall's dynamic packet filtering uses this information
   to establish a dynamic mapping between the care-of address and the
   mobile node's Master Key-ID.

   The destination NSID field is zero, prompting the firewall to
   process the SKIP header and recover the internal packet.  It then
   delivers the original packet to another outbound interface, because
   it is addressed to the home agent (an address within the private
   network). Assuming secure channel configuration number 4, the
   firewall will encrypt the packet using SKIP before forwarding to the
   home agent.

   PACKET FORMAT 1:
   +---------------+----------+----+-----+--------------+--------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
   +---------------+----------+----+-----+--------------+--------------+

     IP Hdr (SKIP):
        Source          mobile node's care-of address
        Destination     public (outside) address on the firewall

     SKIP Hdr:
        Source          NSID = 1
                        Master Key-ID = IPv4 address of the mobile node
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          mobile node's care-of address
        Destination     home agent's address


7.2. Registration Reply from the Home Agent to the Mobile Node via the
     SKIP Firewall

   The home agent processes the registration request, and composes a
   registration reply. Before responding, it examines the care-of
   address reported by the mobile node, and determines whether or not
   it corresponds to an outside address.  If so, the home agent needs
   to send all traffic back through the firewall.  The home agent can
   accomplish this by encapsulating the original registration reply in
   a SKIP packet destined to the firewall (i.e. we assume secure
   channel configuration number 4).



Montenegro               Expires March 18, 1997                [Page 13]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


7.2.1. On the Inside (Private) Network

   The packet from the home agent to the mobile node via the SKIP
   Firewall has the same format as shown above. The relevant fields
   are:

   PACKET FORMAT 2:
   +---------------+----------+----+-----+--------------+------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
   +---------------+----------+----+-----+--------------+------------+

     IP Hdr (SKIP):
        Source          home agent's address
        Destination     private (inside) address on the firewall

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          home agent's address
        Destination     mobile node's care-of address


7.2.2. On the Outside (Public) Network

   The SKIP Firewall recovers the original registration reply packet
   and looks at the destination address: the mobile node's care-of
   address.

   The SKIP Firewall's dynamic packet filtering used the initial
   registration request (Secton 7.1) to establish a dynamic mapping
   between the care-of address and the mobile node's Master Key-ID.
   Hence, before forwarding the registration reply, it encrypts it
   using the mobile node's public key.

   This dynamic binding capability and the use of tunneling mode ESP
   obviate the need to extend the Mobile IP protocol with a "relay
   registration request". However, it requires that the Registration
   Reply exit the private network through the same firewall that
   forwarded the corresponding Registration Request.

   Instead of obtaining the mobile node's permanent address from the
   dynamic binding, a Mobile IP aware firewall could also obtain it
   from the Registration Reply itself. This renders the firewall
   stateless, and lets Registration Requests and Replies traverse the
   periphery of the private network through different firewalls.



Montenegro               Expires March 18, 1997                [Page 14]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   PACKET FORMAT 3:
   +---------------+----------+----+-----+--------------+------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
   +---------------+----------+----+-----+--------------+------------+

     IP Hdr (SKIP):
        Source          firewall's public (outside) address
        Destination     mobile node's care-of address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 1
                        Master Key-ID = IPv4 addr of the mobile node
     Inner IP Hdr:
        Source          home agent's address
        Destination     mobile node's care-of address


8. Data Transfer

   Data transfer proceeds along lines similar to the registration
   request outlined above.  Section 8.1 discusses data traffic sent by
   a mobile node to a correspondent host. Sections 8.2, 8.3 and 8.4
   show three alternative packet formats for the reverse traffic from
   the home agent to the mobile node.


8.1. Data Packet From the Mobile Node to a Correspondent Host

   The mobile node composes a packet destined to a correspondent host
   located within the private network.

   The Mobile IP function in the mobile node examines the Inner IP
   header, and determines that it satisfies conditions "a" and "b1"
   from Section 7.1. The mobile node requests the proper encryption and
   encapsulation services from SKIP.

   Thus, the mobile node in pop-up mode sends encrypted traffic to the
   firewall, using the following format:











Montenegro               Expires March 18, 1997                [Page 15]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   PACKET FORMAT 4:
   +---------------+----------+----+-----+--------------+------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP  |
   +---------------+----------+----+-----+--------------+------+

     IP Hdr (SKIP):
        Source          mobile node's care-of address
        Destination     public (outside) address on the firewall

     SKIP Hdr:
        Source          NSID = 1
                        Master Key-ID = IPv4 address of the mobile node
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          mobile node's home address
        Destination     correspondent host's address

   The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr
   and upper-layer packet (ULP) and checks the destination address.
   Since the packet is destined to a correspondent host in the private
   network, the "Inner" IP datagram is delivered internally.  Once the
   SKIP firewall injects this packet into the private network, it is
   routed independently of its source address.

   As this last assumption is not always true, the mobile node may
   construct a bi-directional tunnel [8] with its home agent. Doing
   so, guarantees that the "Inner IP Hdr" is:

     Inner IP Hdr:
        Source          mobile node's home address
        Destination     home agent address

   When at home, communication between the the mobile node and certain
   external correspondent hosts might need to go through
   application-specific firewalls or proxies, different from the SKIP
   firewall.  When on the public network, the mobile node's
   communication with these hosts, MUST use a bi-directional tunnel.


8.2. Data Packet Tunneled by the Home Agent to the Mobile Node

   The home agent intercepts a packet from a correspondent host to the
   mobile node. It encapsulates it such that the Mobile IP header's
   source and destination addresses are the home agent and care-of
   addresses, respectively. This would suffice for delivery within the
   private network. Since the current care-of address of the mobile
   node is not within the private network, this packet must be sent via



Montenegro               Expires March 18, 1997                [Page 16]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   the firewall. The home agent can accomplish this by encapsulating
   the datagram in a SKIP packet destined to the firewall (i.e. we
   assume secure channel configuration number 4).


8.2.1 Within the Inside (Private) Network

   From the home agent to the private (inside) address of the
   firewall the packet format is:

   PACKET FORMAT 5:
   +--------+------+----+-----+--------+--------+-----+
   | IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
   | (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
   +--------+------+----+-----+--------+--------+-----+

     IP Hdr (SKIP):
        Source          home agent's address
        Destination     private (inside) address on the firewall

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none

     Mobile-IP IP Hdr:
        Source          home agent's address
        Destination     care-of address

     Inner IP Hdr:
        Source          correspondent host's address
        Destination     mobile node's address

     ULP:               upper-layer packet

   The SKIP firewall intercepts the packet and recovers the
   Mobile IP encapsulated packet. Before sending out this
   packet, the dynamic packet filter configured by the original
   registration request above triggers encryption of this packet,
   this time by the SKIP firewall for consumption by the mobile node.

   The packet format above does not require the firewall to have a
   dynamic entry. The association between the mobile node's
   permanent address and it care-of address can be deduced from the
   contents of the "Mobile-IP IP Hdr" and the "Inner IP Hdr".





Montenegro               Expires March 18, 1997                [Page 17]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   The home agent MAY eliminate the Mobile IP header if it
   discriminates between mobile nodes that are registered within the
   private network, and those that are outside. In this case, the
   resultant packet is:

   PACKET FORMAT 6:
   +---------------+----------+----+-----+--------------+-----+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
   +---------------+----------+----+-----+--------------+-----+

     IP Hdr (SKIP):
        Source          home agent's address
        Destination     private (inside) address on the firewall

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none

     Inner IP Hdr:
        Source          correspondent host's address
        Destination     mobile node's address

   The SKIP firewall decrypts the packet, and recovers the original
   datagram. Before forwarding it, it examines its ruleset. It finds a
   dynamic rule which was added in response to the Registration Request
   sent by the mobile node. Accordingly, the SKIP firewall encrypts the
   packet again before forwarding to the mobile node's care-of
   address.

   This optimization requires that the firewall keep some state in the
   form of the aforementioned dynamic entry for the mobile node.


8.2.2. On the Outside (Public) Network

   The SKIP firewall intercepts the packet, and--assuming packet format
   5--recovers the Mobile IP encapsulated datagram. Before sending it
   out, the dynamic packet filter configured by the original
   Registration Request triggers encryption of this packet, this time
   by the SKIP firewall for consumption by the mobile node.  The
   resultant packet is:








Montenegro               Expires March 18, 1997                [Page 18]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   PACKET FORMAT 7:
   +--------+------+----+-----+--------+--------+-----+
   | IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
   | (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
   +--------+------+----+-----+--------+--------+-----+

     IP Hdr (SKIP):
        Source          firewall's public (outside) address
        Destination     mobile node's care-of address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 1
                        Master Key-ID = IPv4 address of the mobile node

     Mobile-IP IP Hdr:
        Source          home agent's address
        Destination     care-of address

     Inner IP Hdr:
        Source          correspondent host's address
        Destination     mobile node's address

     If the firewall receives a packet in format 6, the outgoing
     datagram to the mobile node is:

   PACKET FORMAT 8:
   +---------------+----------+----+-----+--------------+-----+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
   +---------------+----------+----+-----+--------------+-----+

     IP Hdr (SKIP):
        Source          public (outside) address on the firewall
        Destination     mobile node's care-of address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 1
                        Master Key-ID = IPv4 address of the mobile node

     Inner IP Hdr:
        Source          correspondent host's address
        Destination     mobile node's address

   As an optimization, the firewall MAY produce packet format 8 even if
   the packet it receives from the home agent is in format 5. This is



Montenegro               Expires March 18, 1997                [Page 19]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


   possible even if the firewall lacks state in the form of a dynamic
   binding.

   At the mobile node, SKIP processes the packets sent by the
   firewall.  Eventually, the inner IP header and the upper-layer
   packet (ULP) are retrieved and passed on.


9. Security Considerations

   The topic of this document is security. Nevertheless, it is
   imperative to point out the perils involved in allowing a flow of IP
   packets through a firewall. In essence, the mobile host itself MUST
   also take on responsibility for securing the private network,
   because it extends its periphery. This does not mean it stops
   exchanging unencrypted IP packets with hosts on the public network.
   For example, it MAY have to do so in order to satisfy billing
   requirements imposed by the foreign site, or to renew its DHCP
   lease. In the latter case it might filter not only on IP source
   address, but also on protocol and port numbers.

   Therefore, it MUST have some firewall capabilities, otherwise, any
   malicious individual that gains access to it will have gained access
   to the private network as well.


Acknowledgements

    Ideas in this document have benefited from discussions with at
    least the following people: Bill Danielson, Martin Patterson, Tom
    Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash
    Agrawal, Tsutomu Shimomura and Don Hoffman.


References

    [1] C. Perkins.  IP Mobility Support.  Internet Draft -- work in
        progress, May 1996.

    [2] C. Perkins.  IP Encapsulation within IP.  Internet Draft --
        work in progress, May 1996.

    [3] C. Perkins.  Minimal Encapsulation within IP.  Internet Draft
        -- work in progress, May 1996.

    [4] A. Aziz, T. Markson, H. Prafullchandra.  Simple Key-Management
        For Internet Protocols (SKIP).  Internet Draft -- work in
        progress, August 14, 1996.



Montenegro               Expires March 18, 1997                [Page 20]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


    [5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and . Jones.
        SOCKS Protocol Version 5. RFC 1928, March 1996.

    [6] M. Leech. Username/Password Authentication for SOCKS V5.  RFC
        1929, March 1996.

    [7] P V McMahon. GSS-API Authentication Method for SOCKS Version
        5.  Internet Draft -- work in progress, July 1995.

    [8] G. Montenegro.  Bi-directional Tunneling for Mobile IP.
        Internet Draft -- work in progress, September 1996.

    [9] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995

   [10] R. Atkinson.  IP Authentication Header.  RFC 1826, August
        1995.

   [11] A. Aziz, M. Patterson. "Design and Implementation of SKIP".
        Internet Commerce Group white paper ICG-95-004, June 28, 1995.

   [12] Stephen Kent, message to the IETF's IPSEC mailing list,
        Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September
        6, 1996.

   [13] Tom Markson, private communication, June 12, 1996.

   [14] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned
        Diffie-Hellman Public Value.  Internet Draft -- work in
        progress, August 14, 1996.






















Montenegro               Expires March 18, 1997                [Page 21]


INTERNET DRAFT       Firewall Support for Mobile IP       September 1996


Author's Address

          Gabriel E. Montenegro
          Sun Microsystems, Inc.
          2550 Garcia Avenue
          Mailstop UMPK 15-214
          Mountain View, California 94043-1100

          Tel: (415)786-6288
          Fax: (415)786-6445

          gabriel.montenegro@Eng.Sun.COM

          Vipul Gupta
          Sun Microsystems, Inc.
          2550 Garcia Avenue
          Mailstop UMPK 15-214
          Mountain View, California 94043-1100

          Tel: (415)786-3614
          Fax: (415)786-6445

          vipul.gupta@Eng.Sun.COM




























Montenegro               Expires March 18, 1997                [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/