rfc2344.txt

RFC规范的翻译稿

5.1.1. 数据包的处理
   移动节点必须把外地代理指定为其缺省路由器。不这样做将不能保证对移动节点发出的所有数据包进行封装，并且反向隧道将失效。外地代理必须：
      - 检测（detect）移动节点发送的数据包,并且
- 在转发这些数据包之前对这些数据包进行封装。
5.1.2. 数据包头部格式及各域
   本节给出了直接发送方式下数据包头部的格式。这种格式假设使用的是IP-in-IP封装（参考文献[2]）。

   外地代理收到的数据包格式(直接发送方式):

       IP各域：
          源地址=移动节点的家乡地址
目的地址=通信对方主机的地址
       高层协议数据

   外地代理转发的数据包的格式(直接发送方式):

       IP 各域(封装头部):
         源地址=外地代理的转交地址
         目的地址=家乡代理的地址
         Protocol域: 4 (IP-in-IP)
       IP各域(原始头部):
         源地址=移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装头部的各个域必须按下面选取:
      IP 源地址
         从注册请求的转交地址（Care-of Address）域拷贝而得。
IP 目的地址
         从注册请求的家乡代理（Home Agent）域拷贝。
      IP 协议域
         缺省为4 (IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它形式的封装方法。
5.2. 封装发送方式
   这种机制要求移动节点自己实现封装，并且通过把外地代理的地址指定为新的最外层头部的目的地址直接把数据包传送到外地代理。希望发送广播或者多播数据报的移动节点必须使用封装发送方式。
5.2.1 数据包的处理
   外地代理不修改其前向（转发）功能。相反地，它接收数据包，在核实数据包是移动节点发出的以后，它：
- 对数据包进行拆封，恢复出内层数据包
- 对数据包进行重新封装，并把它发送到家乡代理。
   如果外地代理接收到来自移动节点的未经封装的数据包，并且移动节点已经显式请求封装发送方式，那么外地代理不允许使用反向隧道发送该数据包，相反，它必须使用标准的IP路由机制来转发该数据包。
5.2.2. 数据包头部格式及各域
   本节给出了使用封装发送方式的数据包头部的格式。该格式假设使用IP-in-IP封装（参考文献[2]）。
   外地代理接收到的数据包格式(封装发送方式):
       IP各域(封装头部):
         源地址=移动节点的家乡地址
         目的地址=外地代理的地址
         Protoco域: 4 (IP in IP)
       IP各域(原始头部):
         源地址=移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装头部的各域必须按如下选用：
      IP 源地址
         移动节点的家乡地址。
      IP 目的地址
         由代理最近的注册应答中得知的IP源地址。
      IP Protocol域
         缺省为4(IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它封装方法。

   由外地代理转发的数据包的格式(封装发送方式):
       IP 各域(封装头部):
         源地址=外地代理的转交地址
         目的地址=家乡代理的地址
         Protocol域: 4 (IP-in-IP)
       IP 各域(原始头部):
         源地址 =移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装IP头部各域必须按照如下选取:
      IP 源地址
         从注册请求重的转交地址（Care-of Address）域拷贝。
      IP 目的地址
         从注册请求的家乡代理（Home Agent）域拷贝。
      IP Protocol域
         缺省为 4 (IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它封装方法。
5.3. 广播和多播数据报的支持
   如果移动节点以配置转交地址操作，广播和多播数据报按照移动IP规范（参考文献[1]）中的第4.3和4.4 节处理。使用外地代理转交地址的移动节点可以由外地代理通过反向隧道传送广播和多播数据报。但是，这样的移动节点必须使用封装发送方式。
   这样只是把数据报传送到外地代理，外地代理对数据报进行拆封，然后像对待来自移动节点的其它数据报一样处理该数据报，也就是说，通过反向隧道把它传送到家乡代理。
5.4.可选的反向隧道
   传送到本地资源（例如，附近的打印机）的数据包可能受到入口处过滤的影响。使用配置转交地址的移动节点可以对这些数据包的传送进行优化，方法就是不使用反向隧道传送。另一方面，使用外地代理转交地址的移动节点可以通过请求封装发送方式使用可选的反向隧道功能，遵循下面的原则：
      不想被通过反向隧道传送的数据包:
          使用直接发送方式。外地代理必须把这些数据包作为常规的流量来处理：它们可以被转发到家乡代理但是不允许通过反向隧道传送到家乡代理。

      想被通过反向隧道发送的数据包:
         使用封装发送方式发送。外地代理必须按第5.2节处理这些数据包：它们必须通过反向隧道传送到家乡代理。
6. 安全方面的考虑
   本文当描述的扩展是以移动IP规范（参考文献[1]）所描述的安全方面的考虑为基础的。本来，前向隧道和反向隧道的创建都涉及到认证过程，认证过程减少了受攻击的危险。
6.1. 反向隧道劫机及拒绝服务攻击
   一旦隧道建立起来后，恶意的节点将可能“劫持”该隧道并把数据包注入网络中。反向隧道可能使这个问题恶化，因为,当数据包到达隧道的出口点时，它的转发将在超出本地网络之外的地方进行。 这个问题在移动IP规范中也出现，因为它已经指定把反向隧道用于某些特定的应用。
   涉及到外地代理的未经
认证的数据交换将使得恶意的节点伪装成合法的移动节点，并把现存的隧道重定向到另一个家乡代理,或者是另一个恶意的节点。防止这种攻击的最好的方法就是使用移动IP规范（参考文献[1]）中的Mobile-Foreign以及Foreign-Home 认证扩展。
   如果所需的移动安全联合不可用，本文档介绍一种机制来减少这种攻击的范围和效力。移动节点必须把发给外地代理的注册请求中IP头部的TTL设置为255。这就防止了远于一跳（hop）之外的恶意节点伪装成合法节点。注册拒绝中其它的错误码（失败码）使得对这种确实发生的攻击的跟踪变得更容易。
   为了进一步减少这种攻击，移动IP工作组考虑了涉及到使用未认证状态的其它机制。但是，但是这些机制引入了拒绝服务攻击。大家一致认为在只提供很弱的（不加密的）保护来防止攻击的机制之间很难折衷。
6.2. 入口处过滤
   出现入口处过滤的反向隧道的长效性已经有一些问题。推想是网络管理员将把通过反向隧道的数据包（使用IP-in-IP封装的数据包）作为过滤的目标。入口处过滤的建议清楚地说明为什么不是如此（参考文献[8]）:
      当攻击的源变得更像“合法”时，对它的跟踪将变得更简单。
7. 致谢
   封装发送方式由Charlie Perkins提出。Jim Solomon的建议使得本文当形成现在的样子。 
参考文献
   [1] Perkins, C., “IP的移动性支持（移动IP规范）”, RFC 2002, October 1996.

   [2] Perkins, C., “在IP内封装IP（IP-in-IP封装）”, RFC 2003, October
       1996.

   [3] Computer Emergency Response Team (CERT), “IP欺诈攻击及劫持连接终端” , CA-95:01, January 1995。可通过匿名ftp从info.cert.org       in/pub/cert_advisories获得。

   [4] Johnson, D., and C. Perkins, “移动IP中的路由优化”,正在制订中。

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

   [6] Atkinson, R., “IP认证头部”, RFC 1826, August 1995.

   [7] Atkinson, R., “封装安全净载的IP”, RFC 1827,  August 1995.

   [8] Ferguson, P., and D. Senie, “网络入口点过滤：挫败使用源IP地址的拒绝服务攻击”, RFC 2267, January 1998.

   [9] Bradner, S., “RFC中表明条件级别所使用的关键词”, BCP 14, RFC 2119, March 1997.

编辑和主席地址

   本文档的问题可以直接按以下方式联系：
   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]

   工作组可通过现任主席联系：
   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]
完整版权通告
   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


RFC2344 Reverse Tunneling for Mobile IP                              RFC2344  移动IP反向隧道

1


1
中文文档翻译计划