Network Working Group D. Piper
Request for Comments: 2407 Network Alchemy
Category: Standards Track November 1998
Network Working Group D. Piper
Request for Comments: 2407 Network Alchemy
Category: Standards Track November 1998
The Internet IP Security Domain of Interpretation for ISAKMP
ISAKMP解释的Internet IP安全域
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) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
IESG Note
IESG注释
Section 4.4.4.2 states, "All implememtations within the IPSEC DOI MUST support ESP_DES...". Recent work in the area of cryptanalysis suggests that DES may not be sufficiently strong for many applications. Therefore, it is very likely that the IETF will deprecate the use of ESP_DES as a mandatory cipher suite in the near future. It will remain as an optional use protocol. Although the IPsec working group and the IETF in general have not settled on an alternative algorithm (taking into account concerns of security and performance), implementers may want to heed the recommendations of section 4.4.4.3 on the use of ESP_3DES.
第4.4.4.2节规定，“IPSEC DOI中的所有实现必须支持ESP_DES…”。密码分析领域的最新工作表明DES对于许多应用来说可能不够强大。因此，IETF很可能会在不久的将来反对将ESP_DES用作强制性密码套件。它将继续作为可选使用协议。尽管IPsec工作组和IETF总体上尚未确定替代算法（考虑到安全性和性能问题），但实施者可能希望注意第4.4.4.3节关于ESP3des使用的建议。
The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges, payloads, and processing guidelines that occur within a given Domain of Interpretation (DOI). This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations.
Internet安全关联和密钥管理协议（ISAKMP）定义了一个用于Internet安全关联管理和加密密钥建立的框架。该框架包括在给定解释域（DOI）内定义的交换、有效载荷和处理准则。本文档定义了Internet IP安全DOI（IPSEC DOI），当IP使用ISAKMP协商安全关联时，它实例化ISAKMP与IP一起使用。
For a list of changes since the previous version of the IPSEC DOI, please see Section 7.
有关自上一版本IPSEC DOI以来的更改列表，请参阅第7节。
Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads.
在ISAKMP中，解释域用于使用ISAKMP对相关协议进行分组，以协商安全关联。共享DOI的安全协议从公共名称空间选择安全协议和加密转换，并共享密钥交换协议标识符。它们还共享DOI特定有效载荷数据内容的共同解释，包括安全关联和识别有效载荷。
Overall, ISAKMP places the following requirements on a DOI definition:
总的来说，ISAKMP对内政部的定义提出了以下要求：
o define the naming scheme for DOI-specific protocol identifiers o define the interpretation for the Situation field o define the set of applicable security policies o define the syntax for DOI-specific SA Attributes (Phase II) o define the syntax for DOI-specific payload contents o define additional Key Exchange types, if needed o define additional Notification Message types, if needed
o 定义DOI特定协议标识符的命名方案o定义情境字段的解释o定义适用的安全策略集o定义DOI特定SA属性的语法（第二阶段）o定义DOI特定有效负载内容的语法o定义其他密钥交换类型，如果需要，定义其他通知消息类型（如果需要）
The remainder of this document details the instantiation of these requirements for using the IP Security (IPSEC) protocols to provide authentication, integrity, and/or confidentiality for IP packets sent between cooperating host systems and/or firewalls.
本文档的其余部分详细说明了使用IP安全（IPSEC）协议为协作主机系统和/或防火墙之间发送的IP数据包提供身份验证、完整性和/或机密性的这些要求的实例。
For a description of the overall IPSEC architecture, see [ARCH], [AH], and [ESP].
有关整个IPSEC体系结构的描述，请参阅[ARCH]、[AH]和[ESP]。
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 [RFC 2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照[RFC 2119]中的说明进行解释。
Within ISAKMP, all DOI's must be registered with the IANA in the "Assigned Numbers" RFC [STD-2]. The IANA Assigned Number for the Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC DOI, all well-known identifiers MUST be registered with the IANA under the IPSEC DOI. Unless otherwise noted, all tables within this document refer to IANA Assigned Numbers for the IPSEC DOI. See Section 6 for further information relating to the IANA registry for the IPSEC DOI.
在ISAKMP中，所有DOI必须在IANA的“分配编号”RFC[STD-2]中注册。IANA为Internet IP安全DOI（IPSEC DOI）分配的编号为一（1）。在IPSEC DOI中，所有已知标识符必须在IPSEC DOI下向IANA注册。除非另有说明，本文件中的所有表格均指IPSEC DOI的IANA分配编号。有关IPSEC DOI的IANA注册表的更多信息，请参见第6节。
All multi-octet binary values are stored in network byte order.
所有多个八位字节二进制值都以网络字节顺序存储。
Within ISAKMP, the Situation provides information that can be used by the responder to make a policy determination about how to process the incoming Security Association request. For the IPSEC DOI, the Situation field is a four (4) octet bitmask with the following values.
在ISAKMP中，情况提供了可供响应者用于确定如何处理传入安全关联请求的策略的信息。对于IPSEC DOI，情况字段是具有以下值的四（4）个八位组位掩码。
Situation Value
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
Situation Value
--------- -----
SIT_IDENTITY_ONLY 0x01
SIT_SECRECY 0x02
SIT_INTEGRITY 0x04
The SIT_IDENTITY_ONLY type specifies that the security association will be identified by source identity information present in an associated Identification Payload. See Section 4.6.2 for a complete description of the various Identification types. All IPSEC DOI implementations MUST support SIT_IDENTITY_ONLY by including an Identification Payload in at least one of the Phase I Oakley exchanges ([IKE], Section 5) and MUST abort any association setup that does not include an Identification Payload.
SIT_IDENTITY_ONLY类型指定安全关联将由关联标识有效负载中的源标识信息标识。有关各种标识类型的完整说明，请参见第4.6.2节。所有IPSEC DOI实现必须仅通过在至少一个阶段I Oakley交换（[IKE]，第5节）中包含标识有效负载来支持SIT_IDENTITY_，并且必须中止不包含标识有效负载的任何关联设置。
If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the situation consists only of the 4 octet situation bitmap and does not include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) or any subsequent label information. Conversely, if the initiator supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain Identifier MUST be included in the situation payload.
如果发起者既不支持SIT_保密性，也不支持SIT_完整性，则情况仅由4个八位字节的情况位图组成，不包括带标签的域标识符字段（图1，第4.6.1节）或任何后续标签信息。相反，如果启动器支持SIT_保密性或SIT_完整性，则标记的域标识符必须包含在情况负载中。
The SIT_SECRECY type specifies that the security association is being negotiated in an environment that requires labeled secrecy. If SIT_SECRECY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes a sensitivity level and compartment bitmask. See Section 4.6.1 for a complete description of the Security Association Payload format.
SIT_security类型指定在需要标记为security的环境中协商安全关联。如果情景位图中存在SIT_保密，则情景字段后面将是可变长度数据，其中包括灵敏度级别和隔间位掩码。有关安全关联有效载荷格式的完整说明，请参见第4.6.1节。
If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be set in the Situation bitmap and no secrecy level or category bitmaps shall be included.
如果发起者不支持SIT_保密，则情况位图中不得设置SIT_保密，且不得包含保密级别或类别位图。
If a responder does not support SIT_SECRECY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
如果响应者不支持SIT_保密，则应返回不支持情况的通知有效负载，并且必须中止安全关联设置。
The SIT_INTEGRITY type specifies that the security association is being negotiated in an environment that requires labeled integrity. If SIT_INTEGRITY is present in the Situation bitmap, the Situation field will be followed by variable-length data that includes an integrity level and compartment bitmask. If SIT_SECRECY is also in use for the association, the integrity information immediately follows the variable-length secrecy level and categories. See section 4.6.1 for a complete description of the Security Association Payload format.
SIT_INTEGRITY类型指定在需要标记完整性的环境中协商安全关联。如果情景位图中存在SIT_完整性，则情景字段后面将是可变长度数据，其中包括完整性级别和隔室位掩码。如果协会也使用SIT_保密，则完整性信息立即遵循可变长度保密级别和类别。有关安全关联有效载荷格式的完整说明，请参见第4.6.1节。
If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST NOT be set in the Situation bitmap and no integrity level or category bitmaps shall be included.
如果启动器不支持SIT_完整性，则不得在情况位图中设置SIT_完整性，且不得包含完整性级别或类别位图。
If a responder does not support SIT_INTEGRITY, a SITUATION-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
如果响应程序不支持SIT_完整性，则应返回不支持情况的通知负载，并且必须中止安全关联设置。
The IPSEC DOI does not impose specific security policy requirements on any implementation. Host system policy issues are outside of the scope of this document.
IPSEC DOI不会对任何实现强加特定的安全策略要求。主机系统策略问题不在本文档的范围内。
However, the following sections touch on some of the issues that must be considered when designing an IPSEC DOI host implementation. This section should be considered only informational in nature.
但是，以下各节将讨论在设计IPSEC DOI主机实现时必须考虑的一些问题。本节仅应视为信息性章节。
It is expected that many systems choosing to implement ISAKMP will strive to provide a protected domain of execution for a combined IKE key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a separate privileged process.
预计许多选择实现ISAKMP的系统将努力为组合的IKE密钥管理守护程序提供受保护的执行域。在受保护模式多用户操作系统上，此密钥管理守护程序可能作为单独的特权进程存在。
In such an environment, a formalized API to introduce keying material into the TCP/IP kernel may be desirable. The IP Security architecture does not place any requirements for structure or flow between a host TCP/IP kernel and its key management provider.
在这样的环境中，可能需要一个形式化的API将密钥材料引入TCP/IP内核。IP安全体系结构不会对主机TCP/IP内核及其密钥管理提供程序之间的结构或流提出任何要求。
Host systems that implement static keys, either for use directly by IPSEC, or for authentication purposes (see [IKE] Section 5.4), should take steps to protect the static keying material when it is not residing in a protected memory domain or actively in use by the TCP/IP kernel.
实现静态密钥的主机系统，无论是供IPSEC直接使用，还是用于身份验证目的（请参见[IKE]第5.4节），都应在静态密钥材料不在受保护的内存域中或TCP/IP内核正在使用时，采取措施保护静态密钥材料。
For example, on a laptop, one might choose to store the static keys in a configuration store that is, itself, encrypted under a private password.
例如，在笔记本电脑上，可以选择将静态密钥存储在配置存储中，而配置存储本身是在私人密码下加密的。
Depending on the operating system and utility software installed, it may not be possible to protect the static keys once they've been loaded into the TCP/IP kernel, however they should not be trivially recoverable on initial system startup without having to satisfy some additional form of authentication.
根据安装的操作系统和实用程序软件的不同，一旦静态密钥加载到TCP/IP内核中，就可能无法对其进行保护，但是，在初始系统启动时，如果不需要满足某种附加形式的身份验证，静态密钥不应是可恢复的。
It is not realistic to assume that the transition to IPSEC will occur overnight. Host systems must be prepared to implement flexible policy lists that describe which systems they desire to speak securely with and which systems they require speak securely to them. Some notion of proxy firewall addresses may also be required.
假设到IPSEC的转换将在一夜之间发生是不现实的。主机系统必须准备好实施灵活的策略列表，该列表描述了它们希望与哪些系统安全对话，以及它们需要与哪些系统安全对话。可能还需要一些代理防火墙地址的概念。
A minimal approach is probably a static list of IP addresses, network masks, and a security required flag or flags.
最简单的方法可能是IP地址、网络掩码和安全要求标志的静态列表。
A more flexible implementation might consist of a list of wildcard DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional firewall address. The wildcard DNS name would be used to match incoming or outgoing IP addresses, the in/out bitmask would be used to determine whether or not security was to be applied and in which direction, and the optional firewall address would be used to indicate whether or not tunnel mode would be needed to talk to the target system though an intermediate firewall.
更灵活的实现可能包括通配符DNS名称列表（例如“*.foo.bar”）、输入/输出位掩码和可选防火墙地址。通配符DNS名称将用于匹配传入或传出IP地址，输入/输出位掩码将用于确定是否应用安全性以及应用方向，可选的防火墙地址将用于指示是否需要隧道模式通过中间防火墙与目标系统通信。
Host systems implementing a certificate-based authentication scheme will need a mechanism for obtaining and managing a database of certificates.
实现基于证书的身份验证方案的主机系统需要一种获取和管理证书数据库的机制。
Secure DNS is to be one certificate distribution mechanism, however the pervasive availability of secure DNS zones, in the short term, is doubtful for many reasons. What's far more likely is that hosts will
安全DNS将是一种证书分发机制，但是安全DNS区域的普遍可用性在短期内由于许多原因受到怀疑。更有可能的是，东道主会
need an ability to import certificates that they acquire through secure, out-of-band mechanisms, as well as an ability to export their own certificates for use by other systems.
需要能够导入他们通过安全的带外机制获取的证书，以及能够导出他们自己的证书供其他系统使用。
However, manual certificate management should not be done so as to preclude the ability to introduce dynamic certificate discovery mechanisms and/or protocols as they become available.
但是，手动证书管理不应妨碍引入动态证书发现机制和/或协议的能力。
The following sections list the Assigned Numbers for the IPSEC DOI: Situation Identifiers, Protocol Identifiers, Transform Identifiers, AH, ESP, and IPCOMP Transform Identifiers, Security Association Attribute Type Values, Labeled Domain Identifiers, ID Payload Type Values, and Notify Message Type Values.
以下部分列出了IPSEC DOI的分配编号：情况标识符、协议标识符、转换标识符、AH、ESP和IPCOMP转换标识符、安全关联属性类型值、带标签的域标识符、ID有效负载类型值和通知消息类型值。
The ISAKMP proposal syntax was specifically designed to allow for the simultaneous negotiation of multiple Phase II security protocol suites within a single negotiation. As a result, the protocol suites listed below form the set of protocols that can be negotiated at the same time. It is a host policy decision as to what protocol suites might be negotiated together.
ISAKMP提案语法专门设计为允许在一次协商中同时协商多个第二阶段安全协议套件。因此，下面列出的协议套件构成了可以同时协商的协议集。关于哪些协议套件可以一起协商，这是主机策略决定。
The following table lists the values for the Security Protocol Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC DOI.
下表列出了IPSEC DOI的ISAKMP建议有效负载中引用的安全协议标识符的值。
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_IPSEC_AH 2
PROTO_IPSEC_ESP 3
PROTO_IPCOMP 4
The PROTO_ISAKMP type specifies message protection required during Phase I of the ISAKMP protocol. The specific protection mechanism used for the IPSEC DOI is described in [IKE]. All implementations within the IPSEC DOI MUST support PROTO_ISAKMP.
PROTO_ISAKMP类型指定ISAKMP协议第一阶段期间所需的消息保护。[IKE]中描述了用于IPSEC DOI的特定保护机制。IPSEC DOI中的所有实现都必须支持PROTO_ISAKMP。
NB: ISAKMP reserves the value one (1) across all DOI definitions.
注意：ISAKMP在所有DOI定义中保留一（1）个值。
The PROTO_IPSEC_AH type specifies IP packet authentication. The default AH transform provides data origin authentication, integrity protection, and replay detection. For export control considerations, confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.
PROTO_IPSEC_AH类型指定IP数据包身份验证。默认AH转换提供数据源身份验证、完整性保护和重播检测。出于出口控制考虑，任何协议IPSEC-AH转换都不能提供机密性。
The PROTO_IPSEC_ESP type specifies IP packet confidentiality. Authentication, if required, must be provided as part of the ESP transform. The default ESP transform includes data origin authentication, integrity protection, replay detection, and confidentiality.
PROTO_IPSEC_ESP类型指定IP数据包的机密性。如果需要，身份验证必须作为ESP转换的一部分提供。默认ESP转换包括数据源身份验证、完整性保护、重播检测和机密性。
The PROTO_IPCOMP type specifies IP payload compression as defined in [IPCOMP].
PROTO_IPCOMP类型指定[IPCOMP]中定义的IP有效负载压缩。
As part of an ISAKMP Phase I negotiation, the initiator's choice of Key Exchange offerings is made using some host system policy description. The actual selection of Key Exchange mechanism is made using the standard ISAKMP Proposal Payload. The following table lists the defined ISAKMP Phase I Transform Identifiers for the Proposal Payload for the IPSEC DOI.
作为ISAKMP第一阶段协商的一部分，发起人使用某些主机系统策略描述选择密钥交换产品。密钥交换机制的实际选择是使用标准ISAKMP建议有效负载进行的。下表列出了为IPSEC DOI的建议有效负载定义的ISAKMP第一阶段转换标识符。
Transform Value
--------- -----
RESERVED 0
KEY_IKE 1
Transform Value
--------- -----
RESERVED 0
KEY_IKE 1
Within the ISAKMP and IPSEC DOI framework it is possible to define key establishment protocols other than IKE (Oakley). Previous versions of this document defined types both for manual keying and for schemes based on use of a generic Key Distribution Center (KDC). These identifiers have been removed from the current document.
在ISAKMP和IPSEC DOI框架内，可以定义IKE（Oakley）以外的密钥建立协议。本文档的早期版本定义了手动键控和基于使用通用密钥分发中心（KDC）的方案的类型。这些标识符已从当前文档中删除。
The IPSEC DOI can still be extended later to include values for additional non-Oakley key establishment protocols for ISAKMP and IPSEC, such as Kerberos [RFC-1510] or the Group Key Management Protocol (GKMP) [RFC-2093].
IPSEC DOI稍后仍可以扩展，以包括ISAKMP和IPSEC的其他非Oakley密钥建立协议的值，例如Kerberos[RFC-1510]或组密钥管理协议（GKPP）[RFC-2093]。
The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman key exchange (IKE) as defined in the [IKE] document. All implementations within the IPSEC DOI MUST support KEY_IKE.
密钥类型指定了[IKE]文档中定义的混合ISAKMP/Oakley Diffie-Hellman密钥交换（IKE）。IPSEC DOI中的所有实现都必须支持密钥。
The Authentication Header Protocol (AH) defines one mandatory and several optional transforms used to provide authentication, integrity, and replay detection. The following table lists the defined AH Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
认证头协议（AH）定义了一个强制转换和几个可选转换，用于提供认证、完整性和重播检测。下表列出了为IPSEC DOI的ISAKMP建议有效负载定义的AH转换标识符。
Note: the Authentication Algorithm attribute MUST be specified to identify the appropriate AH protection suite. For example, AH_MD5 can best be thought of as a generic AH transform using MD5. To request the HMAC construction with AH, one specifies the AH_MD5 transform ID along with the Authentication Algorithm attribute set to HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the following sections.
注意：必须指定“身份验证算法”属性以标识适当的AH保护套件。例如，最好将AH_MD5视为使用MD5的通用AH转换。要使用AH请求HMAC构造，需要指定AH_MD5转换ID以及设置为HMAC-MD5的身份验证算法属性。在以下部分中，使用“Auth（HMAC-MD5）”符号显示了这一点。
Transform ID Value
------------ -----
RESERVED 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
Transform ID Value
------------ -----
RESERVED 0-1
AH_MD5 2
AH_SHA 3
AH_DES 4
Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. AH_MD5) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.
注：所有强制实现的算法在以下章节中列为“必须”实现（如AHU MD5）。所有其他算法都是可选的，可以在任何特定实现中实现。
The AH_MD5 type specifies a generic AH transform using MD5. The actual protection suite is determined in concert with an associated SA attribute list. A generic MD5 transform is currently undefined.
AH_MD5类型使用MD5指定通用AH转换。实际的保护套件与关联的SA属性列表一起确定。通用MD5转换当前未定义。
All implementations within the IPSEC DOI MUST support AH_MD5 along with the Auth(HMAC-MD5) attribute. This suite is defined as the HMAC-MD5-96 transform described in [HMACMD5].
IPSEC DOI中的所有实现必须支持AH_MD5以及Auth（HMAC-MD5）属性。该套件定义为[HMACMD5]中所述的HMAC-MD5-96转换。
The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH transform (Key/Pad/Data/Key) described in RFC-1826.
AH_MD5类型以及Auth（KPDK）属性指定RFC-1826中描述的AH转换（键/键盘/数据/键）。
Use of AH_MD5 with any other Authentication Algorithm attribute value is currently undefined.
当前未定义将AHU MD5与任何其他身份验证算法属性值一起使用。
The AH_SHA type specifies a generic AH transform using SHA-1. The actual protection suite is determined in concert with an associated SA attribute list. A generic SHA transform is currently undefined.
AH_SHA类型使用SHA-1指定通用AH变换。实际的保护套件与关联的SA属性列表一起确定。通用SHA转换当前未定义。
All implementations within the IPSEC DOI MUST support AH_SHA along with the Auth(HMAC-SHA) attribute. This suite is defined as the HMAC-SHA-1-96 transform described in [HMACSHA].
IPSEC DOI中的所有实现都必须支持AHU SHA以及Auth（HMAC-SHA）属性。该套件定义为[HMACSHA]中所述的HMAC-SHA-1-96转换。
Use of AH_SHA with any other Authentication Algorithm attribute value is currently undefined.
当前未定义将AHU_SHA与任何其他身份验证算法属性值一起使用。
The AH_DES type specifies a generic AH transform using DES. The actual protection suite is determined in concert with an associated SA attribute list. A generic DES transform is currently undefined.
AH_DES类型指定使用DES的通用AH变换。实际的保护套件与关联的SA属性列表一起确定。通用DES转换当前未定义。
The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute to be a DES-MAC transform. Implementations are not required to support this mode.
IPSEC DOI将AHU DES和Auth（DES-MAC）属性定义为DES-MAC转换。不需要实现来支持此模式。
Use of AH_DES with any other Authentication Algorithm attribute value is currently undefined.
将AHU DES与任何其他身份验证算法属性值一起使用目前尚未定义。
The Encapsulating Security Payload (ESP) defines one mandatory and many optional transforms used to provide data confidentiality. The following table lists the defined ESP Transform Identifiers for the ISAKMP Proposal Payload for the IPSEC DOI.
封装安全有效负载（ESP）定义了一个强制转换和许多可选转换，用于提供数据机密性。下表列出了为IPSEC DOI的ISAKMP建议有效负载定义的ESP转换标识符。
Note: when authentication, integrity protection, and replay detection are required, the Authentication Algorithm attribute MUST be specified to identify the appropriate ESP protection suite. For example, to request HMAC-MD5 authentication with 3DES, one specifies the ESP_3DES transform ID with the Authentication Algorithm attribute set to HMAC-MD5. For additional processing requirements, see Section 4.5 (Authentication Algorithm).
注意：当需要身份验证、完整性保护和重播检测时，必须指定“身份验证算法”属性以标识适当的ESP保护套件。例如，要使用3DES请求HMAC-MD5身份验证，可以指定ESP_3DES转换ID，并将“身份验证算法”属性设置为HMAC-MD5。有关其他处理要求，请参见第4.5节（认证算法）。
Transform ID Value
------------ -----
RESERVED 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
Transform ID Value
------------ -----
RESERVED 0
ESP_DES_IV64 1
ESP_DES 2
ESP_3DES 3
ESP_RC5 4
ESP_IDEA 5
ESP_CAST 6
ESP_BLOWFISH 7
ESP_3IDEA 8
ESP_DES_IV32 9
ESP_RC4 10
ESP_NULL 11
Note: all mandatory-to-implement algorithms are listed as "MUST" implement (e.g. ESP_DES) in the following sections. All other algorithms are optional and MAY be implemented in any particular implementation.
注：所有强制实现的算法在以下章节中列为“必须”实现（如ESP_DES）。所有其他算法都是可选的，可以在任何特定实现中实现。
The ESP_DES_IV64 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 64-bit IV.
ESP_DES_IV64类型使用64位IV指定RFC-1827和RFC-1829中定义的DES-CBC转换。
The ESP_DES type specifies a generic DES transform using DES-CBC. The actual protection suite is determined in concert with an associated SA attribute list. A generic transform is currently undefined.
ESP_DES类型使用DES-CBC指定通用DES转换。实际的保护套件与关联的SA属性列表一起确定。通用转换当前未定义。
All implementations within the IPSEC DOI MUST support ESP_DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [DES] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5].
IPSEC DOI中的所有实现都必须支持ESP_DES以及Auth（HMAC-MD5）属性。该套件被定义为[DES]转换，由HMAC MD5[HMACMD5]提供身份验证和完整性。
The ESP_3DES type specifies a generic triple-DES transform. The actual protection suite is determined in concert with an associated SA attribute list. The generic transform is currently undefined.
ESP_3DES类型指定通用的三重DES变换。实际的保护套件与关联的SA属性列表一起确定。通用转换当前未定义。
All implementations within the IPSEC DOI are strongly encouraged to support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite is defined as the [ESPCBC] transform, with authentication and integrity provided by HMAC MD5 [HMACMD5].
强烈鼓励IPSEC DOI中的所有实现支持ESP_3DES以及Auth（HMAC-MD5）属性。该套件被定义为[ESPCBC]转换，由HMAC MD5[HMACMD5]提供身份验证和完整性。
The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
ESP_RC5类型指定[ESPCBC]中定义的RC5转换。
The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
ESP_IDEA类型指定[ESPCBC]中定义的IDEA转换。
The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
ESP_转换类型指定[ESPCBC]中定义的转换转换。
The ESP_BLOWFISH type specifies the BLOWFISH transform defined in [ESPCBC].
ESP_河豚类型指定[ESPCBC]中定义的河豚变换。
The ESP_3IDEA type is reserved for triple-IDEA.
ESP_3IDEA类型为triple IDEA保留。
The ESP_DES_IV32 type specifies the DES-CBC transform defined in RFC-1827 and RFC-1829 using a 32-bit IV.
ESP_DES_IV32类型使用32位IV指定RFC-1827和RFC-1829中定义的DES-CBC转换。
The ESP_RC4 type is reserved for RC4.
ESP_RC4类型是为RC4保留的。
The ESP_NULL type specifies no confidentiality is to be provided by ESP. ESP_NULL is used when ESP is being used to tunnel packets which require only authentication, integrity protection, and replay detection.
ESP_NULL类型指定ESP不提供机密性。当ESP用于隧道数据包（仅需要身份验证、完整性保护和重播检测）时，使用ESP_NULL。
All implementations within the IPSEC DOI MUST support ESP_NULL. The ESP NULL transform is defined in [ESPNULL]. See the Authentication Algorithm attribute description in Section 4.5 for additional requirements relating to the use of ESP_NULL.
IPSEC DOI中的所有实现都必须支持ESP_NULL。ESP NULL转换在[ESPNULL]中定义。有关使用ESP_NULL的其他要求，请参见第4.5节中的认证算法属性描述。
The IP Compression (IPCOMP) transforms define optional compression algorithms that can be negotiated to provide for IP payload compression ([IPCOMP]). The following table lists the defined IPCOMP Transform Identifiers for the ISAKMP Proposal Payload within the
IP压缩（IPCOMP）转换定义了可选的压缩算法，可以通过协商来提供IP有效负载压缩（[IPCOMP]）。下表列出了在中为ISAKMP建议有效负载定义的IPCOMP转换标识符
IPSEC DOI.
内政部。
Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
Transform ID Value
------------ -----
RESERVED 0
IPCOMP_OUI 1
IPCOMP_DEFLATE 2
IPCOMP_LZS 3
The IPCOMP_OUI type specifies a proprietary compression transform. The IPCOMP_OUI type must be accompanied by an attribute which further identifies the specific vendor algorithm.
IPCOMP_OUI类型指定专有的压缩转换。IPCOMP_OUI类型必须附带一个属性，该属性进一步标识特定的供应商算法。
The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate algorithm as specified in [DEFLATE].
IPCOMP_DEFLATE类型指定使用[DEFLATE]中指定的“zlib”DEFLATE算法。
The IPCOMP_LZS type specifies the use of the Stac Electronics LZS algorithm as specified in [LZS].
IPCOMP_LZS类型指定使用[LZS]中指定的Stac Electronics LZS算法。
The following SA attribute definitions are used in Phase II of an IKE negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification.
以下SA属性定义用于IKE协商的第二阶段。属性类型可以是基本（B）或可变长度（V）。这些属性的编码在基本ISAKMP规范中定义。
Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. See [IKE] for further information on attribute encoding in the IPSEC DOI. All restrictions listed in [IKE] also apply to the IPSEC DOI.
描述为基本的属性不能编码为变量。如果可变长度属性的值可以放入两个八位字节，则可以将其编码为基本属性。有关IPSEC DOI中属性编码的更多信息，请参阅[IKE]。[IKE]中列出的所有限制也适用于IPSEC DOI。
Attribute Types
属性类型
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Group Description 3 B
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Compress Dictionary Size 8 B
Compress Private Algorithm 9 V
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Group Description 3 B
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B
Compress Dictionary Size 8 B
Compress Private Algorithm 9 V
Class Values
阶级价值观
SA Life Type SA Duration
SA寿命类型SA持续时间
Specifies the time-to-live for the overall security association. When the SA expires, all keys negotiated under the association (AH or ESP) must be renegotiated. The life type values are:
指定整个安全关联的生存时间。SA到期时，必须重新协商根据关联（AH或ESP）协商的所有密钥。生命类型值为：
RESERVED 0 seconds 1 kilobytes 2
保留0秒1千字节2
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use. For a given Life Type, the value of the Life Duration attribute defines the actual length of the component lifetime -- either a number of seconds, or a number of Kbytes that can be protected.
值3-61439保留给IANA。值61440-65535仅供私人使用。对于给定的寿命类型，“寿命持续时间”属性的值定义了组件寿命的实际长度——秒数或可保护的KB数。
If unspecified, the default value shall be assumed to be 28800 seconds (8 hours).
如果未指定，默认值应假定为28800秒（8小时）。
An SA Life Duration attribute MUST always follow an SA Life Type which describes the units of duration.
SA寿命属性必须始终遵循描述持续时间单位的SA寿命类型。
See Section 4.5.4 for additional information relating to lifetime notification.
有关终身通知的更多信息，请参见第4.5.4节。
Group Description
组描述
Specifies the Oakley Group to be used in a PFS QM negotiation. For a list of supported values, see Appendix A of [IKE].
指定要在PFS QM协商中使用的Oakley组。有关支持值的列表，请参见[IKE]的附录a。
Encapsulation Mode RESERVED 0 Tunnel 1 Transport 2
封装模式保留0隧道1传输2
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use.
值3-61439保留给IANA。值61440-65535仅供私人使用。
If unspecified, the default value shall be assumed to be unspecified (host-dependent).
如果未指定，则应假定默认值未指定（取决于主机）。
Authentication Algorithm RESERVED 0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4
身份验证算法保留0 HMAC-MD5 1 HMAC-SHA 2 DES-MAC 3 KPDK 4
Values 5-61439 are reserved to IANA. Values 61440-65535 are for private use.
值5-61439保留给IANA。值61440-65535仅供私人使用。
There is no default value for Auth Algorithm, as it must be specified to correctly identify the applicable AH or ESP transform, except in the following case.
Auth Algorithm没有默认值，因为必须指定它才能正确识别适用的AH或ESP变换，以下情况除外。
When negotiating ESP without authentication, the Auth Algorithm attribute MUST NOT be included in the proposal.
在没有身份验证的情况下协商ESP时，方案中不得包含Auth ALGORITH属性。
When negotiating ESP without confidentiality, the Auth Algorithm attribute MUST be included in the proposal and the ESP transform ID must be ESP_NULL.
在协商无保密性的ESP时，提案中必须包含“身份验证算法”属性，且ESP转换ID必须为ESP_NULL。
Key Length RESERVED 0
保留的密钥长度为0
There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. For fixed length ciphers, the Key Length attribute MUST NOT be sent.
密钥长度没有默认值，因为必须为使用具有可变密钥长度的密码的转换指定该值。对于固定长度密码，不能发送密钥长度属性。
Key Rounds RESERVED 0
保留密钥0
There is no default value for Key Rounds, as it must be specified for transforms using ciphers with varying numbers of rounds.
密钥轮数没有默认值，因为必须为使用不同轮数的密码的转换指定该值。
Compression Dictionary Size RESERVED 0
压缩字典大小保留为0
Specifies the log2 maximum size of the dictionary.
指定字典的log2最大大小。
There is no default value for dictionary size.
字典大小没有默认值。
Compression Private Algorithm
压缩私有算法
Specifies a private vendor compression algorithm. The first three (3) octets must be an IEEE assigned company_id (OUI). The next octet may be a vendor specific compression subtype, followed by zero or more octets of vendor data.
指定专用供应商压缩算法。前三（3）个八位字节必须是IEEE指定的公司id（OUI）。下一个八位字节可以是特定于供应商的压缩子类型，后跟零个或多个供应商数据八位字节。
To ensure basic interoperability, all implementations MUST be prepared to negotiate all of the following attributes.
为了确保基本的互操作性，所有实现都必须准备好协商以下所有属性。
SA Life Type SA Duration Auth Algorithm
SA生命类型SA持续时间验证算法
To allow for flexible semantics, the IPSEC DOI requires that a conforming ISAKMP implementation MUST correctly parse an attribute list that contains multiple instances of the same attribute class, so long as the different attribute entries do not conflict with one another. Currently, the only attributes which requires this treatment are Life Type and Duration.
为了允许灵活的语义，IPSEC DOI要求一致的ISAKMP实现必须正确解析包含同一属性类的多个实例的属性列表，只要不同的属性条目不相互冲突。目前，需要这种治疗的唯一属性是生命类型和持续时间。
To see why this is important, the following example shows the binary encoding of a four entry attribute list that specifies an SA Lifetime of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a complete description of the attribute encoding format.)
为了了解这一点的重要性，下面的示例显示了四项属性列表的二进制编码，该列表指定SA生存期为100MB或24小时。（有关属性编码格式的完整说明，请参见[ISAKMP]第3.3节。）
Attribute #1:
0x80010001 (AF = 1, type = SA Life Type, value = seconds)
Attribute #1:
0x80010001 (AF = 1, type = SA Life Type, value = seconds)
Attribute #2:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
Attribute #2:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x00015180 (value = 0x15180 = 86400 seconds = 24 hours)
Attribute #3:
0x80010002 (AF = 1, type = SA Life Type, value = KB)
Attribute #3:
0x80010002 (AF = 1, type = SA Life Type, value = KB)
Attribute #4:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
Attribute #4:
0x00020004 (AF = 0, type = SA Duration, length = 4 bytes)
0x000186A0 (value = 0x186A0 = 100000KB = 100MB)
If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted.
如果检测到冲突的属性，则应返回属性不受支持的通知负载，并且必须中止安全关联设置。
If an implementation receives a defined IPSEC DOI attribute (or attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range.
如果实现接收到不支持的已定义IPSEC DOI属性（或属性值），则应发送ATTRIBUTES-not-support，并且必须中止安全关联设置，除非该属性值在保留范围内。
If an implementation receives an attribute value in the reserved range, an implementation MAY chose to continue based on local policy.
如果实现接收到保留范围内的属性值，则实现可以根据本地策略选择继续。
When an initiator offers an SA lifetime greater than what the responder desires based on their local policy, the responder has three choices: 1) fail the negotiation entirely; 2) complete the negotiation but use a shorter lifetime than what was offered; 3) complete the negotiation and send an advisory notification to the initiator indicating the responder's true lifetime. The choice of what the responder actually does is implementation specific and/or based on local policy.
当发起方根据其本地策略提供的SA生存期大于响应方期望的SA生存期时，响应方有三种选择：1）协商完全失败；2） 完成谈判，但使用比所提供的更短的寿命；3） 完成协商并向发起方发送通知，指出响应方的真实生存期。响应者的实际行动取决于具体实施和/或当地政策。
To ensure interoperability in the latter case, the IPSEC DOI requires the following only when the responder wishes to notify the initiator: if the initiator offers an SA lifetime longer than the responder is willing to accept, the responder SHOULD include an ISAKMP Notification Payload in the exchange that includes the responder's IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the RESPONDER-LIFETIME Notification Message type which MUST be used for this purpose.
为了确保后一种情况下的互操作性，IPSEC DOI仅在响应者希望通知启动器时要求以下内容：如果启动器提供的SA生存期长于响应者愿意接受的时间，响应程序应在包含响应程序IPSEC SA负载的exchange中包含ISAKMP通知负载。第4.6.3.1节定义了响应者生存期通知消息类型的有效负载布局，该类型必须用于此目的。
The following sections describe those ISAKMP payloads whose data representations are dependent on the applicable DOI.
以下章节描述了其数据表示依赖于适用DOI的ISAKMP有效载荷。
The following diagram illustrates the content of the Security Association Payload for the IPSEC DOI. See Section 4.2 for a description of the Situation bitmap.
下图说明了IPSEC DOI的安全关联有效负载的内容。有关情况位图的说明，请参见第4.2节。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Labeled Domain Identifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (IPSEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Situation (bitmap) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Labeled Domain Identifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secrecy Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Secrecy Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integrity Length (in octets) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Level ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Integ. Cat. Length (in bits) ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Category Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Security Association Payload Format
图1：安全关联有效负载格式
The Security Association Payload is defined as follows:
安全关联有效负载定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0).
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零（0）。
o RESERVED (1 octet) - Unused, must be zero (0).
o 保留（1个八位字节）-未使用，必须为零（0）。
o Payload Length (2 octets) - Length, in octets, of the current payload, including the generic header.
o 有效负载长度（2个八位字节）-当前有效负载的长度，以八位字节为单位，包括通用标头。
o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, which has been assigned the value one (1).
o 解释域（4个八位字节）-指定IPSEC DOI，该DOI已被赋值为1。
o Situation (4 octets) - Bitmask used to interpret the remainder of the Security Association Payload. See Section 4.2 for a complete list of values.
o 情况（4个八位字节）-用于解释安全关联有效负载剩余部分的位掩码。有关完整的数值列表，请参见第4.2节。
o Labeled Domain Identifier (4 octets) - IANA Assigned Number used to interpret the Secrecy and Integrity information.
o 带标签的域标识符（4个八位字节）-用于解释保密性和完整性信息的IANA分配编号。
o Secrecy Length (2 octets) - Specifies the length, in octets, of the secrecy level identifier, excluding pad bits.
o 保密长度（2个八位字节）-指定保密级别标识符的长度（以八位字节为单位），不包括pad位。
o RESERVED (2 octets) - Unused, must be zero (0).
o 保留（2个八位字节）-未使用，必须为零（0）。
o Secrecy Level (variable length) - Specifies the mandatory secrecy level required. The secrecy level MUST be padded with zero (0) to align on the next 32-bit boundary.
o 保密级别（可变长度）-指定所需的强制保密级别。保密级别必须用零（0）填充，以便在下一个32位边界上对齐。
o Secrecy Category Length (2 octets) - Specifies the length, in bits, of the secrecy category (compartment) bitmap, excluding pad bits.
o 保密类别长度（2个八位字节）-指定保密类别（隔间）位图的长度（位），不包括pad位。
o RESERVED (2 octets) - Unused, must be zero (0).
o 保留（2个八位字节）-未使用，必须为零（0）。
o Secrecy Category Bitmap (variable length) - A bitmap used to designate secrecy categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.
o 保密类别位图（可变长度）-用于指定所需保密类别（隔间）的位图。位图必须填充零（0）才能在下一个32位边界上对齐。
o Integrity Length (2 octets) - Specifies the length, in octets, of the integrity level identifier, excluding pad bits.
o 完整性长度（2个八位字节）-指定完整性级别标识符的长度（以八位字节为单位），不包括焊盘位。
o RESERVED (2 octets) - Unused, must be zero (0).
o 保留（2个八位字节）-未使用，必须为零（0）。
o Integrity Level (variable length) - Specifies the mandatory integrity level required. The integrity level MUST be padded with zero (0) to align on the next 32-bit boundary.
o 完整性级别（可变长度）-指定所需的强制性完整性级别。完整性级别必须用零（0）填充，以便在下一个32位边界上对齐。
o Integrity Category Length (2 octets) - Specifies the length, in bits, of the integrity category (compartment) bitmap, excluding pad bits.
o 完整性类别长度（2个八位字节）-指定完整性类别（隔间）位图的长度（位），不包括焊盘位。
o RESERVED (2 octets) - Unused, must be zero (0).
o 保留（2个八位字节）-未使用，必须为零（0）。
o Integrity Category Bitmap (variable length) - A bitmap used to designate integrity categories (compartments) that are required. The bitmap MUST be padded with zero (0) to align on the next 32-bit boundary.
o 完整性类别位图（可变长度）-用于指定所需完整性类别（隔间）的位图。位图必须填充零（0）才能在下一个32位边界上对齐。
The following table lists the assigned values for the Labeled Domain Identifier field contained in the Situation field of the Security Association Payload.
下表列出了安全关联有效负载的情况字段中包含的标记域标识符字段的分配值。
Domain Value
------- -----
RESERVED 0
Domain Value
------- -----
RESERVED 0
The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision.
标识有效负载用于标识安全关联的发起方。响应程序应使用启动器的标识来确定关联的正确主机系统安全策略要求。例如，主机可能会选择从某一组IP地址要求身份验证和完整性而不要求保密（AH），从另一组IP地址要求完全保密身份验证（ESP）。标识有效载荷提供了可由响应者用于做出此决定的信息。
During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500. If an implementation receives any other values, this MUST be treated as an error and the security association setup MUST be aborted. This event SHOULD be auditable.
在第一阶段协商期间，ID端口和协议字段必须设置为零或UDP端口500。如果实现接收到任何其他值，则必须将其视为错误，并且必须中止安全关联设置。此事件应可审核。
The following diagram illustrates the content of the Identification Payload.
下图说明了标识有效负载的内容。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identification Payload Format
图2：识别有效载荷格式
The Identification Payload fields are defined as follows:
标识有效载荷字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0).
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为零（0）。
o RESERVED (1 octet) - Unused, must be zero (0).
o 保留（1个八位字节）-未使用，必须为零（0）。
o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header.
o 有效负载长度（2个八位字节）-标识数据的长度，以八位字节为单位，包括通用报头。
o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field.
o 标识类型（1个八位字节）-描述标识数据字段中标识信息的值。
o Protocol ID (1 octet) - Value specifying an associated IP protocol ID (e.g. UDP/TCP). A value of zero means that the Protocol ID field should be ignored.
o 协议ID（1个八位字节）-指定相关IP协议ID（例如UDP/TCP）的值。值为零表示应忽略协议ID字段。
o Port (2 octets) - Value specifying an associated port. A value of zero means that the Port field should be ignored.
o 端口（2个八位字节）-指定关联端口的值。值为零表示应忽略端口字段。
o Identification Data (variable length) - Value, as indicated by the Identification Type.
o 标识数据（可变长度）-由标识类型指示的值。
The following table lists the assigned values for the Identification Type field found in the Identification Payload.
下表列出了标识有效负载中标识类型字段的分配值。
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_FQDN 2
ID_USER_FQDN 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8
ID_DER_ASN1_DN 9
ID_DER_ASN1_GN 10
ID_KEY_ID 11
For types where the ID entity is variable length, the size of the ID entity is computed from size in the ID payload header.
对于ID实体长度可变的类型，ID实体的大小根据ID有效负载标头中的大小计算。
When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange.
当使用证书（任何格式）对IKE交换进行身份验证时，用于输入本地策略决策的任何ID都应包含在用于交换身份验证的证书中。
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
ID_IPV4_ADDR类型指定一个四（4）个八位字节的IPV4地址。
The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators.
ID_FQDN类型指定完全限定的域名字符串。ID_FQDN的一个示例是“foo.bar.com”。字符串不应包含任何终止符。
The ID_USER_FQDN type specifies a fully-qualified username string, An example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should not contain any terminators.
ID\u USER\u FQDN类型指定完全限定的用户名字符串，ID\u USER\u FQDN的一个示例是，“piper@foo.bar.com". 字符串不应包含任何终止符。
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV4_ADDR_子网类型指定IPV4地址的范围，由两个四（4）个八位字节值表示。第一个值是IPv4地址。第二个是IPv4网络掩码。请注意，网络掩码中的1表示地址中的对应位是固定的，而0表示“通配符”位。
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address.
ID_IPV6_ADDR类型指定一个十六（16）个八位字节的IPV6地址。
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV6_ADDR_子网类型指定一系列IPV6地址，由两个十六（16）个八位组值表示。第一个值是IPv6地址。第二个是IPv6网络掩码。请注意，网络掩码中的1表示地址中的对应位是固定的，而0表示“通配符”位。
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
ID_IPV4_ADDR_RANGE类型指定IPV4地址的范围，由两个四（4）个八位字节值表示。第一个值是起始IPv4地址（包括），第二个值是结束IPv4地址（包括）。两个指定地址之间的所有地址都被视为在列表中。
The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
ID_IPV6_ADDR_RANGE类型指定IPV6地址的范围，由两个十六（16）个八位字节值表示。第一个值是起始IPv6地址（含），第二个值是结束IPv6地址（含）。两个指定地址之间的所有地址都被视为在列表中。
The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] of the principal whose certificates are being exchanged to establish the SA.
ID_DER_ASN1_DN type指定主体的ASN.1 X.500可分辨名称[X.501]的二进制DER编码，该主体的证书正在交换以建立SA。
The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 X.500 GeneralName [X.509] of the principal whose certificates are being exchanged to establish the SA.
ID_DER_ASN1_GN type指定主体的ASN.1 X.500 GeneralName[X.509]的二进制DER编码，该主体的证书正在交换以建立SA。
The ID_KEY_ID type specifies an opaque byte stream which may be used to pass vendor-specific information necessary to identify which pre-shared key should be used to authenticate Aggressive mode negotiations.
ID_KEY_ID类型指定一个不透明的字节流，该字节流可用于传递供应商特定的必要信息，以确定应使用哪个预共享密钥来验证主动模式协商。
ISAKMP defines two blocks of Notify Message codes, one for errors and one for status messages. ISAKMP also allocates a portion of each block for private use within a DOI. The IPSEC DOI defines the following private message types for its own use.
ISAKMP定义了两个通知消息代码块，一个用于错误，一个用于状态消息。ISAKMP还将每个块的一部分分配给DOI内的私人使用。IPSEC DOI为自己的使用定义了以下私有消息类型。
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Error Types Value
----------------------------- -----
RESERVED 8192
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notify Messages - Status Types Value
------------------------------ -----
RESPONDER-LIFETIME 24576
REPLAY-STATUS 24577
INITIAL-CONTACT 24578
Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in any Quick Mode exchange. These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange.
通知状态消息必须在ISAKMP SA的保护下发送：作为最后一次主模式交换中的有效负载；在主模式或主动模式处理完成后，在单独的信息交换中；或作为任何快速模式交换中的有效负载。这些消息不得在主动模式exchange中发送，因为主动模式不提供必要的保护以将Notify Status消息绑定到exchange。
Nota Bene: a Notify payload is fully protected only in Quick Mode, where the entire payload is included in the HASH(n) digest. In Main Mode, while the notify payload is encrypted, it is not currently included in the HASH(n) digests. As a result, an active substitution attack on the Main Mode ciphertext could cause the notify status message type to be corrupted. (This is true, in general, for the last message of any Main Mode exchange.) While the risk is small, a corrupt notify message might cause the receiver to abort the entire negotiation thinking that the sender encountered a fatal error.
Nota Bene:Notify有效负载仅在快速模式下受到完全保护，其中整个有效负载包含在哈希（n）摘要中。在主模式下，虽然对notify有效负载进行了加密，但它当前未包含在哈希（n）摘要中。因此，对主模式密文的主动替换攻击可能导致notify status消息类型损坏。（通常情况下，对于任何主模式交换的最后一条消息都是如此。）虽然风险很小，但损坏的notify消息可能会导致接收方中止整个协商，认为发送方遇到了致命错误。
Implementation Note: the ISAKMP protocol does not guarantee delivery of Notification Status messages when sent in an ISAKMP Informational Exchange. To ensure receipt of any particular message, the sender SHOULD include a Notification Payload in a defined Main Mode or Quick Mode exchange which is protected by a retransmission timer.
实施说明：ISAKMP协议不保证在ISAKMP信息交换中发送通知状态消息的传递。为确保收到任何特定消息，发送方应在定义的主模式或快速模式交换中包含通知有效负载，该交换由重传计时器保护。
The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder.
响应者生存期状态消息可用于通信响应者选择的IPSEC SA生存期。
When present, the Notification Payload MUST have the following format:
存在时，通知有效负载必须具有以下格式：
o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s)
o 有效负载长度-设置为有效负载长度+数据大小（var）o DOI-设置为IPSEC DOI（1）o协议ID-设置为所选SA o SPI大小中的所选协议ID-设置为十六（16）（两个八位字节ISAKMP cookie）或四（4）（一个IPSEC SPI）o通知消息类型-设置为响应者生命周期（第4.6.3节）o SPI-设置为两个ISAKMP cookie或发送方的入站IPSEC SPI o通知数据-包含带有响应方实际SA生存期的ISAKMP属性列表
Implementation Note: saying that the Notification Data field contains an attribute list is equivalent to saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list.
实现说明：表示通知数据字段包含属性列表等同于表示通知数据字段的长度为零，并且通知有效负载具有关联的属性列表。
The REPLAY-STATUS status message may be used for positive confirmation of the responder's election on whether or not he is to perform anti-replay detection.
REPLAY-STATUS状态消息可用于肯定确认响应者选择是否执行反重播检测。
When present, the Notification Payload MUST have the following format:
存在时，通知有效负载必须具有以下格式：
o Payload Length - set to length of payload + size of data (4) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to REPLAY-STATUS o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - a 4 octet value:
o 有效负载长度-设置为有效负载长度+数据大小（4）o DOI-设置为IPSEC DOI（1）o协议ID-设置为所选SA o SPI大小中的所选协议ID-设置为十六（16）（两个八位字节ISAKMP cookie）或四（4）（一个IPSEC SPI）o Notify Message Type-设置为REPLAY-STATUS o SPI-设置为两个ISAKMP Cookie或发送方的入站IPSEC SPI o通知数据-4个八位组的值：
0 = replay detection disabled 1 = replay detection enabled
0=禁用重播检测1=启用重播检测
The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system. The receiver of this Notification Message might then elect to delete any existing SA's it has for the sending system under the assumption that the sending system has rebooted and no longer has access to the original SA's and their associated keying material. When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload).
当一方希望通知另一方这是与远程系统建立的第一个SA时，可以使用初始联系状态消息。然后，该通知消息的接收者可能会选择删除发送系统的任何现有SA，前提是发送系统已重新启动，并且不再能够访问原始SA及其相关的密钥材料。使用时，通知数据字段的内容应为空（即，有效负载长度应设置为通知有效负载的固定长度）。
When present, the Notification Payload MUST have the following format:
存在时，通知有效负载必须具有以下格式：
o Payload Length - set to length of payload + size of data (0) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to INITIAL-CONTACT o SPI - set to the two ISAKMP cookies o Notification Data - <not included>
o 有效负载长度-设置为有效负载长度+数据大小（0）o DOI-设置为IPSEC DOI（1）o协议ID-设置为所选SA o SPI大小中的所选协议ID-设置为十六（16）（两个八位字节的ISAKMP cookies）o通知消息类型-设置为初始联系人o SPI-设置为两个ISAKMP cookies o通知数据-<未包含>
The IPSEC DOI introduces no additional Key Exchange types.
IPSEC DOI不引入其他密钥交换类型。
This entire memo pertains to the Internet Key Exchange protocol ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to provide for the derivation of cryptographic keying material in a secure and authenticated manner. Specific discussion of the various security protocols and transforms identified in this document can be found in the associated base documents and in the cipher references.
整个备忘录与互联网密钥交换协议（[IKE]）有关，该协议结合了ISAKMP（[ISAKMP]）和Oakley（[Oakley]），以安全和认证的方式提供加密密钥材料的推导。本文档中确定的各种安全协议和转换的具体讨论可在相关基础文档和密码参考中找到。
This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. All values not explicitly defined in previous sections are reserved to IANA.
本文件包含许多由IANA维护的“神奇”数字。本节解释IANA在每个列表中分配额外编号时使用的标准。前几节中未明确定义的所有值都保留给IANA。
The Situation Definition is a 32-bit bitmask which represents the environment under which the IPSEC SA proposal and negotiation is carried out. Requests for assignments of new situations must be accompanied by an RFC which describes the interpretation for the associated bit.
情况定义是一个32位位掩码，表示执行IPSEC SA建议和协商的环境。新情况分配请求必须附有RFC，该RFC描述了相关bit的解释。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The upper two bits are reserved for private use amongst cooperating systems.
上面的两位保留给合作系统之间的专用。
The Security Protocol Identifier is an 8-bit value which identifies a security protocol suite being negotiated. Requests for assignments of new security protocol identifiers must be accompanied by an RFC which describes the requested security protocol. [AH] and [ESP] are examples of security protocol documents.
安全协议标识符是一个8位值，用于标识正在协商的安全协议套件。分配新安全协议标识符的请求必须附有RFC，RFC描述了请求的安全协议。[AH]和[ESP]是安全协议文档的示例。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 249-255 are reserved for private use amongst cooperating systems.
值249-255保留给合作系统之间的私人使用。
The IPSEC ISAKMP Transform Identifier is an 8-bit value which identifies a key exchange protocol to be used for the negotiation. Requests for assignments of new ISAKMP transform identifiers must be accompanied by an RFC which describes the requested key exchange protocol. [IKE] is an example of one such document.
IPSEC ISAKMP转换标识符是一个8位值，用于标识用于协商的密钥交换协议。分配新ISAKMP转换标识符的请求必须附有RFC，RFC描述了请求的密钥交换协议。[IKE]是此类文件的一个示例。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 249-255 are reserved for private use amongst cooperating systems.
值249-255保留给合作系统之间的私人使用。
The IPSEC AH Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide integrity protection for AH. Requests for assignments of new AH transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the AH framework ([AH]).
IPSEC AH转换标识符是一个8位值，用于标识用于为AH提供完整性保护的特定算法。分配新AH转换标识符的请求必须附有RFC，RFC描述了如何在AH框架（[AH]）内使用算法。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 249-255 are reserved for private use amongst cooperating systems.
值249-255保留给合作系统之间的私人使用。
The IPSEC ESP Transform Identifier is an 8-bit value which identifies a particular algorithm to be used to provide secrecy protection for ESP. Requests for assignments of new ESP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the ESP framework ([ESP]).
IPSEC ESP转换标识符是一个8位值，它标识了用于为ESP提供保密保护的特定算法。分配新ESP转换标识符的请求必须附有RFC，RFC描述了如何在ESP框架（[ESP]）中使用该算法。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 249-255 are reserved for private use amongst cooperating systems.
值249-255保留给合作系统之间的私人使用。
The IPSEC IPCOMP Transform Identifier is an 8-bit value which identifier a particular algorithm to be used to provide IP-level compression before ESP. Requests for assignments of new IPCOMP transform identifiers must be accompanied by an RFC which describes how to use the algorithm within the IPCOMP framework ([IPCOMP]). In addition, the requested algorithm must be published and in the public domain.
IPSEC IPCOMP转换标识符是一个8位的值，它标识了在ESP之前用于提供IP级压缩的特定算法。分配新IPCOMP转换标识符的请求必须附有RFC，RFC描述了如何在IPCOMP框架（[IPCOMP]）内使用该算法。此外，请求的算法必须在公共域中发布。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 1-47 are reserved for algorithms for which an RFC has been approved for publication. The values 48-63 are reserved for private use amongst cooperating systems. The values 64-255 are reserved for future expansion.
值1-47保留用于已批准发布RFC的算法。值48-63保留给合作系统之间的私人使用。值64-255保留用于将来扩展。
The IPSEC Security Association Attribute consists of a 16-bit type and its associated value. IPSEC SA attributes are used to pass miscellaneous values between ISAKMP peers. Requests for assignments of new IPSEC SA attributes must be accompanied by an Internet Draft which describes the attribute encoding (Basic/Variable-Length) and its legal values. Section 4.5 of this document provides an example of such a description.
IPSEC安全关联属性由16位类型及其关联值组成。IPSEC SA属性用于在ISAKMP对等方之间传递其他值。请求分配新的IPSEC SA属性时，必须附带描述属性编码（基本/可变长度）及其合法值的Internet草稿。本文件第4.5节提供了此类说明的示例。
The values 32001-32767 are reserved for private use amongst cooperating systems.
值32001-32767保留给合作系统之间的私人使用。
The IPSEC Labeled Domain Identifier is a 32-bit value which identifies a namespace in which the Secrecy and Integrity levels and categories values are said to exist. Requests for assignments of new IPSEC Labeled Domain Identifiers should be granted on demand. No accompanying documentation is required, though Internet Drafts are encouraged when appropriate.
IPSEC标记的域标识符是一个32位的值，它标识了一个名称空间，该名称空间中据说存在保密性和完整性级别以及类别值。分配新的IPSEC标记的域标识符的请求应按需授予。无需随附文件，但适当时鼓励使用互联网草稿。
The values 0x80000000-0xffffffff are reserved for private use amongst cooperating systems.
值0x8000000-0xFFFFFF保留给合作系统之间的私人使用。
The IPSEC Identification Type is an 8-bit value which is used as a discriminant for interpretation of the variable-length Identification Payload. Requests for assignments of new IPSEC Identification Types must be accompanied by an RFC which describes how to use the identification type within IPSEC.
IPSEC标识类型是一个8位值，用作解释可变长度标识有效负载的判别式。请求分配新的IPSEC标识类型必须附带RFC，RFC描述如何在IPSEC中使用标识类型。
If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the transform identifier is assigned.
如果RFC不在标准轨道上（即，它是一个信息性或实验性RFC），则必须在发布RFC和分配转换标识符之前由IESG明确审查和批准。
The values 249-255 are reserved for private use amongst cooperating systems.
值249-255保留给合作系统之间的私人使用。
The IPSEC Notify Message Type is a 16-bit value taken from the range of values reserved by ISAKMP for each DOI. There is one range for error messages (8192-16383) and a different range for status messages (24576-32767). Requests for assignments of new Notify Message Types must be accompanied by an Internet Draft which describes how to use the identification type within IPSEC.
IPSEC通知消息类型是一个16位的值，取自ISAKMP为每个DOI保留的值范围。错误消息有一个范围（8192-16383），状态消息有一个不同的范围（24576-32767）。请求分配新的Notify消息类型时，必须附带一份Internet草稿，其中描述了如何在IPSEC中使用标识类型。
The values 16001-16383 and the values 32001-32767 are reserved for private use amongst cooperating systems.
值16001-16383和值32001-32767保留给合作系统之间的私人使用。
o add explicit reference to [IPCOMP], [DEFLATE], and [LZS] o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed at an IPSEC SPI in addition to the ISAKMP "SPI" o added padding exclusion to Secrecy and Integrity Length text o added forward reference to Section 4.5 in Section 4.4.4 o update document references
o 添加对[IPCOMP]、[DEFLATE]和[LZS]的明确引用，除了ISAKMP“SPI”外，还允许响应者生存期和重播状态指向IPSEC SPI。o在保密性和完整性长度文本中添加填充排除o在第4.4.4节中添加对第4.5节的正向引用o更新文档参考
o update IPCOMP identifier range to better reflect IPCOMP draft o update IANA considerations per Jeff/Ted's suggested text o eliminate references to DES-MAC ID ([DESMAC]) o correct bug in Notify section; ISAKMP Notify values are 16-bits
o 更新IPCOMP标识符范围以更好地反映IPCOMP草案o根据Jeff/Ted的建议文本更新IANA注意事项o消除对DES-MAC ID（[DESMAC]）的引用o纠正Notify部分中的错误；ISAKMP通知值为16位
o corrected name of IPCOMP (IP Payload Compression) o corrected references to [ESPCBC] o added missing Secrecy Level and Integrity Level to Figure 1 o removed ID references to PF_KEY and ARCFOUR o updated Basic/Variable text to align with [IKE] o updated document references and add intro pointer to [ARCH] o updated Notification requirements; remove aggressive reference o added clarification about protection for Notify payloads o restored RESERVED to ESP transform ID namespace; moved ESP_NULL o added requirement for ESP_NULL support and [ESPNULL] reference o added clarification on Auth Alg use with AH/ESP o added restriction against using conflicting AH/Auth combinations
o IPCOMP（IP有效负载压缩）的更正名称o对[ESPCBC]的更正引用o在图1中添加了缺失的保密级别和完整性级别o删除了对PF_密钥和ARCO更新的基本/变量文本的ID引用，以与[IKE]o更新的文档引用保持一致，并添加指向[ARCH]o更新的通知要求的介绍指针；删除攻击性引用o添加关于通知有效负载保护的说明o还原保留到ESP转换ID命名空间；移动ESP_NULL o增加了ESP_NULL支持的要求，[ESPNULL]参考o增加了关于授权Alg使用的澄清，AH/ESP o增加了对使用冲突AH/AUH组合的限制
The following changes were made relative to the IPSEC DOI V6:
相对于IPSEC DOI V6进行了以下更改：
o added IANA Considerations section o moved most IANA numbers to IANA Considerations section o added prohibition on sending (V) encoding for (B) attributes o added prohibition on sending Key Length attribute for fixed length ciphers (e.g. DES) o replaced references to ISAKMP/Oakley with IKE o renamed ESP_ARCFOUR to ESP_RC4 o updated Security Considerations section o updated document references
o 添加了IANA注意事项o部分将大多数IANA编号移至IANA注意事项o部分添加了禁止发送（V）编码（B）属性o添加了禁止发送固定长度密码（如DES）的密钥长度属性o用IKE替换对ISAKMP/Oakley的引用o将ESP_ARCFOUR重命名为ESP_RC4 o更新的安全注意事项部分o更新的文档引用
The following changes were made relative to the IPSEC DOI V5:
对IPSEC DOI V5进行了以下更改：
o changed SPI size in Lifetime Notification text o changed REPLAY-ENABLED to REPLAY-STATUS o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 to Section 4.6.3.1 o added explicit payload layout for 4.6.3.3 o added Implementation Note to Section 4.6.3 introduction o changed AH_SHA text to require SHA-1 in addition to MD5 o updated document references
o 更改了生存期通知文本中的SPI大小o将REPLAY-ENABLED更改为REPLAY-STATUS o将响应者生存期有效负载定义从第4.5.4节移动到第4.6.3.1节o为第4.6.3.3节添加了明确的有效负载布局o在第4.6.3节引言中添加了实施说明o更改了AHU SHA文本，除了MD5 o更新外，还需要SHA-1文件参考
The following changes were made relative to the IPSEC DOI V4:
对IPSEC DOI V4进行了以下更改：
o moved compatibility AH KPDK authentication method from AH transform ID to Authentication Algorithm identifier o added REPLAY-ENABLED notification message type per Architecture o added INITIAL-CONTACT notification message type per list o added text to ensure protection for Notify Status messages o added Lifetime qualification to attribute parsing section o added clarification that Lifetime notification is optional o removed private Group Description list (now points at [IKE]) o replaced Terminology with pointer to RFC-2119 o updated HMAC MD5 and SHA-1 ID references o updated Section 1 (Abstract) o updated Section 4.4 (IPSEC Assigned Numbers) o added restriction for ID port/protocol values for Phase I
o 将兼容性AH KPDK身份验证方法从AH转换ID移动到身份验证算法标识符o根据体系结构添加启用重播的通知消息类型o根据列表添加初始联系人通知消息类型o添加文本以确保对通知状态消息的保护o向属性解析添加生存期限定第o节增加了生命周期通知是可选的澄清o删除了私有组描述列表（现在指向[IKE]）o用指向RFC-2119的指针替换了术语o更新了HMAC MD5和SHA-1 ID参考o更新了第1节（摘要）o更新了第4.4节（IPSEC分配的编号）o增加了对第一阶段ID端口/协议值的限制
The following changes were made relative to the IPSEC DOI V3, that was posted to the IPSEC mailing list prior to the Munich IETF:
针对在慕尼黑IETF之前发布到IPSEC邮件列表的IPSEC DOI V3，进行了以下更改：
o added ESP transform identifiers for NULL and ARCFOUR
o 添加了NULL和ARCFOUR的ESP转换标识符
o renamed HMAC Algorithm to Auth Algorithm to accommodate DES-MAC and optional authentication/integrity for ESP o added AH and ESP DES-MAC algorithm identifiers o removed KEY_MANUAL and KEY_KDC identifier definitions o added lifetime duration MUST follow lifetype attribute to SA Life Type and SA Life Duration attribute definition o added lifetime notification and IPSEC DOI message type table o added optional authentication and confidentiality restrictions to MAC Algorithm attribute definition o corrected attribute parsing example (used obsolete attribute) o corrected several Internet Draft document references o added ID_KEY_ID per ipsec list discussion (18-Mar-97) o removed Group Description default for PFS QM ([IKE] MUST)
o 将HMAC算法重命名为Auth算法，以适应ESP的DES-MAC和可选身份验证/完整性o添加AH和ESP DES-MAC算法标识符o删除密钥_手动和密钥_KDC标识符定义o添加的生存期必须遵循SA生存期类型的生存期属性和SA生存期属性定义o添加的生存期通知和IPSEC DOI消息类型表o在MAC算法属性定义中添加了可选的身份验证和机密性限制o更正了属性解析示例（使用了过时的属性）o更正了多个Internet草稿文档参考o根据IPSEC列表讨论添加了ID_KEY_ID（1997年3月18日）o删除了PFS QM的组描述默认值（[IKE]必须）
Acknowledgments
致谢
This document is derived, in part, from previous works by Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran Atkinson also contributed suggestions and, in many cases, text.
本文件部分源自道格拉斯·莫恩、马克·舍特勒、马克·施耐德、杰夫·特纳、丹·哈金斯和戴夫·卡雷尔之前的作品。马特·托马斯、罗伊·佩雷拉、格雷格·卡特和拉恩·阿特金森也提出了建议，在许多情况下，还提供了文本。
References
工具书类
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, August 1998.
[DEFLATE]Pereira，R.，“使用DEFLATE的IP有效载荷压缩”，RFC 23941998年8月。
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[ESPCBC]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[ESPNULL]Glenn，R.和S.Kent，“NULL加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[DES]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.
[HMACMD5]Madson，C.和R.Glenn，“HMAC-MD5在ESP和AH中的使用”，RFC 2403，1998年11月。
[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[HMACSHA]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，D.，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
[IPCOMP]Shacham，A.，Monsour，R.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPCOMP）”，RFC 23931998年8月。
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[LZS] Friend, R., and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, August 1998.
[LZS]Friend，R.和R.Monsour，“使用LZS的IP有效负载压缩”，RFC 2395，1998年8月。
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[OAKLEY]Orman，H.，“OAKLEY密钥确定协议”，RFC 2412，1998年11月。
[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993.
[X.501]ISO/IEC 9594-2，“信息技术-开放系统互连-目录：模型”，CCITT/ITU建议X.5011993。
[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993.
[X.509]ISO/IEC 9594-8，“信息技术-开放系统互连-目录：认证框架”，CCITT/ITU建议X.509，1993年。
Author's Address
作者地址
Derrell Piper Network Alchemy 1521.5 Pacific Ave Santa Cruz, California, 95060 United States of America
Derrell Piper Network Alchemy加利福尼亚州圣克鲁斯太平洋大道1521.5号，美国
Phone: +1 408 460-3822
EMail: ddp@network-alchemy.com
Phone: +1 408 460-3822
EMail: ddp@network-alchemy.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。