Network Working Group G. Montenegro
Request for Comments: 2356 V. Gupta
Category: Informational Sun Microsystems, Inc.
June 1998
Network Working Group G. Montenegro
Request for Comments: 2356 V. Gupta
Category: Informational Sun Microsystems, Inc.
June 1998
Sun's SKIP Firewall Traversal for Mobile IP
Sun针对移动IP的跳过防火墙穿越
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。本备忘录未规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.
移动IP规范建立了使移动主机能够在更改其网络连接点时维护和使用相同IP地址的机制。移动性意味着比静态操作更高的安全风险，因为流量有时可能采用未知或不可预测的安全特性的不可预见的网络路径。移动IP规范未对数据流量的安全作出规定。本文档中描述的机制允许互联网公共部门的移动节点协商通过跳过防火墙的访问，并构建进入其家庭网络的安全通道。
In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space.
除了保护流量之外，我们的机制还允许移动节点漫游到（1）实施入口过滤和（2）使用不同地址空间的区域。
Table of Contents
目录
1. Introduction ............................................... 2
2. Mobility without a Firewall ................................ 4
3. Restrictions imposed by a Firewall ......................... 4
4. Two Firewall Options: Application relay and IP Security .... 5
4.1 SOCKS version 5 [4] ....................................... 5
4.2 SKIP [3] .................................................. 6
5. Agents and Mobile Node Configurations ...................... 8
6. Supporting Mobile IP: Secure Channel Configurations ........ 9
6.1 I: Encryption only Outside of Private Network ............. 9
6.2 II: End-to-End Encryption ................................. 10
6.3 III: End-to-End Encryption, Intermediate Authentication ... 10
1. Introduction ............................................... 2
2. Mobility without a Firewall ................................ 4
3. Restrictions imposed by a Firewall ......................... 4
4. Two Firewall Options: Application relay and IP Security .... 5
4.1 SOCKS version 5 [4] ....................................... 5
4.2 SKIP [3] .................................................. 6
5. Agents and Mobile Node Configurations ...................... 8
6. Supporting Mobile IP: Secure Channel Configurations ........ 9
6.1 I: Encryption only Outside of Private Network ............. 9
6.2 II: End-to-End Encryption ................................. 10
6.3 III: End-to-End Encryption, Intermediate Authentication ... 10
6.4 IV: Encryption Inside and Outside ......................... 10
6.5 Choosing a Secure Channel Configuration ................... 11
7. Mobile IP Registration Procedure with a SKIP Firewall ...... 11
7.1. Registration Request through the Firewall ................ 12
7.1.1. On the Outside (Public) Network ........................ 13
7.1.2. On the Inside (Private) Network ........................ 14
7.2. Registration Reply through the Firewall .................. 14
7.2.1. On the Inside (Private) Network ........................ 15
7.2.2. On the Outside (Public) Network ........................ 15
7.3. Traversal Extension ...................................... 16
8. Data Transfer .............................................. 18
8.1. Data Packet From the Mobile Node to a Correspondent Node . 18
8.2. Data Packet From a Correspondent Node to the Mobile Node . 19
8.2.1 Within the Inside (Private) Network ..................... 20
8.2.2. On the Outside (Public) Network ........................ 21
9. Security Considerations .................................... 21
Acknowledgements .............................................. 22
References .................................................... 22
Authors' Addresses ............................................ 23
Full Copyright Statement ...................................... 24
6.4 IV: Encryption Inside and Outside ......................... 10
6.5 Choosing a Secure Channel Configuration ................... 11
7. Mobile IP Registration Procedure with a SKIP Firewall ...... 11
7.1. Registration Request through the Firewall ................ 12
7.1.1. On the Outside (Public) Network ........................ 13
7.1.2. On the Inside (Private) Network ........................ 14
7.2. Registration Reply through the Firewall .................. 14
7.2.1. On the Inside (Private) Network ........................ 15
7.2.2. On the Outside (Public) Network ........................ 15
7.3. Traversal Extension ...................................... 16
8. Data Transfer .............................................. 18
8.1. Data Packet From the Mobile Node to a Correspondent Node . 18
8.2. Data Packet From a Correspondent Node to the Mobile Node . 19
8.2.1 Within the Inside (Private) Network ..................... 20
8.2.2. On the Outside (Public) Network ........................ 21
9. Security Considerations .................................... 21
Acknowledgements .............................................. 22
References .................................................... 22
Authors' Addresses ............................................ 23
Full Copyright Statement ...................................... 24
This document specifies what support is required at the firewall, the Mobile IP [1] home agent and the Mobile IP mobile node to enable the latter to access a private network from the Internet. For example, a company employee could attach his/her laptop to some Internet access point by:
本文档规定了防火墙、移动IP[1]归属代理和移动IP移动节点需要哪些支持，以使后者能够从Internet访问专用网络。例如，公司员工可以通过以下方式将其笔记本电脑连接到某个互联网接入点：
a) Dialing into a PPP/SLIP account on an Internet service provider's network.
a) 拨入互联网服务提供商网络上的PPP/SLIP帐户。
b) Connecting into a 10Base-T or similar LAN network available at, for example, an IETF terminal room, a local university, or another company's premises.
b) 连接到10Base-T或类似LAN网络，例如IETF终端室、当地大学或其他公司的场所。
Notice that in these examples, the mobile node's relevant interface (PPP or 10Base-T) is configured with an IP address different from that which it uses "normally" (i.e. at the office). Furthermore, the IP address used is not necessarily a fixed assignment. It may be assigned temporarily and dynamically at the beginning of the session (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).
注意，在这些示例中，移动节点的相关接口（PPP或10Base-T）配置有不同于其“正常”（即在办公室）使用的IP地址的IP地址。此外，所使用的IP地址不一定是固定的分配。它可以在会话开始时临时和动态地分配（例如，在PPP情况下由IPCP分配，在10Base-T情况下由DHCP分配）。
The following discussion assumes a network configuration consisting of a private network separated by a firewall from the general Internet or public network. The systems involved are:
以下讨论假设网络配置由防火墙与通用Internet或公共网络分隔的专用网络组成。涉及的系统包括：
Private Network
专用网络
A protected network separated from the Internet by hosts enforcing access restrictions (firewalls). A private network may use a private address space, and its addresses may not even be routable by the general internet.
通过强制访问限制（防火墙）的主机与Internet分离的受保护网络。专用网络可能使用专用地址空间，其地址甚至可能无法通过通用internet路由。
Public Network
公共网络
The Internet at large. Hosts are able to communicate with each other throughout the public network without firewall-imposed restrictions.
整个互联网。主机能够通过公共网络相互通信，而无需防火墙施加的限制。
Mobile Node (MN)
移动节点（MN）
Its permanent address falls within the range of the private network. The user removes the system from its home network, and connects it to the Internet at another point. The mechanisms outlined in this discussion render this mobility transparent: the mobile node continues accessing its home network and its resources exactly as if it were still within it. Notice that when the mobile node leaves its home network, it may migrate both within and outside of the private network's boundaries. As defined by Mobile IP [1], a mobile node uses a care-of address while roaming.
其永久地址在专用网络的范围内。用户将系统从其家庭网络中删除，并在另一点将其连接到Internet。本讨论中概述的机制使这种移动性透明：移动节点继续访问其家庭网络及其资源，就好像它仍然在其中一样。请注意，当移动节点离开其家庭网络时，它可能会在专用网络边界内外迁移。根据移动IP[1]的定义，移动节点在漫游时使用转交地址。
Home Agent (HA) for the mobile node
移动节点的归属代理（HA）
Serves as a location registry and router as described in the Mobile IP IETF draft.
用作移动IP IETF草案中所述的位置注册表和路由器。
Foreign Agent (FA)
外国代理人（FA）
Serves as a registration relayer and care of address for the mobile node as described in the Mobile IP IETF draft.
作为移动节点的注册中继和转交地址，如移动IP IETF草案中所述。
Correspondent Node (CH)
对应节点（CH）
A system that is exchanging data packets with the mobile node.
与移动节点交换数据包的系统。
Firewall (FW)
防火墙（FW）
The system (or collection of systems) that enforces access control between the private network and the general Internet. It may do so by a combination of functions such as application gatewaying, packet filtering and cryptographic techniques.
在专用网络和通用Internet之间实施访问控制的系统（或系统集合）。它可以通过应用网关、包过滤和密码技术等功能的组合来实现。
The mechanisms described in this document allow a mobile node out on a public sector of the network to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This enables it to communicate with correspondent nodes that belong to the private network, and, if bi-directional tunnels are used, with external hosts that are reachable when the mobile node is at home. The mobile node enjoys the same level of connectivity and privacy as it does when it is in its home network.
本文档中描述的机制允许网络公共部门上的移动节点协商通过跳过防火墙的访问，并构建进入其家庭网络的安全通道。这使得它能够与属于专用网络的对应节点通信，如果使用双向隧道，则能够与移动节点在家时可以访问的外部主机通信。移动节点享有与在其家庭网络中时相同的连通性和隐私级别。
This document does not address the scenario in which the mobile node attempts to access its private network, while within another private network.
本文档不涉及移动节点在另一个专用网络内尝试访问其专用网络的场景。
Sections 2 and 3 provide an overview of the environment being considered and the restrictions it imposes. Section 4 examines firewall technologies. Section 5 discusses the best mode of operation of the participating entities from the point of view of Mobile IP. Section 6 discusses possible configuration for the secure channel. Finally, packet formats are the topic of sections 7 and 8.
第2节和第3节概述了所考虑的环境及其施加的限制。第4节研究防火墙技术。第5节从移动IP的角度讨论了参与实体的最佳运营模式。第6节讨论了安全通道的可能配置。最后，数据包格式是第7节和第8节的主题。
Suppose the mobile node is roaming throughout the general Internet, but its home network is not protected by a firewall. This is typically found in academic environment as opposed to corporate networks.
假设移动节点在通用Internet上漫游，但其家庭网络不受防火墙保护。这通常出现在学术环境中，而不是企业网络中。
This works as prescribed by Mobile IP [1]. The only proviso is that the mobile node would most probably operate with a co-located address instead of using a separate foreign agent's care-of address. This is because, at least in the near term, it is far more likely to be able to secure a temporary care-of-address than it is to find a foreign agent already deployed at the site you are visiting. For example:
这符合移动IP[1]的规定。唯一的限制条件是，移动节点最有可能使用一个共同定位的地址，而不是使用单独的外部代理的转交地址。这是因为，至少在短期内，与找到已部署在您访问的站点的外国代理相比，它更可能获得临时托管地址。例如：
- Internet Service Provider: pre-assigns customers IP addresses, or assigns them out dynamically via PPP's address negotiation.
- 互联网服务提供商：预先分配客户IP地址，或通过PPP的地址协商动态分配。
- An IETF terminal room may pre-assign addresses for your use or offer DHCP services.
- IETF终端室可以预先分配地址供您使用或提供DHCP服务。
- Other locations probably would offer DHCP services.
- 其他地点可能会提供DHCP服务。
The firewall imposes restrictions on packets entering or leaving the private network. Packets are not allowed through unless they conform to a filtering specification, or unless there is a negotiation involving some sort of authentication.
防火墙对进入或离开专用网络的数据包施加限制。数据包不允许通过，除非它们符合过滤规范，或者除非存在涉及某种身份验证的协商。
Another restriction is imposed by the separation between private addresses and general Internet addresses. Strictly speaking, this is not imposed by a firewall, but by the characteristics of the private network. For example, if a packet destined to an internal address originates in the general Internet, it will probably not be delivered. It is not that the firewall drops it. Rather, the Internet's routing fabric is unable to process it. This elicits an ICMP host unreachable packet sent back to the originating node.
另一个限制是专用地址和通用Internet地址之间的分隔。严格地说，这不是由防火墙强加的，而是由专用网络的特性强加的。例如，如果发送到内部地址的数据包来自通用Internet，则它可能不会被发送。这并不是说防火墙将其删除。相反，互联网的路由结构无法处理它。这将导致ICMP主机无法访问的数据包发送回发起节点。
Because of this, the firewall MUST be explicitly targeted as the destination node by outside packets seeking to enter the private network. The routing fabric in the general Internet will only see the public address of the firewall and route accordingly. Once the packet arrives at the firewall, the real packet destined to a private address is recovered.
因此，外部数据包必须明确地将防火墙作为目标节点，以寻求进入专用网络。普通Internet中的路由结构只能看到防火墙的公共地址并相应地进行路由。一旦数据包到达防火墙，将恢复发送到专用地址的真实数据包。
Before delving into any details, lets examine two technologies which may provide firewall support for mobile nodes:
在深入研究任何细节之前，让我们先研究两种可能为移动节点提供防火墙支持的技术：
- application relaying or proxying, or
- 应用程序中继或代理，或
- IP Security.
- IP安全。
To understand the implications, let's examine two specific schemes to accomplish the above: SOCKS version 5 and SKIP.
为了理解其含义，让我们研究两种实现上述功能的具体方案：SOCKS版本5和SKIP。
There is an effort within the authenticated firewall traversal WG (aft) of the IETF to provide a common interface for application relays.
IETF的认证防火墙穿越工作组（aft）努力为应用程序中继提供公共接口。
The solution being proposed is a revised specification of the SOCKS protocol. Version 5 has been extended to include UDP services as well. The SOCKS solution requires that the mobile node -- or another node on its behalf -- establish a TCP session to exchange UDP traffic with the FW. It also has to use the SOCKS library to encapsulate the traffic meant for the FW. The steps required by a SOCKS solution are:
提出的解决方案是修改SOCKS协议的规范。版本5已经扩展到包括UDP服务。SOCKS解决方案要求移动节点（或代表移动节点的另一个节点）建立TCP会话，以与FW交换UDP流量。它还必须使用SOCKS库来封装用于FW的通信量。SOCKS解决方案所需的步骤包括：
- TCP connection established to port 1080 (1.5 round trips)
- 已建立到端口1080的TCP连接（1.5次往返）
- version identifier/method selection negotiation (1 round trip)
- 版本标识符/方法选择协商（1次往返）
- method-dependent negotiation. For example, the Username/Password Authentication [5] requires 1 round trip:
- 方法依赖协商。例如，用户名/密码身份验证[5]需要1次往返：
1. client sends a Username/Password request 2. FW (server) responds
1. 客户端发送用户名/密码请求2。FW（服务器）响应
The GSS-API negotiation requires at least 3 round trips:
GSS-API谈判至少需要3次往返：
1. client context establishment (at least 1 round trip) 2. client initial token/server reply (1 round trip) 3. message protection subnegotiation (at least 1 round trip)
1. 客户端上下文建立（至少1次往返）2。客户端初始令牌/服务器回复（1个往返）3。信息保护子协商（至少1次往返）
- (finally) SOCKS request/reply (1 round trip)
- （最后）SOCKS请求/回复（1次往返）
This is a minimum of 4 (6 with GSS-API) round-trips before the client is able to pass data through the FW using the following header:
在客户机能够使用以下标头通过FW传递数据之前，至少需要4（6个GSS-API）往返行程：
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
+----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+
Bear in mind that the above must be done each time the mobile registers a new care-of address. In addition to this inefficiency, this scheme requires that we use UDP to encapsulate IP datagrams. There is at least one commercial network that does this, but it is not the best solution.
请记住，每次手机注册新的转交地址时，都必须执行上述操作。除此之外，该方案还要求我们使用UDP来封装IP数据报。至少有一个商业网络可以做到这一点，但这并不是最好的解决方案。
Furthermore, SOCKS defines how to establish authenticated connections, but currently it does not provide a clear solution to the problem of encrypting the traffic.
此外，SOCKS定义了如何建立经过身份验证的连接，但目前它没有为流量加密问题提供明确的解决方案。
This header contains the relay information needed by all parties involved to reach those not directly reachable.
此标头包含所有相关方需要的中继信息，以到达无法直接到达的中继。
Alternatively, traffic from the mobile node to the firewall could be encrypted and authenticated using a session-less IP security mechanism like SKIP. This obviates the need to set up a session just to exchange UDP traffic with the firewall.
或者，从移动节点到防火墙的流量可以使用无会话IP安全机制（如SKIP）进行加密和身份验证。这样就不需要设置会话来与防火墙交换UDP通信。
A solution based on SKIP is very attractive in this scenario, as no round trip times are incurred before the mobile node and the firewall achieve mutual trust: the firewall can start relaying packets for the mobile node as soon as it receives the first one. This, of course, implies that SKIP is being used with AH [7] so that authentication information is contained in each packet. Encryption by using ESP [6] is also assumed in this scenario, since the Internet at large is considered a hostile environment. An ESP transform that provides
在这种情况下，基于SKIP的解决方案非常有吸引力，因为在移动节点和防火墙实现互信之前不会产生往返时间：防火墙可以在收到第一个数据包后立即开始为移动节点中继数据包。当然，这意味着SKIP与AH[7]一起使用，因此每个数据包中都包含身份验证信息。在这种情况下，还假设使用ESP[6]进行加密，因为整个互联网被视为一个敌对环境。提供
both authentication and encryption could be used, in which case the AH header need not be included.
可以使用身份验证和加密，在这种情况下，不需要包括AH头。
The firewall and the mobile node may be previously configured with each other's authenticated Diffie-Hellman public components (also known as public values). Alternatively, they could exchange them in real-time using any of the mechanisms defined by the SKIP protocol (on-line certificate directory service or certificate discovery protocol). Home agents and the firewall also MUST have, be able to exchange or obtain each other's public components.
防火墙和移动节点可以预先配置彼此的经认证的Diffie-Hellman公共组件（也称为公共值）。或者，他们可以使用SKIP协议（在线证书目录服务或证书发现协议）定义的任何机制实时交换它们。家庭代理和防火墙还必须具有、能够交换或获取彼此的公共组件。
There are other proposals besides SKIP to achieve IP layer security. However, they are session-oriented key management solutions, and typically imply negotiations spanning several round-trip times before cryptographically secure communications are possible. In this respect they raise similar concerns to those outlined previously in the discussion on SOCKS-based solutions. Others have arrived at similar conclusions regarding the importance of session-less key management for Mobile IP applications [8].
除了SKIP之外，还有其他一些实现IP层安全的方案。然而，它们是面向会话的密钥管理解决方案，通常意味着在实现加密安全通信之前，需要进行多次往返协商。在这方面，他们提出了与前面讨论的基于SOCKS的解决方案类似的问题。对于移动IP应用程序中无会话密钥管理的重要性，其他人也得出了类似的结论[8]。
Another advantage of SKIP is its support for nomadic applications. Typically, two hosts communicating via a secure IP layer channel use the IP source and destination addresses on incoming packets to arrive at the appropriate security association. The SKIP header can easily supersede this default mechanism by including the key ID the recipient must use to obtain the right certificate.
SKIP的另一个优点是它支持游牧应用程序。通常，通过安全IP层通道进行通信的两台主机使用传入数据包上的IP源地址和目标地址到达适当的安全关联。SKIP头可以通过包含接收方获取正确证书所必须使用的密钥ID轻松取代此默认机制。
The key id is specified by two fields in the SKIP header:
密钥id由跳过标头中的两个字段指定：
1) a name space identifier (NSID) to indicate which of the possible name spaces is being used, and,
1) 名称空间标识符（NSID），用于指示正在使用哪些可能的名称空间，以及，
2) a master key identifier (MKID) that uniquely indicates (within the given name space) an id to use in fetching the proper certificate.
2) 一种主密钥标识符（MKID），它唯一地指示（在给定的名称空间内）在获取正确证书时使用的id。
As an example, by setting NSID to 1 and MKID to its home address, a mobile node tells a receiver "ignore the IP source and use my home address instead to look up my public component". Similarly, setting NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates.
例如，通过将NSID设置为1并将MKID设置为其家庭地址，移动节点告诉接收者“忽略IP源，使用我的家庭地址来查找我的公共组件”。类似地，将NSID设置为8可以使用未签名的Diffie-Hellman（UDH）证书。
In this case, the MKID is set to the MD5 hash of the DH public component [10].
在这种情况下，MKID被设置为DH public组件的MD5散列[10]。
In addition to the NSID/MKID feature, Mobile IP is best supported by an appropriate policy at the SKIP firewall in the form of a "nomadic" access control list entry. This is an entry which is filtered by key ID, instead of by IP source address, as is the usual case. It
除了NSID/MKID功能外，移动IP最好由跳过防火墙的适当策略以“游牧”访问控制列表条目的形式提供支持。这是一个按密钥ID过滤的条目，而不是像通常情况那样按IP源地址过滤。信息技术
translates to "allow access from any IP source address for a given NSID/MKID combination". Furthermore, incoming packets MUST have an AH header, so that after properly authenticating them, the firewall establishes a "current address" or "dynamic binding" for the nomadic host. The NSID/MKID combination determines which key should be used with the nomadic host [9].
翻译为“允许从给定NSID/MKID组合的任何IP源地址访问”。此外，传入数据包必须具有AH报头，以便在正确验证它们之后，防火墙为游牧主机建立“当前地址”或“动态绑定”。NSID/MKID组合决定了哪个密钥应该与游牧主机一起使用[9]。
Notice that this supports Mobile IP, because the mobile node always initiates contact. Hence, the SKIP firewall has a chance to learn the mobile node's "current address" from an incoming packet before it attempts to encrypt an outgoing packet.
请注意，这支持移动IP，因为移动节点总是发起联系。因此，跳过防火墙在尝试加密传出数据包之前，有机会从传入数据包中了解移动节点的“当前地址”。
However, this precludes the use of simultaneous bindings by a mobile node. At the firewall, the last Registration Request sent by the mobile node replaces the association between its permanent address and any prior care-of address. In order to support simultaneous bindings the firewall must be able to interpret Mobile IP registration messages.
但是，这排除了移动节点同时使用绑定的可能性。在防火墙上，移动节点发送的最后一个注册请求将替换其永久地址和任何先前转交地址之间的关联。为了支持同时绑定，防火墙必须能够解释移动IP注册消息。
Section 7.2.2 discusses another advantage of making the firewall understand Mobile IP packet formats.
第7.2.2节讨论了使防火墙理解移动IP数据包格式的另一个优点。
In what follows we assume a SKIP-based solution.
在下面的内容中，我们假设一个基于跳过的解决方案。
Depending on which address it uses as its tunnel endpoint, the Mobile IP protocol specifies two ways in which a mobile node can register a mobility binding with its home agent.
根据使用哪个地址作为其隧道端点，移动IP协议指定了移动节点可以向其归属代理注册移动绑定的两种方式。
a) an address advertised for that purpose by the foreign agent
a) 外国代理人为此目的而公布的地址
b) an address belonging to one of the mobile node's interfaces (i.e. operation with a co-located address).
b) 属于移动节点接口之一的地址（即，使用同一地址的操作）。
From the firewall's point of view, the main difference between these two cases hinges on which node prepares the outermost encrypting encapsulation. The firewall MUST be able to obtain the Diffie-Hellman public component of the node that creates the outermost SKIP header in an incoming packet. This is only possible to guarantee in case "b", because the mobile node and the firewall both belong to the same administrative domain. The problem is even more apparent when the mobile node attempts a Registration Request. Here, the foreign agent is not just a relayer, it actually examines the packet sent by the mobile node, and modifies its agent services accordingly. In short, assuming the current specification of Mobile IP and the current lack of trust in the internet at large, only case "b" is possible. Case "a" would require an extension (e.g. a "relay"
从防火墙的角度来看，这两种情况之间的主要区别取决于哪个节点准备最外层的加密封装。防火墙必须能够获取节点的Diffie-Hellman公共组件，该组件在传入数据包中创建最外层的跳过头。这只能在“b”情况下保证，因为移动节点和防火墙都属于同一管理域。当移动节点尝试注册请求时，问题更加明显。这里，外部代理不仅仅是中继层，它实际上检查移动节点发送的数据包，并相应地修改其代理服务。简言之，假设当前的移动IP规范和当前普遍缺乏对互联网的信任，只有情况“b”是可能的。情况“a”需要扩展（例如“继电器”
Registration Request), and modifying code at the home agent, the firewall and the foreign agent.
注册请求），并在本地代理、防火墙和外部代理处修改代码。
Assuming that the firewall offers a secure relay service (i.e. decapsulation and forwarding of packets), the mobile node can reach addresses internal to the private network by encapsulating the packets in a SKIP header and directing them to the firewall.
假设防火墙提供安全中继服务（即数据包的解除封装和转发），移动节点可以通过将数据包封装在跳过报头中并将其定向到防火墙来到达专用网络内部的地址。
Therefore, It is simplest to assume that the mobile node operates with a co-located address.
因此，最简单的假设是移动节点使用共同定位的地址操作。
The mobile node participates in two different types of traffic: Mobile IP registration protocol and data. For the sake of simplicity, the following discussion evaluates different secure channel configurations by examining the initial Registration Request sent by the mobile node to its home agent.
移动节点参与两种不同类型的流量：移动IP注册协议和数据。为了简单起见，以下讨论通过检查移动节点发送给其归属代理的初始注册请求来评估不同的安全信道配置。
Assuming the mobile node operates with a co-located address, it can communicate directly with the firewall. The latter is able to reach the home agent in the private network. Also, the firewall MUST be able to authenticate the mobile node.
假设移动节点使用同一地址运行，它可以直接与防火墙通信。后者能够到达专用网络中的归属代理。此外，防火墙必须能够对移动节点进行身份验证。
The following channel configurations assume the mobile node operates with a co-located address. The region between the HA (home agent) and the FW (firewall) is a private network. The region between the FW and the MN (mobile node) is the outside or public network.
以下信道配置假定移动节点使用同一地址操作。HA（归属代理）和FW（防火墙）之间的区域是专用网络。FW和MN（移动节点）之间的区域是外部或公共网络。
HA FW MN
<=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
HA FW MN
<=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
The traffic is only encrypted between the mobile node out on the general Internet, and the firewall's external interface. This is minimum required. It is the most desirable configuration as the more expensive encrypted channel is only used where it is necessary: on the public network.
流量仅在通用Internet上的移动节点和防火墙的外部接口之间加密。这是最低要求。这是最理想的配置，因为更昂贵的加密通道仅在必要时使用：在公共网络上。
Another possible configuration extends the encrypted tunnel through the firewall:
另一种可能的配置是通过防火墙扩展加密隧道：
HA FW MN
<===================================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
HA FW MN
<===================================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
This limits the firewall to perform a simple packet relay or gatewaying function. Even though this could be accomplished by using the proper destination NSID in the packet, in practice it is probably unrealizable. The reason is that this alternative is probably not very popular with computer security personnel, because authentication is not carried out by the firewall but by the home agent, and the latter's security is potentially much weaker than the former's.
这限制了防火墙执行简单的数据包中继或网关功能。即使这可以通过在数据包中使用适当的目的地NSID来实现，但在实践中它可能无法实现。原因是，这种替代方案可能不太受计算机安全人员的欢迎，因为身份验证不是由防火墙执行的，而是由归属代理执行的，并且后者的安全性可能比前者弱得多。
A third alternative is to allow the firewall to be party to the security association between the home agent and the mobile node. After verifying authentication (AH header), the firewall forwards the encrypted packet (ESP hdr) to the home agent.
第三种选择是允许防火墙成为归属代理和移动节点之间安全关联的一方。验证身份验证（AH报头）后，防火墙将加密数据包（ESP hdr）转发给归属代理。
HA FW MN
<+++++++++++++++++++++> SKIP authentication
<===================================> SKIP encryption
<-----------------------------------> Registration Request path
HA FW MN
<+++++++++++++++++++++> SKIP authentication
<===================================> SKIP encryption
<-----------------------------------> Registration Request path
Here, SKIP is used to provide intermediate authentication with end-to-end security. Although possible, this option implies that the participating entities disclose their pairwise long-term Diffie-Hellman shared secret to the intermediate node.
这里，SKIP用于提供具有端到端安全性的中间身份验证。尽管可能，但此选项意味着参与实体向中间节点披露其成对长期Diffie-Hellman共享秘密。
Whereas Option 2 above is probably not agreeable to security and system administration personnel, option 3 is unsavory to the end user.
尽管上述选项2可能不符合安全和系统管理人员的要求，但选项3却不符合最终用户的要求。
HA FW MN
<============><=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
HA FW MN
<============><=====================> SKIP (AH + ESP)
<-----------------------------------> Registration Request path
Traffic is encrypted on the public as well as on the private network. On the public network, encryption is dictated by a security association between the mobile node and the firewall. On the private network, it is dictated by a security association between the home
在公共网络和专用网络上对流量进行加密。在公共网络上，加密由移动节点和防火墙之间的安全关联决定。在专用网络上，它由家庭之间的安全关联决定
agent and the firewall.
代理和防火墙。
A potential problem in both options 2 and 3 is that their end-to-end channel components assume that the mobile node and the home agent can exchange IP traffic directly with each other. This is generally not the case, as the Internet routing fabric may not have routes to addresses that belong to private networks, and the private routing fabric may ignore how to route to public addresses -- or doing so may be administratively restricted. Therefore, it is necessary for packets to be addressed directly to the firewall, and indirectly -- via some tunneling or relaying capability -- to the real destination on the other side of the firewall.
选项2和3中的一个潜在问题是，它们的端到端信道组件假定移动节点和归属代理可以直接彼此交换IP流量。通常情况并非如此，因为Internet路由结构可能没有到属于专用网络的地址的路由，并且专用路由结构可能忽略如何路由到公共地址，或者这样做可能受到管理限制。因此，有必要将数据包直接发送到防火墙，并通过某种隧道或中继功能间接发送到防火墙另一端的真实目的地。
Options 1 and 4 are essentially equivalent. The latter may be considered overkill, because it uses encryption even within the private network, and this is generally not necessary. What is necessary even within the private network is for the home agent to add an encapsulation (not necessarily encrypted) so as to direct datagrams to the mobile node via the firewall. The type of encapsulation used determines the difference between options 1 and 4. Whereas option 4 uses SKIP, option 1 uses a cleartext encapsulation mechanism. This is obtainable by, for example, using IP in IP encapsulation [2].
选项1和4基本上是等效的。后者可能被认为是杀伤力过大，因为它甚至在专用网络中使用加密，而这通常是不必要的。即使在专用网络内，归属代理也需要添加封装（不一定加密），以便通过防火墙将数据报定向到移动节点。使用的封装类型决定了选项1和4之间的差异。选项4使用SKIP，选项1使用明文封装机制。例如，可以通过在IP封装中使用IP来实现[2]。
Options 1 and 4 are mostly interchangeable. The difference is, of course, that the former does not protect the data from eavesdroppers within the private network itself. This may be unacceptable in certain cases. Traffic from some departments in a company (for example payroll or legal) may need to be encrypted as it traverses other sections of the company.
选项1和4大部分是可互换的。当然，区别在于前者不能保护数据免受私有网络本身的窃听。在某些情况下，这可能是不可接受的。来自公司某些部门（例如工资或法律部门）的流量可能需要加密，因为它会穿越公司的其他部门。
In the interest of being conservative, in what follows we assume option 4 (i.e. traffic is encrypted on the general Internet, as well as within the private network.
为了保守起见，在下文中，我们假设选项4（即，在通用互联网上以及在专用网络内对流量进行加密）。
Since the firewall is party to the security associations governing encryption on both the public and private networks, it is always able to inspect the traffic being exchanged by the home agent and the mobile node. If this is of any concern, the home agent and mobile node could set up a bi-directional tunnel and encrypt it.
由于防火墙是管理公用和专用网络上加密的安全关联的一方，因此它始终能够检查由归属代理和移动节点交换的流量。如果存在任何问题，则归属代理和移动节点可以设置双向隧道并对其进行加密。
When roaming within a private network, a mobile node sends Registration Requests directly to its home agent. On the public Internet, it MUST encapsulate the original Registration Request in a
当在专用网络内漫游时，移动节点直接向其归属代理发送注册请求。在公共互联网上，它必须将原始注册请求封装在
SKIP packet destined to the firewall. The mobile node MUST distinguish between "inside" and "outside" addresses. This could be accomplished by a set of rules defining the address ranges. Nevertheless, actual installations may present serious difficulties in defining exactly what is a private address and what is not.
跳过发送到防火墙的数据包。移动节点必须区分“内部”和“外部”地址。这可以通过一组定义地址范围的规则来实现。然而，实际安装可能会给准确定义什么是私人地址和什么不是私人地址带来严重困难。
Direct human input is a very effective method: it may be obvious to the user that the current point of attachment is outside its private network, and it should be possible to communicate this knowledge to the mobile node software.
直接人工输入是一种非常有效的方法：用户可能很明显，当前连接点在其专用网络之外，并且应该可以将此知识传达给移动节点软件。
The home agent must also distinguish between "inside" and "outside" addresses, but lacks the potential benefit of direct user input. Accordingly, it should be possible for the mobile node to communicate that knowledge to the home agent. To accomplish this we define a Traversal Extension to the Registration Requests and Replies. This extension is also useful when traversing multiple firewalls.
归属代理还必须区分“内部”和“外部”地址，但缺乏直接用户输入的潜在好处。因此，移动节点应该能够将该知识传达给归属代理。为了实现这一点，我们为注册请求和回复定义了一个遍历扩展。此扩展在穿越多个防火墙时也很有用。
In spite of the above mechanisms, errors in judgement are to be expected. Accordingly, the firewall SHOULD be configured such that it will still perform its relaying duties even if they are unnecessarily required by a mobile node with an inside care-of address.
尽管存在上述机制，但预计会出现判断错误。因此，防火墙应被配置为即使具有内部照管地址的移动节点不必要地需要它们，防火墙仍将执行其中继职责。
Upon arriving at a foreign net and acquiring a care-of address, the mobile node must first -- before any data transfer is possible -- initiate a registration procedure. This consists of an authenticated exchange by which the mobile node informs its home agent of its current whereabouts (i.e. its current care-of address), and receives an acknowledgement. This first step of the protocol is very convenient, because the SKIP firewall can use it to dynamically configure its packet filter.
在到达外网并获得转交地址后，移动节点必须首先——在任何数据传输成为可能之前——启动注册过程。这包括经过身份验证的交换，通过该交换，移动节点通知其归属代理其当前位置（即其当前转交地址），并接收确认。协议的第一步非常方便，因为SKIP防火墙可以使用它动态配置其数据包过滤器。
The remainder of this section shows the packet formats used. Section 7.1 discusses how a mobile node sends a Registration Request to its home agent via the SKIP firewall. Section 7.2 discusses how the home agent send the corresponding Registration Reply to the mobile node. Section 7.3 defines the Traversal Extension for use with Registration Requests and Replies.
本节的其余部分显示了所使用的数据包格式。第7.1节讨论了移动节点如何通过SKIP防火墙向其归属代理发送注册请求。第7.2节讨论归属代理如何向移动节点发送相应的注册回复。第7.3节定义了用于注册请求和回复的遍历扩展。
The mobile node arrives at a foreign net, and using mechanisms defined by Mobile IP, discovers it has moved away from home. It acquires a local address at the foreign site, and composes a Registration Request meant for its home agent. The mobile node must decide whether this packet needs to be processed by SKIP or not.
移动节点到达外网，并使用移动IP定义的机制，发现它已离开家。它在国外站点获取本地地址，并为其国内代理编写注册请求。移动节点必须决定是否需要通过SKIP处理该数据包。
This is not a simple rule triggered by a given destination address. It must be applied whenever the following conditions are met:
这不是由给定的目标地址触发的简单规则。只要满足以下条件，就必须使用：
a) the mobile node is using a care-of address that does not belong to the private network (i.e. the mobile node is currently "outside" its private network), and
a) 移动节点正在使用不属于专用网络的转交地址（即，移动节点当前处于其专用网络的“外部”），并且
b) either of:
b) 以下任一项：
b1) the source address of the packet is the mobile node's home address (e.g. this packet's endpoints are dictated by a connection initiated while at home), or
b1）分组的源地址是移动节点的家庭地址（例如，该分组的端点由在家时启动的连接指示），或者
b2) the source address of the packet is the care-of address and the destination address belongs to the private network
b2）数据包的源地址是转交地址，目的地址属于专用网络
Since the above conditions are mobility related, it is best for the Mobile IP function in the node to evaluate them, and then request the appropriate security services from SKIP.
由于上述条件与移动性相关，因此最好由节点中的移动IP功能对其进行评估，然后向SKIP请求适当的安全服务。
The SKIP module must use the firewall destination address and the firewall's certificate in order to address and encrypt the packet. It encrypts it using SKIP combined with the ESP [6] protocol and possibly the AH [7] protocol.
跳过模块必须使用防火墙目标地址和防火墙证书来寻址和加密数据包。它使用SKIP结合ESP[6]协议和AH[7]协议对其进行加密。
The SKIP header's source NSID equals 1, indicating that the Master Key-ID is the mobile node's home address. Notice that the IP packet's source address corresponds to the care-of address -- an address whose corresponding public component is unknown to the firewall.
跳过头的源NSID等于1，表示主密钥ID是移动节点的主地址。请注意，IP数据包的源地址对应于转交地址——防火墙不知道其对应的公共组件的地址。
It is also possible to use Unsigned Diffie-Hellman public components [10]. Doing so greatly reduces SKIP's infrastructure requirements, because there is no need for a Certificate Authority. Of course, for this to be possible the principals' names MUST be securely communicated.
也可以使用未签名的Diffie-Hellman公共组件[10]。这样做大大降低了SKIP的基础架构需求，因为不需要证书颁发机构。当然，要做到这一点，必须安全地传达委托人的姓名。
REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP): Source mobile node's care-of address Destination firewall's public (outside) address
IP Hdr（跳过）：源移动节点的转交地址目标防火墙的公共（外部）地址
SKIP Hdr: Source NSID = 1 Master Key-ID = IPv4 address of the mobile node Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's care-of address Destination home agent's address
跳过Hdr:源NSID=1主密钥ID=移动节点的IPv4地址目标NSID=0主密钥ID=无内部IP Hdr:源移动节点的转交地址目标归属代理的地址
The SKIP Firewall's dynamic packet filtering uses this information to establish a dynamic binding between the care-of address and the mobile node's permanent home address.
SKIP Firewall的动态数据包过滤使用此信息在转交地址和移动节点的永久家庭地址之间建立动态绑定。
The destination NSID field in the above packet is zero, prompting the firewall to process the SKIP header and recover the internal packet. It then delivers the original packet to another outbound interface, because it is addressed to the home agent (an address within the private network). Assuming secure channel configuration number 4, the firewall encrypts the packet using SKIP before forwarding to the home agent.
上述数据包中的destination NSID字段为零，提示防火墙处理SKIP报头并恢复内部数据包。然后，它将原始数据包传递到另一个出站接口，因为它被寻址到归属代理（专用网络中的一个地址）。假设安全通道配置号为4，防火墙在转发到归属代理之前使用SKIP对数据包进行加密。
REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT
+---------------+----------+----+-----+--------------+--------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
+---------------+----------+----+-----+--------------+--------------+
IP Hdr (SKIP): Source firewall's private (inside) address Destination home agent's address
IP Hdr（跳过）：源防火墙的专用（内部）地址目标归属代理的地址
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's care-of address Destination home agent's address
跳过Hdr：源NSID=0主密钥ID=无目标NSID=0主密钥ID=无内部IP Hdr：源移动节点的转交地址目标归属代理的地址
The home agent processes the Registration Request, and composes a Registration Reply. Before responding, it examines the care-of address reported by the mobile node, and determines whether or not it corresponds to an outside address. If so, the home agent needs to send all traffic back through the firewall. The home agent can
归属代理处理注册请求，并编写注册回复。在响应之前，它检查移动节点报告的转交地址，并确定其是否对应于外部地址。如果是这样，则归属代理需要通过防火墙将所有流量发回。国内代理可以
accomplish this by encapsulating the original Registration Reply in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4).
通过将原始注册回复封装在发送到防火墙的跳过数据包（即，我们假设安全通道配置编号4）中来实现这一点。
The packet from the home agent to the mobile node via the SKIP Firewall has the same format as shown above. The relevant fields are:
通过SKIP防火墙从归属代理到移动节点的数据包具有如上所示的相同格式。相关字段包括：
REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP): Source home agent's address Destination firewall's private (inside) address
IP Hdr（跳过）：源归属代理的地址目标防火墙的专用（内部）地址
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source home agent's address Destination mobile node's care-of address
跳过Hdr：源NSID=0主密钥ID=无目标NSID=0主密钥ID=无内部IP Hdr：源归属代理的地址目标移动节点的转交地址
The SKIP Firewall recovers the original Registration Reply packet and looks at the destination address: the mobile node's care-of address.
跳过防火墙恢复原始注册回复数据包并查看目标地址：移动节点的转交地址。
The SKIP Firewall's dynamic packet filtering used the initial Registration Request (Secton 7.1) to establish a dynamic mapping between the care-of address and the mobile node's Master Key-ID. Hence, before forwarding the Registration Reply, it encrypts it using the mobile node's public component.
SKIP Firewall的动态数据包过滤使用初始注册请求（Secton 7.1）在转交地址和移动节点的主密钥ID之间建立动态映射。因此，在转发注册回复之前，它使用移动节点的公共组件对其进行加密。
This dynamic binding capability and the use of tunneling mode ESP obviate the need to extend the Mobile IP protocol with a "relay Registration Request". However, it requires that the Registration Reply exit the private network through the same firewall that forwarded the corresponding Registration Request.
这种动态绑定功能和隧道模式ESP的使用避免了使用“中继注册请求”扩展移动IP协议的需要。但是，它要求注册回复通过转发相应注册请求的防火墙退出专用网络。
Instead of obtaining the mobile node's permanent address from the dynamic binding, a Mobile IP aware firewall could also obtain it from the Registration Reply itself. This renders the firewall stateless, and lets Registration Requests and Replies traverse the periphery of
移动IP感知防火墙也可以从注册回复本身获取移动节点的永久地址，而不是从动态绑定中获取移动节点的永久地址。这使得防火墙成为无状态的，并允许注册请求和回复穿越防火墙的外围
the private network through different firewalls.
私有网络通过不同的防火墙。
REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE
+---------------+----------+----+-----+--------------+------------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
+---------------+----------+----+-----+--------------+------------+
IP Hdr (SKIP): Source firewall's public (outside) address Destination mobile node's care-of address
IP Hdr（跳过）：源防火墙的公共（外部）地址目标移动节点的转交地址
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 1 Master Key-ID = IPv4 addr of the mobile node Inner IP Hdr: Source home agent's address Destination mobile node's care-of address
跳过Hdr:Source NSID=0主密钥ID=none目标NSID=1主密钥ID=IPv4地址移动节点内部IP Hdr:Source home agent的地址目标移动节点的转交地址
The Traversal Extension MAY be included by mobile nodes in Registration Requests, and by home agents in Registration Replies. As per Section 3.6.1.3 of [1], the Traversal Extension must appear before the Mobile-Home Authentication Extension. A Traversal Extension is an explicit notification that there are one or more traversal points (firewalls, fireridges, etc) between the mobile node and its home agent. Negotiating access past these systems may imply a new authentication header, and possibly a new encapsulating header (perhaps as part of tunnel-mode ESP) whose IP destination address is the traversal address.
移动节点可以在注册请求中包括遍历扩展，而归属代理可以在注册回复中包括遍历扩展。根据[1]第3.6.1.3节，遍历扩展必须出现在移动家庭认证扩展之前。遍历扩展是一种显式通知，表明移动节点与其归属代理之间存在一个或多个遍历点（防火墙、Fireridge等）。通过这些系统协商访问可能意味着一个新的身份验证报头，也可能意味着一个新的封装报头（可能作为隧道模式ESP的一部分），其IP目标地址是遍历地址。
Negotiating access past traversal points does not necessarily require cryptographic techniques. For example, systems at the boundary between separate IP address spaces must be explicitly targetted (perhaps using unencrypted IP in IP encapsulation).
通过遍历点协商访问不一定需要密码技术。例如，位于独立IP地址空间之间边界的系统必须明确定位（可能在IP封装中使用未加密的IP）。
A mobile node SHOULD include one Traversal Extension per traversal point in its Registration Requests. If present, their order MUST exactly match the order in which packets encounter them as they flow from the mobile node towards the home agent.
移动节点应在其注册请求中为每个遍历点包含一个遍历扩展。如果存在，它们的顺序必须与数据包从移动节点流向归属代理时遇到它们的顺序完全匹配。
Notice that there may be additional firewalls along the way, but the list of traversal points SHOULD only include those systems with which an explicit negotiation is required.
请注意，沿途可能会有其他防火墙，但遍历点列表应该只包括那些需要显式协商的系统。
Similarly, the home agent SHOULD include one Traversal Extension per traversal point in its Registration Replies. If present, their order MUST exactly match the order in which packets encounter them as they flow from the home agent to the mobile node.
类似地，归属代理应在其注册回复中为每个遍历点包含一个遍历扩展。如果存在，它们的顺序必须与数据包从归属代理流向移动节点时遇到它们的顺序完全匹配。
A Traversal Extension does not include any indication about how access is negotiated. Presumably, this information is obtained through separate means. This document does not attempt to solve the firewall discovery problem, that is, it does not specify how to discover the list of traversal points.
遍历扩展不包括关于如何协商访问的任何指示。据推测，这些信息是通过单独的方式获得的。本文档并不试图解决防火墙发现问题，也就是说，它没有指定如何发现遍历点列表。
As per section 1.9 of [1], the fact that the type value falls within the range 128 to 255 implies that if a home agent or a mobile node encounter a Traversal Extension in a Registration Request or Reply, they may silently ignore it. This is consistent with the fact that the Traversal Extension is essentially a hint.
根据[1]的第1.9节，类型值在128到255范围内的事实意味着，如果归属代理或移动节点在注册请求或回复中遇到遍历扩展，它们可能会默默地忽略它。这与遍历扩展本质上是一个提示这一事实是一致的。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN to HA Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA to MN Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN to HA Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA to MN Traversal Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
129
129
Length
长
10
10
Reserved
含蓄的
0
0
MN to HA Traversal Address
MN到HA遍历地址
The IP address of the an intermediate system or firewall encountered by datagrams sent by the mobile node towards the home agent. Typically, this is the external address of a firewall or firewall complex.
移动节点向归属代理发送的数据报遇到的中间系统或防火墙的IP地址。通常，这是防火墙或防火墙复合体的外部地址。
This field MUST be initialized in Registration Requests. In Registration Replies, it is typically all 0's, otherwise, the mobile node SHOULD interpret it as a hint.
必须在注册请求中初始化此字段。在注册回复中，通常都是0，否则，移动节点应将其解释为提示。
HA to MN Traversal Address
HA到MN遍历地址
The IP address of an intermediate system or firewall encountered by datagrams sent by the home agent towards the mobile node. Typically, this is the internal address of a firewall or firewall complex.
归属代理向移动节点发送的数据报遇到的中间系统或防火墙的IP地址。通常，这是防火墙或防火墙复合体的内部地址。
This field MUST be initialized in Registration Replies. In Registration Requests, it is typically all 0's, otherwise, the home agent SHOULD interpret it as a hint.
必须在注册回复中初始化此字段。在注册请求中，通常都是0，否则，归属代理应将其解释为提示。
Data transfer proceeds along lines similar to the Registration Request outlined above. Section 8.1 discusses data traffic sent by a mobile node to a correspondent node. Section 8.2 shows packet formats for the reverse traffic being tunneled by the home agent to the mobile node.
数据传输过程与上述注册请求类似。第8.1节讨论了移动节点发送到对应节点的数据流量。第8.2节显示了由归属代理通过隧道传输到移动节点的反向流量的数据包格式。
The mobile node composes a packet destined to a correspondent node located within the private network.
移动节点构成目的地为位于专用网络内的对应节点的分组。
The Mobile IP function in the mobile node examines the Inner IP header, and determines that it satisfies conditions "a" and "b1" from Section 7.1. The mobile node requests the proper encryption and encapsulation services from SKIP.
移动节点中的移动IP功能检查内部IP报头，并确定其满足第7.1节中的条件“a”和“b1”。移动节点向SKIP请求正确的加密和封装服务。
Thus, the mobile node with a co-located address sends encrypted traffic to the firewall, using the following format:
因此，具有共同定位地址的移动节点使用以下格式向防火墙发送加密通信量：
DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL
+---------------+----------+----+-----+--------------+------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
+---------------+----------+----+-----+--------------+------+
DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL
+---------------+----------+----+-----+--------------+------+
| IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP |
+---------------+----------+----+-----+--------------+------+
IP Hdr (SKIP): Source mobile node's care-of address Destination public (outside) address on the firewall
IP Hdr（跳过）：防火墙上源移动节点的转交地址目标公共（外部）地址
SKIP Hdr: Source NSID = 1 Master Key-ID = IPv4 address of the mobile node Destination NSID = 0 Master Key-ID = none Inner IP Hdr: Source mobile node's home address Destination correspondent node's address
跳过Hdr:源NSID=1主密钥ID=移动节点的IPv4地址目标NSID=0主密钥ID=无内部IP Hdr:源移动节点的家庭地址目标对应节点的地址
The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr and upper-layer payload (ULP) and checks the destination address. Since the packet is destined to a correspondent node in the private network, the "Inner" IP datagram is delivered internally. Once the SKIP firewall injects this packet into the private network, it is routed independently of its source address.
跳过防火墙拦截此数据包，解密内部IP Hdr和上层有效负载（ULP），并检查目标地址。由于包的目的地是专用网络中的对应节点，“内部”IP数据报在内部传递。跳过防火墙将此数据包注入专用网络后，它将独立于其源地址进行路由。
As this last assumption is not always true, the mobile node may construct a bi-directional tunnel with its home agent. Doing so, guarantees that the "Inner IP Hdr" is:
由于最后一个假设并不总是正确的，移动节点可以与其归属代理构建双向隧道。这样做可确保“内部IP Hdr”为：
Inner IP Hdr: Source care-of address Destination home agent address
内部IP Hdr：源转交地址目标归属代理地址
When at home, communication between the the mobile node and certain external correspondent nodes may need to go through application-specific firewalls or proxies, different from the SKIP firewall. While on the public network, the mobile node's communication with these hosts, MUST use a bi-directional tunnel.
在家时，移动节点和某些外部对应节点之间的通信可能需要通过特定于应用程序的防火墙或代理，这与跳过防火墙不同。在公共网络上，移动节点与这些主机的通信必须使用双向隧道。
The home agent intercepts a packet from a correspondent node to the mobile node. It encapsulates it such that the Mobile IP encapsulating IP header's source and destination addresses are the home agent and care-of addresses, respectively. This would suffice for delivery within the private network. Since the current care-of address of the mobile node is not within the private network, this packet MUST be sent via the firewall. The home agent can accomplish this by encapsulating the datagram in a SKIP packet destined to the firewall (i.e. we assume secure channel configuration number 4).
归属代理截获从对应节点到移动节点的分组。它对其进行封装，使得封装IP报头的源地址和目标地址的移动IP分别是归属代理和转交地址。这就足以在专用网络内交付。由于移动节点的当前转交地址不在专用网络内，因此必须通过防火墙发送此数据包。归属代理可以通过将数据报封装在发送到防火墙的跳过数据包中来实现这一点（即，我们假设安全通道配置编号4）。
From the home agent to the private (inside) address of the firewall the packet format is:
从归属代理到防火墙的专用（内部）地址，数据包格式为：
DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP): Source home agent's address Destination private (inside) address on the firewall
IP Hdr（跳过）：防火墙上源归属代理的地址目标专用（内部）地址
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 0 Master Key-ID = none
跳过Hdr：源NSID=0主密钥ID=无目标NSID=0主密钥ID=无
Mobile-IP IP Hdr: Source home agent's address Destination care-of address
移动IP Hdr：源归属代理的地址目的地转交地址
Inner IP Hdr: Source correspondent node's address Destination mobile node's address
内部IP Hdr：源对应节点的地址目标移动节点的地址
ULP: upper-layer payload
ULP：上层有效载荷
The packet format above does not require the firewall to have a dynamic binding. The association between the mobile node's permanent address and it care-of address can be deduced from the contents of the "Mobile-IP IP Hdr" and the "Inner IP Hdr".
上面的数据包格式不要求防火墙具有动态绑定。从“移动IP Hdr”和“内部IP Hdr”的内容可以推断出移动节点的永久地址和it转交地址之间的关联。
Nevertheless, a nomadic binding is an assurance that currently the mobile node is, in fact, at the care-of address.
然而，游牧绑定保证了当前移动节点实际上由地址管理。
The SKIP firewall intercepts the packet, and recovers the Mobile IP encapsulated datagram. Before sending it out, the dynamic packet filter configured by the original Registration Request triggers encryption of this packet, this time by the SKIP firewall for consumption by the mobile node. The resultant packet is:
跳过防火墙拦截数据包，并恢复移动IP封装的数据报。在发送数据包之前，由原始注册请求配置的动态数据包过滤器会触发该数据包的加密，这次由跳过防火墙触发，以供移动节点使用。生成的数据包是：
DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE
+--------+------+----+-----+--------+--------+-----+
| IP Hdr | SKIP | AH | ESP | mobip | Inner | ULP |
| (SKIP) | Hdr | | | IP Hdr | IP Hdr | |
+--------+------+----+-----+--------+--------+-----+
IP Hdr (SKIP): Source firewall's public (outside) address Destination mobile node's care-of address
IP Hdr（跳过）：源防火墙的公共（外部）地址目标移动节点的转交地址
SKIP Hdr: Source NSID = 0 Master Key-ID = none Destination NSID = 1 Master Key-ID = IPv4 address of the mobile node
跳过Hdr：源NSID=0主密钥ID=无目标NSID=1主密钥ID=移动节点的IPv4地址
Mobile-IP IP Hdr: Source home agent's address Destination care-of address
移动IP Hdr：源归属代理的地址目的地转交地址
Inner IP Hdr: Source correspondent node's address Destination mobile node's address
内部IP Hdr：源对应节点的地址目标移动节点的地址
ULP: upper-layer payload
ULP：上层有效载荷
At the mobile node, SKIP processes the packets sent by the firewall. Eventually, the inner IP header and the upper-layer packet (ULP) are retrieved and passed on.
在移动节点，SKIP处理防火墙发送的数据包。最终，检索并传递内部IP报头和上层数据包（ULP）。
The topic of this document is security. Nevertheless, it is imperative to point out the perils involved in allowing a flow of IP packets through a firewall. In essence, the mobile host itself MUST also take on responsibility for securing the private network, because it extends its periphery. This does not mean it stops exchanging unencrypted IP packets with hosts on the public network. For example, it MAY have to do so in order to satisfy billing requirements imposed by the foreign site, or to renew its DHCP lease.
本文档的主题是安全性。然而，必须指出允许IP数据包通过防火墙所涉及的危险。本质上，移动主机本身也必须承担保护专用网络的责任，因为它扩展了其外围。这并不意味着它停止与公共网络上的主机交换未加密的IP数据包。例如，它可能必须这样做，以满足外国网站强加的计费要求，或续订其DHCP租约。
In the latter case it might filter not only on IP source address, but also on protocol and port numbers.
在后一种情况下，它可能不仅过滤IP源地址，还过滤协议和端口号。
Therefore, it MUST have some firewall capabilities, otherwise, any malicious individual that gains access to it will have gained access to the private network as well.
因此，它必须具有一些防火墙功能，否则，任何恶意个人获得访问它的权限也将获得访问专用网络的权限。
Acknowledgements
致谢
Ideas in this document have benefited from discussions with at least the following people: Bill Danielson, Martin Patterson, Tom Markson, Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash Agrawal, Tsutomu Shimomura and Don Hoffman. Jim Solomon has also provided many helpful comments on this document.
本文件中的想法至少得益于与以下人士的讨论：比尔·丹尼尔森、马丁·帕特森、汤姆·马克森、里奇·斯克伦塔、阿特苏希·新博、贝法尔·拉扎维、阿维纳什·阿格拉瓦尔、岛村津和唐·霍夫曼。Jim Solomon还就本文件提供了许多有用的意见。
References
工具书类
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[3] A. Aziz and M. Patterson, Design and Implementation of SKIP, available on-line at http://skip.incog.com/inet-95.ps. A previous version of the paper was presented at INET '95 under the title Simple Key Management for Internet Protocols (SKIP), and appears in the conference proceedings under that title.
[3] A.Aziz和M.Patterson，SKIP的设计和实现，可在线访问http://skip.incog.com/inet-95.ps. 该论文的前一个版本在INET'95上以互联网协议的简单密钥管理（SKIP）的标题发表，并以该标题出现在会议记录中。
[4] Leech, M., Ganis, M., Lee, Y, Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[4] Leech，M.，Ganis，M.，Lee，Y，Kuris，R.，Koblas，D.，和L.Jones，“SOCKS协议版本5”，RFC 19281996年3月。
[5] Leech, M., "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996.
[5] Leech，M.，“SOCKS V5的用户名/密码验证”，RFC 1929，1996年3月。
[6] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995.
[6] 阿特金森，R.，“IP封装有效载荷”，RFC 1827，1995年8月。
[7] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[7] 阿特金森，R.，“IP认证头”，RFC 1826，1995年8月。
[8] Stephen Kent, message to the IETF's IPSEC mailing list, Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September 6, 1996.
[8] Stephen Kent，发送给IETF IPSEC邮件列表的消息，消息Id:<V0213050AE569A3E904E@[128.89.30.29]>，1996年9月6日。
[9] Tom Markson, private communication, June 12, 1996.
[9] 汤姆·马克森，《私人通讯》，1996年6月12日。
[10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an Unsigned Diffie-Hellman Public Value. Available on-line as http://skip.incog.com/spec/EUDH.html.
[10] A.阿齐兹、T.马克森、H.普拉富钱德拉。无符号Diffie-Hellman公共值的编码。网上提供http://skip.incog.com/spec/EUDH.html.
Authors' Addresses
作者地址
Gabriel E. Montenegro Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
加布里埃尔E.黑山太阳微系统公司，加利福尼亚州山景城圣安东尼奥路901号邮递站UMPK 15-214 94303
Phone: (415)786-6288 Fax: (415)786-6445 EMail: gabriel.montenegro@Eng.Sun.COM
电话：（415）786-6288传真：（415）786-6445电子邮件：加布里埃尔。montenegro@Eng.Sun.COM
Vipul Gupta Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303
Vipul Gupta Sun Microsystems，Inc.加利福尼亚州山景城圣安东尼奥路901号邮递站UMPK 15-214 94303
Phone: (415)786-3614 Fax: (415)786-6445 EMail: vipul.gupta@Eng.Sun.COM
电话：（415）786-3614传真：（415）786-6445电子邮件：vipul。gupta@Eng.Sun.COM
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。