Network Working Group P. Srisuresh
Request for Comments: 2709 Lucent Technologies
Category: Informational October 1999
Network Working Group P. Srisuresh
Request for Comments: 2709 Lucent Technologies
Category: Informational October 1999
Security Model with Tunnel-mode IPsec for NAT Domains
NAT域的隧道模式IPsec安全模型
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described.
有多种NAT口味，如参考文献1所述。在NAT支持的域中，只有领域特定的IP客户端能够执行端到端IPsec安全会话。然而，所有类型的NAT都能够为与外部域中的节点进行对等的私有域主机提供隧道模式IPsec安全性。本文档描述了一种安全模型，通过该模型可以在NAT设备上构建隧道模式IPsec安全性。本节专门介绍在快速模式下如何将安全策略透明地传递给IKE（用于自动密钥交换）。还概述了可以从所述安全模型中获益的应用程序。
NAT devices provide transparent routing to end hosts trying to communicate from disparate address realms, by modifying IP and transport headers en-route. This solution works best when the end user identifier (such as host name) is different from the address used to locate end user.
NAT设备通过修改路由中的IP和传输头，向试图从不同地址域进行通信的终端主机提供透明路由。当最终用户标识符（如主机名）与用于定位最终用户的地址不同时，此解决方案效果最佳。
End-to-end application level payload security can be provided for applications that do not embed realm-specific information in payloads that is meaningless to one of the end-users. Applications that do embed realm-specific information in payload will require an application level gateway (ALG) to make the payload meaningful in both realms. However, applications that require assistance of an ALG en-route cannot pursue end-to-end application level security.
端到端应用程序级有效负载安全性可用于未在有效负载中嵌入领域特定信息的应用程序，这些信息对最终用户之一来说毫无意义。在有效负载中嵌入领域特定信息的应用程序将需要一个应用程序级网关（ALG），以使有效负载在这两个领域中都有意义。但是，在途中需要ALG协助的应用程序无法实现端到端应用程序级别的安全性。
All applications traversing a NAT device, irrespective of whether they require assistance of an ALG or not, can benefit from IPsec tunnel-mode security, when NAT device acts as the IPsec tunnel end point.
当NAT设备充当IPsec隧道端点时，所有通过NAT设备的应用程序，无论是否需要ALG的帮助，都可以受益于IPsec隧道模式安全性。
Section 2 below defines terms specific to this document.
下文第2节定义了本文件的特定术语。
Section 3 describes how tunnel mode IPsec security can be recognized on NAT devices. IPsec Security architecture, format and operation of various types of security mechanisms may be found in [Ref 2], [Ref 3] and [Ref 4]. This section does not address how session keys and policies are exchanged between a NAT device acting as IPsec gateway and external peering nodes. The exchange could have taken place manually or using any of known automatic exchange techniques.
第3节描述如何在NAT设备上识别隧道模式IPsec安全性。IPsec安全架构、格式和各种类型安全机制的操作可在[Ref 2]、[Ref 3]和[Ref 4]中找到。本节不讨论充当IPsec网关的NAT设备与外部对等节点之间如何交换会话密钥和策略。交换可以手动进行，也可以使用任何已知的自动交换技术。
Section 4 assumes that Public Key based IKE protocol [Ref 5] may be used to automate exchange of security policies, session keys and other Security Association (SA) attributes. This section describes a method by which security policies administered for a private domain may be translated for communicating with external nodes. Detailed description of IKE protocol operation may be found in [Ref 5] and [Ref 6].
第4节假设基于公钥的IKE协议[Ref 5]可用于自动交换安全策略、会话密钥和其他安全关联（SA）属性。本节描述了一种方法，通过该方法，可以将为私有域管理的安全策略转换为与外部节点通信。IKE协议操作的详细说明见[Ref 5]和[Ref 6]。
Section 5 describes applications of the security model described in the document. Applications listed include secure external realm connectivity for private domain hosts and secure remote access to enterprise mobile hosts.
第5节描述了文档中描述的安全模型的应用。列出的应用程序包括专用域主机的安全外部域连接和对企业移动主机的安全远程访问。
Definitions for majority of terms used in this document may be found in one of (a) NAT Terminology and Considerations document [Ref 1], (b) IP security Architecture document [Ref 2], or (c) Internet Key Enchange (IKE) document [Ref 5]. Below are terms defined specifically for this document.
本文件中使用的大多数术语的定义可在（a）NAT术语和注意事项文件[Ref 1]、（b）IP安全体系结构文件[Ref 2]或（c）互联网密钥加密（IKE）文件[Ref 5]中找到。以下是专门为本文件定义的术语。
The term "Normal-NAT" is introduced to distinguish normal NAT processing from the NAT processing used for secure packets embedded within an IPsec secure tunnel. "Normal-NAT" is the normal NAT processing as described in [Ref 1].
引入术语“正常NAT”是为了区分正常NAT处理与用于嵌入IPsec安全隧道中的安全数据包的NAT处理。“正常NAT”是指[Ref 1]中所述的正常NAT处理。
The term "IPsec Policy Controlled NAT" (IPC-NAT, for short) is defined to describe the NAT transformation applied as an extension of IPsec transformation to packets embedded within an IP-IP tunnel, for
术语“IPsec策略控制的NAT”（简称IPC-NAT）被定义为描述NAT转换，作为IPsec转换的扩展应用于嵌入IP-IP隧道中的数据包，例如
which the NAT node is a tunnel end point. IPC-NAT function is essentially an adaptation of NAT extensions to embedded packets of tunnel-mode IPsec. Packets subject to IPC-NAT processing are beneficiaries of IPsec security between the NAT device and an external peer entity, be it a host or a gateway node.
其中NAT节点是隧道端点。IPC-NAT功能实质上是将NAT扩展适配到隧道模式IPsec的嵌入式数据包。接受IPC-NAT处理的数据包是NAT设备和外部对等实体（无论是主机还是网关节点）之间IPsec安全的受益者。
IPsec policies place restrictions on what NAT mappings are used. For example, IPsec access control security policies to a peer gateway will likely restrict communication to only certain addresses and/or port numbers. Thus, when NAT performs translations, it must insure that the translations it performs are consist with the security policies.
IPsec策略对使用的NAT映射进行了限制。例如，对等网关的IPsec访问控制安全策略可能会将通信限制为仅限于某些地址和/或端口号。因此，当NAT执行翻译时，它必须确保它执行的翻译符合安全策略。
Just as with Normal-NAT, IPC-NAT function can assume any of NAT flavors, including Traditional-NAT, Bi-directional-NAT and Twice-NAT. An IPC-NAT device would support both IPC-NAT and normal-NAT functions.
与普通NAT一样，IPC-NAT功能可以采用任何NAT风格，包括传统NAT、双向NAT和两次NAT。IPC-NAT设备将支持IPC-NAT和正常NAT功能。
The IP security architecture document [Ref 2] describes how IP network level security may be accomplished within a globally unique address realm. Transport and tunnel mode security are discussed. For purposes of this document, we will assume IPsec security to mean tunnel mode IPsec security, unless specified otherwise. Elements fundamental to this security architecture are (a) Security Policies, that determine which packets are permitted to be subject to Security processing, and (b) Security Association Attributes that identify the parameters for security processing, including IPsec protocols, algorithms and session keys to be applied.
IP安全体系结构文档[Ref 2]描述了如何在全球唯一地址域内实现IP网络级安全。讨论了传输和隧道模式的安全性。在本文档中，我们将假定IPsec安全性是指隧道模式IPsec安全性，除非另有规定。该安全体系结构的基本要素是：（a）安全策略，用于确定允许哪些数据包进行安全处理；（b）安全关联属性，用于标识安全处理的参数，包括要应用的IPsec协议、算法和会话密钥。
Operation of tunnel mode IPsec security on a device that does not support Network Address Translation may be described as below in figures 1 and 2.
在不支持网络地址转换的设备上，隧道模式IPsec安全性的操作如下图1和图2所示。
+---------------+ No +---------------------------+
| | +--->|Forward packet in the Clear|
Outgoing |Does the packet| | |Or Drop, as appropriate. |
-------->|match Outbound |-| +---------------------------+
Packet |Security | | +-------------+
|Policies? | |Yes |Perform | Forward
| | +--->|Outbound |--------->
+---------------+ |Security | IPsec Pkt
|(Tunnel Mode)|
+-------------+
+---------------+ No +---------------------------+
| | +--->|Forward packet in the Clear|
Outgoing |Does the packet| | |Or Drop, as appropriate. |
-------->|match Outbound |-| +---------------------------+
Packet |Security | | +-------------+
|Policies? | |Yes |Perform | Forward
| | +--->|Outbound |--------->
+---------------+ |Security | IPsec Pkt
|(Tunnel Mode)|
+-------------+
Figure 1. Operation of Tunnel-Mode IPsec on outgoing packets.
图1。在传出数据包上运行隧道模式IPsec。
IPsec packet +----------+ +----------+
destined to |Perform | Embedded |Does the | No(Drop)
------------>|Inbound |--------->|Pkt match |-------->
the device |Security | Packet |Inbound SA| Yes(Forward)
|(Detunnel)| |Policies? |
+----------+ +----------+
IPsec packet +----------+ +----------+
destined to |Perform | Embedded |Does the | No(Drop)
------------>|Inbound |--------->|Pkt match |-------->
the device |Security | Packet |Inbound SA| Yes(Forward)
|(Detunnel)| |Policies? |
+----------+ +----------+
Figure 2. Operation of Tunnel-Mode IPsec on Incoming packets
图2。隧道模式IPsec对传入数据包的操作
A NAT device that provides tunnel-mode IPsec security would be required to administer security policies based on private realm addressing. Further, the security policies determine the IPsec tunnel end-point peer. As a result, a packet may be required to undergo different type of NAT translation depending upon the tunnel end-point the IPsec node peers with. In other words, IPC-NAT will need a unique set of NAT maps for each security policy configured. IPC-NAT will perform address translation in conjunction with IPsec processing differently with each peer, based on security policies. The following diagrams (figure 3 and figure 4) illustrate the operation of IPsec tunneling in conjunction with NAT. Operation of an IPC-NAT device may be distinguished from that of an IPsec gateway that does not support NAT as follows.
提供隧道模式IPsec安全性的NAT设备需要管理基于私有领域寻址的安全策略。此外，安全策略确定IPsec隧道端点对等点。结果，根据IPsec节点与之对等的隧道端点，分组可能需要经历不同类型的NAT转换。换句话说，IPC-NAT需要为每个配置的安全策略提供一组唯一的NAT映射。IPC-NAT将根据安全策略对每个对等方执行不同的地址转换和IPsec处理。下图（图3和图4）说明了IPsec隧道与NAT的结合操作。IPC-NAT设备的操作可与不支持NAT的IPsec网关的操作区别如下。
(1) IPC-NAT device has security policies administered using private realm addressing. A traditional IPsec gateway will have its security policies administered using a single realm (say, external realm) addressing.
(1) IPC-NAT设备具有使用私有域寻址管理的安全策略。传统的IPsec网关将使用单个域（例如，外部域）寻址来管理其安全策略。
(2) Elements fundamental to the security model of an IPC-NAT device includes IPC-NAT address mapping (and other NAT parameter definitions) in conjunction with Security policies and SA attributes. Fundamental elements of a traditional IPsec gateway are limited only to Security policies and SA attributes.
(2) IPC-NAT设备安全模型的基本要素包括IPC-NAT地址映射（和其他NAT参数定义）以及安全策略和SA属性。传统IPsec网关的基本元素仅限于安全策略和SA属性。
+---------------+ +-------------------------+
| | No | Apply Normal-NAT or Drop|
Outgoing |Does the packet| +--->| as appropriate |
-------->|match Outbound |-| +-------------------------+
Packet |Security | | +---------+ +-------------+
(Private |Policies? | |Yes |Perform | |Perform |Forward
Domain) | | +--->|Outbound |->|Outbound |-------->
+---------------+ |NAT | |Security |IPsec Pkt
|(IPC-NAT)| |(Tunnel mode)|
+---------+ +-------------+
+---------------+ +-------------------------+
| | No | Apply Normal-NAT or Drop|
Outgoing |Does the packet| +--->| as appropriate |
-------->|match Outbound |-| +-------------------------+
Packet |Security | | +---------+ +-------------+
(Private |Policies? | |Yes |Perform | |Perform |Forward
Domain) | | +--->|Outbound |->|Outbound |-------->
+---------------+ |NAT | |Security |IPsec Pkt
|(IPC-NAT)| |(Tunnel mode)|
+---------+ +-------------+
Figure 3. Tunnel-Mode IPsec on an IPC-NAT device for outgoing pkts
图3。IPC-NAT设备上用于传出PKT的隧道模式IPsec
IPsec Pkt +----------+ +---------+ +----------+
destined |Perform | Embedded |Perform | |Does the |No(Drop)
--------->|Inbound |--------->|Inbound |->|Pkt match |-------->
to device |Security | Packet |NAT | |Inbound SA|Yes(Forward)
(External |(Detunnel)| |(IPC-NAT)| |Policies? |
Domain) +----------+ +---------+ +----------+
IPsec Pkt +----------+ +---------+ +----------+
destined |Perform | Embedded |Perform | |Does the |No(Drop)
--------->|Inbound |--------->|Inbound |->|Pkt match |-------->
to device |Security | Packet |NAT | |Inbound SA|Yes(Forward)
(External |(Detunnel)| |(IPC-NAT)| |Policies? |
Domain) +----------+ +---------+ +----------+
Figure 4. Tunnel-Mode IPsec on an IPC-NAT device for Incoming pkts
图4。IPC-NAT设备上用于传入PKT的隧道模式IPsec
Traditional NAT is session oriented, allowing outbound-only sessions to be translated. All other flavors of NAT are Bi-directional. Any and all flavors of NAT mapping may be used in conjunction with the security policies and secure processing on an IPC-NAT device. For illustration purposes in this document, we will assume tunnel mode IPsec on a Bi-directional NAT device.
传统的NAT是面向会话的，只允许转换出站会话。NAT的所有其他口味都是双向的。NAT映射的任何和所有风格都可以与IPC-NAT设备上的安全策略和安全处理结合使用。为了在本文档中进行说明，我们将在双向NAT设备上采用隧道模式IPsec。
Notice however that a NAT device capable of providing security across IPsec tunnels can continue to support Normal-NAT for packets that do not require IPC-NAT. Address mapping and other NAT parameter definitions for Normal-NAT and IPC-NAT are distinct. Figure 3 identifies how a NAT device distinguishes between outgoing packets that need to be processed through Normal-NAT vs. IPC-NAT. As for packets incoming from external realm, figure 4 outlines packets that may be subject to IPC-NAT. All other packets are subject to Normal-NAT processing only.
但是请注意，能够跨IPsec隧道提供安全性的NAT设备可以继续支持不需要IPC-NAT的数据包的正常NAT。普通NAT和IPC-NAT的地址映射和其他NAT参数定义是不同的。图3显示了NAT设备如何区分需要通过正常NAT和IPC-NAT处理的传出数据包。对于从外部领域传入的数据包，图4概述了可能受IPC-NAT约束的数据包。所有其他数据包仅接受正常NAT处理。
4. Operation of IKE protocol on IPC-NAT device.
4. IPC-NAT设备上IKE协议的操作。
IPC-NAT operation described in the previous section can be accomplished based on manual session key exchange or using an automated key Exchange protocol between peering entities. In this section, we will consider adapting IETF recommended Internet Key Exchange (IKE) protocol on a IPC-NAT device for automatic exchange of security policies and SA parameters. In other words, we will focus on the operation of IKE in conjunction with tunnel mode IPsec on NAT devices. For the reminder of this section, we will refer NAT device to mean IPC-NAT device, unless specified otherwise.
上一节描述的IPC-NAT操作可以基于手动会话密钥交换或使用对等实体之间的自动密钥交换协议来完成。在本节中，我们将考虑在IEC-NAT设备上适应IETF推荐的Internet密钥交换（IKE）协议，以自动交换安全策略和SA参数。换句话说，我们将重点讨论IKE与NAT设备上的隧道模式IPsec的结合操作。对于本节的提醒，我们将NAT设备称为IPC-NAT设备，除非另有规定。
IKE is based on UDP protocol and uses public-key encryption to exchange session keys and other attributes securely across an address realm. The detailed protocol and operation of IKE in the context of IP may be found in [Ref 3] and [Ref 4]. Essentially, IKE has 2 phases.
IKE基于UDP协议，使用公钥加密在地址域之间安全地交换会话密钥和其他属性。IP上下文中IKE的详细协议和操作可在[Ref 3]和[Ref 4]中找到。基本上，IKE有两个阶段。
In the first phase, IKE peers operate in main or aggressive mode to authenticate each other and set up a secure channel between themselves. A NAT device has an interface to the external realm and is no different from any other node in the realm to negotiate phase I
在第一阶段，IKE对等点以主模式或攻击模式运行，以相互验证并在它们之间建立安全通道。NAT设备有一个到外部领域的接口，与领域中协商阶段I的任何其他节点没有区别
with peer external nodes. The NAT device may assume any of the valid Identity types and authentication methodologies necessary to communicate and authenticate with peers in the realm. The NAT device may also interface with a Certification Authority (CA) in the realm to retrieve certificates and perform signature validation.
使用对等外部节点。NAT设备可以采用与域中的对等方通信和认证所需的任何有效身份类型和认证方法。NAT设备还可以与域中的证书颁发机构（CA）接口，以检索证书并执行签名验证。
In the second phase, IKE peers operate in Quick Mode to exchange policies and IPsec security proposals to negotiate and agree upon security transformation algorithms, policies, keys, lifetime and other security attributes. During this phase, IKE process must communicate with IPsec Engine to (a) collect secure session attributes and other parameters to negotiate with peer IKE nodes, and to (b) notify security parameters agreed upon (with peer) during the negotiation.
在第二阶段，IKE对等点以快速模式操作，以交换策略和IPsec安全建议，以协商和商定安全转换算法、策略、密钥、生存期和其他安全属性。在此阶段，IKE进程必须与IPsec引擎通信，以（a）收集安全会话属性和其他参数，与对等IKE节点进行协商，并（b）在协商期间通知（与对等方）商定的安全参数。
An IPC-NAT device, operating as IPsec gateway, has the security policies administered based on private realm addressing. An ALG will be required to translate policies from private realm addressing into external addressing, as the IKE process needs to communicate these policies to peers in external realm. Note, IKE datagrams are not subject to any NAT processing. IKE-ALG simply translates select portions of IKE payload as per the NAT map defined for the policy match. The following diagram illustrates how an IKE-ALG process interfaces with IPC-NAT to take the security policies and IPC-NAT maps and generates security policies that IKE could communicate during quick mode to peers in the external realm.
作为IPsec网关运行的IPC-NAT设备具有基于私有域寻址的安全策略。需要ALG将策略从私有领域寻址转换为外部寻址，因为IKE过程需要将这些策略与外部领域中的对等方进行通信。注意，IKE数据报不接受任何NAT处理。IKE-ALG只是根据为策略匹配定义的NAT映射转换IKE有效负载的选定部分。下图说明了IKE-ALG进程如何与IPC-NAT交互，以获取安全策略和IPC-NAT映射，并生成IKE可以在快速模式下与外部领域中的对等方通信的安全策略。
Policies in quick mode are exchanged with a peer as a combination of IDci and IDcr payloads. The combination of IDs (policies) exchanged by each peer must match in order for the SA parameters on either end to be applied uniformly. If the IDs are not exchanged, the assumption would be that the Quick mode negotiated SA parameters are applicable between the IP addresses assumed by the main mode.
快速模式下的策略作为IDci和IDcr有效负载的组合与对等方交换。每个对等方交换的ID（策略）组合必须匹配，以便统一应用两端的SA参数。如果未交换ID，则假定快速模式协商的SA参数适用于主模式假定的IP地址之间。
Depending on the nature of security policies in place(ex: end-to-end sessions between a pair of nodes vs. sessions with an address range), IKE-ALG may need to request NAT to set up address bindings and/or transport bindings for the lifetime (in seconds or Kilo-Bytes) the sessions are negotiated. In the case the ALG is unable to setup the necessary address bindings or transport bindings, IKE-ALG will not be able to translate security policies and that will result in IKE not pursuing phase II negotiation for the effected policies.
根据现有安全策略的性质（例如：一对节点之间的端到端会话与具有地址范围的会话），IKE-ALG可能需要请求NAT为会话协商的生存期（以秒或千字节为单位）设置地址绑定和/或传输绑定。如果ALG无法设置必要的地址绑定或传输绑定，IKE-ALG将无法转换安全策略，这将导致IKE无法对受影响的策略进行第二阶段协商。
When the Negotiation is complete and successful, IKE will communicate the negotiated security parameters directly to the IPC-NAT gateway engine as described in the following diagram.
协商完成并成功后，IKE将按照下图所述，将协商的安全参数直接传送给IPC-NAT网关引擎。
+---------+
| |
Negotiated Security Parameters | IKE |
+--------------------------------| Process |
|(including session Keys) | |
| +---------+
| ^ ^
| Translated| |
| Secure| |Security
| Policies| |Proposals
v | |
+---------+ Security Policies, based +---------+
| |------------------------->| |
| | on Pvt. realm addressing | |
| IPC-NAT | | |
| (IPsec | IPC-NAT MAPs | IKE-ALG |
| Gateway)|------------------------->| |
| | | |
| | Security Proposals | |
| |------------------------->| |
| | | |
| | NAT Control exchange | |
| |<------------------------>| |
+---------+ +---------+
+---------+
| |
Negotiated Security Parameters | IKE |
+--------------------------------| Process |
|(including session Keys) | |
| +---------+
| ^ ^
| Translated| |
| Secure| |Security
| Policies| |Proposals
v | |
+---------+ Security Policies, based +---------+
| |------------------------->| |
| | on Pvt. realm addressing | |
| IPC-NAT | | |
| (IPsec | IPC-NAT MAPs | IKE-ALG |
| Gateway)|------------------------->| |
| | | |
| | Security Proposals | |
| |------------------------->| |
| | | |
| | NAT Control exchange | |
| |<------------------------>| |
+---------+ +---------+
Figure 5. IKE-ALG translates Security policies, using NAT Maps.
图5。IKE-ALG使用NAT映射转换安全策略。
IPC-NAT operational model described thus far illustrates how a NAT device can be used as an IPsec tunnel end point to provide secure transfer of data in external realm. This section will attempt to illustrate two applications of such a model.
迄今为止描述的IPC-NAT操作模型说明了如何将NAT设备用作IPsec隧道端点，以在外部领域提供安全的数据传输。本节将试图说明这种模型的两个应用。
IPC-NAT Model has a direct application of being able to provide clear as well as secure connectivity with external realm using a NAT device. In particular, IPC-NAT device at the border of a private realm can peer with an IPsec gateway of an external domain to secure the Extranet connection. Extranet refers to the portion of the path that crosses the Internet between peering gateway nodes.
IPC-NAT模型的一个直接应用是能够使用NAT设备提供与外部领域的清晰且安全的连接。特别是，位于私有领域边界的IPC-NAT设备可以与外部域的IPsec网关进行对等，以确保外部网连接的安全。外部网是指在对等网关节点之间穿过Internet的路径部分。
Say, a node from an enterprise moves out of the enterprise, and attempts to connect to the enterprise from remote site, using a temporary service provider assigned address (Care-of-Address). In such a case, the mobile user could setup an IPsec tunnel session with the corporate IPC-NAT device using a user-ID and authentication mechanism that is agreed upon. Further, the user may be configured with enterprise DNS server, as an extension of authentication following IKE Phase I. This would allow the user to access enterprise resources by name.
例如，来自企业的节点移出企业，并尝试使用临时服务提供商分配的地址（转交地址）从远程站点连接到企业。在这种情况下，移动用户可以使用商定的用户ID和认证机制与公司IPC-NAT设备建立IPsec隧道会话。此外，用户可以配置企业DNS服务器，作为IKE阶段I之后身份验证的扩展。这将允许用户按名称访问企业资源。
However, many enterprise servers and applications rely on source IP address for authentication and deny access for packets that do not originate from the enterprise address space. In these scenarios, IPC-NAT has the ability (unlike a traditional IPsec gateway) to perform Network Address Translation (NAT) for remote access users, so their temporary address in external realm is translated into a enterprise domain address, while the packets are within private realm. The flavor of IPC-NAT performed would be traditional NAT (i.e., assuming mobile-user address space to be private realm and Enterprise address space to be external realm), which can either be Basic NAT (using a block of enterprise addresses for translation) or NAPT(using a single enterprise address for translation).
但是，许多企业服务器和应用程序依赖于源IP地址进行身份验证，并拒绝来自企业地址空间的数据包的访问。在这些场景中，IPC-NAT能够（不同于传统的IPsec网关）为远程访问用户执行网络地址转换（NAT），因此他们在外部域中的临时地址被转换为企业域地址，而数据包在私有域中。IPC-NAT的风格是传统NAT（即，假设移动用户地址空间为私有领域，企业地址空间为外部领域），可以是基本NAT（使用一组企业地址进行转换）或NAPT（使用单个企业地址进行转换）。
The secure remote access application described is pertinent to all enterprises, irrespective of whether an enterprise uses IANA registered addresses or not.
所描述的安全远程访问应用程序与所有企业相关，无论企业是否使用IANA注册地址。
The secure remote access application described is different from Mobile-IP in that, the mobile node (described in this application) does not retain the Home-Network address and simply uses the Care-Of-address for communication purposes. It is conceivable for the IPC-NAT Gateway to transparently provide Mobile-IP type connectivity to the Mobile node by binding the mobile node's Care-of-Address with its Home Address. Provision of such an address mapping to IPC-NAT gateway, however, is not within the scope of this document.
所描述的安全远程访问应用程序与移动IP的不同之处在于，移动节点（在本应用程序中描述）不保留归属网络地址，而只是出于通信目的使用转交地址。可以想象，IPC-NAT网关通过将移动节点的转交地址与其家庭地址绑定，透明地向移动节点提供移动IP类型的连接。但是，向IPC-NAT网关提供这样的地址映射不在本文档的范围内。
If NATs and ALGs are not in a trusted boundary, that is a major security problem, as ALGs snoop end user traffic payload. Application level payload could be encrypted end-to-end, so long as the payload does not contain IP addresses and/or transport identifiers that are valid in only one of the realms. With the exception of Realm-Specific IP, end-to-end IP network level security assured by current IPsec techniques is not attainable with NATs in between. The IPC-NAT model described in this document outlines an
如果NAT和ALG不在可信边界内，这将是一个主要的安全问题，因为ALG侦听最终用户流量负载。只要有效负载不包含仅在其中一个领域有效的IP地址和/或传输标识符，应用程序级有效负载就可以端到端加密。除了领域特定的IP之外，当前IPsec技术所保证的端到端IP网络级安全在NAT介于两者之间时是无法实现的。本文档中描述的IPC-NAT模型概述了
approach by which network level security may be obtained within external realm.
可在外部领域内获得网络级安全性的方法。
NATs, when combined with ALGs, can ensure that the datagrams injected into Internet have no private addresses in headers or payload. Applications that do not meet these requirements may be dropped using firewall filters. For this reason, it is not uncommon to find that IPC-NATs, ALGs and firewalls co-exist to provide security at the border of a private network.
当NAT与ALG结合时，可以确保注入Internet的数据报在报头或有效负载中没有私有地址。不符合这些要求的应用程序可能会使用防火墙过滤器丢弃。因此，IPC NAT、ALG和防火墙共存以在专用网络边界提供安全性的情况并不少见。
REFERENCES
参考资料
[1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[1] Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[2] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998
[3] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月
[4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[4] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[6] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[6] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[7] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
[7] Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC21011997年2月。
[8] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[8] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
Author's Address
作者地址
Pyda Srisuresh Lucent technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
美国加利福尼亚州普莱森顿柳树路4464号Pyda Srisuresh-Lucent technologies，邮编94588-8519。
Phone: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com
电话：（925）737-2153传真：（925）737-2110电子邮件：srisuresh@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。