Network Working Group M. Richardson
Request for Comments: 4322 SSW
Category: Informational D.H. Redelmeier
Mimosa
December 2005
Network Working Group M. Richardson
Request for Comments: 4322 SSW
Category: Informational D.H. Redelmeier
Mimosa
December 2005
Opportunistic Encryption using the Internet Key Exchange (IKE)
使用Internet密钥交换（IKE）的机会加密
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
本文档描述了由Linux FreeS/WAN项目设计和实现的机会加密（OE）。OE使用Internet密钥交换（IKE）和IPsec协议。其目的是允许加密用于安全通信，而无需任何特定于所涉及系统对的预先安排。DNS用于分发涉及的每个系统的公钥。这可以抵抗被动攻击。DNS安全性（DNSSEC）的使用也可以保护该系统免受主动攻击者的攻击。
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.
结果，管理开销从系统数量的平方减少到线性依赖，并且即使在事先不知道伙伴的情况下，也可以使安全通信成为默认通信。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of systems involved. Each system administrator adds public key information to DNS records to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once this is done, any two such nodes can communicate securely.
机会主义加密的目的是允许加密，而无需针对所涉及的系统对进行任何预先安排。每个系统管理员将公钥信息添加到DNS记录中以支持机会加密，然后在节点的IPsec堆栈中启用此功能。一旦完成，任何两个这样的节点都可以安全地通信。
This document describes opportunistic encryption as designed and implemented by the Linux FreeS/WAN project in revisions up and including 2.00. Note that 2.01 and beyond implements [RFC3445] in a backward compatible way. A future document [IPSECKEY] will describe a variation that complies with RFC 3445. For project information, see http://www.freeswan.org.
本文档描述了Linux FreeS/WAN项目在修订版（包括2.00版）中设计和实现的机会加密。请注意，2.01及以后版本以向后兼容的方式实现[RFC3445]。未来的文件[IPSECKEY]将描述符合RFC 3445的变更。有关项目信息，请参见http://www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [RFC1984]. The Linux FreeS/WAN project attempts to provide a practical means to implement this policy.
互联网体系结构委员会（IAB）和互联网工程指导小组（IESG）坚定地认为，互联网应该使用强大的加密来提供安全和隐私[RFC1984]。LinuxFrees/WAN项目试图提供一种实现此策略的实用方法。
The project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols because they are standardized, widely available, and can often be deployed very easily without changing hardware or software, or retraining users.
该项目使用IPsec、ISAKMP/IKE、DNS和DNSSEC协议，因为它们是标准化的、广泛可用的，并且通常可以非常轻松地部署，而无需更改硬件或软件，也无需重新培训用户。
The extensions to support opportunistic encryption are simple. No changes to any on-the-wire formats are needed. The only changes are to the policy decision making system. This means that opportunistic encryption can be implemented with very minimal changes to an existing IPsec implementation.
支持机会加密的扩展非常简单。不需要更改任何在线格式。唯一的变化是政策决策系统。这意味着机会主义加密可以通过对现有IPsec实现进行非常小的更改来实现。
Opportunistic encryption creates a "fax effect". The proliferation of the fax machine was possible because it did not require that everyone buy one overnight. Instead, as each person installed one, the value of having one increased because there were more people that could receive faxes. Once opportunistic encryption is installed, it automatically recognizes other boxes using opportunistic encryption, without any further configuration by the network administrator. So, as opportunistic encryption software is installed on more boxes, its value as a tool increases.
机会主义加密会产生“传真效应”。传真机的普及是可能的，因为它不需要每个人都在一夜之间买一台。相反，当每个人都安装了传真机时，拥有传真机的价值就增加了，因为有更多的人可以接收传真。一旦安装了机会主义加密，它将使用机会主义加密自动识别其他盒子，而无需网络管理员进行任何进一步配置。因此，随着机会主义加密软件安装在更多的盒子上，其作为工具的价值也会增加。
This document describes the infrastructure to permit deployment of Opportunistic Encryption.
本文档描述了允许部署机会主义加密的基础结构。
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
术语S/WAN是RSA Data Systems的商标，经本项目许可使用。
To aid in understanding the relationship between security processing and IPsec, we divide policies controlling network traffic into four categories. The traffic is categorized by destination address using longest prefix match. Therefore, each category is enumerated by a set of network prefixes. The categories are mutually exclusive; a particular prefix should only occur in one category.
为了帮助理解安全处理和IPsec之间的关系，我们将控制网络流量的策略分为四类。使用最长前缀匹配按目标地址对流量进行分类。因此，每个类别都由一组网络前缀枚举。这些类别是相互排斥的；特定前缀只能出现在一个类别中。
* Deny: network prefixes to which traffic is always forbidden. * Permit: network prefixes to which traffic in the clear is permitted. * Opportunistic tunnel: network prefixes to which traffic is encrypted if possible, when it otherwise might be sent in the clear. * Configured tunnel: network prefixes to which traffic must be encrypted, and traffic in the clear is never permitted. A traditionally defined Virtual Private Network (VPN) is a form of configured tunnel.
* 拒绝：始终禁止通信的网络前缀。*许可证：允许清除中的流量的网络前缀。*机会主义隧道（Opportunity tunnel）：网络前缀，如果可能，流量将被加密，否则可能以明文形式发送。*已配置隧道：必须加密流量的网络前缀，并且永远不允许清除中的流量。传统定义的虚拟专用网（VPN）是一种配置隧道的形式。
Traditional firewall devices handle the first two categories. No authentication is required. The permit policy is currently the default on the Internet.
传统的防火墙设备处理前两类。不需要身份验证。许可证策略目前是Internet上的默认策略。
This document describes the third category: opportunistic tunnel, which is proposed as the new default for the Internet.
本文档描述了第三类：机会主义隧道，它被提议作为互联网的新默认。
Category four's policy is a very strict "encrypt it or drop it" policy, which requires authentication of the endpoints. As the number of endpoints is typically bounded and is typically under a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology. The mechanism described here, however, does provides an additional way to distribute the authentication materials; it is a public key method that does not require deployment of an X.509 based infrastructure.
Category 4的策略是非常严格的“加密或删除”策略，需要对端点进行身份验证。由于端点的数量通常是有界的，并且通常在单个机构下，因此安排认证材料的分发虽然困难，但不需要任何新技术。然而，这里描述的机制确实提供了分发认证材料的额外方式；它是一种公钥方法，不需要部署基于X.509的基础设施。
Opportunistic encryption creates tunnels between nodes that are essentially strangers. This is done without any prior bilateral arrangement. Therefore, there is the difficult question of how one knows to whom one is talking.
机会主义加密在本质上是陌生人的节点之间创建隧道。这是在没有任何事先双边安排的情况下完成的。因此，一个人如何知道自己在和谁说话是一个困难的问题。
One possible answer is that since no useful authentication can be done, none should be tried. This mode of operation is named "anonymous encryption". An active man-in-the-middle attack can be used to thwart the privacy of this type of communication. Without peer authentication, there is no way to prevent this kind of attack.
一个可能的答案是，由于无法进行有用的身份验证，因此不应尝试任何身份验证。这种操作模式称为“匿名加密”。主动中间人攻击可用于阻止此类通信的隐私。如果没有对等身份验证，就无法防止此类攻击。
Although it is a useful mode, anonymous encryption is not the goal of this project. Simpler methods are available that can achieve anonymous encryption only, but authentication of the peer is a desirable goal. Authentication of the peer is achieved through key distribution in DNS, leveraging upon the authentication of the DNS in DNSSEC.
尽管匿名加密是一种有用的模式，但它不是本项目的目标。更简单的方法可以实现匿名加密，但对等身份验证是一个理想的目标。对等方的身份验证通过DNS中的密钥分发实现，利用DNSSEC中的DNS身份验证。
Peers are, therefore, authenticated with DNSSEC when available. Local policy determines how much trust to extend when DNSSEC is not available.
因此，对等点在可用时由DNSSEC进行身份验证。本地策略确定DNSSEC不可用时要扩展的信任度。
An essential premise of building private connections with strangers is that datagrams received through opportunistic tunnels are no more special than datagrams that arrive in the clear. Unlike in a VPN, these datagrams should not be given any special exceptions when it comes to auditing, further authentication, or firewalling.
与陌生人建立私人联系的一个基本前提是，通过机会主义隧道接收到的数据报并不比到达目的地的数据报更特殊。与VPN不同，在审计、进一步身份验证或防火墙时，这些数据报不应被赋予任何特殊的例外。
When initiating outbound opportunistic encryption, local configuration determines what happens if tunnel setup fails. The packet may go out in the clear, or it may be dropped.
启动出站机会加密时，本地配置将确定隧道设置失败时的情况。数据包可能会被清除，也可能会被丢弃。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC2119]中的说明进行解释
The following network diagram is used in the rest of this document as the canonical diagram:
以下网络图在本文档的其余部分用作规范图：
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
Figure 1: Reference Network Diagram
图1：参考网络图
In this diagram, there are four end-nodes: A, B, C, and D. There are three security gateways, SG-A, SG-B, SG-D. A, D, SG-A, and SG-D are part of the same administrative authority, AS1. SG-A and SG-D are on two different exit paths from organization 1. SG-B and B are part of an independent organization, AS2. Nodes Q and R are nodes on the Internet. PI is the Public Internet ("The Wild").
在该图中，有四个终端节点：A、B、C和D。有三个安全网关，即SG-A、SG-B、SG-D。A、D、SG-A和SG-D是同一管理机构AS1的一部分。SG-A和SG-D位于组织1的两条不同出口路径上。SG-B和B是独立组织AS2的一部分。节点Q和R是Internet上的节点。PI是公共互联网（“野生”）。
Note: The network numbers used in this document are for illustrative purposes only. This document could not use the reserved example network numbers of [RFC3330] because multiple address ranges were needed.
注：本文件中使用的网络编号仅用于说明目的。此文档无法使用[RFC3330]的保留示例网络号，因为需要多个地址范围。
The following terminology is used in this document:
本文件使用以下术语：
Security gateway (or simply gateway): a system that performs IPsec tunnel mode encapsulation/decapsulation. [SG-x] in the diagram.
安全网关（或简称网关）：执行IPsec隧道模式封装/解除封装的系统。图中的[SG-x]。
Alice: node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.
艾丽斯：图中的节点[A]。当需要IP地址时，这是192.1.0.65。
Bob: node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.
图中的节点[B]。当需要IP地址时，这是192.2.0.66。
Carol: node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.
卡罗尔：图中的节点[C]。当需要IP地址时，这是192.1.1.67。
Dave: node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.
戴夫：图中的节点[D]。当需要IP地址时，这是192.3.0.68。
SG-A: Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.
SG-A：爱丽丝的安全网关。内部为192.1.0.1，外部为192.1.1.4。
SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
SG-B：鲍勃的安全网关。内部为192.2.0.1，外部为192.1.1.5。
SG-D: Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.
SG-D：戴夫的安全网关。也是Alice的备份安全网关。内部为192.3.0.1，外部为192.1.1.6。
Configured tunnel: a tunnel that is directly and deliberately hand-configured on participating gateways. Configured tunnels are typically given a higher level of trust than opportunistic tunnels.
已配置隧道：在参与网关上直接手动配置的隧道。配置的隧道通常比机会主义隧道具有更高的信任级别。
Road warrior tunnel: a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed node cannot know the current address for the road warrior.
Road warrior tunnel：连接一个具有固定IP地址的节点和一个具有可变IP地址的节点的配置隧道。road warrior（RW）连接必须由变量节点启动，因为固定节点无法知道road warrior的当前地址。
Anonymous encryption: the process of encrypting a session without any knowledge of who the other parties are. No authentication of identities is done.
匿名加密：在不知道对方是谁的情况下对会话进行加密的过程。未进行身份验证。
Opportunistic encryption: the process of encrypting a session with authenticated knowledge of who the other party is without prearrangement.
机会主义加密：在不预先安排的情况下，通过对另一方身份的认证，对会话进行加密的过程。
Lifetime: the period in seconds (bytes or datagrams) for which a security association will remain alive before rekeying is needed.
生存期：在需要重新设置密钥之前，安全关联将保持活动状态的时间段（以秒为单位）（字节或数据报）。
Lifespan: the effective time for which a security association remains useful. A security association with a lifespan shorter than its lifetime would be removed when no longer needed. A security association with a lifespan longer than its lifetime would need to be re-keyed one or more times.
寿命：安全关联保持有效的有效时间。生命周期短于其生命周期的安全关联将在不再需要时被删除。生命周期长于其生命周期的安全关联需要重新设置一次或多次密钥。
Phase 1 SA: an ISAKMP/IKE security association sometimes referred to as a keying channel.
阶段1 SA：ISAKMP/IKE安全关联，有时称为密钥通道。
Phase 2 SA: an IPsec security association.
阶段2 SA：IPsec安全关联。
Tunnel: another term for a set of phase 2 SA (one in each direction).
隧道：第2阶段SA（每个方向一个）的另一术语。
NAT: Network Address Translation (see [RFC2663]).
NAT：网络地址转换（参见[RFC2663]）。
NAPT: Network Address and Port Translation (see [RFC2663]).
NAPT：网络地址和端口转换（参见[RFC2663]）。
AS: an autonomous system.
AS：一个自治系统。
FQDN: Fully-Qualified Domain Name
FQDN：完全限定域名
Default-free zone: a set of routers that maintain a complete set of routes to all currently reachable destinations. Having such a list, these routers never make use of a default route. A datagram with a destination address not matching any route will be dropped by such a router.
默认自由区：一组路由器，维护到所有当前可到达目的地的一整套路由。有了这样一个列表，这些路由器永远不会使用默认路由。目标地址与任何路由都不匹配的数据报将被这样的路由器丢弃。
The opportunistic encryption security gateway (OE gateway) is a regular gateway node, as described in [RFC0791] section 2.4 and [RFC1812], with the additional capabilities described here and in [RFC2401]. The algorithm described here provides a way to determine, for each datagram, whether or not to encrypt and tunnel the datagram. Two important things that must be determined are whether or not to encrypt and tunnel and, if so, the destination address or name of the tunnel endpoint that should be used.
机会加密安全网关（OE网关）是一个常规网关节点，如[RFC0791]第2.4节和[RFC1812]所述，具有此处和[RFC2401]中所述的附加功能。这里描述的算法为每个数据报提供了一种确定是否加密和隧道数据报的方法。必须确定的两个重要事项是是否加密和隧道，如果是，则应使用隧道端点的目标地址或名称。
The OE gateway determines whether or not to create a tunnel based on the destination address of each packet. Upon receiving a packet with a destination address not recently seen, the OE gateway performs a lookup in DNS for an authorization resource record (see Section 5.2). The record is located using the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization record is found, the OE gateway interprets this as a request for a tunnel to be formed.
OE网关根据每个数据包的目标地址确定是否创建隧道。在接收到目标地址最近未出现的数据包时，OE网关在DNS中查找授权资源记录（参见第5.2节）。使用IP地址在in-addr.arpa（IPv4）或ip6.arpa（IPv6）映射中查找记录。如果找到授权记录，OE网关会将其解释为请求形成隧道。
The authorization resource record also provides the address or name of the tunnel endpoint that should be used.
授权资源记录还提供应使用的隧道端点的地址或名称。
The record may also provide the public RSA key of the tunnel end point itself. This is provided for efficiency only. If the public RSA key is not present, the OE gateway performs a second lookup to find a KEY resource record for the endpoint address or name.
该记录还可以提供隧道端点本身的公开RSA密钥。这只是为了提高效率。如果公钥不存在，OE网关将执行第二次查找，以查找端点地址或名称的密钥资源记录。
Origin and integrity protection of the resource records is provided by DNSSEC (see [RFC4033]). Section 3.2.4.1 documents an optional restriction on the tunnel endpoint if DNSSEC signatures are not available for the relevant records.
DNSSEC提供资源记录的来源和完整性保护（见[RFC4033]）。第3.2.4.1节记录了如果相关记录没有DNSSEC签名，则隧道端点的可选限制。
The OE gateway maintains a cache, in the forwarding plane, of source/destination pairs for which opportunistic encryption has been attempted. This cache maintains a record of whether or not OE was successful so that subsequent datagrams can be forwarded properly without additional delay.
OE网关在转发平面中维护已尝试机会加密的源/目标对的缓存。该缓存维护OE是否成功的记录，以便后续数据报可以在没有额外延迟的情况下正确转发。
Successful negotiation of OE instantiates a new security association. Failure to negotiate OE results in creation of a forwarding policy entry either to deny or permit transmission in the clear future datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking up the same information.
OE的成功协商将实例化一个新的安全关联。未能协商OE会导致创建转发策略条目，以拒绝或允许在明确的未来数据报中传输。这种负缓存是必要的，以避免重复查找相同信息的可能冗长的过程。
The cache is timed out periodically, as described in Section 3.4. This removes entries that are no longer being used and permits the discovery of changes in authorization policy.
缓存会定期超时，如第3.4节所述。这将删除不再使用的条目，并允许发现授权策略中的更改。
The OE gateway is modeled to have a forwarding plane and a control plane. A control channel, such as PF_KEY [RFC2367], connects the two planes.
OE网关被建模为具有转发平面和控制平面。控制通道（如PF_键[RFC2367]）连接两个平面。
The forwarding plane performs per-datagram operations. The control plane contains a keying daemon, such as ISAKMP/IKE, and performs all authorization, peer authentication, and key derivation functions.
转发平面执行每个数据报的操作。控制平面包含一个键控守护进程，如ISAKMP/IKE，并执行所有授权、对等身份验证和密钥派生功能。
Let the OE gateway maintain a collection of objects -- a superset of the security policy database (SPD) specified in [RFC2401]. For each combination of source and destination address, an SPD object exists in one of five following states. Prior to forwarding each datagram, the responder uses the source and destination addresses to pick an entry from the SPD. The SPD then determines if and how the packet is forwarded.
让OE网关维护一组对象——在[RFC2401]中指定的安全策略数据库（SPD）的超集。对于源地址和目标地址的每个组合，SPD对象存在于以下五种状态之一。在转发每个数据报之前，响应者使用源地址和目标地址从SPD中选择条目。然后，SPD确定数据包是否转发以及如何转发。
.--------------.
| nonexistent |
| policy |
`--------------'
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--'
| |--.
`--------------' \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--'
IPsec | | `-------------'
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------' \ | | discard
\ V | packet
.-------------. |
| deny policy |--'
`-------------'
.--------------.
| nonexistent |
| policy |
`--------------'
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--'
| |--.
`--------------' \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--'
IPsec | | `-------------'
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------' \ | | discard
\ V | packet
.-------------. |
| deny policy |--'
`-------------'
If the gateway does not find an entry, then this policy applies. The gateway creates an entry with an initial state of "hold policy" and requests keying material from the keying daemon. The gateway does not forward the datagram; rather, it SHOULD attach the datagram to the SPD entry as the "first" datagram and retain it for eventual transmission in a new state.
如果网关找不到条目，则应用此策略。网关创建一个初始状态为“保持策略”的条目，并从键控守护进程请求键控材料。网关不转发数据报；相反，它应该将数据报作为“第一”数据报附加到SPD条目上，并将其保留，以便在新状态下进行最终传输。
The gateway requests keying material. If the interface to the keying system is lossy (PF_KEY, for instance, can be), the implementation SHOULD include a mechanism to retransmit the keying request at a rate limited to less than 1 request per second. The gateway does not forward the datagram. The gateway SHOULD attach the datagram to the SPD entry as the "last" datagram, where it is retained for eventual
网关请求键入材料。如果到键控系统的接口是有损的（例如，PF_键可以是），则实现应该包括一种机制，以限制在每秒小于1个请求的速率重新传输键控请求。网关不转发数据报。网关应将数据报作为“最后一个”数据报附加到SPD条目，并保留该数据报以供最终使用
transmission. If there is a datagram already stored in this way, then that already-stored datagram is discarded.
传输如果有一个数据报已经以这种方式存储，那么已经存储的数据报将被丢弃。
The rationale behind saving the "first" and "last" datagrams are as follows: The "first" datagram is probably a TCP SYN packet. Once there is keying established, the gateway will release this datagram, avoiding the need for the endpoint to retransmit the datagram. In the case where the connection was not a TCP connection, but was instead a streaming protocol or a DNS request, the "last" datagram that was retained is likely the most recent data. The difference between "first" and "last" may also help the endpoints determine which data was dropped while negotiation took place.
保存“第一”和“最后”数据报的基本原理如下：“第一”数据报可能是TCP SYN数据包。一旦建立了密钥，网关将释放此数据报，从而避免端点重新传输数据报。如果连接不是TCP连接，而是流协议或DNS请求，则保留的“最后”数据报可能是最新的数据。“第一个”和“最后一个”之间的差异也可能有助于端点确定在进行协商时删除了哪些数据。
The gateway forwards the datagram using the normal forwarding table. The gateway enters this state only by command from the keying daemon, and upon entering this state, also forwards the "first" and "last" datagrams.
网关使用普通转发表转发数据报。网关仅通过来自键控守护进程的命令进入此状态，并且在进入此状态时，还转发“第一个”和“最后一个”数据报。
The gateway discards the datagram. The gateway enters this state only by command from the keying daemon, and upon entering this state, discards the "first" and "last" datagrams. An implementation MAY provide the administrator with a control to determine if further datagrams cause ICMP messages to be generated (i.e., ICMP Destination Unreachable, Communication Administratively Prohibited. type=3, code=13).
网关丢弃数据报。网关仅通过来自键控守护进程的命令进入此状态，并且在进入此状态时，丢弃“第一个”和“最后一个”数据报。一种实现可以向管理员提供一种控制，以确定进一步的数据报是否会导致生成ICMP消息（即，ICMP目的地不可访问，通信被行政禁止。类型=3，代码=13）。
The gateway encrypts the datagram using the indicated security association database (SAD) entry. The gateway enters this state only by command from the keying daemon, and upon entering this state, releases and forwards the "first" and "last" datagrams using the new encrypt policy.
网关使用指定的安全关联数据库（SAD）条目加密数据报。网关仅通过来自键控守护进程的命令进入此状态，进入此状态后，使用新的加密策略释放并转发“第一个”和“最后一个”数据报。
If the associated SAD entry expires because of byte, packet or time limits, then the entry returns to the Hold policy, and an expire message is sent to the keying daemon.
如果关联的SAD条目由于字节、数据包或时间限制而过期，则该条目将返回到保持策略，并向键控守护程序发送过期消息。
All states may be created directly by the keying daemon while acting as a gateway.
所有状态都可以由键控守护进程在充当网关时直接创建。
Let the keying daemon maintain a collection of objects. Let them be called "connections" or "conn"s. There are two categories of connection objects: classes and instances. A class represents an abstract policy (i.e., what could be). An instance represents an actual connection (i.e., what is running at the time).
让键控守护进程维护对象的集合。让它们被称为“连接”或“连接”。有两类连接对象：类和实例。一个类表示一个抽象的策略（即可能是什么）。一个实例表示一个实际的连接（即，当时正在运行的连接）。
Let there be two further subtypes of connections: keying channels (Phase 1 SAs) and data channels (Phase 2 SAs). Each data channel object may have a corresponding SPD and SAD entry maintained by the datagram state machine.
还有两种连接类型：键控通道（阶段1 SAs）和数据通道（阶段2 SAs）。每个数据通道对象可具有由数据报状态机维护的相应SPD和SAD条目。
For the purposes of opportunistic encryption, there MUST, at least, be connection classes known as "deny", "always-clear-text", "OE-permissive", and "OE-paranoid". The latter two connection classes define a set of destination prefixes for which opportunistic encryption will be attempted. The administrator MAY set policy options in a number of additional places. An implementation MAY create additional connection classes to further refine these policies.
出于机会主义加密的目的，至少必须有称为“拒绝”、“始终明文”、“OE许可”和“OE偏执”的连接类。后两个连接类定义了一组目标前缀，将尝试对其进行机会加密。管理员可以在许多其他位置设置策略选项。实现可以创建其他连接类来进一步完善这些策略。
The simplest system may need only the "OE-permissive" connection, and would list its own (single) IP address as the source address of this policy and the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the simplest policy is to try opportunistic encryption with all destinations.
最简单的系统可能只需要“OE许可”连接，并将其自己的（单个）IP地址列为此策略的源地址，通配符地址0.0.0.0/0列为目标IPv4地址。也就是说，最简单的策略是对所有目标尝试机会加密。
This simplest policy SHOULD be offered as a preconfigured default.
这个最简单的策略应该作为预配置的默认策略提供。
The distinction between permissive and paranoid Opportunistic Encryption ("OE-paranoid" below) use will become clear in the state transition differences.
许可和偏执的机会主义加密（以下简称“OE偏执”）使用之间的区别将在状态转换差异中变得清晰。
In brief, an OE-permissive policy means to permit traffic to flow in the clear when there is a failure to find and/or use the encryption keys. OE-permissive permits the network to function, even if in an insecure manner.
简言之，OE许可策略意味着当无法找到和/或使用加密密钥时，允许流量在clear中流动。OE许可允许网络运行，即使是以不安全的方式运行。
On failure, a paranoid OE ("OE-paranoid") will install a drop policy. OE-paranoid permits traffic to flow only when appropriate security is available.
失败时，偏执狂OE（“偏执狂OE”）将安装丢弃策略。OE偏执狂只在适当的安全措施可用时才允许流量流动。
In this description of the keying machine's state transitions, the states associated with the keying system itself are omitted because they are best documented in the keying system ([RFC2407], [RFC2408], and [RFC2409] for ISAKMP/IKE), and the details are keying system specific. Opportunistic encryption is not dependent upon any
在对键控机的状态转换的描述中，省略了与键控系统本身相关联的状态，因为它们最好记录在键控系统中（[RFC2407]、[RFC2408]和[RFC2409]对于ISAKMP/IKE），并且细节是特定于键控系统的。机会主义加密不依赖于任何
specific keying protocol, but this document does provide requirements for those using ISAKMP/IKE to assure that implementations inter-operate.
特定的键控协议，但本文档确实为使用ISAKMP/IKE的人提供了要求，以确保实现相互操作。
The state transitions that may be involved in communicating with the forwarding plane are omitted. PF_KEY and similar protocols have their own set of states required for message sends and completion notifications.
省略与转发平面通信中可能涉及的状态转换。PF_密钥和类似协议有其自己的一组状态，用于消息发送和完成通知。
Finally, the retransmits and recursive lookups that are normal for DNS are not included in this description of the state machine.
最后，DNS正常的重传和递归查找不包括在状态机的描述中。
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------'
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------' | destination `---------------'
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------'
| | connection | ^
| `---------------' |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------'
| | & parse TXT RR| ^
| repeated `---------------' |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------'
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------' | destination `---------------'
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------'
| | connection | ^
| `---------------' |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------'
| | & parse TXT RR| ^
| repeated `---------------' |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
| V |
| phase-2 .---------------. | failure
| failure | pending |---------'
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---' | timeout)
| | | IKE | | ^ |
`----------------| states|---------------'
| +=======+ | |
`---------------' |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----' |
`--------------' |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------'
deny----->| connection |
`--------------'
| dead connection - deleted
V
| V |
| phase-2 .---------------. | failure
| failure | pending |---------'
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---' | timeout)
| | | IKE | | ^ |
`----------------| states|---------------'
| +=======+ | |
`---------------' |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----' |
`--------------' |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------'
deny----->| connection |
`--------------'
| dead connection - deleted
V
There is no connection instance for a given source/destination address pair. Upon receipt of a request for keying material for this source/destination pair, the initiator searches through the connection classes to determine the most appropriate policy. Upon determining an appropriate connection class, an instance object is created of that type. Both of the OE types result in a potential OE connection.
给定的源/目标地址对没有连接实例。在接收到此源/目标对的键控材料请求后，启动器将搜索连接类以确定最合适的策略。确定适当的连接类后，将创建该类型的实例对象。这两种OE类型都会导致潜在的OE连接。
Failure to find an appropriate connection class results in an administrator-defined default.
找不到适当的连接类将导致管理员定义的默认连接。
In each case, when the initiator finds an appropriate class for the new flow, an instance connection is made of the class that matched.
在每种情况下，当发起程序为新流找到合适的类时，将为匹配的类建立实例连接。
The nonexistent connection makes a transition to this state when an always-clear-text class is instantiated, or when an OE-permissive connection fails. During the transition, the initiator creates a pass-through policy object in the forwarding plane for the appropriate flow.
当实例化始终明文类或OE许可连接失败时，不存在的连接将转换到此状态。在转换过程中，启动器在转发平面中为适当的流创建一个直通策略对象。
Timing out is the only way to leave this state (see Section 3.2.7).
超时是离开该状态的唯一方法（见第3.2.7节）。
The empty connection makes a transition to this state when a deny class is instantiated, or when an OE-paranoid connection fails. During the transition, the initiator creates a deny policy object in the forwarding plane for the appropriate flow.
当实例化deny类或OE paranoid连接失败时，空连接会转换到此状态。在转换过程中，启动器在转发平面中为适当的流创建拒绝策略对象。
Timing out is the only way to leave this state (see Section 3.2.7).
超时是离开该状态的唯一方法（见第3.2.7节）。
The empty connection makes a transition to this state when one of either OE class is instantiated. During the transition to this state, the initiator creates a hold policy object in the forwarding plane for the appropriate flow.
当其中一个OE类被实例化时，空连接将转换到此状态。在转换到此状态期间，启动器在转发平面中为适当的流创建一个保持策略对象。
In addition, when making a transition into this state, DNS lookup is done in the reverse-map for a TXT delegation resource record (see Section 5.2). The lookup key is the destination address of the flow.
此外，当转换到此状态时，DNS查找在TXT委派资源记录的反向映射中完成（请参阅第5.2节）。查找键是流的目标地址。
There are three ways to exit this state:
有三种方法可以退出此状态：
1. DNS lookup finds a TXT delegation resource record.
1. DNS查找查找TXT委派资源记录。
2. DNS lookup does not find a TXT delegation resource record.
2. DNS查找未找到TXT委派资源记录。
3. DNS lookup times out.
3. DNS查找超时。
Based upon the results of the DNS lookup, the potential OE connection makes a transition to the pending OE connection state. The conditions for a successful DNS look are:
根据DNS查找的结果，潜在的OE连接将转换为挂起的OE连接状态。DNS查找成功的条件包括：
1. DNS finds an appropriate resource record.
1. DNS找到适当的资源记录。
2. It is properly formatted according to Section 5.2.
2. 根据第5.2节的规定，其格式正确。
3. If DNSSEC is enabled, then the signature has been vouched for.
3. 如果启用了DNSSEC，则签名已得到证明。
Note that if the initiator does not find the public key present in the TXT delegation record, then the public key must be looked up as a sub-state. Only successful completion of all the DNS lookups is considered a success.
请注意，如果启动器在TXT委派记录中未找到公钥，则必须将公钥作为子状态进行查找。只有成功完成所有DNS查找才视为成功。
If DNS lookup does not find a resource record or if DNS times out, then the initiator considers the receiver not OE capable. If this is an OE-paranoid instance, then the potential OE connection makes a transition to the deny connection state. If this is an OE-permissive instance, then the potential OE connection makes a transition to the clear-text connection state.
如果DNS查找未找到资源记录或DNS超时，则发起方认为接收方不具备OE能力。如果这是一个OE偏执实例，那么潜在的OE连接将转换为拒绝连接状态。如果这是OE许可实例，则潜在OE连接将转换为明文连接状态。
If the initiator finds a resource record, but it is not properly formatted, or if DNSSEC is enabled and reports a failure to authenticate, then the potential OE connection makes a transition to the deny connection state. This action SHOULD be logged. If the administrator wishes to override this transition between states, then an always-clear class can be installed for this flow. An implementation MAY make this situation a new class.
如果启动器找到资源记录，但其格式不正确，或者如果启用了DNSSEC并报告身份验证失败，则潜在的OE连接将转换为拒绝连接状态。应记录此操作。如果管理员希望覆盖状态之间的转换，则可以为此流安装始终清除类。一个实现可以使这种情况成为一个新类。
An implementation SHOULD also provide an additional administrative control on delegation records and DNSSEC. This control would apply to delegation records (the TXT records in the reverse-map) that are not protected by DNSSEC. Records of this type are only permitted to delegate to their own address as a gateway. When this option is enabled, an active attack on DNS will be unable to redirect packets to other than the original destination.
实施还应提供对委托记录和DNSSEC的额外管理控制。此控件将应用于不受DNSSEC保护的委派记录（反向映射中的TXT记录）。这种类型的记录只允许作为网关委托给它们自己的地址。启用此选项后，DNS上的主动攻击将无法将数据包重定向到原始目的地以外的位置。
The potential OE connection makes a transition to this state when the initiator determines that all the information required from the DNS lookup is present. Upon entering this state, the initiator attempts to initiate keying to the gateway provided.
当启动器确定存在DNS查找所需的所有信息时，潜在OE连接将转换到此状态。进入此状态后，启动器将尝试启动对所提供网关的键控。
Exit from this state occurs with either a successfully created IPsec SA or a failure of some kind. Successful SA creation results in a transition to the key connection state.
成功创建IPsec SA或出现某种故障时，将退出此状态。成功创建SA将导致转换到密钥连接状态。
Three failures have caused significant problems. They are clearly not the only possible failures from keying.
三次失败造成了重大问题。显然，它们不是键控的唯一可能失败。
Note that if there are multiple gateways available in the TXT delegation records, then a failure can only be declared after all of them have been tried. Further, creation of a phase 1 SA does not constitute success. A set of phase 2 SAs (a tunnel) is considered success.
请注意，如果TXT委派记录中有多个可用网关，则只有在尝试了所有网关之后才能声明失败。此外，创建阶段1 SA并不构成成功。一组第2阶段SAs（隧道）被认为是成功的。
The first failure occurs when an ICMP port unreachable is consistently received without any other communication, or when there is silence from the remote end. This usually means that either the gateway is not alive, or the keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition to the clear-text connection, but with a low lifespan. For an OE-pessimistic connection, the initiator makes a transition to the deny connection again with a low lifespan. The lifespan in both cases is kept low because the remote gateway may be in the process of rebooting or be otherwise temporarily unavailable.
当在没有任何其他通信的情况下一致接收到无法访问的ICMP端口时，或者当来自远程端的静默时，会发生第一个故障。这通常意味着要么网关不活动，要么键控守护进程不起作用。对于OE许可连接，启动器将转换为明文连接，但使用寿命较低。对于OE悲观连接，启动器再次转换到拒绝连接，但使用寿命较低。这两种情况下的使用寿命都很低，因为远程网关可能正在重新启动或暂时不可用。
The length of time to wait for the remote keying daemon to wake up is a matter of some debate. If there is a routing failure, 5 minutes is usually long enough for the network to re-converge. Many systems can reboot in that amount of time as well. However, 5 minutes is far too long for most users to wait to hear that they can not connect using OE. Implementations SHOULD make this a tunable parameter.
等待远程键控守护进程唤醒的时间长度是一个有争议的问题。如果出现路由故障，5分钟的时间通常足以使网络重新聚合。许多系统也可以在这段时间内重新启动。然而，对于大多数用户来说，5分钟太长了，他们无法等待听到他们无法使用OE连接的消息。实现应该使其成为可调参数。
The second failure occurs after a phase 1 SA has been created, but there is either no response to the phase 2 proposal, or the initiator receives a negative notify (the notify must be authenticated). The remote gateway is not prepared to do OE at this time. As before, the initiator makes a transition to the clear-text or the deny connection based upon connection class, but this time with a normal lifespan.
第二个失败发生在阶段1 SA创建之后，但是没有对阶段2提案的响应，或者发起人收到否定通知（通知必须经过身份验证）。远程网关此时不准备执行OE。与前面一样，启动器会根据连接类转换为明文或拒绝连接，但这次的使用寿命正常。
The third failure occurs when there is signature failure while authenticating the remote gateway. This can occur when there has been a key roll-over, but DNS has not caught up. In this case again, the initiator makes a transition to the clear-text or the deny connection based upon the connection class. However, the lifespan depends upon the remaining time to live in the DNS. (Note that DNSSEC signed resource records have a different expiry time from non-signed records.)
第三个失败发生在验证远程网关时出现签名失败时。这可能发生在出现密钥翻滚，但DNS没有跟上的情况下。在这种情况下，启动器再次根据连接类转换为明文或拒绝连接。但是，寿命取决于DNS中剩余的生存时间。（请注意，DNSSEC已签名的资源记录与未签名的记录具有不同的到期时间。）
The pending OE connection makes a transition to this state when session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt policy in the forwarding plane for this flow.
当导出会话键控材料（阶段2 SAs）时，挂起的OE连接将转换到此状态。启动器在转发平面中为此流创建加密策略。
There are three ways to exit this state. The first is by receipt of an authenticated delete message (via the keying channel) from the peer. This is normal teardown and results in a transition to the expired connection state.
有三种方法可以退出此状态。第一种是通过从对等方接收经过身份验证的删除消息（通过密钥通道）。这是正常的拆卸，会导致转换到过期的连接状态。
The second exit is by expiry of the forwarding plane keying material. This starts a re-key operation with a transition back to pending OE connection. In general, the soft expiry occurs with sufficient time left to continue using the keys. A re-key can fail, which may result in the connection failing to clear-text or deny as appropriate. In the event of a failure, the forwarding plane policy does not change until the phase 2 SA (IPsec SA) reaches its hard expiry.
第二个出口是转发平面键控材料到期。这将启动重新设置密钥的操作，并转换回挂起的OE连接。一般来说，软过期发生时，有足够的时间继续使用键。重新设置密钥可能会失败，这可能导致连接无法清除文本或拒绝（视情况而定）。在发生故障的情况下，在阶段2 SA（IPsec SA）达到其硬到期之前，转发平面策略不会更改。
The third exit is in response to a negotiation from a remote gateway. If the forwarding plane signals the control plane that it has received an unknown SPI from the remote gateway, or an ICMP is received from the remote gateway indicating an unknown SPI, the initiator should consider that the remote gateway has rebooted or restarted. Since these indications are easily forged, the implementation must exercise care. The initiator should make a cautious (rate-limited) attempt to re-key the connection.
第三个出口是对来自远程网关的协商的响应。如果转发平面向其接收到从远程网关接收到未知SPI的控制平面，或者从远程网关接收指示未知SPI的ICMP，则发起方应考虑远程网关已重新启动或重新启动。由于这些指示很容易伪造，因此实施时必须小心。发起者应谨慎（速率受限）尝试重新设置连接密钥。
The initiator will periodically place each of the deny, clear-text, and keyed connections into this sub-state. See Section 3.4 for more details of how often this occurs. The initiator queries the forwarding plane for last use time of the appropriate policy. If the last use time is relatively recent, then the connection returns to the previous deny, clear-text or keyed connection state. If not, then the connection enters the expired connection state.
启动器将定期将每个拒绝、明文和键控连接置于此子状态。有关这种情况发生频率的更多详细信息，请参见第3.4节。启动器向转发平面查询适当策略的上次使用时间。如果上次使用时间相对较短，则连接将返回到以前的拒绝、明文或键控连接状态。如果没有，则连接将进入过期连接状态。
The DNS query and answer that lead to the expiring connection state are also examined. The DNS query may become stale. (A negative, i.e., no such record, answer is valid for the period of time given by the MINIMUM field in an attached SOA record. See [RFC1034] section 4.3.4.) If the DNS query is stale, then a new query is made. If the results change, then the connection makes a transition to a new state as described in potential OE connection state.
还将检查导致连接状态过期的DNS查询和应答。DNS查询可能会过时。（否定，即没有此类记录，答案在所附SOA记录中最小字段给出的时间段内有效。请参阅[RFC1034]第4.3.4节。）如果DNS查询过时，则进行新查询。如果结果发生变化，则连接将转换到新状态，如潜在OE连接状态中所述。
Note that when considering how stale a connection is, both outgoing SPD and incoming SAD must be queried as some flows may be unidirectional for some time.
请注意，当考虑连接的陈旧程度时，必须同时查询传出SPD和传入SAD，因为某些流在一段时间内可能是单向的。
Also note that the policy at the forwarding plane is not updated unless there is a conclusion that there should be a change.
还请注意，转发平面上的策略不会更新，除非得出应该进行更改的结论。
Entry to this state occurs when no datagrams have been forwarded recently via the appropriate SPD and SAD objects. The objects in the forwarding plane are removed (logging any final byte and packet counts, if appropriate) and the connection instance in the keying plane is deleted.
如果最近没有通过适当的SPD和SAD对象转发数据报，则会进入此状态。删除转发平面中的对象（记录任何最终字节和数据包计数，如果合适），并删除键控平面中的连接实例。
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in Section 3.4.
启动器发送ISAKMP/IKE delete以清除第2阶段SAs，如第3.4节所述。
Whether or not to delete the phase 1 SAs at this time is left as a local implementation issue. Implementations that do delete the phase 1 SAs MUST send authenticated delete messages to indicate that they are doing so. There is an advantage to keeping the phase 1 SAs until they expire: they may prove useful again in the near future.
此时是否删除第1阶段SAs仍属于本地实施问题。确实删除阶段1 SA的实现必须发送经过身份验证的删除消息，以指示它们正在这样做。将阶段1 SA保留到到期有一个好处：它们可能在不久的将来再次被证明是有用的。
The responder has a set of objects identical to those of the initiator.
响应者有一组与启动器相同的对象。
The responder receives an invitation to create a keying channel from an initiator.
响应者从发起方接收创建键控通道的邀请。
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------'
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---'
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------' connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------'
|
|
V
potential OE
connection in
initiator state
machine
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------'
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---'
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------' connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------'
|
|
V
potential OE
connection in
initiator state
machine
Upon entering this state, the responder starts a DNS lookup for a KEY record for the initiator. The responder looks in the reverse-map for a KEY record for the initiator if the initiator has offered an ID_IPV4_ADDR, and in the forward map if the initiator has offered an ID_FQDN type. (See [RFC2407] section 4.6.2.1.)
进入此状态后，响应程序开始DNS查找启动器的密钥记录。如果启动器提供了ID_IPV4_ADDR，则响应程序在反向映射中查找启动器的密钥记录，如果启动器提供了ID_FQDN类型，则在正向映射中查找。（见[RFC2407]第4.6.2.1节。）
The responder exits this state upon successful receipt of a KEY from DNS, and use of the key to verify the signature of the initiator.
响应程序在成功接收到来自DNS的密钥并使用该密钥验证启动器的签名后退出此状态。
Successful authentication of the peer results in a transition to the authenticated OE Peer state.
对等身份验证成功将导致转换到已验证的OE对等状态。
Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation protocol. It is really a form of pseudo-state.
注意，未经验证的OE对等状态通常发生在密钥协商协议的中间。它实际上是一种伪状态。
The peer will eventually propose one or more phase 2 SAs. The responder uses the source and destination address in the proposal to finish instantiating the connection state using the connection class table. The responder MUST search for an identical connection object at this point.
对等方最终将提出一个或多个阶段2 SA。响应者使用建议中的源地址和目标地址，使用连接类表完成连接状态的实例化。此时响应程序必须搜索相同的连接对象。
If an identical connection is found, then the responder deletes the old instance, and the new object makes a transition to the pending OE connection state. This means that new ISAKMP connections with a given peer will always use the latest instance, which is the correct one if the peer has rebooted in the interim.
如果发现相同的连接，那么响应程序将删除旧实例，新对象将转换为挂起的OE连接状态。这意味着与给定对等方的新ISAKMP连接将始终使用最新实例，如果对等方在此期间重新启动，则该实例是正确的。
If an identical connection is not found, then the responder makes the transition according to the rules given for the initiator: it installs appropriate policy: clear, drop, or OE.
如果未找到相同的连接，则响应程序将根据为启动器提供的规则进行转换：它将安装适当的策略：清除、删除或OE。
If OE, and the phase 2 ID (source IP) is different than the phase 1 ID, then additional authorization is required. A TXT record associated with the proposed phase 2 source IP is requested. This is used to confirm authorization for the phase 1 identity to encrypt on behalf of the phase 2. Successful retrieval results in a transition to "Authorized OE Peer".
如果OE和阶段2 ID（源IP）与阶段1 ID不同，则需要额外授权。请求与提议的第2阶段源IP相关的TXT记录。这用于确认阶段1身份的授权，以代表阶段2进行加密。成功检索将导致转换为“授权OE对等方”。
Note that if the initiator is in OE-paranoid mode and the responder is in either always-clear-text or deny, then no communication is possible according to policy. An implementation is permitted to create new types of policies such as "accept OE but do not initiate it". This is a local matter.
请注意，如果发起者处于OE偏执模式，而响应者处于始终明文或拒绝模式，则根据策略，无法进行通信。允许实施创建新类型的策略，例如“接受OE但不启动OE”。这是当地的事。
This state is entered from the Authenticated OE Peer state, upon successful retrieval of the TXT record. The contents of the record are confirmed -- any failures lead to errors, as indicated in Section 3.2.4.
在成功检索TXT记录后，从已验证的OE对等状态输入此状态。确认记录内容——如第3.2.4节所示，任何故障都会导致错误。
A potentially unlimited number of tunnels may exist. In practice, only a few tunnels are used during a period of time. Unused tunnels MUST, therefore, be torn down. Detecting when tunnels are no longer in use is the subject of this section.
可能存在无限数量的隧道。在实践中，一段时间内仅使用少数隧道。因此，必须拆除未使用的隧道。检测隧道何时不再使用是本节的主题。
There are two methods for removing tunnels: explicit deletion or expiry.
删除隧道有两种方法：显式删除或过期。
Explicit deletion requires an IKE delete message. The deletes MUST be authenticated, so both ends of the tunnel must maintain the keying channel (phase 1 ISAKMP SA). An implementation that refuses to either maintain or recreate the keying channel SA will be unable to use this method.
显式删除需要IKE delete消息。删除操作必须经过身份验证，因此隧道两端必须保持键控通道（阶段1 ISAKMP SA）。拒绝维护或重新创建键控通道SA的实现将无法使用此方法。
The tunnel expiry method simply allows the IKE daemon to expire normally without attempting to re-key it.
隧道过期方法只允许IKE守护进程正常过期，而无需尝试对其重新设置密钥。
Regardless of which method is used to remove tunnels, the implementation MUST use a method to determine if the tunnel is still in use. The specifics are a local matter, but the FreeS/WAN project uses the following criteria. These criteria are currently implemented in the key management daemon, but could also be implemented at the SPD layer using an idle timer.
无论使用哪种方法移除隧道，实现都必须使用一种方法来确定隧道是否仍在使用中。具体细节是本地事务，但FreeS/WAN项目使用以下标准。这些标准目前在密钥管理守护进程中实现，但也可以使用空闲计时器在SPD层实现。
Set a short initial (soft) lifespan of 1 minute since many net flows last only a few seconds.
将初始（软）寿命设置为1分钟，因为许多净流量仅持续几秒钟。
At the end of the lifespan, check to see if the tunnel was used by traffic in either direction during the last 30 seconds. If so, assign a longer tentative lifespan of 20 minutes, after which, look again. If the tunnel is not in use, then close the tunnel.
在使用寿命结束时，检查隧道在过去30秒内是否被任何方向的车辆使用。如果是这样的话，请指定一个20分钟的更长的暂定寿命，然后再看一看。如果隧道未使用，则关闭隧道。
The expiring state in the key management system (see Section 3.2.7) implements these timeouts. The timer above may be in the forwarding plane, but then it must be resettable.
密钥管理系统中的到期状态（见第3.2.7节）实现这些超时。上面的计时器可能在转发平面中，但必须可重置。
The tentative lifespan is independent of re-keying; it is just the time when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) Unlike re-keying, this tunnel use check is not costly and should happen reasonably frequently.
暂定寿命与重新设置密钥无关；现在正是考虑隧道未来的时候。（由于这个原因，这里使用的是“寿命”一词，而不是“寿命”）。与重新设置密钥不同，此隧道使用检查成本不高，应该经常进行。
A multi-step back-off algorithm is not considered worth the effort here.
在这里，多步退避算法被认为是不值得的。
If the security gateway and the client host are the same, and not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown decisions MAY pay attention to TCP connection status as reported by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is expected. Closing of the only TCP connection through a tunnel is a strong hint that no more traffic is expected.
如果安全网关和客户机主机相同，而不是堆栈中的凹凸或有线实现中的凹凸，则隧道拆卸决策可能会注意本地TCP层报告的TCP连接状态。仍然开放的TCP连接几乎可以保证预期会有更多的流量。关闭通过隧道的唯一TCP连接是一个强烈的提示，表明预计不会有更多的流量。
Teardown should always be coordinated between the two ends of the tunnel by interpreting and sending delete notifications. There is a detailed sub-state in the expired connection state of the key manager that relates to retransmits of the delete notifications, but this is considered to be a keying system detail.
应始终通过解释和发送删除通知来协调隧道两端的拆卸。密钥管理器的过期连接状态中有一个详细的子状态，与删除通知的重新传输有关，但这被认为是密钥系统的详细信息。
On receiving a delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones also and notify the remote end with a delete. If the local system receives a delete for a tunnel that is no longer in existence, then two delete messages have crossed paths. Ignore the delete. The operation has already been completed. Do not generate any messages in this situation.
在接收到隧道（或其中的一些子集）的出站SA的删除后，还应拆除入站SA，并用删除通知远程端。如果本地系统接收到已不存在的隧道的删除，则两条删除消息已交叉。忽略删除。操作已完成。在这种情况下，不要生成任何消息。
Tunnels are to be considered as bidirectional entities, even though the low-level protocols don't treat them this way.
隧道被视为双向实体，即使低级协议不这样处理它们。
When the deletion is initiated locally, rather than as a response to a received delete, send a delete for (all) the inbound SAs of a tunnel. If the local system does not receive a responding delete for the outbound SAs, try re-sending the original delete. Three tries spaced 10 seconds apart seems a reasonable level of effort. A failure of the other end to respond after 3 attempts indicates that the possibility of further communication is unlikely. Remove the outgoing SAs. (The remote system may be a mobile node that is no longer present or powered on.)
在本地启动删除时，而不是作为对接收到的删除的响应，为隧道的（所有）入站SA发送删除。如果本地系统没有收到出站SAs的响应删除，请尝试重新发送原始删除。间隔10秒的三次尝试似乎是合理的努力水平。另一端在3次尝试后未能响应表明不太可能进行进一步通信。卸下传出SAs。（远程系统可能是不再存在或已通电的移动节点。）
After re-keying, transmission should switch to using the new outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs should be cleared out promptly (delete should be sent for the
重新键入密钥后，传输应立即切换到使用新的传出SAs（ISAKMP或IPsec），并应立即清除旧的剩余传出SAs（应为
outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics.
而不是等待它们过期。这减少了混乱，并最大限度地减少了操作员进行诊断时的混乱。
The IKE wire protocol needs no modifications. The major changes are implementation issues relating to how the proposals are interpreted, and from whom they may come.
IKE wire协议不需要修改。主要的变化是与如何解释提案以及提案来自谁有关的实施问题。
As opportunistic encryption is designed to be useful between peers without prior operator configuration, an IKE daemon must be prepared to negotiate phase 1 SAs with any node. This may require a large amount of resources to maintain cookie state, as well as large amounts of entropy for nonces, cookies, and so on.
由于机会主义加密被设计为在没有事先操作员配置的对等方之间有用，因此必须准备一个IKE守护进程来与任何节点协商阶段1 SAs。这可能需要大量资源来维护cookie状态，以及nonce、cookie等的大量熵。
The major changes to support opportunistic encryption are at the IKE daemon level. These changes relate to handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be co-resident on the same gateway.
支持机会加密的主要更改是在IKE守护进程级别。这些更改涉及到密钥获取请求的处理、公钥和TXT记录的查找，以及与防火墙和可能共同驻留在同一网关上的其他安全设施的交互。
In a typical configured tunnel, the address of SG-B is provided via configuration. Furthermore, the mapping of an SPD entry to a gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then the mapping to a gateway is determined by the reverse DNS records.
在典型配置的隧道中，SG-B的地址通过配置提供。此外，SPD条目到网关的映射通常为1:1映射。当使用0.0.0.0/0 SPD输入技术时，到网关的映射由反向DNS记录确定。
The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. Although a synchronous DNS request can be implemented for proof of concept, experience is that it can cause very high latencies when a queue of queries must all timeout in series.
进行DNS查找并等待回复的需要通常会向IKE引入新状态和新事件源（DNS回复）。虽然可以实现同步DNS请求以进行概念验证，但经验表明，当查询队列必须全部串联超时时，它可能会导致非常高的延迟。
Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with some of the protocol steps.
使用异步DNS查找还将允许DNS查找与某些协议步骤重叠。
SG-A will have to establish its identity. Use an IPv4 (IPv6) ID in phase 1.
SG-A必须确定其身份。在阶段1中使用IPv4（IPv6）ID。
There are many situations where the administrator of SG-A may not be able to control the reverse DNS records for SG-A's public IP address. Typical situations include dialup connections and most residential-
在许多情况下，SG-A的管理员可能无法控制SG-A公共IP地址的反向DNS记录。典型情况包括拨号连接和大多数住宅连接-
type broadband Internet access (ADSL, cable-modem) connections. In these situations, a fully qualified domain name that is under the control of SG-A's administrator may be used when acting as an initiator only. The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions.
类型宽带互联网接入（ADSL、电缆调制解调器）连接。在这些情况下，在SG-a管理员控制下的完全限定域名只能作为启动器使用。应在阶段1中使用FQDN ID。有关更多详细信息和限制，请参见第5.3节。
Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or an FQDN ID, an IKE daemon needs to examine local caches and configuration files to determine if this is part of a configured tunnel. If no configured tunnels are found, then the implementation should attempt to retrieve a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN ID.
收到具有IPv4（IPv6）ID或FQDN ID的第1阶段SA建议后，IKE守护程序需要检查本地缓存和配置文件，以确定这是否是已配置隧道的一部分。如果未找到已配置的隧道，则实现应尝试在IPv4/IPv6 ID的情况下从反向DNS检索密钥记录，或在FQDN ID的情况下从正向DNS检索密钥记录。
It is reasonable that if other non-local sources of policy are used (COPS, LDAP), they be consulted concurrently, but that some clear ordering of policy be provided. Note that due to variances in latency, implementations must wait for positive or negative replies from all sources of policy before making any decisions.
合理的做法是，如果使用其他非本地策略源（COP、LDAP），可以同时咨询它们，但必须提供一些明确的策略顺序。请注意，由于延迟的差异，实现必须等待所有策略源的肯定或否定答复，然后才能做出任何决定。
The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, nor uses the NSEC records to provide authentication of the absence of a TXT or KEY record. Rather, this implementation uses a trusted path to a DNSSEC-capable caching resolver.
所述实现（FRES/WAN 1.98）既不直接使用DNSSEC来明确验证区域信息的真实性，也不使用NSEC记录来验证是否存在TXT或密钥记录。相反，此实现使用到支持DNSSEC的缓存解析器的受信任路径。
To distinguish between an authenticated and an unauthenticated DNS resource record, a stub resolver capable of returning DNSSEC information MUST be used.
要区分已验证和未验证的DNS资源记录，必须使用能够返回DNSSEC信息的存根解析器。
Main mode MUST be used.
必须使用主模式。
The initiator MUST offer at least one proposal using some combination of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be proposed first. (See [RFC3526])
发起人必须至少提供一份提案，使用3DES、HMAC-MD5或HMAC-SHA1、DH组2或5的组合。应首先提出第5组。（参见[RFC3526]）
The initiator MAY offer additional proposals, but the cipher MUST not be weaker than 3DES. The initiator SHOULD limit the number of proposals such that the IKE datagrams do not need to be fragmented.
发起者可以提供其他建议，但密码不得弱于3DES。发起人应限制提议的数量，以便IKE数据报不需要分段。
The responder MUST accept one of the proposals. If any configuration of the responder is required, then the responder is not acting in an opportunistic way.
响应者必须接受其中一个建议。如果需要响应者的任何配置，则响应者不会以机会主义方式行事。
The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external interface of the initiator for phase 1. (There is an exception, see Section 5.3.) The authentication method MUST be RSA public key signatures. The RSA key for the initiator SHOULD be placed into a DNS KEY record in the reverse space of the initiator (i.e., using in-addr.arpa or ip6.arpa).
启动器应使用阶段1启动器外部接口的ID_IPV4_ADDR（IPV6的ID_IPV6_ADDR）。（有一个例外，请参见第5.3节。）身份验证方法必须是RSA公钥签名。启动器的RSA密钥应放入启动器反向空间中的DNS密钥记录中（即，使用in-addr.arpa或ip6.arpa）。
The initiator MUST propose a tunnel between the ultimate sender ("Alice" or "A") and ultimate recipient ("Bob" or "B") using 3DES-CBC mode, MD5, or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
发起者必须使用3DES-CBC模式、MD5或SHA1身份验证在最终发送者（“Alice”或“a”）和最终接收者（“Bob”或“B”）之间建立隧道。必须规定完全的前向保密。
Tunnel mode MUST be used.
必须使用隧道模式。
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
标识必须是ID\u IPV4\u ADDR\u子网，掩码为/32。
Authorization for the initiator to act on Alice's behalf is determined by looking for a TXT record in the reverse-map at Alice's IP address.
启动器代表Alice行事的授权是通过在Alice IP地址的反向映射中查找TXT记录来确定的。
Compression SHOULD NOT be mandatory. It MAY be offered as an option.
压缩不应该是强制性的。它可以作为一个选项提供。
In order to establish their own identities, security gateways SHOULD publish their public keys in their reverse DNS via DNSSEC's KEY record. See section 3 of RFC 2535 [RFC2535].
为了建立自己的身份，安全网关应通过DNSSEC的密钥记录在其反向DNS中发布其公钥。参见RFC 2535[RFC2535]第3节。
For example:
例如：
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
钥匙0x4200 4 1 AQNJjkKlIk9…NYUKK8
0x4200: The flag bits, indicating that this key is prohibited for confidentiality use (it authenticates the peer only, a separate Diffie-Hellman exchange is used for confidentiality), and that this key is associated with the non-zone entity whose name is the RR owner name. No other flags are set.
0x4200:标志位，指示此密钥禁止用于机密性（它仅对对等方进行身份验证，单独的Diffie-Hellman交换用于机密性），并且此密钥与名称为RR所有者名称的非区域实体相关联。没有设置其他标志。
4: This indicates that this key is for use by IPsec.
4：这表示此密钥供IPsec使用。
1: An RSA key is present.
1：存在RSA密钥。
AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in [RFC3110].
AQNJKKLIK9…NYUKK8：主机的公钥，如[RFC3110]所述。
Use of several KEY records allows for key roll-over. The SIG Payload in IKE phase 1 SHOULD be accepted if the public key, given by any KEY RR, validates it.
使用多个钥匙记录允许钥匙翻滚。如果任何密钥RR给出的公钥验证了IKE阶段1中的SIG有效负载，则应接受该有效负载。
If, for example, machine Alice wishes SG-A to act on her behalf, then she publishes a TXT record to provide authorization for SG-A to act on Alice's behalf. This is done similarly for Bob and SG-B.
例如，如果机器Alice希望SG-A代表她行事，那么她会发布一条TXT记录，为SG-A代表Alice行事提供授权。对于Bob和SG-B，这是类似的。
These records are located in the reverse DNS (in-addr.arpa or ip6.arpa) for their respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC. DNSSEC is required to defend against active attacks.
这些记录位于其各自IP地址的反向DNS（in-addr.arpa或ip6.arpa）中。反向DNS应由DNSSEC保护。DNSSEC需要防御主动攻击。
If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at:
如果Alice的地址是P.Q.R.s，则她可以通过在以下位置发布记录来授权另一个节点代表她行事：
S.R.Q.P.in-addr.arpa
S.R.Q.P.in-addr.arpa
The contents of the resource record are expected to be a string that uses the following syntax, as suggested in RFC1464 [RFC1464]. (Note that the reply to query may include other TXT resource records used by other applications.)
资源记录的内容应该是使用以下语法的字符串，如RFC1464[RFC1464]中所建议的。（请注意，对查询的回复可能包括其他应用程序使用的其他TXT资源记录。）
X-IPsec-Server(P)=A.B.C.D public-key
X-IPsec-Server（P）=A.B.C.D公钥
Figure 2: Format of reverse delegation record
图2：反向委托记录的格式
P: Specifies a precedence for this record. This is similar to MX record preferences. Lower numbers have stronger preference.
P：指定此记录的优先级。这类似于MX记录首选项。数字越低，偏好越强。
A.B.C.D: Specifies the IP address of the Security Gateway for this client machine.
A.B.C.D:指定此客户端计算机的安全网关的IP地址。
public-key: Is the encoded RSA Public key of the Security Gateway. The public-key is provided here to avoid a second DNS lookup. If this field is absent, then a KEY resource record should be looked up in the reverse-map of A.B.C.D. The key is transmitted in base64 format.
公钥：是安全网关的编码RSA公钥。此处提供公钥是为了避免第二次DNS查找。如果此字段不存在，则应在a.B.C.D.的反向映射中查找密钥资源记录。密钥以base64格式传输。
The fields of the record MUST be separated by whitespace. This MAY be: space, tab, newline, or carriage return. A space is preferred.
记录的字段必须用空格分隔。这可能是：空格、制表符、换行符或回车符。一个空间是首选。
In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse-map), then Alice may delegate to a public key by domain name.
如果Alice位于没有固定地址（或无法控制其反向映射）的安全网关后面的公共地址，则Alice可以通过域名委托给公钥。
X-IPsec-Server(P)=@FQDN public-key
X-IPsec-Server(P)=@FQDN public-key
Figure 3: Format of reverse delegation record (FQDN version)
图3：反向委托记录的格式（FQDN版本）
P: Is as above. FQDN: Specifies the FQDN that the Security Gateway will identify itself with. public-key: Is the encoded RSA Public key of the Security Gateway.
P:同上。FQDN：指定安全网关将使用其标识自身的FQDN。公钥：是安全网关的编码RSA公钥。
If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records.
如果存在多个具有最强（编号最低）优先级的此类TXT记录，则从最强首选项记录中指定的安全网关中任意选择一个。
When packed into wire-format, TXT records that are longer than 255 characters are divided into smaller <character-strings>. (See [RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored.
当打包成wire格式时，长度超过255个字符的TXT记录被分成更小的<character string>。（参见[RFC1035]第3.3节和第3.3.14节。）必须将其重新组装成单个字符串进行处理。base64编码中的空白字符将被忽略。
It has been suggested to use the KEY, OPT, CERT, or KX records instead of a TXT record. None is satisfactory.
建议使用KEY、OPT、CERT或KX记录，而不是TXT记录。没有一个是令人满意的。
The KEY RR has a protocol field that could be used to indicate a new protocol, and an algorithm field that could be used to indicate different contents in the key data. However, the KEY record is clearly not intended for storing what are really authorizations, it is just for identities. Other uses have been discouraged.
密钥RR有一个可用于指示新协议的协议字段和一个可用于指示密钥数据中不同内容的算法字段。然而，密钥记录显然不是用于存储真正的授权，它只是用于标识。其他用途已被劝阻。
OPT resource records, as defined in [RFC2671], are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are, therefore, inappropriate for use here.
[RFC2671]中定义的OPT资源记录不用于存储信息。它们不会被加载、缓存或转发。因此，它们不适合在这里使用。
CERT records [RFC2538] can encode almost any set of information. A custom type code could be used permitting any suitable encoding to be stored, not just X.509. According to the RFC, the certificate RRs are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers.
证书记录[RFC2538]几乎可以对任何一组信息进行编码。可以使用自定义类型代码来存储任何合适的编码，而不仅仅是X.509。根据RFC，证书RRs将在内部签名，这可能会增加不需要和不必要的批量。较大的DNS记录可能需要TCP而不是UDP传输。
At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be investigated, and may be proposed in a future revision of this document.
在协议设计时，CERT-RR没有得到广泛的部署，因此不能被依赖。将对CERT记录的使用进行调查，并可能在本文件的未来版本中提出建议。
KX records are ideally suited for use instead of TXT records, but had not been deployed at the time of implementation.
KX记录非常适合代替TXT记录使用，但在实施时尚未部署。
Unfortunately, not every administrator has control over the contents of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the authorization record present in the reverse-map of Alice may refer to a FQDN instead of an IP address.
不幸的是，并不是每个管理员都能控制反向映射的内容。当启动器（SG-A）没有合适的反向映射时，Alice反向映射中的授权记录可能引用FQDN而不是IP地址。
In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A forward lookup for a KEY record on the FQDN must yield the initiator's public key.
在这种情况下，客户端的TXT记录提供完全限定的域名（FQDN）来代替其安全网关的IP地址。启动器应在阶段1中使用ID_FQDN ID有效负载。FQDN上的密钥记录的正向查找必须产生启动器的公钥。
This method can also be used when the external address of SG-A is dynamic.
当SG-A的外部地址是动态的时，也可以使用此方法。
If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse-map. When Alice and SG-A are one and the same (i.e., Alice is acting as an end-node) then there is no need for this when initiating only.
如果SG-A代表Alice行事，则Alice仍必须在其反向地图中授权SG-A这样做。当Alice和SG-A是同一个节点（即Alice充当终端节点）时，仅在启动时不需要这样做。
However, Alice must still delegate to herself if she wishes others to initiate OE to her. See Figure 3.
然而，如果Alice希望其他人向她发起OE，她仍然必须授权给自己。参见图3。
Good cryptographic hygiene says that one should replace public/private key pairs periodically. Some administrators may wish to do this as often as daily. Typical DNS propagation delays are determined by the SOA Resource Record MINIMUM parameter, which controls how long DNS replies may be cached. For reasonable operation of DNS servers, administrators usually want this value to be at least several hours, sometimes as a long as a day. This presents a problem: a new key MUST not be used prior to its propagation through DNS.
良好的密码卫生要求定期更换公钥/私钥对。一些管理员可能希望每天都这样做。典型的DNS传播延迟由SOA资源记录最小参数确定，该参数控制DNS回复的缓存时间。为了DNS服务器的合理运行，管理员通常希望该值至少为几个小时，有时长达一天。这就产生了一个问题：在新密钥通过DNS传播之前，不能使用它。
This problem is dealt with by having the Security Gateway generate a new public/private key pair, at least MINIMUM seconds in advance of using it. It then adds this key to the DNS (both as a second KEY
通过让安全网关至少在使用前几秒钟生成新的公钥/私钥对来解决此问题。然后，它将此密钥添加到DNS（都作为第二个密钥）
record and in additional TXT delegation records) at key generation time. Note: only one key is allowed in each TXT record.
在密钥生成时记录和其他TXT委托记录）。注意：每个TXT记录中只允许有一个键。
When authenticating, all gateways MUST have available all public keys that are found in DNS for this entity. This permits the authenticating end to check both the key for "today" and the key for "tomorrow". Note that it is the end which is creating the signature (possesses the private key) that determines which key is to be used.
进行身份验证时，所有网关必须具有此实体在DNS中找到的所有可用公钥。这允许认证端同时检查“今天”和“明天”的密钥。请注意，创建签名（拥有私钥）的目的是确定要使用哪个密钥。
There are no fundamentally new issues for implementing opportunistic encryption in the presence of network address translation. Rather, there are only the regular IPsec issues with NAT traversal.
在存在网络地址转换的情况下，实现机会加密没有根本性的新问题。相反，NAT遍历只存在常规的IPsec问题。
There are several situations to consider for NAT.
NAT有几种情况需要考虑。
If a security gateway is also performing network address translation on behalf of an end-system, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typically configured tunnels, which often exist to bridge islands of private network address space. The security gateway will use the translated source address for phase 2, and so the responding security gateway will look up that address to confirm SG-A's authorization.
如果安全网关也代表终端系统执行网络地址转换，则应在对数据包进行机会加密之前对其进行转换。这与通常配置的隧道不同，隧道通常用于桥接专用网络地址空间的孤岛。安全网关将在第2阶段使用转换后的源地址，因此响应的安全网关将查找该地址以确认SG-A的授权。
In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and control over the reverse-map is assumed. Placing of TXT records is possible.
在NAT（1:1）的情况下，进行转换的地址空间必须是全局唯一的，并且假定可以控制反向映射。可以放置TXT记录。
In the case of NAPT (m:1), the address will be the security gateway itself. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse-map. This is identical to situations involving a single host acting on behalf of itself. For initiators (but not responders), an FQDN-style ID can be used to get around a lack of a reverse-map.
对于NAPT（m:1），地址将是安全网关本身。获取密钥和TXT记录的能力将再次取决于是否对反向映射进行管理控制。这与单个主机代表其自身运行的情况相同。对于发起者（但不是响应者），可以使用FQDN样式ID来解决缺少反向映射的问题。
If there is a NAT or NAPT between the security gateways, then normal IPsec NAT traversal problems occur. In addition to the transport problem, which may be solved by other mechanisms, there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for the security gateway, there is no appropriate ID for phase 2. Due to the NAT, the end systems live in different IP address spaces.
如果安全网关之间存在NAT或NAPT，则会出现正常的IPsec NAT穿越问题。除了可以通过其他机制解决的传输问题外，还有使用什么阶段1和阶段2 ID的问题。虽然FQDN可以在安全网关的阶段1期间使用，但阶段2没有合适的ID。由于NAT，终端系统位于不同的IP地址空间。
If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for another end system to address a packet to this end system. Not only is opportunistic encryption impossible, but it is also impossible for any communication to be initiated to the end system. It may be possible for this end system to initiate such communication. This creates an asymmetry, but this is common for NAPT.
如果终端系统位于NAT（可能是SG-B）之后，那么实际上，另一个终端系统无法将数据包寻址到此终端系统。机会主义加密不仅不可能，而且也不可能启动到终端系统的任何通信。该终端系统可能会启动此类通信。这会造成不对称，但这在NAPT中很常见。
When Alice and SG-A are components of the same system, they are considered to be a host implementation. The packet sequence scenario remains unchanged.
当Alice和SG-A是同一系统的组件时，它们被视为主机实现。数据包序列场景保持不变。
Components marked Alice are the upper layers (TCP, UDP, the application), and SG-A is the IP layer.
标记为Alice的组件是上层（TCP、UDP、应用程序），SG-A是IP层。
Note that tunnel mode is still required.
请注意，仍然需要隧道模式。
As Alice and SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice to initiate. She can rely on FQDN in a forward map. This is particularly attractive to mobile nodes such as notebook computers at conferences. To respond, Alice/SG-A will still need an entry in Alice's reverse-map.
由于Alice和SG-A代表自己行事，因此Alice不需要基于TXT的委派记录来启动。她可以在正向映射中依赖FQDN。这对移动节点（如会议中的笔记本电脑）特别有吸引力。为了响应，Alice/SG-A仍然需要在Alice的反向映射中输入一个条目。
If there are multiple paths between Alice and Bob (as illustrated in the diagram with SG-D), then additional DNS records are required to establish authorization.
如果Alice和Bob之间存在多条路径（如SG-D图所示），则需要额外的DNS记录来建立授权。
In Figure 1, Alice has two ways to exit her network: SG-A and SG-D. Previously, SG-D has been ignored. Postulate that there are routers between Alice and her set of security gateways (denoted by the + signs and the marking of an autonomous system number for Alice's network). Datagrams may, therefore, travel to either SG-A or SG-D en route to Bob.
在图1中，Alice有两种退出网络的方法：SG-A和SG-D。以前，SG-D被忽略。假设Alice和她的一组安全网关之间存在路由器（用+符号表示，并标记Alice网络的自治系统编号）。因此，数据报可能在发送至Bob的途中发送至SG-A或SG-D。
As long as all network connections are in good order, it does not matter how datagrams exit Alice's network. When they reach either security gateway, the security gateway will find the TXT delegation record in Bob's reverse-map, and establish an SA with SG-B.
只要所有网络连接都处于良好状态，数据报如何退出Alice的网络并不重要。当它们到达任一安全网关时，安全网关将在Bob的反向映射中找到TXT委派记录，并使用SG-B建立SA。
SG-B has no problem establishing that either of SG-A or SG-D may speak for Alice, because Alice has published two equally weighted TXT delegation records:
SG-B可以确定SG-A或SG-D中的任何一个可以代表Alice发言，因为Alice已经发布了两个同等权重的TXT授权记录：
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
Figure 4: Multiple gateway delegation example for Alice
图4:Alice的多网关委派示例
Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through their tunnel to SG-B.
Alice的路由器现在可以进行任何需要的负载共享。SG-A和SG-D都通过隧道向SG-B发送发往Bob的数据报。
Alice's use of non-equal weight delegation records to show preference of one gateway over another, has relevance only when SG-B is initiating to Alice.
Alice使用非等重委托记录来显示一个网关对另一个网关的偏好，只有在SG-B向Alice发起时才具有相关性。
If the precedences are the same, then SG-B has a more difficult time. It must decide which of the two tunnels to use. SG-B has no information about which link is less loaded, nor which security gateway has more cryptographic resources available. SG-B, in fact, has no knowledge of whether both gateways are even reachable.
如果先例相同，则SG-B的时间更为困难。它必须决定使用两条隧道中的哪一条。SG-B没有关于哪个链路负载较少的信息，也没有关于哪个安全网关具有更多可用加密资源的信息。事实上，SG-B不知道两个网关是否都可以到达。
The Public Internet's default-free zone may well know a good route to Alice, but the datagrams that SG-B creates must be addressed to either SG-A or SG-D; they can not be addressed to Alice directly.
公共互联网的默认自由区很可能知道通往Alice的好路线，但SG-B创建的数据报必须发送给SG-a或SG-D；它们不能直接寄给爱丽丝。
SG-B may make a number of choices:
SG-B可做出多种选择：
1. It can ignore the problem and round robin among the tunnels. This causes losses during times when one or the other security gateway is unreachable. If this worries Alice, she can change the weights in her TXT delegation records. 2. It can send to the gateway from which it most recently received datagrams. This assumes that routing and reachability are symmetrical. 3. It can listen to BGP information from the Internet to decide which system is currently up. This is clearly much more complicated, but if SG-B is already participating in the BGP peering system to announce Bob, the results data may already be available to it. 4. It can refuse to negotiate the second tunnel. (It is unclear whether or not this is even an option.) 5. It can silently replace the outgoing portion of the first tunnel with the second one while still retaining the incoming portions of both. Thus, SG-B can accept datagrams from either SG-A or SG-D, but send only to the gateway that most recently re-keyed with it.
1. 它可以忽略问题，在隧道之间进行循环。当一个或另一个安全网关无法访问时，这会导致丢失。如果这让Alice担心，她可以更改TXT委派记录中的权重。2.它可以发送到最近从中接收数据报的网关。这假设路由和可达性是对称的。3.它可以从互联网上收听BGP信息，以确定当前正在运行的系统。这显然要复杂得多，但如果SG-B已经参与BGP对等系统来宣布Bob，那么结果数据可能已经提供给它了。4.它可以拒绝通过第二条隧道。（尚不清楚这是否是一种选择。）。它可以悄悄地用第二个隧道替换第一个隧道的输出部分，同时仍然保留两个隧道的输入部分。因此，SG-B可以接受来自SG-A或SG-D的数据报，但只发送到最近用它重新设置密钥的网关。
Local policy determines which choice SG-B makes. Note that even if SG-B has perfect knowledge about the reachability of SG-A and SG-D, Alice may not be reachable from either of these security gateways because of internal reachability issues.
当地政策决定SG-B的选择。请注意，即使SG-B完全了解SG-A和SG-D的可达性，由于内部可达性问题，可能无法从这些安全网关中访问Alice。
FreeS/WAN implements option 5. Implementing a different option is being considered. The multi-homing aspects of OE are not well developed and may be the subject of a future document.
释放/广域网实现选项5。正在考虑实施另一种选择。OE的多归宿方面还没有很好地开发，可能是未来文档的主题。
If a DNS server fails to respond, local policy decides whether or not to permit communication in the clear as embodied in the connection classes in Section 3.2. It is easy to mount a denial of service attack on the DNS server responsible for a particular network's reverse-map. Such an attack may cause all communication with that network to go in the clear if the policy is permissive, or fail completely if the policy is paranoid. Please note that this is an active attack.
如果DNS服务器未能响应，本地策略将决定是否允许在clear中进行通信，如第3.2节中的连接类所示。在负责特定网络反向映射的DNS服务器上很容易发起拒绝服务攻击。如果策略是允许的，则此类攻击可能会导致与该网络的所有通信中断；如果策略是偏执的，则可能会导致通信完全失败。请注意，这是一次主动攻击。
There are still many networks that do not have properly configured reverse-maps. Further, if the policy is not to communicate, the above denial of service attack isolates the target network. Therefore, the decision of whether or not to permit communication in the clear MUST be a matter of local policy.
仍然有许多网络没有正确配置反向映射。此外，如果策略不通信，则上述拒绝服务攻击会隔离目标网络。因此，是否允许在clear中进行通信的决定必须是当地政策的问题。
DNS records claim that opportunistic encryption should occur, but the target gateway either does not respond on port 500, or refuses the proposal. This may be because of a crash or reboot, a faulty configuration, or a firewall filtering port 500.
DNS记录声称应该进行机会主义加密，但目标网关要么在端口500上不响应，要么拒绝该建议。这可能是由于崩溃或重新启动、配置错误或防火墙过滤端口500造成的。
The receipt of ICMP port, host or network unreachable messages indicates a potential problem, but MUST NOT cause communication to fail immediately. ICMP messages are easily forged by attackers. If such a forgery caused immediate failure, then an active attacker could easily prevent any encryption from ever occurring, possibly preventing all communication.
收到ICMP端口、主机或网络无法访问的消息表示存在潜在问题，但不得立即导致通信失败。攻击者很容易伪造ICMP消息。如果此类伪造导致即时失败，那么主动攻击者可以轻松阻止任何加密的发生，可能会阻止所有通信。
In these situations a log should be produced and local policy should dictate if communication is then permitted in the clear.
在这些情况下，应生成日志，并且当地政策应规定是否允许以明文形式进行通信。
Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break. In general there is no notification of this. Even in the event of a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has specific reason to talk to them immediately. Over-quick response to temporary network outages is undesirable. Note that a tunnel can be torn down and then re-established without any effect visible to the user except a pause in traffic. On the other hand, if one end reboots, the other end can't get datagrams to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms.
隧道有时会因为远端崩溃、断开连接或网络链路中断而中断。一般来说，没有关于这方面的通知。即使在崩溃和成功重启的情况下，除非重启的SG有明确的理由立即与他们交谈，否则其他SG也不会听到。对临时网络中断的快速响应是不可取的。请注意，可以拆除隧道，然后重新修建，但用户看不到任何影响，交通暂停除外。另一方面，如果一端重新启动，另一端在发现情况之前根本无法向其发送数据报（除了通过IKE）。因此，倾向于快速反应是恰当的，即使是以偶尔的错误警报为代价。
A mechanism for recovery after reboot is a topic of current research and is not specified in this document.
重新启动后的恢复机制是当前研究的主题，本文档中没有具体说明。
A deliberate shutdown should include an attempt, using delete messages, to notify all other SGs currently connected by phase 1 SAs that communication is about to fail. Again, a remote SG will assume this is a teardown. Attempts by the remote SGs to negotiate new tunnels as replacements should be ignored. When possible, SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previously established connections.
故意关机应包括尝试使用删除消息通知当前由第1阶段SAs连接的所有其他SGs通信即将失败。同样，远程SG将假定这是一次拆卸。远程SGs试图协商新隧道作为替代品的尝试应被忽略。在可能的情况下，SGs应尝试在非易失性存储器中保存有关当前连接的SGs的信息，以便在崩溃后，可以向以前的合作伙伴发送初始联系人，以指示以前建立的所有连接的丢失。
The method of obtaining information by reverse DNS lookup causes problems for people who cannot control their reverse DNS bindings. This is an unresolved problem in this version, and is out of scope.
通过反向DNS查找获取信息的方法会给无法控制其反向DNS绑定的人带来问题。这是此版本中未解决的问题，超出范围。
Two example scenarios follow. In the first example, GW-A (Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE policy. The clear-text policy serves as a reference for what occurs in TCP/IP in the absence of Opportunistic Encryption.
下面是两个示例场景。在第一个示例中，GW-A（网关A）和GW-B（网关B）始终具有明文策略，在第二个示例中，它们具有OE策略。明文策略可作为在没有机会加密的情况下TCP/IP中发生的情况的参考。
Alice wants to communicate with Bob. Perhaps she wants to retrieve a web page from Bob's web server. In the absence of opportunistic encryptors, the following events occur:
爱丽丝想和鲍勃交流。也许她想从Bob的web服务器检索网页。在没有机会主义加密机的情况下，会发生以下事件：
Alice SG-A DNS SG-B Bob Human or application 'clicks' with a name. (1)
Alice SG-A DNS SG-B Bob Human或应用程序使用名称“单击”。(1)
------(2)-------------->
Application looks up
name in DNS to get
IP address.
------(2)-------------->
Application looks up
name in DNS to get
IP address.
<-----(3)---------------
Resolver returns "A" RR
to application with IP
address.
<-----(3)---------------
Resolver returns "A" RR
to application with IP
address.
(4) Application starts a TCP session or UDP session and OS sends first datagram
(4) 应用程序启动TCP会话或UDP会话，操作系统发送第一个数据报
Alice SG-A DNS SG-B Bob
----(5)----->
Datagram is seen at first gateway
from Alice (SG-A).
Alice SG-A DNS SG-B Bob
----(5)----->
Datagram is seen at first gateway
from Alice (SG-A).
----------(6)------>
Datagram traverses
network.
----------(6)------>
Datagram traverses
network.
------(7)----->
Datagram arrives
at Bob, is provided
to TCP.
------(7)----->
Datagram arrives
at Bob, is provided
to TCP.
<------(8)------
A reply is sent.
<------(8)------
A reply is sent.
<----------(9)------
Datagram traverses
network.
<----(10)-----
Alice receives
answer.
<----------(9)------
Datagram traverses
network.
<----(10)-----
Alice receives
answer.
Alice SG-A DNS SG-B Bob
(11)----------->
A second exchange
occurs.
Alice SG-A DNS SG-B Bob
(11)----------->
A second exchange
occurs.
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
Figure 5: Timing of regular transaction
图5：常规交易的时间安排
In the presence of properly configured opportunistic encryptors, the event list is extended. Only changes are annotated.
如果存在正确配置的机会主义加密机，则会扩展事件列表。仅对更改进行注释。
The following symbols are used in the time-sequence diagram:
时间序列图中使用了以下符号：
- A single dash represents clear-text datagrams. = An equals sign represents phase 2 (IPsec) cipher-text datagrams. ~ A single tilde represents clear-text phase 1 datagrams. # A hash sign represents phase 1 (IKE) cipher-text datagrams.
- 单个破折号表示明文数据报。=等号表示第2阶段（IPsec）密文数据报单个波浪线表示明文第1阶段数据报哈希符号表示第1阶段（IKE）密文数据报。
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E)~~~~
~~~~~~~~~~~~~(5F)~~~>
<~~~~~~~~~~~~(5G)~~~~
#############(5H)###>
<----(5I)---
-----(5J)-->
<############(5K)####
#############(5L)###>
<----(5M)---
-----(5N)-->
<############(5O)####
#############(5P)###>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E)~~~~
~~~~~~~~~~~~~(5F)~~~>
<~~~~~~~~~~~~(5G)~~~~
#############(5H)###>
<----(5I)---
-----(5J)-->
<############(5K)####
#############(5L)###>
<----(5M)---
-----(5N)-->
<############(5O)####
#############(5P)###>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
Figure 6: Timing of opportunistic encryption transaction
图6：机会加密事务的计时
For the purposes of this section, we will describe only the changes that occur between Figure 5 and Figure 6. This corresponds to time points 5, 6, 7, 9, and 10 on the list above.
在本节中，我们将仅描述图5和图6之间发生的更改。这对应于上面列表中的时间点5、6、7、9和10。
At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy (the nonexistent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon.
在第（5）点，SG-A截获数据报，因为该源/目标对缺少策略（不存在的策略状态）。SG-A创建保持策略，并缓冲数据报。SG-A从键控守护进程请求密钥。
(5B) DNS query for TXT record. (5C) DNS response for TXT record. (5D) Initial IKE message to responder. (5E) Message 2 of phase 1 exchange. SG-B receives the message. A new connection instance is created in the unauthenticated OE peer state. (5F) Message 3 of phase 1 exchange. SG-A sends a Diffie-Hellman exponent. This is an internal state of the keying daemon. (5G) Message 4 of phase 1 exchange. SG-B responds with a Diffie-Hellman exponent. This is an internal state of the keying protocol. (5H) Message 5 of phase 1 exchange. SG-A uses the phase 1 SA to send its identity under encryption. The choice of identity is discussed in Section 4.6.1. This is an internal state of the keying protocol. (5I) Responder lookup of initiator key. SG-B asks DNS for the public key of the initiator. DNS looks for a KEY record by IP address in the reverse-map. That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa (recall that SG-A's external address is 192.1.1.4). SG-B uses the resulting public key to authenticate the initiator. See Section 5.1 for further details. (5J) DNS replies with public key of initiator. Upon successfully authenticating the peer, the connection instance makes a transition to authenticated OE peer on SG-B. The format of the TXT record returned is described in Section 5.2. Responder replies with ID and authentication. SG-B sends its ID along with authentication material, completing the phase 1 negotiation. (5L) IKE phase 2 negotiation. Having established mutually agreeable authentications (via KEY) and authorizations (via TXT), SG-A proposes to create an IPsec tunnel for datagrams transiting from Alice to Bob. This tunnel is established only for the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B.
（5B）TXT记录的DNS查询。（5C）TXT记录的DNS响应。（5D）发送给响应者的初始IKE消息。（5E）第1阶段交换的消息2。SG-B接收消息。在未经验证的OE对等状态下创建新连接实例。（5F）第1阶段交换的信息3。SG-A发送一个Diffie-Hellman指数。这是键控守护程序的内部状态。（5G）第1阶段交换的消息4。SG-B以Diffie-Hellman指数响应。这是键控协议的内部状态。（5H）第1阶段交换的消息5。SG-A使用阶段1 SA在加密下发送其身份。第4.6.1节讨论了标识的选择。这是键控协议的内部状态。（5I）响应程序查找启动器密钥。SG-B向DNS请求启动器的公钥。DNS在反向映射中按IP地址查找密钥记录。也就是说，查询4.1.1.192.in-addr.arpa的密钥资源记录（回想一下，SG-a的外部地址是192.1.1.4）。SG-B使用生成的公钥对启动器进行身份验证。详见第5.1节。（5J）使用发起方的公钥进行DNS应答。成功验证对等方后，连接实例将转换到SG-B上已验证的OE对等方。返回的TXT记录格式在第5.2节中描述。响应者使用ID和身份验证进行回复。SG-B将其ID与认证材料一起发送，完成第1阶段协商。（5L）IKE第2阶段谈判。在建立了相互同意的身份验证（通过密钥）和授权（通过TXT）之后，SG-A建议为从Alice传输到Bob的数据报创建一个IPsec隧道。该隧道仅为Alice/Bob组合而建立，不适用于SG-A和SG-B后面的任何子网。
(5M) Authorization for SG-A to speak for Alice. While the identity of SG-A has been established, its authority to speak for Alice has not yet been confirmed. SG-B does a reverse lookup on Alice's address for a TXT record. (5N) Responder determines initiator's authority. A TXT record is returned. It confirms that SG-A is authorized to speak for Alice. Upon receiving this specific proposal, SG-B's connection instance makes a transition into the potential OE connection state. SG-B may already have an instance, and the check is made as described above. (5O) Responder agrees to proposal. SG-B, satisfied that SG-A is authorized, proceeds with the phase 2 exchange. The responder MUST setup the inbound IPsec SAs before sending its reply. (5P) Final acknowledgement from initiator. The initiator agrees with the responder's choice of proposal and sets up the tunnel. The initiator sets up the inbound and outbound IPsec SAs. Upon receipt of this message, the responder may now setup the outbound IPsec SAs. (6) IPsec succeeds and sets up a tunnel for communication between Alice and Bob.
（5M）授权SG-A代表Alice发言。虽然SG-A的身份已经确定，但其代表爱丽丝发言的权力尚未得到确认。SG-B在Alice的地址上反向查找TXT记录。（5N）响应者确定发起人的权限。返回一个TXT记录。它确认SG-A有权代表Alice发言。收到此具体建议后，SG-B的连接实例将转换为潜在OE连接状态。SG-B可能已经有一个实例，并按照上述方式进行检查。（5O）响应者同意该提议。SG-B在确信SG-A获得授权后，继续进行第2阶段的交换。在发送回复之前，响应程序必须设置入站IPsec SAs。（5P）发起者的最终确认。发起者同意响应者对方案的选择，并设置隧道。启动器设置入站和出站IPsec SAs。收到此消息后，响应者现在可以设置出站IPsec SAs。（6） IPsec成功并为Alice和Bob之间的通信建立了一个隧道。
SG-A sends the datagram saved at step (5) through the newly created tunnel to SG-B, where it gets decrypted and forwarded. Bob receives it at (7) and replies at (8). SG-B already has a tunnel up with G1 and uses it. At (9), SG-B has already established an SPD entry mapping Bob->Alice via a tunnel, so this tunnel is simply applied. The datagram is encrypted to SG-A, decrypted by SG-A, and passed to Alice at (10).
SG-A将在步骤（5）中保存的数据报通过新创建的隧道发送到SG-B，在那里对其进行解密和转发。Bob在（7）处收到，并在（8）处回复。SG-B已经有了一个与G1相连的隧道并使用它。在（9）处，SG-B已经通过一个隧道建立了一个SPD入口映射Bob->Alice，因此只需应用这个隧道。数据报被加密到SG-A，由SG-A解密，并在（10）处传递给Alice。
Configured tunnels are setup using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that are in known places (distinguished name from LDAP, DNS). These keys are then used to configure a specific tunnel.
配置的隧道是使用双边机制设置的：交换公钥（原始RSA、DSA、PKIX）、预共享机密，或通过引用已知位置的密钥（与LDAP、DNS的区别名称）。然后使用这些键配置特定的隧道。
A pre-configured tunnel may be on all the time, or may be keyed only when needed. The endpoints of the tunnel are not necessarily static; many mobile applications (road warrior) are considered to be configured tunnels.
预先配置的隧道可能一直处于开启状态，也可能仅在需要时设置密钥。隧道的端点不一定是静态的；许多移动应用程序（road warrior）被认为是通过隧道配置的。
The primary characteristic is that configured tunnels are assigned specific security properties. They may be trusted in different ways relating to exceptions to firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions.
主要特征是配置的隧道被指定了特定的安全属性。它们可能以不同的方式受到信任，这些方式与防火墙规则的例外、NAT处理的例外以及带宽或其他服务质量限制有关。
Opportunistic tunnels are not inherently trusted in any strong way. They are created without prior arrangement. As the two parties are strangers, there MUST be no confusion of datagrams that arrive from opportunistic peers and those that arrive from configured tunnels. A security gateway MUST take care that an opportunistic peer cannot impersonate a configured peer.
机会主义隧道在本质上并不可靠。它们是在没有事先安排的情况下创建的。由于双方都是陌生人，因此从机会主义对等方发送的数据报和从配置的隧道发送的数据报必须不混淆。安全网关必须注意机会主义对等方不能模拟已配置的对等方。
Ingress filtering MUST be used to make sure that only datagrams authorized by negotiation (and the concomitant authentication and authorization) are accepted from a tunnel. This is to prevent one peer from impersonating another.
必须使用入口过滤来确保隧道中只接受通过协商（以及伴随的身份验证和授权）授权的数据报。这是为了防止一个对等方冒充另一个对等方。
An implementation suggestion is to treat opportunistic tunnel datagrams as if they arrive on a logical interface distinct from other configured tunnels. As the number of opportunistic tunnels that may be created automatically on a system is potentially very high, careful attention to scaling should be taken into account.
一个实现建议是将机会主义隧道数据报视为它们到达的逻辑接口不同于其他配置的隧道。由于可能在系统上自动创建的机会主义隧道数量可能非常高，因此应仔细注意扩展。
As with any IKE negotiation, opportunistic encryption cannot be secure without authentication. Opportunistic encryption relies on DNS for its authentication information and, therefore, cannot be fully secure without a secure DNS. Without secure DNS, opportunistic encryption can protect against passive eavesdropping but not against active man-in-the-middle attacks.
与任何IKE协商一样，没有身份验证，机会主义加密是不安全的。机会主义加密的身份验证信息依赖于DNS，因此，如果没有安全的DNS，就无法完全安全。如果没有安全的DNS，机会加密可以防止被动窃听，但不能防止主动中间人攻击。
Typical usage of per datagram access control lists is to implement various kinds of security gateways. These are typically called "firewalls".
每个数据报访问控制列表的典型用法是实现各种安全网关。这些通常被称为“防火墙”。
Typical usage of a virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to datagrams that arrive in the VPN.
防火墙内虚拟专用网络（VPN）的典型用途是绕过两个网络之间的全部或部分访问控制。对到达VPN的数据报给予额外的信任（如前一节所述）。
Datagrams that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a datagram arriving in the clear SHOULD also be applied to datagrams arriving opportunistically.
通过机会主义配置的隧道到达的数据报不得被信任。适用于到达clear的数据报的任何安全策略也应适用于偶然到达的数据报。
There are several different forms of denial of service that an implementor should be concerned with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors).
实施者应该关注几种不同形式的拒绝服务。这些问题中的大多数都与拥有大量移动对等点（道路战士）的安全网关共享。
The design of ISAKMP/IKE, and its use of cookies, defend against many kinds of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is possible to form phase 1 SAs with any machine on the Internet.
ISAKMP/IKE的设计及其Cookie的使用可以抵御多种拒绝服务。机会主义改变了这样一种假设，即如果第1阶段（ISAKMP）SA经过身份验证，那么它是值得创建的。由于网关将与任何机器通信，因此可以与Internet上的任何机器形成阶段1 SAs。
Substantive portions of this document are based upon previous work by Henry Spencer. [OEspec]
本文件的实质部分基于Henry Spencer以前的工作。[OEspec]
Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore, and John Denker for their comments and constructive criticism.
感谢Tero Kivinen、Sandy Harris、Wes Hardarker、Robert Moskowitz、Jakob Schlyter、Bill Sommerfeld、John Gilmore和John Denker的评论和建设性批评。
Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
桑德拉·霍夫曼和比尔·迪基进行了详细的校对和编辑。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schneider，M.和M.Schertler，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[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月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]Eastlake，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[IPSECKEY] Richardson, M., "A Method for Storing IPsec keying Material in DNS", RFC 4025, March 2005.
[IPSECKEY]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 40252005年3月。
[OEspec] H. Spencer and Redelmeier, D., "Opportunistic Encryption", paper, http://www.freeswan.org/ oeid/opportunism-spec.txt, May 2001.
[OEspec]H.Spencer和Redelmeier，D.，“机会主义加密”，论文，http://www.freeswan.org/ oeid/Opportunitism-spec.txt，2001年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1464]Rosenbaum，R.，“使用域名系统存储任意字符串属性”，RFC 1464，1993年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.
[RFC1984]IAB，IESG，Carpenter，B.和F.Baker，“IAB和IESG关于加密技术和互联网的声明”，RFC 1984，1996年8月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]McDonald，D.，Metz，C.和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538]Eastlake，D.和O.Gudmundsson，“在域名系统（DNS）中存储证书”，RFC 25381999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
Authors' Addresses
作者地址
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
Michael C.Richardson Sandelman软件公司位于加利福尼亚州K1Z 5V7的渥太华道森大道470号
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
D. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Avenue Toronto, ON M4N 2W6 CA
D.Hugh Redelmeier含羞草系统公司，地址：加拿大多伦多市多尼诺大道29号，M4N 2W6
EMail: hugh@mimosa.com
EMail: hugh@mimosa.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。