Network Working Group V. Devarapalli
Request for Comments: 5266 Wichorus
BCP: 136 P. Eronen
Category: Best Current Practice Nokia
June 2008
Network Working Group V. Devarapalli
Request for Comments: 5266 Wichorus
BCP: 136 P. Eronen
Category: Best Current Practice Nokia
June 2008
Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
使用移动IPv4和IKEv2移动和多址（MOBIKE）实现安全连接和移动
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.
企业用户在漫游和连接到企业提供的服务时需要移动性和安全连接。当用户从不受信任的网络连接到企业时，需要安全连接。当用户在企业网络内部或外部移动并获得新的IP地址时，移动性是有益的。本文档描述了一种使用移动IPv4（MIPv4）和IKEv2移动扩展（MOBIKE）提供安全连接和移动的解决方案。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.2. Operation When Moving from a Trusted Network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Applicability to a Mobile Operator Network . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.2. Operation When Moving from a Trusted Network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Applicability to a Mobile Operator Network . . . . . 13
A typical enterprise network consists of users connecting to the services from a trusted network (intranet), and from an untrusted network (Internet). The trusted and untrusted networks are typically separated by a demilitarized zone (DMZ). Access to the intranet is controlled by a firewall and a Virtual Private Network (VPN) gateway in the DMZ.
典型的企业网络由从可信网络（intranet）和不可信网络（Internet）连接到服务的用户组成。受信任和不受信任的网络通常由非军事区（DMZ）分隔。内联网的访问由DMZ中的防火墙和虚拟专用网（VPN）网关控制。
Enterprise users, when roaming on untrusted networks, most often have to authenticate themselves to the VPN gateway and set up a secure tunnel in order to access the intranet. The use of IPsec VPNs is very common to enable such secure connectivity to the intranet. When the user is on the trusted network, VPNs are not used. However, the users benefit tremendously when session mobility between subnets, through the use of Mobile IPv4, is available.
企业用户在不受信任的网络上漫游时，通常必须向VPN网关验证自己的身份，并设置一个安全隧道才能访问intranet。IPsec VPN的使用非常常见，可以实现与intranet的这种安全连接。当用户位于受信任网络上时，不会使用VPN。然而，当通过使用移动IPv4实现子网之间的会话移动时，用户将受益匪浅。
There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [RFC5265] [RFC4093]. The solution described in [RFC5265] was designed with certain restrictions, including requiring no modifications to the VPN gateways, and involves the use of two layers of MIPv4, with one home agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node. However, the solution described here is only applicable when Internet Key Exchange Protocol version 2 (IKEv2) IPsec VPNs are used.
在使用移动IPv4和IPsec VPN向企业提供漫游和安全连接方面已经做了一些工作[RFC5265][RFC4093]。[RFC5265]中描述的解决方案在设计时有一定的限制，包括不需要修改VPN网关，并且涉及使用两层MIPv4，一层在内部网中，另一层在Internet中或VPN网关之前的DMZ中。在这个解决方案中，每个数据包的开销非常高。在移动节点上同时实现和激活两个MIPv4实例也是一个挑战。但是，此处描述的解决方案仅适用于使用Internet密钥交换协议版本2（IKEv2）IPsec VPN的情况。
This document describes an alternate solution that does not require two layers of MIPv4. The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted network. The mobile node uses the tunnel inner address (TIA) given out by the IPsec VPN gateway as the co-located care-of address (CoA) for MIPv4 registration. This eliminates the need for using an external MIPv4 home agent and the need for encapsulating the VPN tunnel inside a MIPv4 tunnel.
本文档介绍了一种不需要两层MIPv4的替代解决方案。本文档中描述的解决方案在移动节点位于受信任网络上时使用移动IPv4，在移动节点位于不受信任网络上时使用支持MOBIKE的IPsec VPN。移动节点使用IPsec VPN网关给出的隧道内部地址（TIA）作为用于MIPv4注册的同址转交地址（CoA）。这样就不需要使用外部MIPv4主代理，也不需要将VPN隧道封装在MIPv4隧道中。
The following assumptions are made for the solution described in this document.
针对本文件中描述的解决方案，做出以下假设。
o IKEv2 [RFC4306] and IPsec [RFC4301] are used to set up the VPN tunnels between the mobile node and the VPN gateway.
o IKEv2[RFC4306]和IPsec[RFC4301]用于在移动节点和VPN网关之间建立VPN隧道。
o The VPN gateway and the mobile node support MOBIKE extensions as defined in [RFC4555].
o VPN网关和移动节点支持[RFC4555]中定义的MOBIKE扩展。
o When the mobile node is on the trusted network, traffic should not go through the DMZ. Current deployments of firewalls and DMZs consider the scenario where only a small amount of the total enterprise traffic goes through the DMZ. Routing through the DMZ typically involves stateful inspection of each packet by the firewalls in the DMZ. Moreover, the DMZ architecture assumes that the DMZ is less secure than the internal network. Therefore, the DMZ-based architecture allows the least amount of traffic to traverse the DMZ, that is, only traffic between the trusted network and the external network. Requiring all normal traffic to the mobile nodes to traverse the DMZ would negate this architecture.
o 当移动节点位于受信任网络上时，流量不应通过DMZ。防火墙和DZZ的当前部署考虑了只有少量企业流量通过DMZ的场景。通过DMZ的路由通常涉及DMZ中防火墙对每个数据包的状态检查。此外，DMZ体系结构假定DMZ的安全性低于内部网络。因此，基于DMZ的体系结构允许通过DMZ的通信量最少，即仅允许受信任网络和外部网络之间的通信量。要求移动节点的所有正常流量通过DMZ将否定这种体系结构。
o When the mobile node is on the trusted network and uses a wireless access technology, confidentiality protection of the data traffic is provided by the particular access technology. In some networks, confidentiality protection MAY be available between the mobile node and the first hop access router, in which case it is not required at layer 2.
o 当移动节点位于可信网络上并且使用无线接入技术时，数据业务的机密性保护由特定接入技术提供。在一些网络中，可以在移动节点和第一跳接入路由器之间提供保密保护，在这种情况下，在第2层不需要保密保护。
This document also presents a solution for the mobile node to detect when it is on a trusted network, so that the IPsec tunnel can be dropped and the mobile node can use Mobile IP in the intranet.
本文档还为移动节点提供了一种解决方案，以检测其何时位于受信任网络上，从而可以丢弃IPsec隧道，并且移动节点可以在intranet中使用移动IP。
IPsec VPN gateways that use IKEv1 [RFC2409] are not addressed in this document.
使用IKEv1[RFC2409]的IPsec VPN网关不在本文档中介绍。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Many of the following terms are defined in [RFC5265], but are repeated here to make this document self-contained.
[RFC5265]中定义了以下许多术语，但在此处重复这些术语是为了使本文件完整。
FA: Mobile IPv4 foreign agent.
FA：移动IPv4外部代理。
Co-CoA: co-located care-of address.
共同CoA：共同托管地址。
FA-CoA: foreign agent care-of address.
FA CoA：外国代理人转交地址。
FW: firewall.
防火墙。
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) network.
i-FA：驻留在受信任（intranet）网络中的移动IPv4外部代理。
i-HA: Mobile IPv4 home agent residing in the trusted (intranet) network.
i-HA：驻留在受信任（intranet）网络中的移动IPv4归属代理。
i-MIP: The mobile node uses the home agent in the internal network.
i-MIP：移动节点在内部网络中使用归属代理。
VPN-TIA: VPN tunnel inner address. This address is given out by the VPN gateway during IKE negotiation and is routable in the trusted network.
VPN-TIA:VPN隧道内部地址。该地址在IKE协商期间由VPN网关给出，可在可信网络中路由。
mVPN: VPN with MOBIKE functionality.
mVPN：具有MOBIKE功能的VPN。
The following access modes are used in explaining the protocol. The access modes are explained in more detail in [RFC5265].
以下访问模式用于解释协议。访问模式在[RFC5265]中有更详细的说明。
f: i-MIP with FA-CoA
f:i-MIP和FA-CoA
c: i-MIP with Co-CoA
c:i-MIP联合辅酶A
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
mc:i-MIP，支持MOBIKE的VPN，VPN-TIA作为共同CoA
The mobile node is configured with a home address that remains the same irrespective of whether the mobile node is inside or outside the enterprise network. The mobile node is also reachable at the same home address irrespective of its current point of attachment. When the mobile node is connected to the intranet directly, it uses Mobile IP for internal mobility.
移动节点被配置为具有保持不变的归属地址，而不管移动节点是在企业网络内部还是外部。无论移动节点的当前连接点如何，移动节点也可在相同的家庭地址处到达。当移动节点直接连接到intranet时，它使用移动IP进行内部移动。
When the mobile node roams and connects to an untrusted network outside the enterprise, it sets up a VPN tunnel to the VPN gateway. However, it still maintains a valid binding cache entry at the i-HA. It uses the VPN-TIA, allocated by the VPN gateway, as the co-located CoA for registration with the i-HA. If the VPN-TIA changes or if the mobile node moves and connects to another VPN gateway, then it sends a Registration Request to the i-HA using the new co-located CoA.
当移动节点漫游并连接到企业外部不受信任的网络时，它会建立一个到VPN网关的VPN隧道。但是，它仍然在i-HA上维护一个有效的绑定缓存项。它使用VPN网关分配的VPN-TIA作为同一位置的CoA，用于向i-HA注册。如果VPN-TIA发生变化，或者如果移动节点移动并连接到另一个VPN网关，则它将使用新的同址CoA向i-HA发送注册请求。
If the mobile node moves while outside the enterprise and its access network changes, it uses the MOBIKE protocol to update the VPN gateway of its current address. The internal home agent is not aware of the mobile node's movement as long as the mobile node is attached to the same VPN gateway and the TIA remains the same.
如果移动节点在企业外部移动且其接入网络发生变化，则它将使用MOBIKE协议更新其当前地址的VPN网关。只要移动节点连接到同一VPN网关且TIA保持不变，内部归属代理就不会知道移动节点的移动。
Figure 1 depicts the network topology assumed for the solution. It also shows the possible mobile node locations and access modes.
图1描述了为解决方案假设的网络拓扑。它还显示了可能的移动节点位置和访问模式。
{home} (MN) [i-HA]
\ /
.-+---+-.
( )
[mVPN] `--+----'
! !
.--+--. [R]
( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
{home} (MN) [i-HA]
\ /
.-+---+-.
( )
[mVPN] `--+----'
! !
.--+--. [R]
( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
Figure 1: Network Topology Using MIPv4 and MOBIKE
图1：使用MIPv4和MOBIKE的网络拓扑
The solution described above results in a Mobile IP tunnel inside an IPsec tunnel. The Mobile IP tunnel is between the mobile node and the home agent, and the IPsec tunnel is between the mobile node (MN) and the mVPN gateway. The mobile node MUST reverse tunnel through the home agent [RFC3024] when the Mobile IP tunnel is inside an IPsec tunnel.
上述解决方案在IPsec隧道内产生移动IP隧道。移动IP隧道位于移动节点和归属代理之间，IPsec隧道位于移动节点（MN）和mVPN网关之间。当移动IP隧道位于IPsec隧道内时，移动节点必须通过归属代理[RFC3024]反向隧道。
The overhead of running a Mobile IP tunnel inside an IPsec tunnel can be avoided by having the Mobile IP foreign agent functionality on the VPN gateway. This is out of scope for this document and is further described in [MEGHANA].
通过在VPN网关上具有移动IP外部代理功能，可以避免在IPsec隧道内运行移动IP隧道的开销。这超出了本文件的范围，并在[MEGHANA]中作了进一步说明。
Whenever the mobile node attaches to a new link, it may encounter a foreign agent. The mobile node MUST not use the foreign agent care-of address with the i-HA when attached to an untrusted access network. The default behavior for the mobile node is to always configure an address from the access link using DHCP. The mobile node then checks if it is attached to a trusted access network by sending a Registration Request to the i-HA in the co-located care-of address mode. If the mobile node discovers that it is attached to a trusted access network, then it MAY start using a foreign agent care-of address with the i-HA. In order to do this, the mobile node has to perform a new registration with the i-HA.
每当移动节点连接到新链路时，它可能会遇到外部代理。当连接到不受信任的接入网络时，移动节点不得使用具有i-HA的外部代理转交地址。移动节点的默认行为是始终使用DHCP从访问链路配置地址。然后，移动节点通过在同一位置的转交地址模式下向i-HA发送注册请求来检查其是否连接到可信接入网络。如果移动节点发现它连接到可信接入网络，那么它可以开始使用i-HA的外部代理转交地址。为了做到这一点，移动节点必须向i-HA执行新的注册。
The mobile node can use a foreign agent on a untrusted access network, if there is an external home agent that the mobile node is able to use. The use of an external home agent in the untrusted access network and a home agent in the trusted access network at the same time is described in detail in [RFC5265].
如果存在移动节点能够使用的外部归属代理，则移动节点可以在不受信任的接入网络上使用外部代理。[RFC5265]中详细描述了在不可信接入网络中同时使用外部归属代理和在可信接入网络中同时使用归属代理。
Some IPsec VPN implementations allow a host to send traffic directly to the Internet when attached to an untrusted network. This traffic bypasses the IPsec tunnel with the VPN gateway. This document does not prevent such traffic from being sent out from the host, but there will be no mobility or session continuity for the traffic. Any data traffic that is sent through the Mobile IP tunnel with the home agent is always sent through the VPN gateway.
某些IPsec VPN实现允许主机在连接到不受信任的网络时直接向Internet发送流量。此流量通过VPN网关绕过IPsec隧道。本文档不阻止从主机发送此类流量，但不会为流量提供移动性或会话连续性。通过移动IP隧道与归属代理发送的任何数据流量始终通过VPN网关发送。
The following access modes are used in the solution described in this document.
本文档中描述的解决方案使用以下访问模式。
This access mode is standard Mobile IPv4 [RFC3344] with a co-located care-of address. The mobile node must detect that it is connected to an internal trusted network before using this mode. The co-located care-of address is assigned by the access network to which the mobile node is attached.
此访问模式为标准移动IPv4[RFC3344]，具有同一位置的转交地址。在使用此模式之前，移动节点必须检测到它已连接到内部可信网络。同一位置的转交地址由移动节点所连接的接入网络分配。
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address. The mobile node can use this mode only when it detects that it is connected to an internal trusted network and also detects a foreign agent on the access network.
此访问模式为标准移动IPv4[RFC3344]，具有外部代理转交地址。移动节点仅当检测到其连接到内部可信网络并且还检测到接入网络上的外部代理时，才可以使用此模式。
This access mode involves using both Mobile IPv4 and a MOBIKE-enabled IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec tunnel. The mobile node uses the VPN-TIA as the co-located CoA for registering with the home agent. This mode is used only when the mobile node is attached to an untrusted network and is required to set up an IPsec tunnel with a VPN gateway to gain access to the trusted network.
此访问模式涉及同时使用移动IPv4和启用MOBIKE的IPsec VPN网关，从而在IPsec隧道内形成移动IP隧道。移动节点使用VPN-TIA作为共同定位的CoA，用于向归属代理注册。此模式仅在移动节点连接到不受信任的网络并且需要使用VPN网关设置IPsec隧道以访问受信任的网络时使用。
When the mobile node is inside the enterprise network and attached to the intranet, it uses Mobile IPv4 [RFC3344] for subnet mobility. The mobile node always configures a care-of address through DHCP on the access link and uses it as the co-located care-of address. The mobile node MAY use a foreign agent care-of address, if a foreign agent is available. However, the foreign agent care-of address is used only when the mobile node is attached to the trusted access network. The mobile node attempts Foreign Agent discovery and CoA address acquisition through DHCP simultaneously in order to avoid the delay in discovering a foreign agent when there is no foreign agent available. The mobile node maintains a valid binding cache entry at all times at the home agent mapping the home address to the current CoA. Whenever the mobile node moves, it sends a Registration Request to update the binding cache entry.
当移动节点位于企业网络内部并连接到intranet时，它使用移动IPv4[RFC3344]进行子网移动。移动节点始终通过访问链路上的DHCP配置转交地址，并将其用作同一位置的转交地址。如果外部代理可用，则移动节点可以使用外部代理转交地址。然而，只有当移动节点连接到可信接入网络时，才使用外部代理转交地址。移动节点同时尝试通过DHCP发现外部代理和获取CoA地址，以避免在没有外部代理可用时发现外部代理的延迟。移动节点始终在归属代理处维护有效的绑定缓存条目，将归属地址映射到当前CoA。每当移动节点移动时，它都会发送一个注册请求来更新绑定缓存条目。
The Mobile IP signaling messages between the mobile node and the home agent are authenticated as described in [RFC3344].
移动节点和归属代理之间的移动IP信令消息按照[RFC3344]中所述进行认证。
The mobile node maintains a valid binding cache entry at the home agent even when it is outside the enterprise network.
移动节点在归属代理中维护有效的绑定缓存条目，即使它位于企业网络之外。
When the mobile node is attached to an untrusted network, it sets up an IPsec VPN tunnel with the VPN gateway to gain access to the enterprise network. If the mobile node moves and its IP address changes, it initiates the MOBIKE protocol [RFC4555] to update the address on the VPN gateway.
当移动节点连接到不受信任的网络时，它会使用VPN网关设置IPsec VPN隧道以访问企业网络。如果移动节点移动且其IP地址更改，则会启动MOBIKE协议[RFC4555]以更新VPN网关上的地址。
The mobile node maintains a binding at the home agent even when it is outside the enterprise network. If the TIA changes due to the mobile node re-connecting to the VPN gateway or attaching to a different VPN gateway, the mobile node should send a Registration Request to its home agent to update the binding cache with the new TIA.
移动节点在归属代理上保持绑定，即使它在企业网络之外。如果由于移动节点重新连接到VPN网关或连接到不同的VPN网关而导致TIA发生变化，则移动节点应向其归属代理发送注册请求，以使用新的TIA更新绑定缓存。
Security boundary detection is based on the reachability of the i-HA from the mobile node's current point of attachment. Whenever the mobile node detects a change in network connectivity, it sends a Registration Request to the i-HA without any VPN encapsulation. If the mobile node receives a Registration Reply with the Trusted Networks Configured (TNC) extension from the i-HA, then it assumes that it is on a trusted network. The TNC extension is described in [RFC5265]. The mobile node MUST check that the Registration Reply is integrity protected using the mobile node-home agent mobility
安全边界检测基于i-HA从移动节点的当前连接点的可达性。每当移动节点检测到网络连接发生变化时，它都会向i-HA发送注册请求，而不进行任何VPN封装。如果移动节点从i-HA接收到具有可信网络配置（TNC）扩展的注册应答，则它假定它位于可信网络上。[RFC5265]中描述了TNC扩展。移动节点必须使用移动节点归属代理移动来检查注册回复是否受到完整性保护
security association before concluding it is attached to a trusted network. This security boundary detection is based on the mechanism described in [RFC5265] to detect attachment to the internal trusted network. The mobile node should re-transmit the Registration Request if it does not receive the Registration Reply within a timeout period. The number of times the mobile node should re-transmit the Registration Request and the timeout period for receiving the Registration Reply are configurable on the mobile node.
安全关联，然后将其连接到受信任的网络。此安全边界检测基于[RFC5265]中描述的机制，用于检测与内部可信网络的连接。如果移动节点在超时时间内未收到注册回复，则应重新发送注册请求。移动节点应重新发送注册请求的次数和接收注册回复的超时时间可在移动节点上配置。
When the mobile node is attached to an untrusted network and is using an IPsec VPN to the enterprise network, the ability to send a Registration Request to the i-HA without VPN encapsulation would require some interaction between the IPsec and MIPv4 modules on the mobile node. This is local to the mobile node and out of scope for this document.
当移动节点连接到不受信任的网络并使用IPsec VPN连接到企业网络时，在不封装VPN的情况下向i-HA发送注册请求的能力需要移动节点上的IPsec和MIPv4模块之间进行一些交互。这是移动节点本地的，不在本文档的范围内。
If the mobile node has an existing VPN tunnel to its VPN gateway, it MUST send a MOBIKE message at the same time as the registration request to the i-HA whenever the IP address changes. If the mobile node receives a response from the VPN gateway, but not from the i-HA, it assumes it is outside the enterprise network. If it receives a response from the i-HA, then it assumes it is inside the enterprise network.
如果移动节点具有到其VPN网关的现有VPN隧道，则每当IP地址更改时，它必须在向i-HA发送注册请求的同时向i-HA发送MOBIKE消息。如果移动节点从VPN网关接收到响应，而不是从i-HA接收到响应，则假定它位于企业网络之外。如果它接收到来自i-HA的响应，则假定它位于企业网络内。
There could also be some out-of-band mechanisms that involve configuring the wireless access points with some information that the mobile node can recognize as access points that belong to the trusted network in an enterprise network. Such mechanisms are beyond the scope of this document.
还可能存在一些带外机制，这些机制涉及使用移动节点可以识别为属于企业网络中的受信任网络的接入点的一些信息来配置无线接入点。这种机制超出了本文件的范围。
The mobile node should not send any normal traffic while it is trying to detect whether it is attached to the trusted or untrusted network. This is described in more detail in [RFC5265].
移动节点在尝试检测其是否连接到受信任或不受信任的网络时，不应发送任何正常流量。[RFC5265]对此进行了更详细的描述。
When the mobile node is outside the enterprise network and attached to an untrusted network, it has an IPsec VPN tunnel with its mobility aware VPN gateway, and a valid registration with a home agent on the intranet with the VPN-TIA as the care-of address.
当移动节点位于企业网络之外并连接到不受信任的网络时，它有一个带有移动感知VPN网关的IPsec VPN隧道，并在内部网上以VPN-TIA作为转交地址向归属代理进行有效注册。
If the mobile node moves and its IP address changes, it performs the following steps:
如果移动节点移动且其IP地址更改，则执行以下步骤：
1a. Initiate an IKE mobility exchange to update the VPN gateway with the current address. If the new network is also untrusted, this will be enough for setting up the connectivity. If the new network is trusted, and if the VPN gateway is reachable, this
1a。启动IKE移动交换以使用当前地址更新VPN网关。如果新网络也不受信任，这将足以设置连接。如果新网络是可信的，并且VPN网关是可访问的，则
exchange will allow the mobile node to keep the VPN state alive while on the trusted side. If the VPN gateway is not reachable from inside, then this exchange will fail.
exchange将允许移动节点在受信任端保持VPN状态为活动状态。如果无法从内部访问VPN网关，则此交换将失败。
1b. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal home agent without VPN encapsulation.
1b。在步骤1的同时，向内部归属代理发送移动IPv4注册请求，无需VPN封装。
2. If the mobile node receives a Registration Reply to the request sent in step 1b, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling. The mobile node MAY tear down the VPN tunnel.
2. 如果移动节点接收到对在步骤1b中发送的请求的注册回复，则当前子网是可信子网，并且移动节点可以在没有VPN隧道的情况下通信。移动节点可以拆除VPN隧道。
When the mobile node is inside the enterprise and attached to the intranet, it does not use a VPN tunnel for data traffic. It has a valid binding cache entry at its home agent. If the VPN gateway is reachable from the trusted network, the mobile node MAY have valid IKEv2 security associations with its VPN gateway. The IPsec security associations can be created when required. The mobile node may have to re-negotiate the IKEv2 security associations to prevent them from expiring.
当移动节点位于企业内部并连接到intranet时，它不会使用VPN隧道进行数据通信。它在其主代理中具有有效的绑定缓存项。如果VPN网关可从受信任网络访问，则移动节点可能与其VPN网关具有有效的IKEv2安全关联。可以在需要时创建IPsec安全关联。移动节点可能必须重新协商IKEv2安全关联，以防止它们过期。
If the mobile node moves and its IP address changes, it performs the following steps:
如果移动节点移动且其IP地址更改，则执行以下步骤：
1. Initiate an IKE mobility exchange to update the VPN gateway with the current address, or if there is no VPN connection, then establish a VPN tunnel with the gateway from the new local IP address. If the new network is trusted, and if the VPN gateway is reachable, this exchange will allow the mobile node to keep the VPN state alive, while in the trusted side. If the new network is trusted and if the VPN gateway is not reachable from inside, then this exchange will fail.
1. 启动IKE移动交换以使用当前地址更新VPN网关，或者如果没有VPN连接，则从新的本地IP地址与网关建立VPN隧道。如果新网络受信任，并且VPN网关可访问，则此交换将允许移动节点在受信任端保持VPN状态为活动状态。如果新网络受信任，并且无法从内部访问VPN网关，则此交换将失败。
2. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal home agent without VPN encapsulation.
2. 在步骤1的同时，向内部归属代理发送移动IPv4注册请求，无需VPN封装。
3. If the mobile node receives a Registration Reply to the request sent in step 2, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling, using only Mobile IP with the new care-of address.
3. 如果移动节点收到对步骤2中发送的请求的注册回复，则当前子网是受信任的子网，并且移动节点可以在没有VPN隧道的情况下通信，仅使用具有新转交地址的移动IP。
4. If the mobile node didn't receive the response in step 3, and if the VPN tunnel is successfully established and registered in step 1, then the mobile node sends a Registration Request over the VPN tunnel to the internal home agent. After receiving a Registration Reply from the home agent, the mobile node can start
4. 如果移动节点在步骤3中没有收到响应，并且如果在步骤1中成功建立并注册了VPN隧道，则移动节点通过VPN隧道向内部归属代理发送注册请求。在接收到来自归属代理的注册回复之后，移动节点可以启动
communicating over the VPN tunnel with the Mobile IP home address.
通过VPN隧道与移动IP主地址通信。
There could be a Network Address Translation (NAT) device between the mobile node and the home agent in any of the access modes, 'c', 'f', and 'mc', and between the mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 NAT traversal, as described in [RFC3519], should be used by the mobile node and the home agent in access modes 'c' or 'f', when there is a NAT device present. When using access mode, 'mc', IPsec NAT traversal [RFC3947] [RFC3948] should be used by the mobile node and the VPN gateway, if there is a NAT device present. Typically, the TIA would be a routable address inside the enterprise network. But in some cases, the TIA could be from a private address space associated with the VPN gateway. In such a case, Mobile IPv4 NAT traversal should be used in addition to IPsec NAT traversal in the 'mc' mode.
在任何接入模式“c”、“f”和“mc”下的移动节点和归属代理之间，以及在接入模式“mc”下的移动节点和VPN网关之间，可能存在网络地址转换（NAT）设备。如[RFC3519]中所述，当存在NAT设备时，移动节点和归属代理应在访问模式“c”或“f”下使用移动IPv4 NAT穿越。当使用访问模式“mc”时，如果存在NAT设备，移动节点和VPN网关应使用IPsec NAT遍历[RFC3947][RFC3948]。通常，TIA是企业网络内的可路由地址。但在某些情况下，TIA可能来自与VPN网关关联的专用地址空间。在这种情况下，除了“mc”模式下的IPsec NAT遍历外，还应使用移动IPv4 NAT遍历。
Enterprise connectivity typically requires very strong security, and the solution described in this document was designed keeping this in mind.
企业连接性通常需要非常强的安全性，本文档中描述的解决方案就是在考虑这一点的情况下设计的。
Security concerns related to the mobile node detecting that it is on a trusted network and thereafter dropping the VPN tunnel are described in [RFC5265].
[RFC5265]中描述了与移动节点检测到其位于可信网络上并随后丢弃VPN隧道相关的安全问题。
When the mobile node sends a Registration Request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
当移动节点从未通过IPsec隧道的不受信任网络向i-HA发送注册请求时，它将显示i-HA的地址、其自身身份（包括NAI和家庭地址）以及不受信任网络的身份验证扩展中的身份验证者值。在某些部署中，这可能是一个问题。
Please see [RFC4555] for MOBIKE-related security considerations, and [RFC3519], [RFC3947] for security concerns related to the use of NAT traversal mechanisms for Mobile IPv4 and IPsec.
请参见[RFC4555]了解与MOBIKE相关的安全注意事项，以及[RFC3519]、[RFC3947]了解与移动IPv4和IPsec使用NAT遍历机制相关的安全问题。
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval Shah, and John Cruz for their participation in developing this solution.
作者要感谢Henry Haverinen、Sandro Grech、Dhaval Shah和John Cruz参与开发此解决方案。
The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni Korhonen, and Sami Vaarala for reviewing the document.
作者还要感谢Henrik Levkowetz、Jari Arkko、TJ Kniveton、Vidya Narayanan、Yaron Sheffer、Hans Sjostrand、Jouni Korhonen和Sami Vaarala审阅了该文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265]Vaarala，S.和E.Kloving，“跨基于IPsec的VPN网关的移动IPv4穿越”，RFC 5265，2008年6月。
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093]Adrangi，F.和H.Levkowetz，“问题陈述：虚拟专用网络（VPN）网关的移动IPv4穿越”，RFC 4093，2005年8月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]黑山，G.“移动IP的反向隧道，修订版”，RFC 3024，2001年1月。
[MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure Connectivity and Mobility", Work in Progress, February 2008.
[MEGHANA]Sahasrabudhe，M.和V.Devarapalli，“优化以确保连接性和移动性”，正在进行的工作，2008年2月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[RFC3519]Levkowetz，H.和S.Vaarala，“网络地址转换（NAT）设备的移动IP遍历”，RFC 3519，2003年4月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
The solution described in this document can also be applied to a Mobile Operator's network when the Operator deploys heterogeneous access networks and some of the access networks are considered as trusted networks and others as untrusted networks. Figure 2 illustrates such a network topology.
当运营商部署异构接入网络时，本文档中描述的解决方案也可应用于移动运营商的网络，其中一些接入网络被视为可信网络，而另一些则被视为不可信网络。图2说明了这样的网络拓扑。
+----------------------+
| +----+ |
+----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
+----------------------+
| +----+ |
+----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
Figure 2: Network Topology of a Mobile Operator with Trusted and Untrusted Networks
图2：具有可信和不可信网络的移动运营商的网络拓扑
An IPsec VPN gateway provides secure connectivity to the Operator's internal network for mobile nodes attached to an untrusted access network. The VPN gateway supports MOBIKE extensions so that the IPsec tunnels survive any IP address change when the mobile node moves while attached to the untrusted access networks.
IPsec VPN网关为连接到不可信访问网络的移动节点提供到运营商内部网络的安全连接。VPN网关支持MOBIKE扩展，因此当移动节点连接到不受信任的访问网络时，IPsec隧道在任何IP地址更改后都不会失效。
When the mobile node is attached to the trusted access network, it uses Mobile IP with the i-HA. It uses the IP address obtained from the trusted access network as the co-located care-of address to register with the i-HA. If a foreign agent is available in the trusted access network, the mobile node may use a foreign agent care-of address. If the mobile node moves and attaches to an untrusted access network, it sets up an IPsec tunnel with the VPN gateway to access the Operator's internal network. It uses the IPsec TIA as the co-located care-of address to register with the i-HA thereby creating a Mobile IP tunnel inside an IPsec tunnel.
当移动节点连接到可信接入网络时，它使用带有i-HA的移动IP。它使用从可信接入网络获得的IP地址作为同一位置的转交地址，以便向i-HA注册。如果外部代理在可信接入网络中可用，则移动节点可以使用外部代理转交地址。如果移动节点移动并连接到不受信任的访问网络，它将使用VPN网关设置IPsec隧道以访问运营商的内部网络。它使用IPsec TIA作为同一位置的转交地址，向i-HA注册，从而在IPsec隧道内创建移动IP隧道。
When the mobile node is attached to the trusted access network, it can either be attached to a foreign link in the trusted network or to the home link directly. This document does not impose any restrictions.
当移动节点连接到可信接入网络时，它可以连接到可信网络中的外部链路，也可以直接连接到归属链路。本文件不施加任何限制。
Authors' Addresses
作者地址
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
Vijay Devarapalli Wichorus 3590北第一街圣何塞，加利福尼亚州95134
EMail: vijay@wichorus.com
EMail: vijay@wichorus.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.