rfc3024.txt

RFC 的详细文档！


RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   While the registration is in effect, a home agent MUST process each
   valid reverse tunneled packet (as determined by checks like the
   above) by decapsulating it, recovering the original packet, and then
   forwarding it on behalf of its sender (the mobile node) to the
   destination address (the correspondent host).

5. Mobile Node to Foreign Agent Delivery Styles

   This section specifies how the mobile node sends its data traffic via
   the foreign agent.  In all cases, the mobile node learns the foreign
   agent's link-layer address from the link-layer header in the agent
   advertisement.

5.1. Direct Delivery Style

   This delivery mechanism is very simple to implement at the mobile
   node, 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, and
   does not allow selective reverse tunneling (section 5.4).

5.1.1. Packet Processing

   The mobile node MUST designate 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:

      -  detect packets sent by the mobile node, and

      -  modify its forwarding function to encapsulate them before
         forwarding.

5.1.2. Packet Header Format and Fields

   This section shows the format of the packet headers used by the
   Direct Delivery style.  The formats shown assume IP in IP
   encapsulation [2].

   Packet format received by the foreign agent (Direct Delivery Style):

      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 (Direct Delivery Style):




Montenegro                  Standards Track                    [Page 13]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      IP fields (encapsulating header):
        Source Address = foreign agent's care-of 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

   These fields of the encapsulating header MUST be chosen as follows:

      IP Source Address

         Copied from the Care-of Address field within the Registration
         Request.

      IP Destination Address

         Copied from the Home Agent field within the most recent
         successful Registration Reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

5.2. Encapsulating Delivery Style

   This mechanism requires that the mobile node implement encapsulation,
   and 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 the
   Encapsulating Delivery Style.

5.2.1 Packet Processing

   The foreign agent does not modify its forwarding function.  Rather,
   it receives an encapsulated packet and after verifying that it was
   sent by the mobile node, it:

      -  decapsulates to recover the inner packet,

      -  re-encapsulates, and sends it to the home agent.

   If a foreign agent receives an un-encapsulated packet from a mobile
   node which had explicitly requested the Encapsulated Delivery Style,
   then the foreign agent MUST NOT reverse tunnel such a packet and
   rather MUST forward it using standard, IP routing mechanisms.



Montenegro                  Standards Track                    [Page 14]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


5.2.2. Packet Header Format and Fields

   This section shows the format of the packet headers used by the
   Encapsulating Delivery style.  The formats shown assume IP in IP
   encapsulation [2].

   Packet format received by the foreign agent (Encapsulating Delivery
   Style):

      IP fields (encapsulating header):
        Source Address = mobile node's home 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

   The fields of the encapsulating IP header MUST be chosen as follows:

      IP Source Address

         The mobile node's home address.

      IP Destination Address

         The address of the agent as learned from the IP source address
         of the agent's most recent successful registration reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

   Packet format forwarded by the foreign agent (Encapsulating Delivery
   Style):

      IP fields (encapsulating header):
        Source Address = foreign agent's care-of 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

   These fields of the encapsulating IP header MUST be chosen as
   follows:



Montenegro                  Standards Track                    [Page 15]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      IP Source Address

         Copied from the Care-of Address field within the Registration
         Request.

      IP Destination Address

         Copied from the Home Agent field within the most recent
         successful Registration Reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

5.3. Support for Broadcast and Multicast Datagrams

   If a mobile node is operating with a co-located care-of address,
   broadcast and multicast datagrams are handled according to Sections
   4.3 and 4.4 of the Mobile IP specification [1].  Mobile nodes using a
   foreign agent care-of address MAY have their broadcast and multicast
   datagrams reverse-tunneled by the foreign agent.  However, any mobile
   nodes doing so MUST use the encapsulating 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.

5.4. Selective Reverse Tunneling

   Packets destined to local resources (for example, a nearby printer)
   might be unaffected by ingress filtering.  A mobile node with a co-
   located care-of address MAY optimize delivery of these packets by not
   reverse tunneling them.  On the other hand, a mobile node using a
   foreign agent care-of address MAY use this selective reverse
   tunneling capability by requesting the Encapsulating Delivery Style,
   and following these guidelines:

      Packets NOT meant to be reversed tunneled:

         Sent using the Direct Delivery style.  The foreign agent MUST
         process these packets as regular traffic:  they MAY be
         forwarded but MUST NOT be reverse tunneled to the home agent.








Montenegro                  Standards Track                    [Page 16]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      Packets meant to be reverse tunneled:

         Sent using the Encapsulating Delivery style.  The foreign agent
         MUST process these packets as specified in section 5.2: they
         MUST be reverse tunneled 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].
   Essentially, creation of both forward and reverse tunnels involves an
   authentication procedure, which reduces the risk for attack.

6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks

   Once the tunnel is set up, a malicious node 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.

   Unauthenticated exchanges involving the foreign agent allow a
   malicious node to pose as a valid mobile node and re-direct an
   existing reverse tunnel to another home agent, perhaps another
   malicious node.  The best way to protect against these attacks is by
   employing the Mobile-Foreign and Foreign-Home Authentication
   Extensions defined in [1].

   If the necessary mobility security associations are not available,
   this document introduces a mechanism to reduce the range and
   effectiveness of the attacks.  The mobile node MUST set to 255 the
   TTL value in the IP headers of Registration Requests sent to the
   foreign agent.  This prevents malicious nodes more than one hop away
   from posing as valid mobile nodes.  Additional codes for use in
   registration denials make those attacks that do occur easier to
   track.

   With the goal of further reducing the attacks the Mobile IP Working
   Group considered other mechanisms involving the use of
   unauthenticated state.  However, these introduce the possibilities of
   denial-of-service attacks.  The consensus was that this was too much
   of a trade-off for mechanisms that guarantee no more than weak (non-
   cryptographic) protection against attacks.







Montenegro                  Standards Track                    [Page 17]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


6.2. Ingress Filtering

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

6.3. Reverse Tunneling for Disparate Address Spaces

   There are security implications involved with the foreign agent's
   using link-layer information to select the proper reverse tunnel for
   mobile node packets (section A.3).  Unauthenticated link-layers allow
   a malicious mobile node to misuse another's existing reverse tunnel,
   and inject packets into the network.

   For this solution to be viable, the link-layer MUST securely
   authenticate traffic received by the foreign agent from the mobile
   nodes.  Unauthenticated link-layer technologies (for example shared
   ethernet) are not recommended to implement disparate address support.

7. IANA Considerations

   The Encapsulating Delivery Style extension defined in section 3.3 is
   a Mobile IP registration extension as defined in [1].  IANA assigned
   the value of 130 for this purpose at the time of the publication of
   RFC 2344.

   The Code values defined in section 3.4 are error codes as defined in
   [1].  They correspond to error values associated with rejection by
   the home and foreign agents.  At the time of the publication of RFC
   2344, IANA assigned codes 74-76 for the foreign agent rejections and
   codes 137-139 for the home agent rejections.  The code for 'delivery
   style not supported' has been assigned a value of 79 by the IANA for
   this purpose.

8. Acknowledgements

   The encapsulating style of delivery was proposed by Charlie Perkins.
   Jim Solomon has been instrumental in shaping this document into its
   present form.  Thanks to Samita Chakrabarti for helpful comments on
   disparate address space support, and for most of the text in section
   A.4.




Montenegro                  Standards Track                    [Page 18]