rfc2344.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

Network Working Group                              G. Montenegro, Editor
Request for Comments: 2344                        Sun Microsystems, Inc.
Category: Standards Track                                       May 1998


                    Reverse Tunneling for Mobile IP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

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
   network, 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.

Table of Contents

   1. Introduction ................................................   2
   1.1. Terminology ...............................................   3
   1.2. Assumptions ...............................................   4
   1.3. Justification .............................................   4
   2. Overview ....................................................   4
   3. New Packet Formats ..........................................   5
   3.1. Mobility Agent Advertisement Extension ....................   5
   3.2. Registration Request ......................................   5
   3.3. Encapsulating Delivery Style Extension ....................   6
   3.4. New Registration Reply Codes ..............................   7
   4. Changes in Protocol Behavior ................................   8
   4.1. Mobile Node Considerations ................................   8



Montenegro                  Standards Track                     [Page 1]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


   4.1.1. Sending Registration Requests to the Foreign Agent ......   8
   4.1.2. Receiving Registration Replies from the Foreign Agent ...   9
   4.2. Foreign Agent Considerations ..............................   9
   4.2.1. Receiving Registration Requests from the Mobile Node ...   10
   4.2.2. Relaying Registration Requests to the Home Agent .......   10
   4.3. Home Agent Considerations ................................   10
   4.3.1. Receiving Registration Requests from the Foreign Agent .   11
   4.3.2. Sending Registration Replies to the Foreign Agent ......   11
   5. Mobile Node to Foreign Agent Delivery Styles ...............   12
   5.1. Direct Delivery Style ....................................   12
   5.1.1. Packet Processing ......................................   12
   5.1.2. Packet Header Format and Fields ........................   12
   5.2. Encapsulating Delivery Style .............................   13
   5.2.1 Packet Processing .......................................   13
   5.2.2. Packet Header Format and Fields ........................   14
   5.3. Support for Broadcast and Multicast Datagrams ............   15
   5.4. Selective Reverse Tunneling ..............................   15
   6. Security Considerations ....................................   16
   6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ...   16
   6.2. Ingress Filtering ........................................   17
   7. Acknowledgements ...........................................   17
   References ....................................................   17
   Editor and Chair Addresses ....................................   18
   Full Copyright Statement ......................................   19

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 (for example, IP spoofing attacks), and
   in accordance with RFC 2267 [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 network
   prefix from where it emanates.

   This document discusses topologically correct reverse tunnels.



Montenegro                  Standards Track                     [Page 2]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


   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 (for example, when
        sending packets to other hosts in its home network) may be so
        low that they might expire before reaching their destination.  A
        reverse tunnel solves the problem as it represents a TTL
        decrement of one [5].

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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [9].










Montenegro                  Standards Track                     [Page 3]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


1.2. Assumptions

   Mobility is constrained to a common IP address space (that is, 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 may not know if the
   correspondent host can decapsulate packets, reverse tunnels in that
   context are not discussed here.

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 correct co-located care-of address.

   However, one of the primary objectives of the Mobile IP specification
   is not to 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 mobile nodes,
   even in the presence of filtering routers.

2. Overview

   A mobile node arrives at a foreign network, listens for agent
   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





Montenegro                  Standards Track                     [Page 4]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


   mobile node wishes to deliver packets to the foreign agent, it also
   requests either the Direct or the Encapsulating Delivery Style
   (section 5).

   In the Direct Delivery Style, the mobile node designates the foreign
   agent as its default router and proceeds to send packets directly to
   the foreign agent, that is, without encapsulation.  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 re-tunnels them to the home agent, using the foreign
   agent's care-of address as the entry-point of this new tunnel.

3. New Packet Formats

3.1. Mobility Agent Advertisement Extension

    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 Mobility Agent Advertisement 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: Direct and Encapsulating Delivery Style
   (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 as per [1].

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



Montenegro                  Standards Track                     [Page 5]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


   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.

   In Registration Requests sent by a mobile node, the Time to Live
   field in the IP header MUST be set to 255.  This limits a denial of
   service attack in which malicious hosts send false Registration
   Requests (see Section 6).

    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. Mobile nodes using a foreign agent care-of
               address ask the foreign agent to reverse-tunnel its
               packets.

3.3. Encapsulating Delivery Style Extension

   The Encapsulating Delivery Style Extension MAY be included by the
   mobile node in registration requests to further specify reverse
   tunneling behavior. It is expected to be used only by the foreign
   agent.  Accordingly, the foreign agent MUST consume this extension
   (that is, it must not relay it to the home agent or include it in



Montenegro                  Standards Track                     [Page 6]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


   replies to the mobile node).  As per Section 3.6.1.3 of [1], the
   mobile node MUST include the Encapsulating Delivery Style Extension
   after the Mobile-Home Authentication Extension, and before the
   Mobile-Foreign Authentication Extension, if present.

   The Encapsulating Delivery Style Extension MUST NOT be included if
   the 'T' bit is not set in the Registration Request.

   If this extension is absent, Direct Delivery is assumed.
   Encapsulation is done according to what was negotiated for the
   forward tunnel (that is, IP in IP is assumed unless specified
   otherwise). For more details on the delivery styles, please refer to
   section 5.