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

Versions: 00 01 02 03 04 05 rfc2344                                     
Internet Engineering Task Force                            G. Montenegro
INTERNET DRAFT                                    Sun Microsystems, Inc.
                                                        January 31, 1996

                    Reverse Tunneling for Mobile IP
               draft-ietf-mobileip-tunnel-reverse-00.txt

Status of This Memo

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

   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

   Mobile IP uses tunneling from the home agent to the mobile node's
   care-of address, but rarely in the reverse direction.  Usually, a
   mobile node sends its packets through a router on the foreign net,
   and assumes that routing is independent of source address.  When
   this assumption is not true, it is convenient to establish a
   topologically correct reverse tunnel from the care-of address to the
   home agent.

   This document proposes backwards-compatible extensions to Mobile IP
   in order to support topologically correct reverse tunnels.  This
   document does not attempt to solve the problems posed by firewalls
   located between the home agent and the mobile node's care-of
   address.



Montenegro               Expires July 31, 1997                  [Page 1]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


1. Introduction

   Section 1.3 of the Mobile IP specification [1] lists the following
   assumption:

      It is assumed that IP unicast datagrams are routed based on the
      destination address in the datagram header (i.e., not by source
      address).

   Because of security concerns (e.g. IP spoofing attacks), and in
   accordance with the IAB [8] and CERT [3] advisories to this effect,
   routers that break this assumption are increasingly more common.

   In the presence of such routers, the source and destination IP
   address in a packet must be topologically correct. The forward
   tunnel complies with this, as its endpoints (home agent address and
   care-of address) are properly assigned addresses for their
   respective locations. On the other hand, the source IP address of a
   packet transmitted by the mobile node does not correspond to the
   location from where it emanates.

   This document discusses topologically correct reverse tunnels.

   Mobile IP does dictate the use of reverse tunnels in the context of
   multicast datagram routing and mobile routers. However, the source
   IP address is set to the mobile node's home address, so these
   tunnels are not topologically correct.

   Notice that there are several uses for reverse tunnels regardless of
   their topological correctness:

      - Mobile routers: reverse tunnels obviate the need for recursive
        tunneling [1].

      - Multicast: reverse tunnels enable a mobile node away from home
        to (1) join multicast groups in its home network, and (2)
        transmit multicast packets such that they emanate from its home
        network [1].

      - The TTL of packets sent by the mobile node (particularly when
        it addresses other hosts in its home network) may be so low
        that they may expire before reaching their destination.  A
        reverse tunnel solves the problem as it represents a TTL
        decrement of one [5].







Montenegro               Expires July 31, 1997                  [Page 2]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


1.1. Terminology

   The discussion below uses terms defined in the Mobile IP
   specification.  Additionally, it uses the following terms:

      Forward Tunnel

         A tunnel that shuttles packets towards the mobile node. It
         starts at the home agent, and ends at the mobile node's
         care-of address.

      Reverse Tunnel

         A tunnel that starts at the mobile node's care-of address and
         terminates at the home agent.

      Light-weight mobile node

         A mobile node that relies on a separate foreign agent for
         tunneling services (i.e. the care-of address belongs to the
         foreign agent).


1.2. Assumptions

   Mobility is constrained to one IP address space (e.g. the routing
   fabric between, say, the mobile node and the home agent is not
   partitioned into a "private" and a "public" network).

   This document does not attempt to solve the firewall traversal
   problem. Rather, it assumes one of the following is true:

      - There are no intervening firewalls along the path of the
        tunneled packets.

      - Any intervening firewalls share the security association
        necessary to process any authentication [6] or encryption [7]
        headers which may have been added to the tunneled packets.

   The reverse tunnels considered here are symmetric, that is, they use
   the same configuration (encapsulation method, IP address endpoints)
   as the forward tunnel. IP in IP encapsulation [2] is assumed unless
   stated otherwise.

   Route optimization [4] introduces forward tunnels initiated at a
   correspondent host.  Since a mobile node cannot know if the
   correspondent host can decapsulate packets, reverse tunnels in that
   context are not discussed here.



Montenegro               Expires July 31, 1997                  [Page 3]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


1.3. Justification

   Why not let the mobile node itself initiate the tunnel to the home
   agent?  This is indeed what it should do if it is already operating
   with a topologically significant co-located address.

   However, one of the primary objectives of the Mobile IP
   specification is to not *require* this mode of operation.

   The mechanisms outlined in this document are primarily intended for
   use by mobile nodes that rely on the foreign agent for forward
   tunnel support. It is desirable to continue supporting these
   "lightweight" mobile nodes, even in the presence of filtering
   routers.


2. Overview

   A light-weight mobile node arrives at a foreign net, listens for
   advertisements and selects a foreign agent that supports reverse
   tunnels. It requests this service when it registers through the
   selected foreign agent. At this time, and depending on how the
   mobile node wishes to deliver packets to the foreign agent, it also
   requests either the lightweight or the encapsulating style of
   delivery (section 5).

   In the lightweight delivery style, the mobile node designates the
   foreign agent as its default router and proceeds to send packets as
   usual. The foreign agent intercepts them, and tunnels them to the
   home agent.

   In the encapsulating delivery style, the mobile node encapsulates
   all its outgoing packets to the foreign agent.  The foreign agent
   decapsulates and tunnels again, this time, directly to the home
   agent.


3. New Packet Formats


3.1. Agent Advertisements: Mobile Service Extension










Montenegro               Expires July 31, 1997                  [Page 4]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Lifetime            |R|B|H|F|M|G|V|T|  reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |

   The only change to the Mobile Service Extension [1] is the
   additional 'T' bit:

      T        Agent offers reverse tunneling service.

   A foreign agent that sets the 'T' bit MUST support the two delivery
   styles currently supported (section 5).

   Using this information, a mobile node is able to choose a foreign
   agent that supports reverse tunnels. Notice that if a mobile node
   does not understand this bit, it simply ignores it.


3.2. Registration Request

   Reverse tunneling support is added directly into the Registration
   Request by using one of the "rsvd" bits.  If a foreign or home agent
   that does not support reverse tunnels receives a request with the
   'T' bit set, the Registration Request fails. This results in a
   registration denial (failure codes are specified in section 3.4).

   Most home agents would not object to providing reverse tunnel
   support, because they "SHOULD be able to decapsulate and further
   deliver packets addressed to themselves, sent by a mobile node"
   [1].  In the case of topologically correct reverse tunnels, the
   packets are not sent by the mobile node as distinguished by its home
   address.  Rather, the outermost (encapsulating) IP source address on
   such datagrams is the care-of address of the mobile node.
   Nevertheless, home agents  probably already support the required
   decapsulation and further forwarding.











Montenegro               Expires July 31, 1997                  [Page 5]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |S|B|D|M|G|V|T|-|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

   The only change to the Registration Request packet is the additional
   'T' bit:

      T        If the 'T' bit is set, the mobile node asks its home
               agent to accept a reverse tunnel from the care-of
               address. Lightweight mobile nodes ask the foreign
               agent to reverse-tunnel its packets.

3.3. Reverse Tunnel Extension

   The Reverse Tunnel Extension is used to further specify reverse
   tunneling behavior. Currently, it is only possible to request the
   encapsulating style of delivery, but future behavior may be
   defined.  The Reverse Tunnel Extension MUST NOT be included if the
   'T' bit is not set in the Registration Request.

   If this extension is absent, or if no style is explicitly requested,
   the Lightweight Delivery is assumed.  Besides the latter, currently
   only the Encapsulating style is defined (section 5).















Montenegro               Expires July 31, 1997                  [Page 6]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |E|          reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     128

      Length   2

      E        Encapsulating style of delivery. Encapsulation is done
               according to what was negotiated for the forward tunnel
               (i.e., IP in IP is assumed unless specified otherwise).

      reserved Ignored upon reception. Must be set to zero when
               transmitting.


3.4. New Registration Reply Codes

   Foreign and home agent replies must convey if the reverse tunnel
   request failed.  Four new reply codes are defined. The use of codes
   74 and 137 is preferred over code 70 for foreign agents and code 134
   for home agents [1]:

      Service denied by the foreign agent:

      74 requested reverse tunnel unavailable
      75 reverse tunnel is mandatory and 'T' bit not set

   and

      Service denied by the home agent:

      137 requested reverse tunnel unavailable
      138 reverse tunnel is mandatory and 'T' bit not set


4. Changes in Protocol Behavior

   Reverse tunnels must be handled appropriately by the different
   mobility entities. Differences in protocol behavior with respect to
   the Mobile IP specification are:


4.1. Mobile Node Considerations

   A mobile node sets the 'T' bit in its Registration Request to



Montenegro               Expires July 31, 1997                  [Page 7]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


   petition a reverse tunnel. It may optionally also include a
   Reverse Tunnel Extension. Possible outcomes are:

      - The foreign agent returns a registration denial. Depending on
        the reply code and following the error checking guidelines in
        [1], the mobile node MAY try zeroing the 'T' bit, eliminating
        the Reverse Tunnel Extension (if one was present), and issuing
        a new registration.

      - The home agent returns a registration denial. Depending on the
        reply code and following the error checking guidelines in [1],
        the mobile node MAY try zeroing the 'T' bit, eliminating the
        Reverse Tunnel Extension (if one was present), and issuing a
        new registration.

      - The home agent returns a Registration Reply indicating that the
        service will be provided.

   In this last case, the mobile node has succeeded in establishing a
   reverse tunnel between its care-of address and its home agent.  If
   the mobile node is operating with a co-located address, it SHOULD
   encapsulate all outgoing data such that the destination address of
   the outer header is the home agent. Not doing so does not
   necessarily preclude data transmission, but it defeats the purpose
   of the reverse tunnel.

   If the care-of address belongs to a separate foreign agent, the
   mobile node MUST employ whatever delivery style was requested
   (lightweight or encapsulated) and proceed as specified in section
   5.


4.2. Foreign Agent Considerations

   A foreign agent that receives a Registration Request with the 'T'
   bit set MAY either:

      - Return a Registration Reply denying the request. Valid return
        codes are 74 (requested reverse tunnel unavailable) or 70
        (poorly formed request). Code 74 is preferred.

      - Verify the packet according to [1] and then relay it to the
        home agent.

   Upon receipt of a Registration Reply that satisfies validity checks,
   it MUST update its visitor list, including indication that this
   mobile node has been granted a reverse tunnel and the delivery style
   expected (section 5).



Montenegro               Expires July 31, 1997                  [Page 8]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


   While this visitor list entry is in effect, the foreign agent MUST
   process incoming traffic according to the delivery style,
   encapsulate it and tunnel it from the care-of address to the home
   agent's address.


4.3. Home Agent Considerations

   A home agent that receives a Registration Request with the 'T' bit
   set processes the packet as specified in the Mobile IP specification
   [1]. As a result, it determines if it can accomodate the forward
   tunnel request. As a last check, the home agent verifies that it can
   support a reverse tunnel with the same configuration.

   If it can, the home agent sends back a Registration Reply with code
   0 or 1. A registration denial should send back code 137 (requested
   reverse tunnel unavailable) or 134 (poorly formed Request).  Code
   137 is preferred.

   After a successful registration, the home agent will receive
   encapsulated packets addressed to it. For each such packet it MAY
   search for a mobility binding whose care-of address is the source of
   the outer header, and whose mobile node address is the source of the
   inner header.

   The home agent MUST decapsulate, recover the original packet, and
   then forward it on behalf of its sender (the mobile node) to the
   destination address (the correspondent host).


5. Mobile Node to Foreign Agent Delivery Styles


5.1. Lightweight Delivery Style

   This delivery mechanism is very simple to implement, and uses small
   (non-encapsulated) packets on the link between the mobile node and
   the foreign agent (potentially a very slow link).  However, it only
   supports reverse-tunneling of unicast packets.

   It is achieved by the mobile node's designating the foreign agent as
   its default router Not doing so will not guarantee encapsulation of
   all the mobile node's outgoing traffic, and defeats the purpose of
   the reverse tunnel. The foreign agent must modify its forwarding
   function to detect packets sent by the mobile node, and
   re-encapsulate before forwarding.





Montenegro               Expires July 31, 1997                  [Page 9]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


   Packet format received by the foreign agent (lightweight delivery):

       Data Link fields:
         Source Address = mobile node's MAC address
         Destination Address = foreign agent's MAC address
       IP fields:
         Source Address = mobile node's home address
         Destination Address = correspondent host's address
       Upper Layer Protocol

   Packet format forwarded by the foreign agent (lightweight delivery):

       Data Link fields:
         Source Address = foreign agent's MAC address
         Destination Address = next hop router's MAC address
       IP fields (encapsulating header):
         Source Address = foreign agent's address
         Destination Address = home agent's address
         Protocol field: 4 (IP in IP)
       IP fields (original header):
         Source Address = mobile node's home address
         Destination Address = correspondent host's address
       Upper Layer Protocol


5.2. Encapsulating Delivery Style

   This mechanism requires that the mobile node implement
   encapsulation. The mobile node explicitly directs packets at the
   foreign agent by designating it as the destination address in a new
   outermost header.  Mobile nodes that wish to send either broadcast
   or multicast packets MUST use encapsulating delivery.

   The foreign agent does not have to modify its forwarding function.
   Rather, it receives the encapsulated packets and after verifying
   that they were sent by the mobile node, recovers the inner packets,
   re-encapsulates them and sends them to the home agent.














Montenegro               Expires July 31, 1997                 [Page 10]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


   Packet format received by the foreign agent (encapsulated delivery):

       Data Link fields:
         Source Address = mobile node's MAC address
         Destination Address = foreign agent's MAC address
       IP fields (encapsulating header):
         Source Address = mobile node's address
         Destination Address = foreign agent's address
         Protocol field: 4 (IP in IP)
       IP fields (original header):
         Source Address = mobile node's home address
         Destination Address = correspondent host's address
       Upper Layer Protocol

   Packet format forwarded by the foreign agent (encapsulated delivery):

       Data Link fields:
         Source Address = foreign agent's MAC address
         Destination Address = next hop router's MAC address
       IP fields (encapsulating header):
         Source Address = foreign agent's address
         Destination Address = home agent's address
         Protocol field: 4 (IP in IP)
       IP fields (original header):
         Source Address = mobile node's home address
         Destination Address = correspondent host's address
       Upper Layer Protocol


5.3. Support for Broadcast and Multicast Datagrams

   If a mobile node is operating with a co-located address, broadcast
   and multicast datagrams are handled according to Sections 4.3 and
   4.4 of the Mobile IP specification [1]. Light-weight mobile nodes
   MAY have their broadcast and multicast datagrams reverse-tunneled by
   the foreign agent.  However, this requires the use of the the
   encapulating delivery style.

   This delivers the datagram only to the foreign agent.  The latter
   decapsulates it and then processes it as any other packet from the
   mobile node, namely, by reverse tunneling it to the home agent.


6. Security Considerations

   The extensions outlined in this document are subject to the security
   considerations outlined in the Mobile IP specification [1].
   Essentialy, creation of both forward and reverse tunnels involves an



Montenegro               Expires July 31, 1997                 [Page 11]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


   authentication procedure, which reduces the risk for attack.

   However, once the tunnel is set up, a malicious user could hijack it
   to inject packets into the network. Reverse tunnels might exacerbate
   this problem, because upon reaching the tunnel exit point packets
   are forwarded beyond the local network. This concern is also present
   in the Mobile IP specification, as it already dictates the use of
   reverse tunnels for certain applications.

   There has been some concern regarding the long-term effectiveness of
   reverse-tunneling in the presence of ingress filtering. The
   conjecture is that network administrators will target
   reverse-tunneled packets (IP in IP encapsulated packets) for
   filtering. The ingress filtering recommendation spells out why this
   is not the case [8]:

      Tracking the source of an attack is simplified when the source is
      more likely to be "valid."


7. Acknowledgements

   The encapsulating style of delivery was proposed by Charlie Perkins.


References

    [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996.

    [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October
        1996.

    [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
        and Hijacked Terminal Connections", CA-95:01, January 1995.
        Available via anonymous ftp from info.cert.org in
        /pub/cert_advisories.

    [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP --
        work in progress, draft-ietf-mobileip-optim-05.txt, November
        1996.

    [5] Manuel Rodriguez, private communication, August 1995.

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

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




Montenegro               Expires July 31, 1997                 [Page 12]


INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996


    [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending
        Against IP Source Address Spoofing -- work in progress,
        draft-ferguson-ingress-filtering-01.txt, February 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

          gab@eng.sun.com



































Montenegro               Expires July 31, 1997                 [Page 13]