Network Working Group N. Williams
Request for Comments: 5660 Sun
Category: Standards Track October 2009
Network Working Group N. Williams
Request for Comments: 5660 Sun
Category: Standards Track October 2009
IPsec Channels: Connection Latching
IPsec通道：连接锁存
Abstract
摘要
This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
本文档抽象地指定了如何将应用程序和传输协议与IPsec连接起来，以便在连接的生命周期内通过锁定到特定IPsec安全关联（SA）参数的“连接”（数据包流）来创建“通道”。连接锁存是在IPsec之上分层的，不会修改底层IPsec体系结构。
Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.
连接锁存可用于防止应用程序意外地将实时数据包流暴露给非预期的对等方，无论是由于IPsec的重新配置，还是由于使用弱对等身份到对等地址关联。对等ID和对等地址的弱关联是比没有更好的安全性（BTN）的核心；因此，连接锁存可以为BTNS IPsec节点增加重要的保护措施。
Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels.
最后，IPsec通道的可用性将使使用通道绑定到IPsec通道成为可能。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
包括信托法律条款第4.e节所述的简化BSD许可证文本，且不提供BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Connection Latching .............................................4
2.1. Latching of Quality-of-Protection Parameters ...............8
2.2. Connection Latch State Machine .............................9
2.3. Normative Model: ULP Interfaces to the Key Manager ........12
2.3.1. Race Conditions and Corner Cases ...................17
2.3.2. Example ............................................18
2.4. Informative Model: Local Packet Tagging ...................19
2.5. Non-Native Mode IPsec .....................................21
2.6. Implementation Note Regarding Peer IDs ....................22
3. Optional Features ..............................................22
3.1. Optional Protection .......................................22
4. Simultaneous Latch Establishment ...............................23
5. Connection Latching to IPsec for Various ULPs ..................23
5.1. Connection Latching to IPsec for TCP ......................24
5.2. Connection Latching to IPsec for UDP with
Simulated Connections .....................................24
5.3. Connection Latching to IPsec for UDP with
Datagram-Tagging APIs .....................................25
5.4. Connection Latching to IPsec for SCTP .....................25
5.5. Handling of BROKEN State for TCP and SCTP .................26
6. Security Considerations ........................................27
6.1. Impact on IPsec ...........................................27
6.2. Impact on IPsec of Optional Features ......................28
6.3. Security Considerations for Applications ..................28
6.4. Channel Binding and IPsec APIs ............................29
6.5. Denial-of-Service Attacks .................................29
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................30
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Connection Latching .............................................4
2.1. Latching of Quality-of-Protection Parameters ...............8
2.2. Connection Latch State Machine .............................9
2.3. Normative Model: ULP Interfaces to the Key Manager ........12
2.3.1. Race Conditions and Corner Cases ...................17
2.3.2. Example ............................................18
2.4. Informative Model: Local Packet Tagging ...................19
2.5. Non-Native Mode IPsec .....................................21
2.6. Implementation Note Regarding Peer IDs ....................22
3. Optional Features ..............................................22
3.1. Optional Protection .......................................22
4. Simultaneous Latch Establishment ...............................23
5. Connection Latching to IPsec for Various ULPs ..................23
5.1. Connection Latching to IPsec for TCP ......................24
5.2. Connection Latching to IPsec for UDP with
Simulated Connections .....................................24
5.3. Connection Latching to IPsec for UDP with
Datagram-Tagging APIs .....................................25
5.4. Connection Latching to IPsec for SCTP .....................25
5.5. Handling of BROKEN State for TCP and SCTP .................26
6. Security Considerations ........................................27
6.1. Impact on IPsec ...........................................27
6.2. Impact on IPsec of Optional Features ......................28
6.3. Security Considerations for Applications ..................28
6.4. Channel Binding and IPsec APIs ............................29
6.5. Denial-of-Service Attacks .................................29
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................30
IPsec protects packets with little or no regard for stateful packet flows associated with upper-layer protocols (ULPs). This exposes applications that rely on IPsec for session protection to risks associated with changing IPsec configurations, configurations that allow multiple peers access to the same addresses, and/or weak association of peer IDs and their addresses. The latter can occur as a result of "wildcard" matching in the IPsec Peer Authorization Database (PAD), particularly when Better Than Nothing Security (BTNS) [RFC5387] is used.
IPsec保护数据包时很少或根本不考虑与上层协议（ULP）相关的有状态数据包流。这使依赖IPsec进行会话保护的应用程序面临与更改IPsec配置、允许多个对等方访问相同地址的配置以及/或对等ID与其地址弱关联相关的风险。后者可能是IPsec对等授权数据库（PAD）中的“通配符”匹配的结果，特别是在使用优于无的安全性（BTN）[RFC5387]时。
Applications that wish to use IPsec may have to ensure that local policy on the various end-points is configured appropriately [RFC5406] [USING-IPSEC]. There are no standard Application Programming Interfaces (APIs) to do this (though there are non-standard APIs, such as [IP_SEC_OPT.man]) -- a major consequence of which, for example, is that applications must still use hostnames (and, e.g., the Domain Name System [RFC1034]) and IP addresses in existing APIs and must depend on an IPsec configuration that they may not be able to verify. In addition to specifying aspects of required Security Policy Database (SPD) configuration, application specifications must also address PAD/SPD configuration to strongly bind individual addresses to individual IPsec identities and credentials (certificates, public keys, etc.).
希望使用IPsec的应用程序可能必须确保在各个端点上正确配置本地策略[RFC5406][USING-IPsec]。没有标准的应用程序编程接口（API）来实现这一点（尽管存在非标准API，如[IP_SEC_OPT.man]）——例如，其主要后果是应用程序必须仍然使用主机名（以及域名系统[RFC1034]）和现有API中的IP地址，并且必须依赖于他们可能无法验证的IPsec配置。除了指定所需安全策略数据库（SPD）配置的各个方面外，应用程序规范还必须解决PAD/SPD配置问题，以便将各个地址与各个IPsec标识和凭据（证书、公钥等）紧密绑定。
IPsec is, then, quite cumbersome for use by applications. To address this, we need APIs to IPsec. Not merely APIs for configuring IPsec, but also APIs that are similar to the existing IP APIs (e.g., "BSD Sockets"), so that typical applications making use of UDP [RFC0768], TCP [RFC0793], and Stream Control Transmission Protocol (SCTP) [RFC4960] can make use of IPsec with minimal changes.
因此，IPsec对于应用程序来说相当麻烦。为了解决这个问题，我们需要IPsec的API。不仅是用于配置IPsec的API，还包括与现有IP API类似的API（例如，“BSD套接字”），因此，使用UDP[RFC0768]、TCP[RFC0793]和流控制传输协议（SCTP）[RFC4960]的典型应用程序可以使用IPsec，而只需进行最小的更改。
This document describes the foundation for IPsec APIs that UDP and TCP applications can use: a way to bind the traffic flows for, e.g., TCP connections to security properties desired by the application. We call these "connection latches" (and, in some contexts, "IPsec channels"). The methods outlined below achieve this by interfacing ULPs and applications to IPsec.
本文描述了UDP和TCP应用程序可以使用的IPSec API的基础：一种将业务流（例如TCP连接）绑定到应用程序所期望的安全属性的方法。我们称这些为“连接锁存”（在某些上下文中称为“IPsec通道”）。下面概述的方法通过将ULP和应用程序连接到IPsec来实现这一点。
If widely adopted, connection latching could make application use of IPsec much simpler, at least for certain classes of applications.
如果广泛采用，连接锁存可以使IPsec的应用程序使用更加简单，至少对于某些类别的应用程序是如此。
Connection latching, as specified herein, is primarily about watching updates to the SPD and Security Association Database (SAD) to detect changes that are adverse to an application's requirements for any given packet flow, and to react accordingly (such as by synchronously alerting the ULP and application before packets can be sent or
如本文所述，连接锁存主要是关于监视对SPD和安全关联数据库（SAD）的更新，以检测对任何给定分组流的应用程序的需求不利的更改，并相应地作出反应（例如，通过在分组可以被发送或接收之前同步地警告ULP和应用程序）
received under the new policy). Under no circumstance are IPsec policy databases to be modified by connection latching in any way that can persist beyond the lifetime of the related packet flows, nor reboots. Under no circumstance is the PAD to be modified at all by connection latching. If all optional features of connection latching are excluded, then connection latching can be implemented as a monitor of SPD and SAD changes that intrudes in their workings no more than is needed to provide synchronous alerts to ULPs and applications.
根据新政策收到）。在任何情况下，IPsec策略数据库都不能以任何方式通过连接锁存进行修改，这种方式可以持续到相关数据包流的生命周期之外，也不能重新启动。在任何情况下，都不能通过连接锁定来修改焊盘。如果排除了连接锁存的所有可选功能，则可以将连接锁存作为SPD和SAD更改的监视器来实现，这些更改侵入了它们的工作，只需向ULP和应用程序提供同步警报。
We assume the reader is familiar with the IPsec architecture [RFC4301] and Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306].
我们假设读者熟悉IPsec体系结构[RFC4301]和Internet密钥交换协议版本2（IKEv2）[RFC4306]。
Note: the terms "connection latch" and "IPsec channel" are used interchangeably below. The latter term relates to "channel binding" [RFC5056]. Connection latching is suitable for use in channel binding applications, or will be, at any rate, when the channel bindings for IPsec channels are defined (the specification of IPsec channel bindings is out of scope for this document).
注：以下术语“连接锁存器”和“IPsec通道”可互换使用。后一术语涉及“通道绑定”[RFC5056]。连接锁存适合在通道绑定应用程序中使用，或者在定义IPsec通道的通道绑定时（IPsec通道绑定的规范不在本文档的范围内）无论如何都会使用连接锁存。
Note: where this document mentions IPsec peer "ID" it refers to the Internet Key Exchange (IKE) peer ID (e.g., the ID derived from a peer's cert, as well as the cert), not the peer's IP address.
注意：本文档提及IPsec对等“ID”时，它指的是Internet密钥交换（IKE）对等ID（例如，从对等方的证书以及证书派生的ID），而不是对等方的IP地址。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Abstract function names are all capitalized and denoted by a pair of parentheses. In their descriptions, the arguments appear within the parentheses, with optional arguments surrounded by square brackets. Return values, if any, are indicated by following the function argument list with "->" and a description of the return value. For example, "FOO(3-tuple, [message])" would be a function named "FOO" with two arguments, one of them optional, and returning nothing, whereas "FOOBAR(handle) -> state" would be a function with a single, required argument that returns a value. The values' types are described in the surrounding text.
抽象函数名都是大写的，并用一对括号表示。在它们的描述中，参数出现在括号内，可选参数用方括号括起来。返回值（如果有）通过在函数参数列表后面加“->”和返回值的说明来表示。例如，“FOO（3元组，[message]）将是一个名为“FOO”的函数，它有两个参数，其中一个是可选的，不返回任何内容，而“FOOBAR（handle）->state”将是一个函数，它有一个返回值的必需参数。值的类型在周围的文本中描述。
An "IPsec channel" is a packet flow associated with a ULP control block, such as a TCP connection, where all the packets are protected by IPsec SAs such that:
“IPsec通道”是与ULP控制块（如TCP连接）相关联的数据包流，其中所有数据包均受IPsec SAs保护，以便：
o the peer's identity is the same for the lifetime of the packet flow;
o 对等方的身份在分组流的生存期内是相同的；
o the quality of IPsec protection used for the packet flow's individual packets is the same for all of them for the lifetime of the packet flow.
o 在数据包流的生命周期内，用于数据包流的各个数据包的IPsec保护质量对于所有数据包都是相同的。
An IPsec channel is created when the associated packet flow is created. This can be the result of a local operation (e.g., a connect()) that causes the initial outgoing packet for that flow to be sent, or it can be the result of receiving the first/initiating packet for that flow (e.g., a TCP SYN packet).
创建关联的数据包流时，将创建IPsec通道。这可能是导致发送该流的初始传出数据包的本地操作（例如，connect（））的结果，也可能是接收该流的第一个/起始数据包（例如，TCP SYN数据包）的结果。
An IPsec channel is destroyed when the associated packet flow ends. An IPsec channel can also be "broken" when the connection latch cannot be maintained for some reason (see below), in which case the ULP and application are informed.
当相关的数据包流结束时，IPsec通道被破坏。当由于某种原因（见下文）无法维护连接闩锁时，IPsec通道也可能“断开”，在这种情况下，会通知ULP和应用程序。
IPsec channels are created by "latching" various parameters listed below to a ULP connection when the connections are created. The REQUIRED set of parameters bound in IPsec channels is:
创建连接时，通过将下面列出的各种参数“锁定”到ULP连接来创建IPsec通道。IPsec通道中绑定的所需参数集为：
o Type of protection: confidentiality and/or integrity protection;
o 保护类型：保密性和/或完整性保护；
o Transport mode versus tunnel mode;
o 运输模式与隧道模式；
o Quality of protection (QoP): cryptographic algorithm suites, key lengths, and replay protection (see Section 2.1);
o 保护质量（QoP）：加密算法套件、密钥长度和重播保护（见第2.1节）；
o Local identity: the local ID asserted to the peer, as per the IPsec processing model [RFC4301] and BTNS [RFC5386];
o 本地标识：根据IPsec处理模型[RFC4301]和BTN[RFC5386]向对等方声明的本地标识；
o Peer identity: the peer's asserted and authorized IDs, as per the IPsec processing model [RFC4301] and BTNS [RFC5386].
o 对等身份：根据IPsec处理模型[RFC4301]和BTN[RFC5386]，对等身份的断言和授权ID。
The SAs that protect a given IPsec channel's packets may change over time in that they may expire and be replaced with equivalent SAs, or they may be re-keyed. The set of SAs that protect an IPsec channel's packets need not be related by anything other than the fact that they must be congruent to the channel (i.e., the SAs' parameters must match those that are latched into the channel). In particular, it is desirable that IPsec channels survive the expiration of IKE_SAs and child SAs because operational considerations of the various key exchange protocols then cannot affect the design and features of connection latching.
保护给定IPsec通道的数据包的SAs可能会随着时间的推移而改变，因为它们可能会过期并被等效的SAs替换，或者可能会重新设置密钥。保护IPsec通道的数据包的SA集不需要与任何其他内容相关，除非它们必须与通道一致（即，SAs的参数必须与锁存到通道中的参数匹配）。特别是，希望IPsec信道在IKE_SAs和子SAs到期后仍然有效，因为各种密钥交换协议的操作考虑不会影响连接锁存的设计和特性。
When a situation arises in which the SPD is modified, or an SA is added to the SAD, such that the new policy and/or SA are not congruent to an established channel (see previous paragraph), then we consider this a conflict. Conflict resolution is addressed below.
当出现SPD被修改的情况，或者SA被添加到SAD中时，使得新的策略和/或SA与已建立的信道不一致（参见前面的段落），那么我们认为这是冲突。下文讨论了冲突解决。
Requirements and recommendations:
要求和建议：
o If an IPsec channel is desired, then packets for a given connection MUST NOT be sent until the channel is established.
o 如果需要IPsec通道，则在建立通道之前，不得发送给定连接的数据包。
o If an IPsec channel is desired, then inbound packets for a given connection MUST NOT be accepted until the channel is established. That is, inbound packets for a given connection arriving prior to the establishment of the corresponding IPsec channel must be dropped or the channel establishment must fail.
o 如果需要IPsec通道，则在建立通道之前，不得接受给定连接的入站数据包。也就是说，必须丢弃在建立相应IPsec通道之前到达的给定连接的入站数据包，否则通道建立必须失败。
o Once an IPsec channel is established, packets for the latched connection MUST NOT be sent unprotected nor protected by an SA that does not match the latched parameters.
o 一旦建立IPsec通道，锁存连接的数据包不得在未受保护的情况下发送，也不得由与锁存参数不匹配的SA进行保护。
o Once an IPsec channel is established, packets for the latched connection MUST NOT be accepted unprotected nor protected by an SA that does not match the latched parameters. That is, such packets must either be dropped or cause the channel to be terminated and the application to be informed before data from such a packet can be delivered to the application.
o 一旦建立IPsec通道，锁存连接的数据包不得在未受保护的情况下接受，也不得由与锁存参数不匹配的SA进行保护。也就是说，在可以将来自这样的分组的数据传送到应用程序之前，必须丢弃这样的分组或者导致信道终止并且通知应用程序。
o Implementations SHOULD provide programming interfaces for inquiring the values of the parameters latched in a connection.
o 实现应提供用于查询连接中锁定的参数值的编程接口。
o Implementations that provide such programming interfaces MUST make available to applications all relevant and available information about a peer's ID, including authentication information. This includes the peer certificate, when one is used, and the trust anchor to which it was validated (but not necessarily the whole certificate validation chain).
o 提供此类编程接口的实现必须向应用程序提供有关对等方ID的所有相关和可用信息，包括身份验证信息。这包括使用对等证书时的对等证书，以及对其进行验证的信任锚点（但不一定包括整个证书验证链）。
o Implementations that provide such programming interfaces SHOULD make available to applications any information about local and/or remote public and private IP addresses, in the case of NAT-traversal.
o 在NAT穿越的情况下，提供此类编程接口的实现应向应用程序提供有关本地和/或远程公共和私有IP地址的任何信息。
o Implementations that provide such programming interfaces SHOULD make available to applications the inner and outer local and peer addresses whenever the latched connection uses tunnel-mode SAs.
o 每当锁存连接使用隧道模式SAs时，提供此类编程接口的实现应使应用程序能够使用内部和外部本地和对等地址。
o Implementations SHOULD provide programming interfaces for setting the values of the parameters to be latched in a connection that will be initiated or accepted, but these interfaces MUST limit what values applications may request according to system policy (i.e., the IPsec PAD and SPD) and the application's local privileges.
o 实现应提供编程接口，用于设置要锁定在将被启动或接受的连接中的参数值，但这些接口必须根据系统策略（即IPsec PAD和SPD）和应用程序的本地权限限制应用程序可能请求的值。
(Typical system policy may not allow applications any choices here. Policy extensions allowing for optional protection are described in Section 3.1.)
（典型的系统策略可能不允许应用程序在此进行任何选择。允许可选保护的策略扩展在第3.1节中描述。）
o Implementations SHOULD create IPsec channels automatically by default when the application does not explicitly request an IPsec channel. Implementations MAY provide a way to disable automatic creation of connection latches.
o 默认情况下，当应用程序未明确请求IPsec通道时，实现应自动创建IPsec通道。实现可以提供一种禁用自动创建连接锁存器的方法。
o The parameters latched in an IPsec channel MUST remain unchanged once the channel is established.
o 一旦通道建立，IPsec通道中锁定的参数必须保持不变。
o Timeouts while establishing child SAs with parameters that match those latched into an IPsec channel MUST be treated as packet loss (as happens, for example, when a network partitions); normal ULP and/or application timeout handling and retransmission considerations apply.
o 在建立子SA时，如果子SA的参数与锁存到IPsec通道中的参数相匹配，则超时必须视为数据包丢失（例如，当网络分区时发生的情况）；正常ULP和/或应用程序超时处理和重传注意事项适用。
o Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) For example, if such an implementation relies on keeping some aspects of connection latch state in the restartable key management process (e.g., values that potentially have large representations, such as BTNS peer IDs), then either such state must be restored on restart of such a process, or outstanding connection latches must be transitioned to the CLOSED state.
o 具有可重启密钥管理进程（或“守护进程”）的实现必须安排现有的锁存连接断开和断开，或使其在密钥交换进程重启后继续存在。（上述要求暗示了这一点。）例如，如果这种实现依赖于在可重启密钥管理过程中保持连接锁存状态的某些方面（例如，可能具有较大表示形式的值，例如BTN对等ID），则必须在重新启动该过程时恢复任何一种状态，或未完成的连接闩锁必须转换为关闭状态。
o Dynamic IPsec policy (see Section 3.1) related to connection latches, if any, MUST be torn down when latched connections are torn down, and MUST NOT survive reboots.
o 与连接锁存（如果有）相关的动态IPsec策略（请参阅第3.1节）必须在断开锁存连接时断开，并且不得在重新启动后继续存在。
o When IKE dead-peer detection (DPD) concludes that the remote peer is dead or has rebooted, then the system SHOULD consider all connection latches with that peer to be irremediably broken.
o 当IKE死对等检测（DPD）断定远程对等体已经死亡或重新启动时，系统应该考虑与该对等体的所有连接锁存器被不可分割地破坏。
We describe two models, one of them normative, of IPsec channels for native IPsec implementations. The normative model is based on abstract programming interfaces in the form of function calls between ULPs and the key management component of IPsec (basically, the SAD,
我们描述了用于本机IPsec实现的IPsec通道的两个模型，其中一个是标准模型。规范模型基于ULP和IPsec密钥管理组件（基本上是SAD、，
augmented with a Latch Database (LD)). The second model is based on abstract programming interfaces between ULPs and the IPsec (Encapsulating Security Payload / Authentication Header (ESP/AH)) layer in the form of meta-data tagging of packets within the IP stack.
通过闩锁数据库（LD）进行扩充。第二个模型基于ULPs和IPsec（封装安全有效负载/认证头（ESP/AH））层之间的抽象编程接口，以IP堆栈中数据包的元数据标记的形式。
The two models given below are not, however, entirely equivalent. One model cannot be implemented with Network Interface cards (NICs) that offload ESP/AH but that do not tag incoming packets passed to the host processor with SA information, nor allow the host processor to so tag outgoing packets. That same model can be easily extended to support connection latching with unconnected datagram "sockets", while the other model is rigidly tied to a notion of "connections" and cannot be so extended. There may be other minor differences between the two models. Rather than seek to establish equivalency for some set of security guarantees, we instead choose one model to be the normative one.
然而，下面给出的两个模型并不完全相同。一种模型不能使用网络接口卡（NIC）实现，该网卡卸载ESP/AH，但不使用SA信息标记传递给主机处理器的传入数据包，也不允许主机处理器标记传出数据包。同一个模型可以很容易地扩展，以支持与未连接的数据报“套接字”的连接锁存，而另一个模型严格地绑定到“连接”的概念上，因此无法扩展。这两种模型之间可能还有其他细微的区别。我们不寻求为某些安全保证集建立等价性，而是选择一种模型作为规范模型。
We also provide a model for non-native implementations, such as bump-in-the-stack (BITS) and Security Gateway (SG) implementations. The connection latching model for non-native implementations is not full-featured as it depends on estimating packet flow state, which may not always be possible. Nor can non-native IPsec implementations be expected to provide APIs related to connection latching (implementations that do could be said to be native). As such, this third model is not suitable for channel binding applications [RFC5056].
我们还为非本机实现提供了一个模型，例如堆栈中的凹凸（BITS）和安全网关（SG）实现。非本机实现的连接锁存模型功能不全，因为它依赖于对数据包流状态的估计，这可能并不总是可能的。非本机IPsec实现也不能提供与连接锁存相关的API（这样的实现可以说是本机的）。因此，第三种模型不适用于通道绑定应用[RFC5056]。
In IPsec, the assumption of IKE initiator/responder roles is non-deterministic. That is, sometimes an IKE SA and child SAs will be initiated by the "client" (e.g., the caller of the connect() BSD sockets function) and sometimes by the "server" (e.g., the caller of the accept() BSD Sockets function). This means that the negotiation of quality of protection is also non-deterministic unless one of the peers offers a single cryptographic suite in the IKE negotiation.
在IPsec中，IKE发起方/响应方角色的假设是不确定的。也就是说，有时IKE SA和子SA将由“客户端”（例如，connect（）BSD套接字函数的调用方）启动，有时由“服务器”（例如，accept（）BSD套接字函数的调用方）启动。这意味着保护质量的协商也是不确定的，除非其中一个对等方在IKE协商中提供单个密码套件。
When creating narrow child SAs with traffic selectors matching the connection latch's 5-tuple, it is possible to constrain the IKE Quality-of-Protection negotiation to a single cryptographic suite. Therefore, implementations SHOULD provide an API for requesting the use of such child SAs. Implementors SHOULD consider an application request for a specific QoP to imply a request for narrow child SAs.
当使用与连接闩锁的5元组匹配的流量选择器创建窄子SA时，可以将IKE保护质量协商限制到单个加密套件。因此，实现应该提供一个API来请求使用这样的子SA。实现者应该考虑特定QOP的应用请求，暗示对窄子SAS的请求。
When using SAs with traffic selectors encompassing more than just a single flow, then the system may only be able to latch a set of cryptographic suites, rather than a single cryptographic suite. In such a case, an implementation MUST report the QoP being used as indeterminate.
当使用SAs时，流量选择器不仅仅包含单个流，系统可能只能锁定一组加密套件，而不是单个加密套件。在这种情况下，实现必须将使用的QoP报告为不确定。
Connection latches can exist in any of the following five states:
连接闩锁可以存在于以下五种状态中的任意一种：
o LISTENER
o 听众
o ESTABLISHED
o 确立
o BROKEN (there exist SAs that conflict with the given connection latch, conflicting SPD changes have been made, or DPD has been triggered and the peer is considered dead or restarted)
o 断开（存在与给定连接闩锁冲突的SA，已进行冲突的SPD更改，或已触发DPD，且对等方被视为已死亡或已重新启动）
o CLOSED (by the ULP, the application or administratively)
o 关闭（由ULP、应用程序或管理）
and always have an associated owner, or holder, such as a ULP transmission control block (TCB).
并且始终有相关的所有者或持有者，如ULP变速箱控制块（TCB）。
A connection latch can be born in the LISTENER state, which can transition only to the CLOSED state. The LISTENER state corresponds to LISTEN state of TCP (and other ULPs) and is associated with IP 3-tuples, and can give rise to new connection latches in the ESTABLISHED state.
连接锁存器可以在侦听器状态下生成，侦听器状态只能转换为关闭状态。侦听器状态对应于TCP（和其他ULP）的侦听状态，并与IP 3元组关联，并且可以在已建立状态下产生新的连接锁存。
A connection latch can also be born in the ESTABLISHED and BROKEN states, either through the direct initiative of a ULP or when an event occurs that causes a LISTENER latch to create a new latch (in either ESTABLISHED or BROKEN states). These states represent an active connection latch for a traffic flow's 5-tuple. Connection latches in these two states can transition to the other of the two states, as well as to the CLOSED state.
连接锁存器也可以在已建立和已断开状态下生成，可以通过ULP的直接启动，也可以在导致侦听器锁存器创建新锁存器的事件发生时生成（在已建立或已断开状态下）。这些状态表示流量的5元组的活动连接锁存器。这两种状态下的连接锁存器可以转换到这两种状态中的另一种，也可以转换到关闭状态。
Connection latches remain in the CLOSED state until their owners are informed except where the owner caused the transition, in which case this state is fleeting. Transitions from ESTABLISHED or BROKEN states to the CLOSED state should typically be initiated by latch owners, but implementations SHOULD provide administrative interfaces through which to close active latches.
连接闩锁将保持关闭状态，直到通知其所有者，除非所有者导致转换，在这种情况下，此状态是短暂的。从已建立或中断状态到关闭状态的转换通常应由闩锁所有者启动，但实现应提供管理接口，通过该接口关闭活动闩锁。
Connection latches transition to the BROKEN state when there exist SAs in the SAD whose traffic selectors encompass the 5-tuple bound by the latch, and whose peer and/or parameters conflict with those bound by the latch. Transitions to the BROKEN state also take place when
当SAD中存在SA时，连接闩锁转换为断开状态，SA的流量选择器包含闩锁绑定的5元组，并且其对等和/或参数与闩锁绑定的参数冲突。在以下情况下，也会发生到断开状态的转换：
SPD changes occur that would cause the latched connection's packets to be sent or received with different protection parameters than those that were latched. Transitions to the BROKEN state are also allowed when IKEv2 DPD concludes that the remote peer is dead or has rebooted. Transitions to the BROKEN state always cause the associated owner to be informed. Connection latches in the BROKEN state transition back to ESTABLISHED when all SA and/or SPD conflicts are cleared.
SPD更改会导致锁存连接的数据包以不同于锁存连接的保护参数发送或接收。当IKEv2 DPD断定远程对等机已死亡或已重新启动时，也允许转换到断开状态。向断开状态的转换始终会导致通知关联的所有者。清除所有SA和/或SPD冲突后，处于断开状态的连接锁存将转换回已建立状态。
Most state transitions are the result of local actions of the latch owners (ULPs). The only exceptions are: birth into the ESTABLISHED state from latches in the LISTENER state, transitions to the BROKEN state, transitions from the BROKEN state to ESTABLISHED, and administrative transitions to the CLOSED state. (Additionally, see the implementation note about restartable key management processes in Section 2.)
大多数状态转换是闩锁所有者（ULP）本地操作的结果。唯一的例外是：从侦听器状态的闩锁出生到已建立状态，转换到已断开状态，从已断开状态转换到已建立状态，以及管理转换到已关闭状态。（此外，请参见第2节中关于可重启密钥管理过程的实施说明。）
The state diagram below makes use of conventions described in Section 1.1 and state transition events described in Section 2.3.
下面的状态图使用了第1.1节中描述的约定和第2.3节中描述的状态转换事件。
<CREATE_LISTENER_LATCH(3-tuple, ...)>
:
v <CREATE_CONNECTION_LATCH(5-tuple, ...)>
/--------\ : :
+------|LISTENER|...... : :
| \--------/ : : : +--------------------+
| : : : : |Legend: |
| : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote |
| connect() : : : | state transition|
| called, ...) v v : | |
| : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+
| : | <conflict
| : <conflict or DPD>
| : cleared> | :
| : | | :
| : | v v
| : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/
| |
<RELEASE_LATCH()> <RELEASE_LATCH()>
| |
| v
| /------\
+------------------->|CLOSED|
\------/
<CREATE_LISTENER_LATCH(3-tuple, ...)>
:
v <CREATE_CONNECTION_LATCH(5-tuple, ...)>
/--------\ : :
+------|LISTENER|...... : :
| \--------/ : : : +--------------------+
| : : : : |Legend: |
| : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote |
| connect() : : : | state transition|
| called, ...) v v : | |
| : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+
| : | <conflict
| : <conflict or DPD>
| : cleared> | :
| : | | :
| : | v v
| : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/
| |
<RELEASE_LATCH()> <RELEASE_LATCH()>
| |
| v
| /------\
+------------------->|CLOSED|
\------/
Figure 1: Connection Latching State Machine
图1：连接锁存状态机
The details of the transitions depend on the model of connection latching followed by any given implementation. See the following sections.
转换的详细信息取决于任何给定实现所遵循的连接锁存模型。请参见以下章节。
This section describes the NORMATIVE model of connection latching.
本节描述了连接锁定的标准模型。
In this section, we describe connection latching in terms of a function-call interface between ULPs and the "key manager" component of a native IPsec implementation. Abstract interfaces for creating, inquiring about, and releasing IPsec channels are described.
在本节中，我们将根据ULP和本机IPsec实现的“密钥管理器”组件之间的函数调用接口来描述连接锁定。描述了用于创建、查询和释放IPsec通道的抽象接口。
This model adds a service to the IPsec key manager (i.e., the component that manages the SAD and interfaces with separate implementations of, or directly implements, key exchange protocols): management of connection latches. There is also a new IPsec database, the Latch Database (LD), that contains all connection latch objects. The LD does not persist across system reboots.
此模型向IPsec密钥管理器（即，管理SAD并与单独的密钥交换协议实现或直接实现密钥交换协议的接口的组件）添加服务：连接锁存的管理。还有一个新的IPsec数据库，即闩锁数据库（LD），它包含所有连接闩锁对象。LD不会在系统重新启动期间持续存在。
The traditional IPsec processing model allows the concurrent existence of SAs with different peers but overlapping traffic selectors. Such behavior, in this model, directly violates the requirements for connection latching (see Section 2). We address this problem by requiring that connection latches be broken (and holders informed) when such conflicts arise.
传统的IPsec处理模型允许SA与不同的对等方同时存在，但流量选择器重叠。在这个模型中，这种行为直接违反了连接锁存的要求（参见第2节）。我们通过要求在出现此类冲突时断开连接闩锁（并通知持有人）来解决此问题。
The following INFORMATIVE figure illustrates this model and API in terms that are familiar to many implementors, though not applicable to all:
下图以许多实施者都熟悉的术语说明了此模型和API，但并不适用于所有实施者：
+--------------------------------------------+
| +--------------+ |
| |Administrator | |
| |apps | |
| +--------------+ |
| ^ ^ |
| | | | user mode
| v v |
| +--------------+ +-------++--------+ |
| |App | |IKEv2 || | |
| | | | +---+ || +----+ | |
| | | | |PAD| || |SPD | | |
| | | | +---+ || +--^-+ | |
| +--------------+ +-+-----++----+---+ |
| ^ | | |
+---|---------------------|-----------|------+ user/kernel mode
| |syscalls | PF_KEY | | interface
| | | [RFC2367] | |
+---|---------------------|-----------|------+
| v | | |
|+-------+ +------------|-----------|-----+|
||ULP | | IPsec key|manager | ||
|+-------+ | | +--------v----+||
| ^ ^ | | | Logical SPD |||
| | | | | +-----------^-+||
| | | | +-------+ | || kernel mode
| | | | | | ||
| | | | +----------+ +--v--+ | ||
| | +-------->| Latch DB |<-->| SAD | | ||
| | | +----------+ +--^--+ | ||
| | +--------------------|------|--+|
+-|-------------------------------v------v---+
| | IPsec Layer (ESP/AH) |
| | |
+-v------------------------------------------+
| IP Layer |
+--------------------------------------------+
+--------------------------------------------+
| +--------------+ |
| |Administrator | |
| |apps | |
| +--------------+ |
| ^ ^ |
| | | | user mode
| v v |
| +--------------+ +-------++--------+ |
| |App | |IKEv2 || | |
| | | | +---+ || +----+ | |
| | | | |PAD| || |SPD | | |
| | | | +---+ || +--^-+ | |
| +--------------+ +-+-----++----+---+ |
| ^ | | |
+---|---------------------|-----------|------+ user/kernel mode
| |syscalls | PF_KEY | | interface
| | | [RFC2367] | |
+---|---------------------|-----------|------+
| v | | |
|+-------+ +------------|-----------|-----+|
||ULP | | IPsec key|manager | ||
|+-------+ | | +--------v----+||
| ^ ^ | | | Logical SPD |||
| | | | | +-----------^-+||
| | | | +-------+ | || kernel mode
| | | | | | ||
| | | | +----------+ +--v--+ | ||
| | +-------->| Latch DB |<-->| SAD | | ||
| | | +----------+ +--^--+ | ||
| | +--------------------|------|--+|
+-|-------------------------------v------v---+
| | IPsec Layer (ESP/AH) |
| | |
+-v------------------------------------------+
| IP Layer |
+--------------------------------------------+
Figure 2: Informative Implementation Architecture Diagram
图2：信息实现架构图
The ULP interfaces to the IPsec LD are as follows:
IPsec LD的ULP接口如下所示：
o CREATE_LISTENER_LATCH(3-tuple, [type and quality-of-protection parameters]) -> latch handle | error
o 创建|侦听器|闩锁（3元组，[保护参数的类型和质量]）->闩锁句柄|错误
If there is no conflicting connection latch object in the LISTENER state for the given 3-tuple (local address, protocol, and local port number), and local policy permits it, then this operation atomically creates a connection latch object in the LISTENER state for the given 3-tuple.
如果给定3元组（本地地址、协议和本地端口号）的侦听器状态中没有冲突的连接闩锁对象，并且本地策略允许，则此操作会自动为给定3元组创建侦听器状态中的连接闩锁对象。
When a child SA is created that matches a listener latch's 3-tuple, but not any ESTABLISHED connection latch's 5-tuple (local address, remote address, protocol, local port number, and remote port number), then the key manager creates a new connection latch object in the ESTABLISHED state. The key manager MUST inform the holder of the listener latch of connection latches created as a result of the listener latch; see the "ALERT()" interface below.
当创建的子SA与侦听器闩锁的3元组匹配，但与任何已建立连接闩锁的5元组（本地地址、远程地址、协议、本地端口号和远程端口号）不匹配时，密钥管理器将在已建立状态下创建新的连接闩锁对象。密钥管理器必须通知侦听器闩锁的持有者由于侦听器闩锁而创建的连接闩锁；请参阅下面的“ALERT（）”界面。
o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID]) -> latch handle | error
o 创建_连接_闩锁（5元组，[保护参数的类型和质量]，[对等ID]，[本地ID]）->闩锁句柄|错误
If a) the requested latch does not exist (or exists, but is in the CLOSED state), b) all the latch parameters are provided, or if suitable SAs exist in the SAD from which to derive them, and c) if there are no conflicts with the SPD and SAD, then this creates a connection latch in the ESTABLISHED state. If the latch parameters are not provided and no suitable SAs exist in the SAD from which to derive those parameters, then the key manager MUST initiate child SAs, and if need be, IKE_SA, from which to derive those parameters.
如果a）请求的锁存器不存在（或存在，但处于关闭状态），b）提供所有锁存器参数，或者如果从中派生它们的SAD中存在合适的SA，以及c）如果与SPD和SAD没有冲突，则这将在已建立状态下创建连接锁存器。如果未提供锁存参数，并且SAD中不存在用于派生这些参数的合适SA，则密钥管理器必须启动子SA，如果需要，则启动用于派生这些参数的IKE_SA。
The key manager MAY delay the child SA setup and return immediately after the policy check, knowing that the ULP that requested the latch will subsequently output a packet that will trigger the SA establishment. Such an implementation may require an additional, fleeting state in the connection latch state machine, a "LARVAL" state, so to speak, that is not described herein.
密钥管理器可以延迟子SA设置并在策略检查后立即返回，知道请求锁存的ULP随后将输出将触发SA建立的分组。这样的实现可能需要连接锁存状态机中的附加的快速状态，也就是说，这里没有描述的“幼虫”状态。
If the connection latch ultimately cannot be established, either because of conflicts or because no SAs can be established with the peer at the destination address, then an error is returned to the ULP. (If the key manager delayed SA establishment, and SA establishment ultimately fails, then the key manager has to inform the ULP, possibly asynchronously. This is one of several details that implementors who use a LARVAL state must take care of.)
如果由于冲突或无法与目标地址的对等方建立SAs，最终无法建立连接闩锁，则会向ULP返回错误。（如果密钥管理器延迟SA建立，并且SA建立最终失败，则密钥管理器必须通知ULP，可能是异步的。这是使用幼体状态的实现者必须注意的几个细节之一。）
o RELEASE_LATCH(latch object handle)
o 释放闩锁（闩锁对象手柄）
Changes the state of the given connection latch to CLOSED; the connection latch is then deleted.
将给定连接闩锁的状态更改为关闭；然后删除连接闩锁。
The key manager MAY delete any existing child SAs that match the given latch if it had been in the ESTABLISHED states. If the key manager does delete such SAs, then it SHOULD inform the peer with an informational Delete payload (see IKEv2 [RFC4306]).
密钥管理器可以删除与给定闩锁匹配的任何现有子SA（如果该闩锁已处于已建立状态）。如果密钥管理器确实删除了这样的SA，那么它应该用信息性删除有效负载通知对等方（参见IKEv2[RFC4306]）。
o FIND_LATCH(5-tuple) -> latch handle | error
o 查找锁存（5元组）->锁存句柄错误
Given a 5-tuple returns a latch handle (or an error).
给定一个5元组，返回一个锁存句柄（或一个错误）。
o INQUIRE_LATCH(latch object handle) -> {latch state, latched parameters} | error
o 查询闩锁（闩锁对象句柄）->{闩锁状态，闩锁参数}错误
Returns all available information about the given latch, including its current state (or an error).
返回有关给定闩锁的所有可用信息，包括其当前状态（或错误）。
The IPsec LD interface to the ULP is as follows:
到ULP的IPsec LD接口如下所示：
o ALERT(latch object handle, 5-tuple, new state, [reason])
o 警报（闩锁对象句柄，5元组，新状态，[原因]）
Alerts a ULP as to an asynchronous state change for the given connection latch and, optionally, provides a reason for the change.
提醒ULP给定连接闩锁的异步状态更改，并（可选）提供更改原因。
This interface is to be provided by each ULP to the key manager. The specific details of how this interface is provided are implementation details, thus not specified here (for example, this could be a "callback" function or "closure" registered as part of the CREATE_LISTENER_LATCH() interface, or it could be provided when the ULP is loaded onto the running system via a registration interface provided by the key manager).
该接口由每个ULP提供给密钥管理器。如何提供此接口的具体细节是实现细节，因此此处未指定（例如，这可能是作为CREATE_LISTENER_lack（）的一部分注册的“回调”函数或“闭包”）接口，也可以在ULP通过密钥管理器提供的注册接口加载到运行系统时提供）。
Needless to say, the LD is updated whenever a connection latch object is created, deleted, or broken.
不用说，每当创建、删除或断开连接闩锁对象时，LD都会更新。
The API described above is a new service of the IPsec key manager. In particular, the IPsec key manager MUST prevent conflicts amongst latches, and it MUST prevent conflicts between any latch and existing or proposed child SAs as follows:
上面描述的API是IPsec密钥管理器的新服务。特别是，IPsec密钥管理器必须防止闩锁之间的冲突，并且必须防止任何闩锁与现有或建议的子SA之间的冲突，如下所示：
o Non-listener connection latches MUST NOT be created if there exist conflicting SAs in the SAD at the time the connection latch is requested or would be created (from a listener latch). A child SA
o 如果在请求或将创建连接闩锁时（从侦听器闩锁）SAD中存在冲突SA，则不得创建非侦听器连接闩锁。一个孩子
conflicts with another, in view of a latch, if and only if: a) its traffic selectors and the conflicting SA's match the given latch's, and b) its peer, type-of-protection, or quality-of-protection parameters differ from the conflicting SA.
从闩锁的角度来看，当且仅当：a）其流量选择器和冲突SA与给定闩锁匹配，以及b）其对等方、保护类型或保护质量参数与冲突SA不同时，才与另一个发生冲突。
o Child SA proposals that would conflict with an extant connection latch and whose traffic selectors can be narrowed to avoid the conflict SHOULD be narrowed (see Section 2.9 of [RFC4306]); otherwise, the latch MUST be transitioned to the BROKEN state.
o 应缩小与现有连接闩锁冲突且其流量选择器可缩小以避免冲突的子SA方案（见[RFC4306]第2.9节）；否则，闩锁必须转换为断开状态。
o Where child SA proposals that would conflict with an extant connection latch cannot be narrowed to avoid the conflict, the key manager MUST break the connection latch and inform the holder (i.e., the ULP) prior to accepting the conflicting SAs.
o 如果无法缩小与现有连接闩锁冲突的子SA提案以避免冲突，则密钥管理器必须断开连接闩锁，并在接受冲突的SA之前通知持有人（即ULP）。
Finally, the key manager MUST protect latched connections against SPD changes that would change the quality of protection afforded to a latched connection's traffic, or which would bypass it. When such a configuration change takes place, the key manager MUST respond in either of the following ways. The REQUIRED to implement behavior is to transition into the BROKEN state all connection latches that conflict with the given SPD change. An OPTIONAL behavior is to logically update the SPD as if a PROTECT entry had been added at the head of the SPD-S with traffic selectors matching only the latched connection's 5-tuple, and with processing information taken from the connection latch. Such updates of the SPD MUST NOT survive system crashes or reboots.
最后，密钥管理器必须保护锁存连接不受SPD变化的影响，SPD变化会改变为锁存连接的通信量提供的保护质量，或者会绕过它。当发生此类配置更改时，密钥管理器必须以以下任一方式响应。实现行为所需的是将所有与给定SPD更改冲突的连接锁存转换为断开状态。一种可选的行为是逻辑上更新SPD，就像在SPD-S的头部添加了一个保护条目一样，流量选择器只匹配锁存连接的5元组，并使用从连接锁存器获取的处理信息。SPD的此类更新不得在系统崩溃或重新启动后继续存在。
ULPs create latched connections by interfacing with IPsec as follows:
ULP通过与IPsec接口创建锁存连接，如下所示：
o For listening end-points, the ULP will request a connection latch listener object for the ULP listener's 3-tuple. Any latching parameters requested by the application MUST be passed along.
o 对于侦听端点，ULP将为ULP侦听器的3元组请求连接闩锁侦听器对象。必须传递应用程序请求的任何锁定参数。
o When the ULP receives a packet initiating a connection for a 5-tuple matching a 3-tuple listener latch, then the ULP will ask the key manager whether a 5-tuple connection latch was created. If not, then the ULP will either reject the new connection or accept it and inform the application that the new connection is not latched.
o 当ULP接收到一个发起5元组连接的数据包，该数据包与3元组侦听器锁存器匹配时，ULP将询问密钥管理器是否创建了5元组连接锁存器。如果没有，ULP将拒绝或接受新连接，并通知应用程序新连接未锁定。
o When initiating a connection, the ULP will request a connection latch object for the connection's 5-tuple. Any latching parameters requested by the application MUST be passed along. If no latch can be created, then the ULP MUST either return an error to the application or continue with the new connection and inform the application that the new connection is not latched.
o 启动连接时，ULP将为连接的5元组请求连接闩锁对象。必须传递应用程序请求的任何锁定参数。如果无法创建闩锁，则ULP必须向应用程序返回错误或继续新连接，并通知应用程序新连接未被闩锁。
o When a connection is torn down and no further packets are expected for it, then the ULP MUST request that the connection latch object be destroyed.
o 当一个连接被拆毁，并且预期不会有更多的数据包出现时，ULP必须请求销毁连接闩锁对象。
o When tearing down a listener, the ULP MUST request that the connection latch listener object be destroyed.
o 拆除侦听器时，ULP必须请求销毁连接闩锁侦听器对象。
o When a ULP listener rejects connections, the ULP will request the destruction of any connection latch objects that may have been created as a result of the peer's attempt to open the connection.
o 当ULP侦听器拒绝连接时，ULP将请求销毁任何可能由于对等方尝试打开连接而创建的连接闩锁对象。
o When the key manager informs a ULP that a connection latch has transitioned to the BROKEN state, then the ULP MUST stop sending packets and MUST drop all subsequent incoming packets for the affected connection until it transitions back to ESTABLISHED. Connection-oriented ULPs SHOULD act as though the connection is experiencing packet loss.
o 当密钥管理器通知ULP连接闩锁已转换为断开状态时，ULP必须停止发送数据包，并且必须丢弃受影响连接的所有后续传入数据包，直到其转换回已建立状态。面向连接的ULP应该像连接正在经历数据包丢失一样工作。
o When the key manager informs a ULP that a connection latch has been administratively transitioned to the CLOSED state, then connection-oriented ULPs MUST act as though the connection has been reset by the peer. Implementations of ULPs that are not connection-oriented, and which have no API by which to simulate a reset, MUST drop all inbound packets for that connection and MUST NOT send any further packets -- the application is expected to detect timeouts and act accordingly.
o 当密钥管理器通知ULP连接闩锁已通过管理方式转换为关闭状态时，面向连接的ULP必须像连接已被对等方重置一样工作。不面向连接且没有用于模拟重置的API的ULP实现必须丢弃该连接的所有入站数据包，并且不得发送任何进一步的数据包——应用程序预计将检测超时并相应地采取行动。
The main benefit of this model of connection latching is that it accommodates IPsec implementations where ESP/AH handling is implemented in hardware (for all or a subset of the host's SAD), even where the hardware does not support tagging inbound packets with the indexes of SAD entries corresponding to the SAs that protected them.
这种连接锁存模式的主要好处是，它适应了在硬件中实现ESP/AH处理的IPsec实现（对于主机的所有SAD或其子集），即使硬件不支持使用与保护它们的SAs对应的SAD条目索引标记入站数据包。
ULPs MUST drop inbound packets and stop sending packets immediately upon receipt of a connection latch break message. Otherwise, the ULP will not be able to distinguish inbound packets that were protected consistently with the connection's latch from inbound packets that were not. This may include dropping inbound packets that were protected by a suitable SA; dropping such packets is no different, from the ULP's point of view, than packet loss elsewhere on the network at the IP layer or below -- harmless, from a security point of view as the connection fails safe, but it can result in retransmits.
ULP必须在收到连接闩锁中断消息后立即丢弃入站数据包并停止发送数据包。否则，ULP将无法区分使用连接锁存器一致保护的入站数据包与未使用连接锁存器的入站数据包。这可包括丢弃由适当SA保护的入站分组；从ULP的角度来看，丢弃这样的数据包与IP层或更低层的网络上其他地方的数据包丢失没有什么不同——从安全角度看，这是无害的，因为连接失败是安全的，但它可能导致重新传输。
Another race condition is as follows. A PROTECTed TCP SYN packet may be received and decapsulated, but the SA that protected it could have expired before the key manager creates the connection latch that would be created by that packet. In this case, the key manager will have to initiate new child SAs so as to determine what the sender's peer ID is so it can be included in the connection latch. Here, there is no guarantee that the peer ID for the new SAs will be the same as those of the peer that sent the TCP SYN packet. This race condition is harmless: TCP will send a SYN+ACK to the wrong peer, which will then respond with a RST -- the connection latch will reflect the new peer however, so if the new peer is malicious it will not be able to appear to be the old peer. Therefore, this race condition is harmless.
另一个竞赛条件如下。可以接收并解除封装受保护的TCP SYN数据包，但在密钥管理器创建将由该数据包创建的连接锁存器之前，保护该数据包的SA可能已过期。在这种情况下，密钥管理器必须启动新的子SAs，以便确定发送方的对等ID，以便将其包括在连接闩锁中。这里，不能保证新SA的对等ID与发送TCP SYN数据包的对等ID相同。这种竞争条件是无害的：TCP将向错误的对等方发送SYN+ACK，然后该对等方将以RST响应——然而，连接锁存器将反映新对等方，因此如果新对等方是恶意的，它将无法显示为旧对等方。因此，这种竞争条件是无害的。
Consider several systems with a very simple PAD containing a single entry like so:
考虑几个具有非常简单的PAD的系统，包含一个单一的条目，如：
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <any valid to trust anchor X> 192.0.2/24 by-IP
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <any valid to trust anchor X> 192.0.2/24 by-IP
Figure 3: Example PAD
图3：示例焊盘
And a simple SPD like so:
还有一个简单的SPD，如下所示：
Rule Local Remote Next Action
TS TS Proto
---- ----- ------ ----- ----------------
1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...)
1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...)
1 ANY ANY ANY BYPASS
Rule Local Remote Next Action
TS TS Proto
---- ----- ------ ----- ----------------
1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...)
1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...)
1 ANY ANY ANY BYPASS
Figure 4: [SG-A] SPD Table
图4:[SG-A]SPD表
Effectively this says: for TCP ports 1-5000 in our network, allow only peers that have credentials issued by CA X and PROTECT that traffic with ESP, otherwise, bypass all other traffic.
实际上，这表明：对于我们网络中的TCP端口1-5000，只允许具有CA X颁发的凭据的对等方，并使用ESP保护该流量，否则，绕过所有其他流量。
Now let's consider two hosts, A and B, in this network that wish to communicate using port 4000, and a third host, C, that is also in the same network and wishes to attack A and/or B. All three hosts have credentials and certificates issued by CA X. Let's also imagine that A is connected to its network via a wireless link and is dynamically addressed.
现在让我们考虑两个主机，A和B，在这个网络中，希望使用端口4000和第三个主机C通信，这也是在同一个网络中，并希望攻击A和/或B。所有三个主机都有CA X颁发的凭据和证书。我们还可以设想A通过无线链路连接到其网络，并动态寻址。
B is listening on port 4000. A initiates a connection from port 32800 to B on port 4000.
B正在监听端口4000。A启动从端口32800到端口4000上B的连接。
We'll assume no IPsec APIs, but that TCP creates latches where possible.
我们假设没有IPSecAPI，但TCP会在可能的情况下创建锁存。
We'll consider three cases: a) A and B both support connection latching, b) only A does, c) only B does. For the purposes of this example, the SAD is empty on all three hosts when A initiates its TCP connection to B on port 4000.
我们将考虑三种情况：A）A和B都支持连接锁存，B）只有A，C）只有B。在本例中，当A在端口4000上启动与B的TCP连接时，所有三台主机上的SAD都为空。
When an application running on A initiates a TCP connection to B on port 4000, A will begin by creating a connection latch. Since the SAD is empty, A will initiate an IKEv2 exchange to create an IKE_SA with B and a pair of child SAs for the 5-tuple {TCP, A, 32800, B, 4000}, then a new latch will be created in ESTABLISHED state. Sometime later, TCP will send a SYN packet protected by the A-to-B child SA, per the SPD.
当在A上运行的应用程序在端口4000上启动到B的TCP连接时，A将首先创建连接锁存器。由于SAD为空，A将启动IKEv2交换，以创建一个IKE_SA和一对5元组{TCP，A，32800，B，4000}的子SA，然后将在已建立状态下创建一个新锁存器。稍后，TCP将根据SPD发送一个由a-to-B子SA保护的SYN数据包。
When an application running on B creates a TCP listener "socket" on port 4000, B will create a LISTENER connection latch for the 3-tuple {TCP, B, 4000}. When B receives A's TCP SYN packet, it will then create a connection latch for {TCP, B, 4000, A, 32800}. Since, by this point, child SAs have been created whose traffic selectors encompass this 5-tuple and there are no other conflicting SAs in the SAD, this connection latch will be created in the ESTABLISHED state.
当在B上运行的应用程序在端口4000上创建TCP侦听器“套接字”时，B将为3元组{TCP，B，4000}创建侦听器连接锁存器。当B收到A的TCP SYN数据包时，它将为{TCP，B，4000，A，32800}创建一个连接锁存器。由于此时已创建其流量选择器包含此5元组的子SA，并且SAD中没有其他冲突SA，因此将在已建立状态下创建此连接闩锁。
If C attempts to mount a man-in-the-middle attack on A (i.e., pretends to have B's address(es)) any time after A created its connection latch, then C's SAs with A will cause the connection latch to break, and the TCP connection to be reset (since we assume no APIs by which TCP could notify the application of the connection latch break). If C attempts to impersonate A to B, then the same thing will happen on B.
如果C在a创建其连接锁存器后的任何时间尝试在a上安装中间人攻击（即，假装有B的地址），那么C的SA和a将导致连接锁存器断开，TCP连接被重置（因为我们假设TCP没有API可以通知应用程序连接锁存器断开）。如果C试图将A模拟成B，那么同样的事情也会发生在B上。
If A does not support connection latching, then C will be able to impersonate B to A at any time. Without having seen the cleartext of traffic between A and B, C will be limited by the TCP sequence numbers to attacks such as RST attacks. Similarly, if B does not support connection latching, then C will be able to impersonate A to B.
如果A不支持连接锁存，那么C将能够随时将B模拟为A。在没有看到A和B之间的明文通信的情况下，C将受到TCP序列号的限制，无法进行诸如RST攻击之类的攻击。类似地，如果B不支持连接锁存，那么C将能够模拟A到B。
In this section, we describe connection latching in terms of interfaces between ULPs and IPsec based on tagging packets as they go up and down the IP stack.
在本节中，我们将根据ULP和IPsec之间的接口描述连接锁定，这些接口基于在IP堆栈上下移动时标记数据包。
This section is INFORMATIVE.
本节内容丰富。
In this model, the ULPs maintain connection latch objects and state, rather than the IPsec key manager, as well as effectively caching a subset of the decorrelated SPD in ULP TCBs. Tagging packets, as they move up and down the stack, with SA identifiers then allows the ULPs to enforce connection latching semantics. These tags, of course, don't appear on the wire.
在该模型中，ULP维护连接锁存对象和状态，而不是IPsec密钥管理器，并在ULP TCB中有效缓存解相关SPD的子集。当数据包在堆栈中上下移动时，使用SA标识符标记数据包，然后允许ULP强制执行连接锁存语义。当然，这些标记不会出现在导线上。
The interface between the ULPs and IPsec interface is as follows:
ULPs和IPsec接口之间的接口如下：
o The IPsec layer tags all inbound protected packets addressed to the host with the index of the SAD entry corresponding to the SA that protected the packet.
o IPsec层使用与保护数据包的SA相对应的SAD条目索引标记所有发往主机的入站受保护数据包。
o The IPsec layer understands two types of tags on outbound packets:
o IPsec层理解出站数据包上的两种类型的标记：
* a tag specifying a set of latched parameters (peer ID, quality of protection, etc.) that the IPsec layer will use to find or acquire an appropriate SA for protecting the outbound packet (else IPsec will inform the ULP and drop the packet);
* 指定一组锁存参数（对等ID、保护质量等）的标签，IPsec层将使用该参数查找或获取用于保护出站数据包的适当SA（否则IPsec将通知ULP并丢弃数据包）；
* a tag requesting feedback about the SA used to protect the outgoing packet, if any.
* 请求有关SA的反馈的标签，用于保护传出数据包（如果有）。
ULPs create latched connections by interfacing with IPsec as follows:
ULP通过与IPsec接口创建锁存连接，如下所示：
o When the ULP passes a connection's initiating packet to IP, the ULP requests feedback about the SA used to protect the outgoing packet, if any, and may specify latching parameters requested by the application. If the packet is protected by IPsec, then the ULP records certain parameters of the SA used to protect it in the connection's TCB.
o 当ULP将连接的起始数据包传递给IP时，ULP请求有关用于保护传出数据包（如果有）的SA的反馈，并且可以指定应用程序请求的锁定参数。如果数据包受IPsec保护，则ULP会在连接的TCB中记录用于保护数据包的SA的某些参数。
o When a ULP receives a connection's initiating packet, it processes the IPsec tag of the packet, and it records in the connection's TCB the parameters of the SA that should be latched.
o 当ULP接收到连接的起始数据包时，它处理数据包的IPsec标记，并在连接的TCB中记录应锁定的SA参数。
Once SA parameters are recorded in a connection's TCB, the ULP enforces the connection's latch, or binding, to these parameters as follows:
一旦SA参数记录在连接的TCB中，ULP将对这些参数强制连接的锁存或绑定，如下所示：
o The ULP processes the IPsec tag of all inbound packets for a given connection and checks that the SAs used to protect input packets match the connection latches recorded in the TCBs. Packets that are not so protected are dropped (this corresponds to transitioning the connection latch to the BROKEN state until the
o ULP处理给定连接的所有入站数据包的IPsec标记，并检查用于保护输入数据包的SAs是否与TCB中记录的连接锁存匹配。不受保护的数据包将被丢弃（这相当于将连接锁存转换为断开状态，直到
next acceptable packet arrives, but in this model, this transition is imaginary) or cause the ULP to break the connection latch and inform the application.
下一个可接受的数据包到达，但在此模型中，此转换是虚构的）或导致ULP断开连接闩锁并通知应用程序。
o The ULP always requests that outgoing packets be protected by SAs that match the latched connection by appropriately tagging outbound packets.
o ULP始终请求通过适当标记出站数据包，由与锁定连接匹配的SAs保护出站数据包。
By effectively caching a subset of the decorrelated SPD in ULP TCBs and through its packet tagging nature, this method of connection latching can also optimize processing of the SPD by obviating the need to search it, both, on input and output, for packets intended for the host or originated by the host. This makes implementation of the OPTIONAL "logical SPD" updates described in Sections 2.3 and 3.1 an incidental side effect of this approach.
通过在ULP TCB中有效地缓存解相关SPD的子集并通过其分组标记性质，这种连接锁存方法还可以通过避免在输入和输出时搜索用于主机或由主机发起的分组来优化SPD的处理。这使得第2.3节和第3.1节中描述的可选“逻辑SPD”更新的实施成为该方法附带的副作用。
This model of connection latching may not be workable with ESP/AH offload hardware that does not support the packet tagging scheme described above.
对于不支持上述数据包标记方案的ESP/AH卸载硬件，这种连接锁存模式可能不可行。
Note that this model has no explicit BROKEN connection latch state.
请注意，此模型没有明确的断开连接闩锁状态。
Extending the ULP/IPsec packet-tagging interface to the application for use with connection-less datagram transports should enable applications to use such transports and implement connection latching at the application layer.
将ULP/IPsec数据包标记接口扩展到应用程序以用于无连接数据报传输，应使应用程序能够使用此类传输，并在应用程序层实现连接锁存。
This section is INFORMATIVE.
本节内容丰富。
Non-native IPsec implementations, primarily BITS and SG, can implement connection latching, too. One major distinction between native IPsec and BITS, bump-in-the-wire (BITW), or SG IPsec is the lack of APIs for applications at the end-points in the case of the latter. As a result, there can be no uses of the latch management interfaces as described in Section 2.3: not at the ULP end-points. Therefore, BITS/BITW/SG implementations must discern ULP connection state from packet inspection (which many firewalls can do) and emulate calls to the key manager accordingly.
非本机IPsec实现（主要是BITS和SG）也可以实现连接锁存。本机IPsec和BITS、线内凹凸（BITW）或SG IPsec之间的一个主要区别是，在后者的情况下，在端点处缺少应用程序的API。因此，不能使用第2.3节中所述的闩锁管理接口：不在ULP端点。因此，BITS/BITW/SG实现必须将ULP连接状态与数据包检查区分开来（许多防火墙都可以这样做），并相应地模拟对密钥管理器的调用。
When a connection latch is broken, a BITS/BITW/SG implementation may have to fake a connection reset by sending appropriate packets (e.g., TCP RST packets), for the affected connections.
当连接锁存器断开时，BITS/BITW/SG实现可能必须通过为受影响的连接发送适当的数据包（例如TCP RST数据包）来伪造连接重置。
As with all stateful middleboxes, this scheme suffers from the inability of the middlebox to interact with the applications. For example, connection death may be difficult to ascertain. Nor can
与所有有状态的中间盒一样，该方案的缺点是中间盒无法与应用程序交互。例如，连接死亡可能很难确定。也不能
channel binding applications work with channels maintained by proxy without being able to communicate (securely) about it with the middlebox.
通道绑定应用程序使用代理维护的通道，而不能够（安全地）与中间盒进行通信。
One of the recommendations for connection latching implementors is to make peer CERT payloads (certificates) available to the applications.
对于连接锁存实现者的建议之一是使对等证书有效负载（证书）可用于应用程序。
Additionally, raw public keys are likely to be used in the construction of channel bindings for IPsec channels (see [IPSEC-CB]), and they must be available, in any case, in order to implement leap-of-faith at the application layer (see [RFC5386] and [RFC5387]).
此外，原始公钥可能用于构建IPsec通道的通道绑定（请参见[IPsec-CB]），并且在任何情况下都必须可用，以便在应用层实现信任飞跃（请参见[RFC5386]和[RFC5387]）。
Certificates and raw public keys are large bit strings, too large to be reasonably kept in kernel-mode implementations of connection latching (which will likely be the typical case). Such implementations should intern peer IDs in a user-mode database and use small integers to refer to them from the kernel-mode SAD and LD. Corruption of such a database is akin to corruption of the SAD/LD; in the event of corruption, the implementation MUST act as though all ESTABLISHED and BROKEN connection latches are administratively transitioned to the CLOSED state. Implementations without IPsec APIs MAY hash peer IDs and use the hash to refer to them, preferably using a strong hash algorithm.
证书和原始公钥是大位字符串，太大了，无法在连接锁存的内核模式实现中合理地保留（这可能是典型的情况）。这种实现应该在用户模式数据库中插入对等ID，并使用小整数从内核模式SAD和LD引用它们。这种数据库的损坏类似于SAD/LD的损坏；在发生损坏的情况下，实现必须像所有已建立和已断开的连接锁存器都在管理上转换为关闭状态一样工作。没有IPsec api的实现可以散列对等id并使用散列来引用它们，最好使用强散列算法。
At its bare minimum, connection latching is a passive layer atop IPsec that warns ULPs of SPD and SAD changes that are incompatible with the SPD/SAD state that was applicable to a connection when it was established.
至少，连接锁存是IPsec上的一个被动层，它警告ULP SPD和SAD更改与建立连接时适用于连接的SPD/SAD状态不兼容。
There are some optional features, such as (abstract) APIs. Some of these features make connection latching a somewhat more active feature. Specifically, the optional logical SPD updates described in Section 2.3 and the optional protection/bypass feature described in the following sub-section.
有一些可选特性，例如（抽象）API。其中一些特性使连接锁存变得更为活跃。具体而言，第2.3节中描述的可选逻辑SPD更新和下一小节中描述的可选保护/旁路功能。
Given IPsec APIs, an application could request that a connection's packets be protected where they would otherwise be bypassed; that is, applications could override BYPASS policy. Locally privileged applications could request that their connections' packets be bypassed rather than protected; that is, privileged applications could override PROTECT policy. We call this "optional protection".
给定IPSecAPI，应用程序可以请求保护连接的数据包，否则这些数据包将被绕过；也就是说，应用程序可以覆盖旁路策略。本地特权应用程序可以请求绕过而不是保护其连接的数据包；也就是说，特权应用程序可以覆盖保护策略。我们称之为“选择性保护”。
Both native IPsec models of connection latching can be extended to support optional protection. With the model described in Section 2.4, optional protection comes naturally: the IPsec layer need only check that the protection requested for outbound packets meets or exceeds (as determined by local or system policy) the quality of protection, if any, required by the SPD. In the case of the model described in Section 2.3, enforcement of minimum protection requirements would be done by the IPsec key manager via the connection latch state machine.
两种本机IPsec连接锁存模型都可以扩展以支持可选保护。对于第2.4节中描述的模型，可选保护自然出现：IPsec层只需检查出站数据包请求的保护是否满足或超过（由本地或系统策略确定）SPD要求的保护质量（如果有）。对于第2.3节中描述的模型，IPsec密钥管理器将通过连接锁存状态机执行最低保护要求。
When an application requests, and local policy permits, either additional protection or bypassing protection, then the SPD MUST be logically updated such that there exists a suitable SPD entry protecting or bypassing the exact 5-tuple recorded by the corresponding connection latch. Such logical SPD updates MUST be made at connection latch creation time, and MUST be made atomically (see the note about race conditions in Section 2.3). Such updates of the SPD MUST NOT survive system crashes or reboots.
当应用程序请求附加保护或旁路保护，且本地策略允许时，必须在逻辑上更新SPD，以便存在合适的SPD条目保护或旁路相应连接锁存器记录的精确5元组。此类逻辑SPD更新必须在连接锁存器创建时进行，并且必须以原子方式进行（请参阅第2.3节中有关竞争条件的说明）。SPD的此类更新不得在系统崩溃或重新启动后继续存在。
Some connection-oriented ULPs, specifically TCP, support simultaneous connections (where two clients connect to each other, using the same 5-tuple, at the same time). Connection latching supports simultaneous latching as well, provided that the key exchange protocol does not make it impossible.
一些面向连接的ULP，特别是TCP，支持同时连接（其中两个客户端同时使用相同的5元组相互连接）。连接锁存也支持同时锁存，前提是密钥交换协议不会使之成为不可能。
Consider two applications doing a simultaneous TCP connect to each other and requesting an IPsec channel. If they request the same connection latching parameters, then the connection and channel should be established as usual. Even if the key exchange protocol in use doesn't support simultaneous IKE_SA and/or child SA establishment, provided one peer's attempt to create the necessary child SAs succeeds, then the other peer should be able to notice the new SAs immediately upon failure of its attempts to create the same.
考虑两个应用程序同时进行TCP连接并请求IPSec通道。如果它们请求相同的连接锁存参数，则应像往常一样建立连接和通道。即使使用中的密钥交换协议不支持同时建立IKE_SA和/或子SA，只要一个对等方尝试创建必要的子SA成功，那么另一个对等方应该能够在尝试创建相同的子SA失败时立即注意到新SA。
If, however, the two peer applications were to request different connection latching parameters, then the connection latch must fail on one end or on both ends.
但是，如果两个对等应用程序请求不同的连接锁存参数，则连接锁存器必须在一端或两端发生故障。
The following sub-sections describe connection latching for each of three transport protocols. Note that for TCP and UDP, there is nothing in the following sections that should not already be obvious from the remainder of this document. The section on SCTP, however, specifies details related to SCTP multi-homing, that may not be as obvious.
以下小节描述了三种传输协议中每种协议的连接锁存。请注意，对于TCP和UDP，以下各节中没有任何内容在本文档的其余部分中不明显。但是，关于SCTP的部分详细说明了与SCTP多归宿相关的细节，这些细节可能并不明显。
IPsec connection latch creation/release for TCP [RFC0793] connections is triggered when:
TCP[RFC0793]连接的IPsec连接闩锁创建/释放在以下情况下触发：
o a TCP listener end-point is created (e.g., when the BSD Sockets listen() function is called on a socket). This should cause the creation of a LISTENER connection latch.
o 创建TCP侦听器端点（例如，在套接字上调用BSD Sockets listen（）函数时）。这将导致创建侦听器连接闩锁。
o a TCP SYN packet is received on an IP address and port number for which there is a listener. This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o TCP SYN数据包在有侦听器的IP地址和端口号上接收。这将导致创建已建立或已断开的连接闩锁。
o a TCP SYN packet is sent (e.g., as the result of a call to the BSD Sockets connect() function). This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o 发送TCP SYN数据包（例如，作为调用BSD Sockets connect（）函数的结果）。这将导致创建已建立或已断开的连接闩锁。
o any state transition of a TCP connection to the CLOSED state will cause a corresponding transition for any associated connection latch to the CLOSED state as well.
o TCP连接到关闭状态的任何状态转换都将导致任何关联的连接锁存器也相应地转换到关闭状态。
See Section 5.5 for how to handle latch transitions to the BROKEN state.
有关如何处理闩锁转换到断开状态的信息，请参见第5.5节。
UDP [RFC0768] is a connection-less transport protocol. However, some networking APIs (e.g., the BSD Sockets API) allow for emulation of UDP connections. In this case, connection latching can be supported using either model given above. We ignore, in this section, the fact that the connection latching model described in Section 2.4 can support per-datagram latching by extending its packet tagging interfaces to the application.
UDP[RFC0768]是一种无连接传输协议。但是，某些网络API（例如BSD套接字API）允许模拟UDP连接。在这种情况下，可以使用上述任一模型支持连接锁存。在本节中，我们忽略了一个事实，即第2.4节中描述的连接锁存模型可以通过将其包标记接口扩展到应用程序来支持每数据报锁存。
IPsec connection latch creation/release for UDP connections is triggered when:
UDP连接的IPsec连接闩锁创建/释放在以下情况下触发：
o an application creates a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o 应用程序创建UDP“连接”。这将导致创建已建立或已断开的连接闩锁。
o an application destroys a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o 应用程序破坏UDP“连接”。这将导致创建已建立或已断开的连接闩锁。
When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken, then UDP should inform the application, if
当连接锁存器转换为断开状态且应用程序请求（或系统策略指示）连接断开时，UDP应通知应用程序（如果需要）
there is a way to do so, or else it should wait, allowing the application-layer keepalive/timeout strategy, if any, to time out the connection.
有一种方法可以做到这一点，否则它应该等待，允许应用层keepalive/timeout策略（如果有的话）超时连接。
What constitutes an appropriate action in the face of administrative transitions of connection latches to the CLOSED state depends on whether the implementation's "connected" UDP sockets API provides a way for the socket to return an error indicating that it has been closed.
在连接锁存器向关闭状态的管理转换过程中，什么构成适当的操作取决于实现的“已连接”UDP套接字API是否为套接字返回指示其已关闭的错误提供了一种方法。
Implementations based on either model of connection latching can provide applications with datagram-tagging APIs based on those described in Section 2.4. Implementations UDP with of the normative model of IPsec connection latching have to confirm, on output, that the application provided 5-tuple agrees with the application-provided connection latch; on input, UDP can derive the tag by searching for a connection latch matching incoming datagram's 5-tuple.
基于任何一种连接锁存模型的实现都可以为应用程序提供基于第2.4节所述的数据报标记API。IPsec连接锁存的标准模型的UDP实现必须在输出时确认应用程序提供的5元组与应用程序提供的连接锁存一致；在输入时，UDP可以通过搜索与传入数据报的5元组匹配的连接锁存来派生标记。
SCTP [RFC4960], a connection-oriented protocol is similar, in some ways, to TCP. The salient difference, with respect to connection latching, between SCTP and TCP is that SCTP allows each end-point to be identified by a set of IP addresses, though, like TCP, each end-point of an SCTP connection (or, rather, SCTP association) can only have one port number.
SCTP[RFC4960]，一种面向连接的协议，在某些方面与TCP类似。在连接锁存方面，SCTP和TCP之间的显著区别在于，SCTP允许通过一组IP地址标识每个端点，尽管与TCP一样，SCTP连接（或者更确切地说，SCTP关联）的每个端点只能有一个端口号。
We can represent the multiplicity of SCTP association end-point addresses as a multiplicity of 5-tuples, each of which with its own connection latch. Alternatively, we can extend the connection latch object to support a multiplicity of addresses for each end-point. The first approach is used throughout this document; therefore, we will assume that representation.
我们可以将SCTP关联端点地址的多重性表示为5元组的多重性，每个元组都有自己的连接锁存器。或者，我们可以扩展连接闩锁对象，以支持每个端点的多个地址。第一种方法贯穿本文件；因此，我们将假设该代表性。
Of course, this approach results in N x M connection latches for any SCTP associations (where one end-point has N addresses and the other has M); whereas the alternative requires one connection latch per SCTP association (with N + M addresses). Implementors may choose either approach.
当然，这种方法会导致任何SCTP关联的N x M连接锁存（其中一个端点有N个地址，另一个有M个地址）；然而，替代方案要求每个SCTP关联（具有N+M地址）有一个连接闩锁。实现者可以选择其中一种方法。
IPsec connection latch creation/release for SCTP connections is triggered when:
在以下情况下触发SCTP连接的IPsec连接闩锁创建/释放：
o an SCTP listener end-point is created (e.g., when the SCTP sockets listen() function is called on a socket). This should cause the creation of a LISTENER connection latch for each address of the listener.
o 创建SCTP侦听器端点（例如，在套接字上调用SCTP sockets listen（）函数时）。这将导致为侦听器的每个地址创建侦听器连接锁存器。
o an SCTP INIT chunk is received on an IP address and port number for which there is a listener. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches, one for each distinct 5-tuple given the client and server's addresses.
o 在有侦听器的IP地址和端口号上接收SCTP INIT块。这将导致创建一个或多个已建立或已断开的连接锁存器，给定客户端和服务器的地址，每个不同的5元组对应一个。
o an SCTP INIT chunk is sent (e.g., as the result of a call to the SCTP sockets connect() function). This should cause the creation of one or more ESTABLISHED or BROKEN connection latches.
o 发送SCTP INIT块（例如，作为调用SCTP sockets connect（）函数的结果）。这将导致创建一个或多个已建立或已断开的连接闩锁。
o an SCTP Address Configuration Change Chunk (ASCONF) [RFC5061] adding an end-point IP address is sent or received. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches.
o 发送或接收添加端点IP地址的SCTP地址配置更改块（ASCONF）[RFC5061]。这将导致创建一个或多个已建立或已断开的连接闩锁。
o any state transition of an SCTP association to the CLOSED state will cause a corresponding transition for any associated connection latches to the CLOSED state as well.
o SCTP关联到关闭状态的任何状态转换都将导致任何关联的连接锁存器也相应地转换到关闭状态。
o an SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is sent or received. This should cause one or more associated connection latches to be CLOSED.
o 发送或接收删除端点IP地址的SCTP ASCONF区块[RFC5061]。这将导致一个或多个相关连接闩锁关闭。
See Section 5.5 for how to handle latch transitions to the BROKEN state.
有关如何处理闩锁转换到断开状态的信息，请参见第5.5节。
There are several ways to handle connection latch transitions to the BROKEN state in the case of connection-oriented ULPs like TCP or SCTP:
在面向连接的ULP（如TCP或SCTP）的情况下，有几种方法可以处理连接闩锁转换到断开状态：
a. Wait for a possible future transition back to the ESTABLISHED state, until which time the ULP will not move data between the two end-points of the connection. ULP and application timeout mechanisms will, of course, be triggered in the event of too lengthy a stay in the BROKEN state. SCTP can detect these timeouts and initiate failover, in the case of multi-homed associations.
a. 等待将来可能转换回已建立状态，直到此时ULP不会在连接的两个端点之间移动数据。当然，ULP和应用程序超时机制将在中断状态停留时间过长时触发。在多宿关联的情况下，SCTP可以检测这些超时并启动故障切换。
b. Act as though the connection has been reset (RST message received, in TCP, or ABORT message received, in SCTP).
b. 如同连接已被重置一样操作（在TCP中接收到RST消息，或在SCTP中接收到中止消息）。
c. Act as though an ICMP destination unreachable message had been received (in SCTP such messages can trigger path failover in the case of multi-homed associations).
c. 如同接收到ICMP目标不可访问的消息（在SCTP中，在多宿关联的情况下，此类消息可触发路径故障切换）。
Implementations SHOULD provide APIs that allow applications either 1) to be informed (asynchronously or otherwise) of latch breaks so that they may choose a disposition, and/or 2) to select a specific disposition a priori (before a latch break happens). The options for disposition are wait, close, or proceed with path failover.
实现应提供API，允许应用程序1）被告知（异步或其他）闩锁中断，以便选择处置，和/或2）事先选择特定处置（在闩锁中断发生之前）。处置选项包括等待、关闭或继续路径故障切换。
Implementations MUST provide a default disposition in the event of a connection latch break. Though (a) is clearly the purist default, we RECOMMEND (b) for TCP and SCTP associations where only a single path remains (one 5-tuple), and (c) for multi-homed SCTP associations. The rationale for this recommendation is as follows: a conflicting SA most likely indicates that the original peer is gone and has been replaced by another, and it's not likely that the original peer will return; thus, failing faster seems reasonable.
在连接闩锁中断的情况下，实现必须提供默认配置。虽然（a）显然是纯粹的默认值，但我们建议（b）只保留一条路径（一个5元组）的TCP和SCTP关联，以及（c）多宿主SCTP关联。该建议的基本原理如下：冲突的SA很可能表示原始对等点已消失并被另一个对等点替换，并且原始对等点不太可能返回；因此，更快地失败似乎是合理的。
Note that our recommended default behavior does not create off-path reset denial-of-service (DoS) attacks. To break a connection latch, an attacker would first have to successfully establish an SA, with one of the connection's end-points, that conflicts with the connection latch and that requires multiple messages to be exchanged between that end-point and the attacker. Unless the attacker's chosen victim end-point allows the attacker to claim IP address ranges for its SAs, then the attacker would have to actually take over the other end-point's addresses, which rules out off-path attacks.
请注意，我们建议的默认行为不会创建路径外重置拒绝服务（DoS）攻击。要断开连接闩锁，攻击者首先必须成功建立SA，该SA具有连接的一个端点，与连接闩锁冲突，并且需要在该端点和攻击者之间交换多条消息。除非攻击者选择的受害者端点允许攻击者声明其SA的IP地址范围，否则攻击者必须实际接管另一个端点的地址，从而排除非路径攻击。
Connection latching effectively adds a mechanism for dealing with the existence, in the SAD, of multiple non-equivalent child SAs with overlapping traffic selectors. This mechanism consists of, at minimum, a local notification of transport protocols (and, through them, applications) of the existence of such a conflict that affects a transport layer's connections. Affected transports are also notified when the conflict is cleared. The transports must drop inbound packets, and must not send outbound packets for connections that are affected by a conflict. In this minimal form, connection latching is a passive, local feature layered atop IPsec.
连接锁存有效地增加了一种机制，用于处理SAD中存在的具有重叠流量选择器的多个非等效子SA。该机制至少包括传输协议（以及通过它们的应用程序）的本地通知，通知存在影响传输层连接的冲突。冲突清除后，也会通知受影响的传输。传输必须丢弃入站数据包，并且不得为受冲突影响的连接发送出站数据包。在这种最小形式中，连接锁存是一种被动的、本地的功能，它分层在IPsec之上。
We achieve this by adding a new type of IPsec database, the Latch Database (LD), containing objects that represent a transport protocol's interest in protecting a given packet flow from such conflicts. The LD is managed in conjunction with updates to the SAD and the SPD, so that updates to either that conflict with established connection latches can be detected. For some IPsec implementations, this may imply significant changes to their internals. However, two different models of connection latching are given, and we hope that most native IPsec implementors will find at least one model to be simple enough to implement in their stack.
我们通过添加一种新类型的IPsec数据库，即闩锁数据库（LD），来实现这一点，该数据库包含表示传输协议对保护给定数据包流免受此类冲突影响的对象。LD与SAD和SPD的更新一起管理，以便可以检测到与已建立的连接锁存冲突的更新。对于某些IPsec实现，这可能意味着对其内部进行重大更改。然而，给出了两种不同的连接锁存模型，我们希望大多数本机IPsec实现者会发现至少有一种模型足够简单，可以在他们的堆栈中实现。
This notion of conflicting SAs and how to deal with the situation does not modify the basic IPsec architecture -- the feature of IPsec that allows such conflicts to arise remains, and it is up to the transport protocols and applications to select whether and how to respond to them.
这种冲突SA的概念以及如何处理这种情况并没有改变基本的IPsec体系结构——IPsec允许出现此类冲突的功能仍然存在，是否以及如何响应这些冲突取决于传输协议和应用程序。
There are, however, interesting corner cases in the normative model of connection latching that implementors must be aware of. The notes in Section 2.3.1 are particularly relevant.
然而，在连接锁存的规范模型中有一些有趣的情况，实现者必须知道。第2.3.1节中的注释特别相关。
Section 3 describes optional features of connection latching where the key manager takes on a somewhat more active, though still local, role. There are two such features: optional protect/bypass and preservation of "logical" SPD entries to allow latched connections to remain in the ESTABLISHED state in the face of adverse administrative SPD (but not SAD) changes. These two features interact with administrative interfaces to IPsec; administrators must be made aware of these features, and they SHOULD be given a way to break ESTABLISHED connection latches. Also, given recent trends toward centralizing parts of IPsec policy, these two features can be said to have non-local effects where they prevent distributed policy changes from taking effect completely.
第3节描述了连接锁存的可选特性，其中密钥管理器承担了一个更为活跃但仍然是本地的角色。有两个这样的功能：可选的保护/旁路和“逻辑”SPD条目的保留，以允许锁存连接在遇到不利的管理SPD（但不是SAD）更改时保持在已建立的状态。这两个特性与IPsec的管理接口交互；必须让管理员了解这些功能，并且应该为他们提供一种方法来断开已建立的连接锁存。此外，考虑到最近IPsec策略部分集中化的趋势，这两个特性可以说具有非本地效应，它们阻止分布式策略更改完全生效。
Connection latching is not negotiated. It is therefore possible for one end of a connection to be using connection latching while the other does not; in which case, it's possible for policy changes local to the non-latched end to cause packets to be sent unprotected. The end doing connection latching will reject unprotected packets, but if they bear sensitive data, then the damage may already be done. Therefore, applications SHOULD check that both ends of a connection are latched (such a check is implicit for applications that use channel binding to IPsec).
连接锁存未协商。因此，连接的一端可能使用连接锁存，而另一端不使用连接锁存；在这种情况下，非锁存端的本地策略更改可能会导致数据包在不受保护的情况下发送。end Do连接锁存将拒绝未受保护的数据包，但如果它们包含敏感数据，则可能已经造成了损坏。因此，应用程序应该检查连接的两端是否都被锁存（这样的检查对于使用到IPsec的通道绑定的应用程序是隐式的）。
Connection latching protects individual connections from weak peer ID<->address binding, IPsec configuration changes, and from configurations that allow multiple peers to assert the same addresses. But connection latching does not ensure that any two connections with the same end-point addresses will have the same latched peer IDs. In other words, applications that use multiple concurrent connections between two given nodes may not be protected any more or less by use of IPsec connection latching than by use of IPsec alone without connection latching. Such multi-connection applications can, however, examine the latched SA parameters of each connection to ensure that all concurrent connections with the same end-point addresses also have the same end-point IPsec IDs.
连接锁存保护单个连接不受弱对等ID<->地址绑定、IPsec配置更改以及允许多个对等方声明相同地址的配置的影响。但是连接锁存不能确保具有相同端点地址的任何两个连接将具有相同的锁存对等ID。换句话说，在两个给定节点之间使用多个并发连接的应用程序可能不会受到IPsec连接锁存的保护，而不是单独使用IPsec而不使用连接锁存的保护。然而，此类多连接应用程序可以检查每个连接的锁定SA参数，以确保具有相同端点地址的所有并发连接也具有相同的端点IPsec ID。
Connection latching protects against TCP RST attacks. It does not help, however, if the original peer of a TCP connection is no longer available (e.g., if an attacker has been able to interrupt the network connection between the two peers).
连接锁存可防止TCP RST攻击。但是，如果TCP连接的原始对等方不再可用（例如，如果攻击者能够中断两个对等方之间的网络连接），则这没有帮助。
IPsec channels are a prerequisite for channel binding [RFC5056] to IPsec. Connection latching provides such channels, but the channel bindings for IPsec channels (latched connections) are not specified herein -- that is a work in progress [IPSEC-CB].
IPsec通道是将[RFC5056]通道绑定到IPsec的先决条件。连接锁存提供了这样的通道，但是这里没有指定IPsec通道（锁存连接）的通道绑定——这是一项正在进行的工作[IPsec-CB]。
Without IPsec APIs, connection latching provides marginal security benefits over traditional IPsec. Such APIs are not described herein; see [ABSTRACT-API].
在没有IPSecAPI的情况下，与传统IPsec相比，连接锁提供的安全性优势微乎其微。本文不描述此类api；参见[ABSTRACT-API]。
Connection latch state transitions to the BROKEN state can be triggered by on-path attackers and any off-path attackers that can attack routers or cause an end-point to accept an ICMP Redirect message. Connection latching protects applications against on- and off-path attackers in general, but not against on-path denial of service specifically.
连接锁存状态转换为断开状态可由路径上攻击者和任何可能攻击路由器或导致端点接受ICMP重定向消息的非路径攻击者触发。连接锁存通常可保护应用程序免受路径上和路径外攻击者的攻击，但不会特别针对路径上拒绝服务。
Attackers can break latches if they can trigger DPD on one or both end-points and if they cause packets to not move between two end-points. Such attacks generally require that the attacker be on-path; therefore, we consider it acceptable to break latches when DPD concludes that a peer is dead or rebooted.
如果攻击者能够在一个或两个端点上触发DPD，并且导致数据包无法在两个端点之间移动，则攻击者可以破坏锁存。此类攻击通常要求攻击者位于路径上；因此，我们认为当DPD断定对等体已死亡或重新启动时，可以中断锁存器。
Attackers can also break latches if IPsec policy on a node allows the attacker to use the IP address of a peer of that node. Such
如果节点上的IPsec策略允许攻击者使用该节点对等方的IP地址，则攻击者还可以断开闩锁。这样的
configurations are expected to be used in conjunction with BTNS in general. Such attacks generally require that the attacker be on-path.
一般来说，这些配置将与BTN一起使用。此类攻击通常要求攻击者位于路径上。
The author thanks Michael Richardson for all his help, as well as Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel Migault, and many others who've participated in the BTNS WG or who've answered questions about IPsec, connection latching implementations, etc.
作者感谢Michael Richardson提供的所有帮助，以及Stephen Kent、Sam Hartman、Bill Sommerfeld、Dan McDonald、Daniel Migault和许多其他参与BTNS工作组或回答过IPsec、连接锁定实现等问题的人。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，2008年11月。
[ABSTRACT-API] Richardson, M., "An abstract interface between applications and IPsec", Work in Progress, November 2008.
[ABSTRACT-API]Richardson，M.，“应用程序和IPsec之间的抽象接口”，正在进行的工作，2008年11月。
[IPSEC-CB] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", Work in Progress, April 2008.
[IPSEC-CB]Williams，N.，“使用IKEv2和公钥的IPSEC端点通道绑定”，正在进行的工作，2008年4月。
[IP_SEC_OPT.man] Sun Microsystems, Inc., "ipsec(7P) man page, Solaris 10 Reference Manual Collection".
[IP_SEC_OPT.man]Sun Microsystems，Inc.，“ipsec（7P）手册页，Solaris 10参考手册集”。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387]Touch，J.，Black，D.，和Y.Wang，“比没有更好的安全性（BTNS）的问题和适用性声明”，RFC 5387，2008年11月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406]Bellovin，S.，“指定IPsec版本2使用的指南”，BCP 146，RFC 5406，2009年2月。
[USING-IPSEC] Dondeti, L. and V. Narayanan, "Guidelines for using IPsec and IKEv2", Work in Progress, October 2006.
[USING-IPSEC]Dondeti，L.和V.Narayanan，“IPSEC和IKEv2的使用指南”，正在进行的工作，2006年10月。
Author's Address
作者地址
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@sun.com
EMail: Nicolas.Williams@sun.com