Internet Engineering Task Force (IETF) D. Black
Request for Comments: 7146 EMC
Updates: 3720, 3723, 3821, 3822, 4018, 4172, P. Koning
4173, 4174, 5040, 5041, 5042, 5043, Dell
5044, 5045, 5046, 5047, 5048 April 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 7146 EMC
Updates: 3720, 3723, 3821, 3822, 4018, 4172, P. Koning
4173, 4174, 5040, 5041, 5042, 5043, Dell
5044, 5045, 5046, 5047, 5048 April 2014
Category: Standards Track
ISSN: 2070-1721
Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
通过IP保护块存储协议：IPsec v3的RFC 3723要求更新
Abstract
摘要
RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.
RFC 3723规定了基于IPsec v2（RFC 2401和相关RFC）的IP块存储协议（例如，Internet小型计算机系统接口（iSCSI））的IPsec要求；这些要求随后应用于远程直接数据放置协议，例如远程直接内存访问协议（RDMAP）。本文档将RFC 3723的IPsec要求更新为IPsec v3（RFC 4301和相关RFC），并根据RFC 3723发布以来密码学的发展对所需算法进行了一些更改。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7146.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7146.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Summary of Changes to RFC 3723 .............................4
1.3. Other Updated RFCs .........................................4
2. ESP Requirements ................................................6
2.1. Data Origin Authentication and Data Integrity Transforms ...6
2.2. Confidentiality Transform Requirements .....................7
3. IKEv1 and IKEv2 Requirements ....................................8
3.1. Authentication Requirements ...............................10
3.2. DH Group and PRF Requirements .............................11
4. Security Considerations ........................................11
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................16
Appendix A. Block Cipher Birthday Bounds ..........................17
Appendix B. Contributors ..........................................17
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Summary of Changes to RFC 3723 .............................4
1.3. Other Updated RFCs .........................................4
2. ESP Requirements ................................................6
2.1. Data Origin Authentication and Data Integrity Transforms ...6
2.2. Confidentiality Transform Requirements .....................7
3. IKEv1 and IKEv2 Requirements ....................................8
3.1. Authentication Requirements ...............................10
3.2. DH Group and PRF Requirements .............................11
4. Security Considerations ........................................11
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................16
Appendix A. Block Cipher Birthday Bounds ..........................17
Appendix B. Contributors ..........................................17
[RFC3723] specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 ([RFC2401] and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP [RFC5040]. This document updates RFC 3723's IPsec requirements to IPsec v3 ([RFC4301] and related RFCs) to reflect developments since RFC 3723 was published.
[RFC3723]指定基于IPsec v2（[RFC2401]和相关RFC）的IP上的块存储协议（例如iSCSI[RFC3720]）的IPsec要求；这些要求随后应用于远程直接数据放置协议，例如RDMAP[RFC5040]。本文档将RFC 3723的IPsec要求更新为IPsec v3（[RFC4301]和相关RFC），以反映自RFC 3723发布以来的发展。
For brevity, this document uses the term "block storage protocols" to refer to all protocols to which RFC 3723's requirements apply; see Section 1.3 for details.
为简洁起见，本文件使用术语“块存储协议”指RFC 3723要求适用的所有协议；详见第1.3节。
In addition to the IPsec v2 requirements in RFC 3723, IPsec v3, as specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), SHOULD be implemented for block storage protocols. Retention of the mandatory requirement for IPsec v2 provides interoperability with existing implementations, and the strong recommendation for IPsec v3 encourages implementers to move forward to that newer version of IPsec.
除了RFC 3723中的IPsec v2要求外，[RFC4301]和相关RFC（如IKEv2[RFC5996]）中规定的IPsec v3还应针对块存储协议实施。保留IPsec v2的强制要求提供了与现有实现的互操作性，而IPsec v3的强烈建议鼓励实现者向IPsec的新版本迈进。
Cryptographic developments since the publication of RFC 3723 necessitate changes to the encryption transform requirements for IPsec v2, as explained further in Section 2.2; these updated requirements also apply to IPsec v3.
如第2.2节所述，自RFC 3723发布以来的加密发展需要对IPsec v2的加密转换要求进行更改；这些更新的要求也适用于IPsec v3。
Block storage protocols can be expected to operate at high data rates (multiple gigabits/second). The cryptographic requirements in this document are strongly influenced by that expectation; an important example is that Triple Data Encryption Standard Cipher Block Chaining (3DES CBC) is no longer recommended for block storage protocols due to the frequent rekeying impacts of 3DES's 64-bit block size at high data rates.
块存储协议可以预期以高数据速率（千兆位/秒）运行。本文件中的密码要求受到该期望的强烈影响；一个重要的例子是，由于3DES的64位块大小在高数据速率下会频繁地重新设置密钥，因此不再建议将三重数据加密标准密码块链（3DES CBC）用于块存储协议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document makes the following changes to RFC 3723:
本文件对RFC 3723进行了以下更改：
o Adds requirements that IPsec v3 SHOULD be implemented (Encapsulating Security Payload (ESPv3) and IKEv2) in addition to IPsec v2 (see Section 1).
o 增加了除了IPsec v2之外还应实现IPsec v3（封装安全有效负载（ESPv3）和IKEv2）的要求（参见第1节）。
o Requires extended sequence numbers for both ESPv2 and ESPv3 (see Section 2).
o ESPv2和ESPv3都需要扩展序列号（参见第2节）。
o Clarifies key-size requirements for AES CBC MAC with XCBC extensions (MUST implement 128-bit keys; see Section 2.1).
o 澄清带有XCBC扩展的AES CBC MAC的密钥大小要求（必须实现128位密钥；参见第2.1节）。
o Adds IPsec v3 requirements for AES Galois Message Authentication Code (GMAC) and Galois/Counter Mode (GCM) (SHOULD implement when IKEv2 is supported; see Sections 2.1 and 2.2).
o 增加了AES Galois消息身份验证码（GMAC）和Galois/计数器模式（GCM）的IPsec v3要求（应在支持IKEv2时实施；请参阅第2.1和2.2节）。
o Removes implementation requirements for 3DES CBC and AES in Counter mode (AES CTR) (changes requirements for both to "MAY implement"). Adds a "MUST implement" requirement for AES CBC (see Section 2.2).
o 删除计数器模式（AES CTR）下3DES CBC和AES的实施要求（将两者的要求更改为“可实施”）。增加AES CBC的“必须实施”要求（见第2.2节）。
o Adds specific IKEv2 implementation requirements (see Section 3).
o 增加了具体的IKEv2实施要求（见第3节）。
o Removes the requirement that IKEv1 use UDP port 500 (see Section 3).
o 删除了IKEv1使用UDP端口500的要求（参见第3节）。
o Allows the use of the Online Certificate Status Protocol (OCSP) in addition to Certificate Revocation Lists (CRLs) to check certificates, and changes the Diffie-Hellman group size recommendation to a minimum of 2048 bits (see Section 3).
o 允许在证书吊销列表（CRL）之外使用在线证书状态协议（OCSP）检查证书，并将Diffie-Hellman组大小建议更改为最小2048位（参见第3节）。
RFC 3723's IPsec requirements have been applied to a number of protocols. For that reason, in addition to updating RFC 3723's IPsec requirements, this document also updates the IPsec requirements for each protocol that uses RFC 3723; that is, the following RFCs are updated -- in each case, the update is solely to the IPsec requirements:
RFC 3723的IPsec要求已应用于许多协议。因此，除了更新RFC 3723的IPsec要求外，本文件还更新了使用RFC 3723的每个协议的IPsec要求；也就是说，更新了以下RFC——在每种情况下，更新仅针对IPsec要求：
o [RFC3720] "Internet Small Computer Systems Interface (iSCSI)"
o [RFC3720]“Internet小型计算机系统接口（iSCSI）”
o [RFC3821] "Fibre Channel Over TCP/IP (FCIP)"
o [RFC3821]“TCP/IP上的光纤通道（FCIP）”
o [RFC3822] "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)"
o [RFC3822]“使用服务位置协议版本2（SLPv2）查找TCP/IP（FCIP）上的光纤通道实体”
o [RFC4018] "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)"
o [RFC4018]“使用服务位置协议版本2（SLPv2）查找Internet小型计算机系统接口（iSCSI）目标和名称服务器”
o [RFC4172] "iFCP - A Protocol for Internet Fibre Channel Storage Networking"
o [RFC4172]“iFCP-用于Internet光纤通道存储网络的协议”
o [RFC4173] "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol"
o [RFC4173]“使用Internet小型计算机系统接口（iSCSI）协议引导客户端”
o [RFC4174] "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service"
o [RFC4174]“Internet存储名称服务的IPv4动态主机配置协议（DHCP）选项”
o [RFC5040] "A Remote Direct Memory Access Protocol Specification"
o [RFC5040]“远程直接内存访问协议规范”
o [RFC5041] "Direct Data Placement over Reliable Transports"
o [RFC5041]“通过可靠传输直接放置数据”
o [RFC5042] "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security"
o [RFC5042]“直接数据放置协议（DDP）/远程直接内存访问协议（RDMAP）安全性”
o [RFC5043] "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation"
o [RFC5043]“流控制传输协议（SCTP）直接数据放置（DDP）自适应”
o [RFC5044] "Marker PDU Aligned Framing for TCP Specification"
o [RFC5044]“TCP规范的标记PDU对齐帧”
o [RFC5045] "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)"
o [RFC5045]“远程直接内存访问协议（RDMA）和直接数据放置（DDP）的适用性”
o [RFC5046] "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)"
o [RFC5046]“用于远程直接内存访问（RDMA）的Internet小型计算机系统接口（iSCSI）扩展”
o [RFC5047] "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)"
o [RFC5047]“DA:用于Internet小型计算机系统接口（iSCSI）的数据移动器体系结构”
o [RFC5048] "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications"
o [RFC5048]“互联网小型计算机系统接口（iSCSI）更正和澄清”
[RFC3721] and [RFC5387] are not updated by this document, as their usage of RFC 3723 does not encompass its IPsec requirements.
[RFC3721]和[RFC5387]未在本文件中更新，因为它们对RFC 3723的使用不包括其IPsec要求。
In addition, this document's updated IPsec requirements apply to the new specifications for iSCSI [RFC7143] and iSCSI Extensions for RDMA (iSER) [RFC7145].
此外，本文档更新的IPsec要求适用于iSCSI[RFC7143]的新规范和RDMA（iSER）[RFC7145]的iSCSI扩展。
This document uses the term "block storage protocols" to refer to the protocols (listed above) to which RFC 3723's requirements (as updated by the requirements in this document) apply.
本文件使用术语“块存储协议”来指RFC 3723要求（根据本文件中的要求更新）适用的协议（如上所列）。
RFC 3723 requires that implementations MUST support IPsec ESPv2 [RFC2406] in tunnel mode as part of IPsec v2 to provide security for both control packets and data packets; and that when ESPv2 is utilized, per-packet data origin authentication, integrity, and replay protection MUST be provided.
RFC 3723要求实现必须在隧道模式下支持IPsec ESPv2[RFC2406]，作为IPsec v2的一部分，以提供控制数据包和数据包的安全性；当使用ESPv2时，必须提供每包数据源身份验证、完整性和重播保护。
This document modifies RFC 3723 to require that implementations SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of IPsec v3 to provide security for both control packets and data packets; per-packet data origin authentication, integrity, and replay protection MUST be provided when ESPv3 is utilized.
本文件修改了RFC 3723，要求实现还应支持隧道模式下的IPsec ESPv3[RFC4303]，作为IPsec v3的一部分，以提供控制数据包和数据包的安全性；当使用ESPv3时，必须提供每包数据源身份验证、完整性和重播保护。
At the high speeds at which block storage protocols are expected to operate, a single IPsec security association (SA) could rapidly exhaust the ESP 32-bit sequence number space, requiring frequent rekeying of the SA, as rollover of the ESP sequence number within a single SA is prohibited for both ESPv2 [RFC2406] and ESPv3 [RFC4303]. In order to provide the means to avoid this potentially undesirable frequent rekeying, implementations that are capable of operating at speeds of 1 gigabit/second or higher MUST implement extended (64-bit) sequence numbers for ESPv2 (and ESPv3, if supported) and SHOULD use extended sequence numbers for all block storage protocol traffic. Extended sequence number negotiation as part of security association establishment is specified in [RFC4304] for IKEv1 and [RFC5996] for IKEv2.
在块存储协议预期运行的高速下，单个IPsec安全关联（SA）可能会迅速耗尽ESP 32位序列号空间，需要频繁地为SA重新键入密钥，因为ESPv2[RFC2406]和ESPv3[RFC4303]都禁止在单个SA内滚动ESP序列号。为了提供避免这种可能不受欢迎的频繁密钥更新的方法，能够以1千兆位/秒或更高速度运行的实现必须为ESPv2（和ESPv3，如果支持）实现扩展（64位）序列号，并且应该为所有块存储协议通信量使用扩展序列号。[RFC4304]针对IKEv1和[RFC5996]针对IKEv2规定了作为安全关联建立一部分的扩展序列号协商。
RFC 3723 requires that:
RFC 3723要求：
o HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96 [RFC2404].
o HMAC-SHA1必须以HMAC-SHA-1-96[RFC2404]的形式实施。
o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566].
o 应实施带有XCBC扩展的AES CBC MAC[RFC3566]。
This document clarifies RFC 3723's key-size requirements for implementations of AES CBC MAC with XCBC extensions; 128-bit keys MUST be supported, and other key sizes MAY also be supported.
本文件澄清了RFC 3723对使用XCBC扩展实现AES CBC MAC的关键尺寸要求；必须支持128位密钥，也可以支持其他密钥大小。
This document also adds a requirement for IPsec v3:
本文档还添加了IPsec v3的要求：
o Implementations that support IKEv2 [RFC5996] SHOULD also implement AES GMAC [RFC4543]. AES GMAC implementations MUST support 128-bit keys and MAY support other key sizes.
o 支持IKEv2[RFC5996]的实现也应该实现AES GMAC[RFC4543]。AES GMAC实现必须支持128位密钥，并且可能支持其他密钥大小。
The rationale for the added requirement is that GMAC is more amenable to hardware implementations that may be preferable for the high data rates at which block storage protocols can be expected to operate.
增加要求的理由是，GMAC更适合于硬件实现，而硬件实现可能更适合于预期块存储协议运行的高数据速率。
RFC 3723 requires that:
RFC 3723要求：
o 3DES in CBC mode (3DES CBC) [RFC2451] [triple-des-spec] MUST be supported.
o 必须支持CBC模式下的3DES（3DES CBC）[RFC2451][triple des spec]。
o AES in Counter mode (AES CTR) [RFC3686] SHOULD be supported.
o 应支持计数器模式下的AES（AES CTR）[RFC3686]。
o NULL encryption [RFC2410] MUST be supported.
o 必须支持空加密[RFC2410]。
The above requirements from RFC 3723 regarding 3DES CBC and AES CTR are replaced in this document by requirements that both 3DES CBC and AES CTR MAY be implemented. The NULL encryption requirement is not changed by this document. The 3DES CBC requirement matched the basic encryption interoperability requirement for IPsec v2. At the time of RFC 3723's publication, AES in Counter mode was the encryption transform that was most amenable to hardware implementation, as hardware implementation may be preferable for the high data rates at which block storage protocols can be expected to operate. This document changes both of these requirements, based on cryptographic developments since the publication of RFC 3723.
本文件将RFC 3723中有关3DES CBC和AES CTR的上述要求替换为3DES CBC和AES CTR均可实施的要求。本文档未更改空加密要求。3DES CBC要求符合IPsec v2的基本加密互操作性要求。在RFC 3723发布时，计数器模式下的AES是最适合硬件实现的加密转换，因为硬件实现可能更适合于块存储协议预期运行的高数据速率。本文件根据自RFC 3723发布以来的密码技术发展，更改了这两项要求。
The requirement for 3DES CBC has become problematic due to 3DES's 64-bit block size; i.e., the core cipher encrypts or decrypts 64 bits at a time. Security weaknesses in encryption start to appear as the amount of data encrypted under a single key approaches the birthday bound of 32 GiB (gibibytes) for a cipher with a 64-bit block size; see Appendix A and [triple-des-birthday]. It is prudent to rekey well before that bound is reached, and 32 GiB or some significant fraction thereof is less than the amount of data that a block storage protocol may transfer in a single session. This may require frequent rekeying, e.g., to obtain an order-of-magnitude (10x) safety margin by rekeying after 3 GiB on a multi-gigabit/sec link. In contrast, AES has a 128-bit block size, which results in a much larger birthday bound (2^68 bytes); see Appendix A. AES CBC [RFC3602] is the primary mandatory-to-implement encryption transform for interoperability and hence is the appropriate mandatory-to-implement transform replacement for 3DES CBC.
由于3DES的64位块大小，对3DES CBC的要求变得有问题；i、 例如，核心密码一次加密或解密64位。当使用单个密钥加密的数据量接近64位块大小密码的32 GiB（GiB字节）的生日界限时，加密中的安全弱点开始出现；见附录A和[三重des生日]。谨慎的做法是在达到该界限之前很早就重新设置密钥，并且32gib或其中的一些重要部分小于块存储协议在单个会话中可以传输的数据量。这可能需要频繁地重新键入，例如，通过在千兆位/秒链路上3 GiB后重新键入来获得数量级（10x）安全裕度。相比之下，AES有128位的块大小，这导致更大的生日界限（2^68字节）；参见附录A。AES CBC[RFC3602]是实现互操作性加密转换的主要强制性要求，因此是实现3DES CBC转换替换的适当强制性要求。
AES in Counter mode (AES CTR) is no longer the encryption transform that is most amenable to hardware implementation. That characterization now applies to AES GCM [RFC4106], which provides both encryption and integrity protection in a single cryptographic
计数器模式下的AES（AES CTR）不再是最适合硬件实现的加密转换。这一特征现在适用于AES GCM[RFC4106]，它在一个密码系统中提供加密和完整性保护
mechanism (in contrast, neither HMAC-SHA1 nor AES CBC MAC with XCBC extensions is well suited for hardware implementation, as both transforms do not pipeline well). AES GCM is also capable of providing confidentiality protection for the IKEv2 key exchange protocol, but not the IKEv1 protocol [RFC5282], and therefore the new AES GCM "SHOULD" requirement is based on the presence of support for IKEv2.
机制（相比之下，HMAC-SHA1和带有XCBC扩展的AES CBC MAC都不适合硬件实现，因为两种转换都不能很好地通过管道进行）。AES GCM还能够为IKEv2密钥交换协议提供保密保护，但不能为IKEv1协议[RFC5282]提供保密保护，因此，新的AES GCM“应该”要求基于对IKEv2的支持。
For the reasons described in the preceding paragraphs, the confidentiality transform requirements in RFC 3723 are replaced by the following:
出于上述段落所述的原因，RFC 3723中的保密要求替换为以下内容：
o 3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST implement" requirement).
o 可以实施CBC模式下的3DE（代替RFC 3723的“必须实施”要求）。
o AES in Counter mode (AES CTR) MAY be implemented (replaces RFC 3723's "SHOULD implement" requirement).
o 可实施计数器模式下的AES（AES CTR）（代替RFC 3723的“应实施”要求）。
o AES in CBC mode MUST be implemented. AES CBC implementations MUST support 128-bit keys and MAY support other key sizes.
o 必须实现CBC模式下的AES。AES CBC实现必须支持128位密钥，并且可能支持其他密钥大小。
o Implementations that support IKEv2 SHOULD also implement AES GCM. AES GCM implementations MUST support 128-bit keys and MAY support other key sizes.
o 支持IKEv2的实现也应该实现AES GCM。AES GCM实现必须支持128位密钥，并且可能支持其他密钥大小。
o NULL encryption [RFC2410] MUST be supported.
o 必须支持空加密[RFC2410]。
The requirement for support of NULL encryption enables the use of SAs that provide data origin authentication and data integrity, but not confidentiality.
支持空加密的要求允许使用SAs提供数据源身份验证和数据完整性，但不提供机密性。
Other transforms MAY be implemented in addition to those listed above.
除了上面列出的转换之外，还可以实现其他转换。
Note: To avoid ambiguity, the original IKE protocol [RFC2409] is referred to as "IKEv1" in this document.
注：为避免歧义，原始IKE协议[RFC2409]在本文件中称为“IKEv1”。
This document adds requirements for IKEv2 usage with block storage protocols and makes the following two changes to the IKEv1 requirements in RFC 3723 (the new Diffie-Hellman (DH) group requirement also applies to IKEv2):
本文件增加了块存储协议对IKEv2使用的要求，并对RFC 3723中的IKEv1要求进行了以下两项更改（新的Diffie-Hellman（DH）集团要求也适用于IKEv2）：
o When DH groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec security associations. The recommendation for the use of 1024-bit DH
o 使用DH组时，应提供至少2048位的DH组，作为创建IPsec安全关联的所有建议的一部分。建议使用1024位DH
groups with 3DES CBC and HMAC-SHA1 has been removed; the use of 1024-bit DH groups is NOT RECOMMENDED, and
3DES-CBC和HMAC-SHA1组已被移除；不建议使用1024位DH组，并且
o The requirement to use UDP port 500 is removed in order to allow NAT traversal [RFC3947].
o 为了允许NAT遍历，删除了使用UDP端口500的要求[RFC3947]。
There are no other changes to RFC 3723's IKEv1 requirements, but many of them are restated in this document in order to provide context for the new IKEv2 requirements.
RFC 3723的IKEv1要求没有其他变更，但本文件中重申了许多变更，以便为新的IKEv2要求提供上下文。
RFC 3723 requires that IKEv1 [RFC2409] be supported for peer authentication, negotiation of security associations, and key management, using the IPsec domain of interpretation (DOI) [RFC2407], and further requires that manual keying not be used since it does not provide the rekeying support necessary for operation at high data rates. This document adds a requirement that IKEv2 [RFC5996] SHOULD be supported for peer authentication, negotiation of security associations, and key management. The prohibition of manual keying as stated in RFC 3723 is extended to IKEv2; manual keying MUST NOT be used with any version of IPsec for protocols to which the requirements in this document apply.
RFC 3723要求使用IPsec解释域（DOI）[RFC2407]支持IKEv1[RFC2409]进行对等身份验证、安全关联协商和密钥管理，并进一步要求不使用手动密钥，因为它不提供在高数据速率下操作所需的重新密钥支持。本文件增加了一项要求，即应支持IKEv2[RFC5996]进行对等身份验证、安全关联协商和密钥管理。RFC 3723中规定的手动键控禁止扩展至IKEv2；对于本文档中的要求适用的协议，任何版本的IPsec都不得使用手动键控。
RFC 3723's requirements for IKEv1 mode implementation and usage are unchanged; this document does not extend those requirements to IKEv2 because IKEv2 does not have modes.
RFC 3723对IKEv1模式实施和使用的要求保持不变；本文件并未将这些要求扩展到IKEv2，因为IKEv2没有模式。
When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be interpreted as a reason for tearing down the block storage protocol connection (e.g., TCP-based). If additional traffic is sent, a new SA will be created to protect that traffic.
使用IPsec时，接收到删除SA的IKEv1第2阶段删除消息或IKEv2信息交换不应被解释为断开块存储协议连接（例如，基于TCP的连接）的原因。如果发送了额外的流量，将创建一个新的SA来保护该流量。
The method used to determine whether a block storage protocol connection should be established using IPsec is regarded as an issue of IPsec policy administration and thus is not defined in this document. The method used by an implementation that supports both IPsec v2 and v3 to determine which versions of IPsec are supported by a block storage protocol peer is also regarded as an issue of IPsec policy administration and thus is also not defined in this document. If both IPsec v2 and v3 are supported by both endpoints of a block storage protocol connection, the use of IPsec v3 is RECOMMENDED.
用于确定是否应使用IPsec建立块存储协议连接的方法被视为IPsec策略管理的问题，因此本文档中没有定义。支持IPsec v2和v3的实现用于确定块存储协议对等方支持哪些版本的IPsec的方法也被视为IPsec策略管理的问题，因此本文档中也没有定义。如果块存储协议连接的两个端点都支持IPsec v2和v3，则建议使用IPsec v3。
The authentication requirements for IKEv1 are unchanged by this document but are restated here for context, along with the authentication requirements for IKEv2:
本文件未对IKEv1的认证要求进行修改，但此处根据上下文和IKEv2的认证要求进行了重申：
a. Peer authentication using a pre-shared cryptographic key MUST be supported. Certificate-based peer authentication using digital signatures MAY be supported. For IKEv1 [RFC2409], peer authentication using the public key encryption methods specified in Sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used.
a. 必须支持使用预共享加密密钥的对等身份验证。可能支持使用数字签名的基于证书的对等身份验证。对于IKEv1[RFC2409]，不应使用[RFC2409]第5.2节和第5.3节中规定的公钥加密方法进行对等身份验证。
b. When digital signatures are used for authentication, all IKEv1 and IKEv2 negotiators SHOULD use Certificate Request Payload(s) to specify the certificate authority and SHOULD check the certificate validity via the pertinent Certificate Revocation List (CRL) or the use of the Online Certificate Status Protocol (OCSP) [RFC6960] before accepting a PKI certificate for use in authentication. OCSP support within the IKEv2 protocol is specified in [RFC4806].
b. 当使用数字签名进行身份验证时，所有IKEv1和IKEv2谈判者应使用证书请求有效载荷来指定证书颁发机构，并应通过相关证书撤销列表（CRL）或使用在线证书状态协议（OCSP）检查证书有效性。[RFC6960]在接受用于身份验证的PKI证书之前。[RFC4806]中规定了IKEv2协议内的OCSP支持。
c. IKEv1 implementations MUST support Main Mode and SHOULD support Aggressive Mode. Main Mode with the pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP addresses. While in many cases pre-shared keys offer good security, situations in which dynamically assigned addresses are used force the use of a group pre-shared key, which creates vulnerability to a man-in-the-middle attack. These requirements do not apply to IKEv2 because it has no modes.
c. IKEv1实现必须支持主模式，并且应该支持主动模式。当启动器或目标使用动态分配的IP地址时，不应使用带有预共享密钥身份验证方法的主模式。虽然在许多情况下，预共享密钥提供了良好的安全性，但在使用动态分配的地址的情况下，强制使用组预共享密钥，这会造成中间人攻击的漏洞。这些要求不适用于IKEv2，因为它没有模式。
d. In the IKEv1 Phase 2 Quick Mode, in exchanges for creating the Phase 2 SA, the Identification Payload MUST be present. This requirement does not apply to IKEv2 because it has no modes.
d. 在IKEv1阶段2快速模式下，作为创建阶段2 SA的交换，必须存在识别有效载荷。该要求不适用于IKEv2，因为它没有模式。
e. The following identification type requirements apply to IKEv1. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN SHOULD be supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.
e. 以下识别类型要求适用于IKEv1。必须支持ID_IPV4_ADDR、ID_IPV6_ADDR（如果协议栈支持IPV6）和ID_FQDN标识类型；应支持ID\u用户\u FQDN。不应使用IP子网、IP地址范围、ID_DER_ASN1_DN和ID_DER_ASN1_GN标识类型。不得使用ID\u密钥\u ID标识类型。
f. When IKEv2 is supported, the following identification requirements apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identification Types MUST be supported; ID_RFC822_ADDR SHOULD be supported. The ID_DER_ASN1_DN and ID_DER_ASN1_GN Identification Types SHOULD NOT be used. The ID_KEY_ID Identification Type MUST NOT be used.
f. 当支持IKEv2时，以下识别要求适用。必须支持ID_IPV4_ADDR、ID_IPV6_ADDR（如果协议栈支持IPV6）和ID_FQDN标识类型；应支持ID\u RFC822\u ADDR。不应使用ID_DER_ASN1_DN和ID_DER_ASN1_GN标识类型。不得使用ID\u密钥\u ID标识类型。
The reasons for the identification requirements in items e and f above are as follows:
上述e项和f项中标识要求的原因如下：
o IP Subnet and IP Address Range are too broad to usefully identify an iSCSI endpoint.
o IP子网和IP地址范围太宽，无法有效标识iSCSI端点。
o The _DN and _GN types are X.500 identities; it is usually better to use an identity from subjectAltName in a PKI certificate.
o DN和GN类型为X.500标识；通常最好在PKI证书中使用subjectAltName中的标识。
o ID_KEY_ID is an opaque identifier that is not interoperable among different IPsec implementations as specified. Heterogeneity in some block storage protocol implementations can be expected (e.g., iSCSI initiator vs. iSCSI target implementations), and hence heterogeneity among IPsec implementations is important.
o ID_KEY_ID是一个不透明的标识符，在指定的不同IPsec实现之间不可互操作。某些块存储协议实施中的异构性是可以预期的（例如，iSCSI启动器与iSCSI目标实施），因此IPsec实施中的异构性非常重要。
This document does not change the support requirements for Diffie-Hellman (DH) groups and Pseudo-Random Functions (PRFs). See [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2 requirements. Implementers are advised to check for subsequent RFCs that update either of these RFCs, as such updates may change these requirements.
本文件不改变Diffie-Hellman（DH）组和伪随机函数（PRF）的支持要求。IKEv1要求见[RFC4109]，IKEv2要求见[RFC4307]。建议实施者检查更新这些RFC的后续RFC，因为这些更新可能会改变这些需求。
When DH groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec security associations for both IKEv1 and IKEv2.
使用DH组时，应提供至少2048位的DH组，作为为IKEv1和IKEv2创建IPsec安全关联的所有建议的一部分。
RFC 3723 requires that support for perfect forward secrecy in the IKEv1 Quick Mode key exchange MUST be implemented. This document extends that requirement to IKEv2; support for perfect forward secrecy in the CREATE_CHILD_SA key exchange MUST be implemented for the use of IPsec with block storage protocols.
RFC 3723要求必须在IKEv1快速模式密钥交换中实现对完美前向保密性的支持。本文件将该要求扩展至IKEv2；对于IPsec与块存储协议的使用，必须在CREATE_CHILD_SA密钥交换中实现对完美前向保密性的支持。
This entire document is about security.
整个文档都是关于安全性的。
The security considerations sections of all of the referenced RFCs apply, and particular note should be taken of the security considerations for the encryption transforms whose requirement levels are changed by this RFC:
所有参考RFC的安全注意事项部分均适用，并且应特别注意加密转换的安全注意事项，其要求级别由本RFC更改：
o AES GMAC [RFC4543] (new requirement -- SHOULD be supported when IKEv2 is supported),
o AES GMAC[RFC4543]（新要求——支持IKEv2时应支持），
o 3DES CBC [RFC2451] (changed from "MUST be supported" to "MAY be supported"),
o 3DES CBC[RFC2451]（从“必须支持”更改为“可能支持”），
o AES CTR [RFC3686] (changed from "SHOULD be supported" to "MAY be supported"),
o AES CTR[RFC3686]（从“应支持”更改为“可能支持”），
o AES CBC [RFC3602] (new requirement -- MUST be supported), and
o AES CBC[RFC3602]（新要求——必须得到支持），以及
o AES GCM [RFC4106] (new requirement -- SHOULD be supported when IKEv2 is supported).
o AES GCM[RFC4106]（新要求——在支持IKEv2时应予以支持）。
Of particular interest are the security considerations concerning the use of AES GCM [RFC4106] and AES GMAC [RFC4543]; both modes are vulnerable to catastrophic forgery attacks if a nonce is ever repeated with a given key.
特别令人感兴趣的是有关使用AES GCM[RFC4106]和AES GMAC[RFC4543]的安全考虑；如果使用给定密钥重复一个nonce，这两种模式都容易受到灾难性伪造攻击。
The requirement level for 3DES CBC has been reduced, based on considerations for high-speed implementations; 3DES CBC remains an optional encryption transform that may be suitable for implementations limited to operating at lower speeds where the required rekeying frequency for 3DES is acceptable.
基于对高速实现的考虑，3DES CBC的需求水平已经降低；3DES CBC仍然是一种可选的加密转换，可能适用于仅限于以较低速度运行的实现，其中3DES所需的密钥更新频率是可接受的。
The requirement level for AES CTR has been reduced, based solely on hardware implementation considerations that favor AES GCM, as opposed to changes in AES CTR's security properties. AES CTR remains an optional security transform that is suitable for use in general, as it does not share 3DES CBC's requirement for frequent rekeying when operating at high data rates.
AES CTR的需求水平已经降低，仅基于有利于AES GCM的硬件实现考虑，而不是AES CTR安全属性的变化。AES CTR仍然是一种可选的安全转换，适合一般使用，因为它不符合3DES CBC在高数据速率下运行时频繁重新键入的要求。
Key sizes with comparable strength SHOULD be used for the cryptographic algorithms and transforms for any individual IPsec security association. See Section 5.6 of [SP800-57] for further discussion.
对于任何单个IPsec安全关联的加密算法和转换，应使用具有类似强度的密钥大小。进一步讨论见[SP800-57]第5.6节。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效负载（ESP）”，RFC 3686，2004年1月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3821, July 2004.
[RFC3821]Rajagopal，M.，Rodriguez，E.，和R.Weber，“TCP/IP上的光纤通道（FCIP）”，RFC 38212004年7月。
[RFC3822] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004.
[RFC3822]Peterson，D.“使用服务位置协议版本2（SLPv2）查找TCP/IP上的光纤通道（FCIP）实体”，RFC 3822，2004年7月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4018] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)", RFC 4018, April 2005.
[RFC4018]Bakke，M.，Hufferd，J.，Voruganti，K.，Krueger，M.，和T.Sperry，“通过使用服务位置协议版本2（SLPv2）查找Internet小型计算机系统接口（iSCSI）目标和名称服务器”，RFC 4018，2005年4月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005.
[RFC4109]Hoffman，P.，“互联网密钥交换算法第1版（IKEv1）”，RFC 4109，2005年5月。
[RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.
[RFC4172]Monia，C.，Mullendore，R.，Travostino，F.，Jeong，W.，和M.Edwards，“iFCP-互联网光纤通道存储网络协议”，RFC 4172，2005年9月。
[RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[RFC4173]Sarkar，P.，Missimer，D.，和C.Sapuntzakis，“使用互联网小型计算机系统接口（iSCSI）协议引导客户端”，RFC 41732005年9月。
[RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service", RFC 4174, September 2005.
[RFC4174]Monia，C.，Tseng，J.，和K.Gibbons，“互联网存储名称服务的IPv4动态主机配置协议（DHCP）选项”，RFC 4174，2005年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005.
[RFC4304]Kent，S.，“互联网安全关联和密钥管理协议（ISAKMP）IPsec解释域（DOI）的扩展序列号（ESN）附录”，RFC 43042005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，RFC 4543，2006年5月。
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RFC5040]Recio，R.，Metzler，B.，Culley，P.，Hilland，J.，和D.Garcia，“远程直接内存访问协议规范”，RFC 50402007年10月。
[RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[RFC5041]Shah，H.，Pinkerton，J.，Recio，R.，和P.Culley，“可靠传输上的直接数据放置”，RFC 50412007年10月。
[RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007.
[RFC5042]Pinkerton，J.和E.Deleganes，“直接数据放置协议（DDP）/远程直接内存访问协议（RDMAP）安全”，RFC 50422007年10月。
[RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation", RFC 5043, October 2007.
[RFC5043]Bestler，C.和R.Stewart，“流控制传输协议（SCTP）直接数据放置（DDP）自适应”，RFC 50432007年10月。
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007.
[RFC5044]Culley，P.，Elzur，U.，Recio，R.，Bailey，S.，和J.Carrier，“TCP规范的标记PDU对齐帧”，RFC 5044，2007年10月。
[RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[RFC5046]Ko，M.，Chadalapaka，M.，Hufferd，J.，Elzur，U.，Shah，H.，和P.Thaler，“远程直接内存访问（RDMA）的互联网小型计算机系统接口（iSCSI）扩展”，RFC 5046，2007年10月。
[RFC5048] Chadalapaka, M., "Internet Small Computer System Interface (iSCSI) Corrections and Clarifications", RFC 5048, October 2007.
[RFC5048]Chadalapaka，M.，“互联网小型计算机系统接口（iSCSI）更正和澄清”，RFC 5048，2007年10月。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5282]Black，D.和D.McGrew，“使用互联网密钥交换第2版（IKEv2）协议的加密有效负载的认证加密算法”，RFC 5282，2008年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 69602013年6月。
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, April 2014.
[RFC7143]Chadalapaka，M.，Satran，J.，Meth，K.，和D.Black，“互联网小型计算机系统接口（iSCSI）协议（整合）”，RFC 71432014年4月。
[RFC7145] Ko, M. and A. Nezhinsky, "Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification", RFC 7145, April 2014.
[RFC7145]Ko，M.和A.Nezhinsky，“远程直接内存访问（RDMA）规范的互联网小型计算机系统接口（iSCSI）扩展”，RFC 71452014年4月。
[SP800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "NIST Special Publication 800-57: Recommendation for Key Management - Part 1: General (Revision 3)", July 2012, <http://csrc.nist.gov/publications/nistpubs/800-57/ sp800-57_part1_rev3_general.pdf>.
[SP800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“NIST特别出版物800-57：关键管理建议-第1部分：总则（第3版）”，2012年7月<http://csrc.nist.gov/publications/nistpubs/800-57/ sp800-57\u part1\u rev3\u general.pdf>。
[triple-des-birthday] McGrew, D., "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes (Cryptology ePrint Archive: Report 2012/ 623)", November 2012, <http://eprint.iacr.org/2012/623>.
[triple-des birthday]McGrew，D.，“64位分组密码模式不可能的明文密码分析和可能的明文冲突攻击（密码学EPRIT存档：报告2012/623）”，2012年11月<http://eprint.iacr.org/2012/623>.
[triple-des-spec] American Bankers Association (ABA), "American National Standard for Financial Services X9.52-1998 - Triple Data Encryption Algorithm Modes of Operation", July 1998.
[triple des spec]美国银行家协会（ABA），“美国金融服务国家标准X9.52-1998-三重数据加密算法操作模式”，1998年7月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721]Bakke，M.，Hafner，J.，Hufferd，J.，Voruganti，K.，和M.Krueger，“互联网小型计算机系统接口（iSCSI）命名和发现”，RFC 37212004年4月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]Myers，M.和H.Tschofenig，“IKEv2的在线证书状态协议（OCSP）扩展”，RFC 4806，2007年2月。
[RFC5045] Bestler, C. and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007.
[RFC5045]Bestler，C.和L.Coene，“远程直接内存访问协议（RDMA）和直接数据放置（DDP）的适用性”，RFC 5045，2007年10月。
[RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)", RFC 5047, October 2007.
[RFC5047]Chadalapaka，M.，Hufferd，J.，Satran，J.，和H.Shah，“DA：互联网小型计算机系统接口（iSCSI）的数据移动器体系结构”，RFC 5047，2007年10月。
[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月。
This appendix provides the birthday bounds for the 3DES and AES ciphers based on [triple-des-birthday], which states: "Theory advises against using a w-bit block cipher to encrypt more than 2^(w/2) blocks with a single key; this is known as the birthday bound".
本附录提供了基于[三重des生日]的3DES和AES密码的生日界限，其中指出：“理论上建议不要使用w位分组密码用单个密钥加密超过2^（w/2）个块；这称为生日界限”。
For a cipher with a 64-bit block size (e.g., 3DES), w = 64, so the birthday bound is 2^32 blocks. As each block contains 8 (2^3) bytes, the birthday bound is 2^35 bytes = 2^5 gibibytes, i.e., 32 GiB, where 1 gibibyte (GiB) = 2^30 bytes. Note that a gigabyte (decimal quantity) is not the same as a gibibyte (binary quantity); 1 gigabyte (GB) = 10^6 bytes.
对于具有64位块大小（例如3DES）的密码，w=64，因此生日界限为2^32块。由于每个块包含8（2^3）个字节，因此生日界限为2^35字节=2^5 GiB字节，即32 GiB，其中1 GiB字节（GiB）=2^30字节。请注意，千兆字节（十进制数）与千兆字节（二进制数）不同；1GB（GB）=10^6字节。
For a cipher with a 128-bit block size (e.g., AES), w = 128, so the birthday bound is 2^64 blocks. As each block contains 16 (2^4) bytes, the birthday bound is 2^68 bytes = 2^8 exbibytes, i.e., 256 EiB, where 1 exbibyte (EiB) = 2^60 bytes. Note that an exabyte (decimal quantity) is not the same as an exbibyte (binary quantity); 1 exabyte (EB) = 10^9 bytes.
对于具有128位块大小（例如AES）的密码，w=128，因此生日界限为2^64个块。由于每个块包含16（2^4）个字节，生日界限为2^68字节=2^8个字节，即256个EiB，其中1个字节=2^60字节。请注意，exabyte（十进制数量）与exbibyte（二进制数量）不同；1个字节（EB）=10^9个字节。
David McGrew's observations about the birthday bound implications of 3DES's 64-bit block size on the ipsec@ietf.org mailing list led to changing from 3DES CBC to AES CBC as the mandatory-to-implement encryption algorithm, based on the birthday bound discussion in Appendix A.
David McGrew关于3DES的64位块大小对系统的生日限制影响的观察ipsec@ietf.org根据附录A中关于生日的讨论，邮件列表导致将3DES CBC更改为AES CBC，作为实现加密算法的强制性要求。
The original authors of RFC 3723 were Bernard Aboba, Joshua Tseng, Jesse Walker, Venkat Rangan, and Franco Travostino. Comments from Francis Dupont, Yaron Sheffer, Tom Talpey, Sean Turner, and Tom Yu have improved this document and are gratefully acknowledged.
RFC3723的原始作者是伯纳德·阿博巴、曾约书亚、杰西·沃克、文卡特·兰根和弗朗哥·特拉沃斯蒂诺。Francis Dupont、Yaron Sheffer、Tom Talpey、Sean Turner和Tom Yu的评论改进了本文件，对此表示感谢。
Authors' Addresses
作者地址
David L. Black EMC Corporation 176 South St. Hopkinton, MA 01748 USA
David L.Black EMC公司美国马萨诸塞州霍普金顿南大街176号01748
Phone: +1 508 293-7953
EMail: david.black@emc.com
Phone: +1 508 293-7953
EMail: david.black@emc.com
Paul Koning Dell 300 Innovative Way Nashua, NH 03062 USA
保罗·科宁戴尔300创新之路美国新罕布什尔州纳舒亚03062
Phone: +1 603 249-7703
EMail: paul_koning@Dell.com
Phone: +1 603 249-7703
EMail: paul_koning@Dell.com