rfc2344.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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 13]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


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 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 14]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


      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 Registration
         Request.

      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 15]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


      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 16]

RFC 2344            Reverse Tunneling for Mobile IP             May 1998


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

7. Acknowledgements

   The encapsulating style of delivery was proposed by Charlie Perkins.
   Jim Solomon has been instrumental in shaping this document into its
   present form.

References

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

   [2] Perkins, C., "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] Johnson, D., and C. Perkins, "Route Optimization in Mobile IP",
       Work in Progress.

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

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

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

   [8] Ferguson, P., and D. Senie, "Network Ingress Filtering: Defeating
       Denial of Service Attacks which employ IP Source Address
       Spoofing", RFC 2267, January 1998.

   [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.





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


Editor and Chair Addresses

   Questions about this document may be directed at:

   Gabriel E. Montenegro
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK 15-214
   Mountain View, California 94303

   Voice:  [phone]
   Fax:    [phone]
   EMail: [e-mail]

   The working group can be contacted via the current chairs:

   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd. - Rm 2240
   Schaumburg, IL  60196

   Voice:  [phone]
   Fax:    [phone]
   EMail: [e-mail]


   Erik Nordmark
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK17-202
   Mountain View, California 94303

   Voice:  [phone]
   EMail: [e-mail]

















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


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Montenegro                  Standards Track                    [Page 19]