Network Working Group B. Aboba
Request for Comments: 3723 Microsoft
Category: Standards Track J. Tseng
McDATA Corporation
J. Walker
Intel
V. Rangan
Brocade Communications Systems Inc.
F. Travostino
Nortel Networks
April 2004
Network Working Group B. Aboba
Request for Comments: 3723 Microsoft
Category: Standards Track J. Tseng
McDATA Corporation
J. Walker
Intel
V. Rangan
Brocade Communications Systems Inc.
F. Travostino
Nortel Networks
April 2004
Securing Block Storage Protocols over IP
通过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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.
本文档讨论如何使用IPsec和IKE（Internet密钥交换）保护通过IP（Internet协议）运行的块存储和存储发现协议。针对iSCSI（Internet协议小型计算机系统接口）、iFCP（Internet光纤通道存储网络）和FCIP（TCP/IP上的光纤通道）以及iSNS（Internet存储名称服务器）和SLPv2（服务位置协议v2）发现协议开发了威胁模型和安全协议。分析了性能问题和资源约束。
Table of Contents
目录
1. Introduction ................................................. 3
1.1. iSCSI Overview ......................................... 3
1.2. iFCP Overview .......................................... 4
1.3. FCIP Overview .......................................... 4
1.4. IPsec Overview ......................................... 4
1.5. Terminology ............................................ 6
1.6. Requirements Language .................................. 7
1. Introduction ................................................. 3
1.1. iSCSI Overview ......................................... 3
1.2. iFCP Overview .......................................... 4
1.3. FCIP Overview .......................................... 4
1.4. IPsec Overview ......................................... 4
1.5. Terminology ............................................ 6
1.6. Requirements Language .................................. 7
2. Block Storage Protocol Security .............................. 7
2.1. Security Requirements ................................. 7
2.2. Resource Constraints ................................... 10
2.3. Security Protocol ...................................... 12
2.4. iSCSI Authentication ................................... 16
2.5. SLPv2 Security ......................................... 18
2.6. iSNS Security .......................................... 24
3. iSCSI security Inter-Operability Guidelines .................. 28
3.1. iSCSI Security Issues .................................. 28
3.2. iSCSI and IPsec Interaction ............................ 29
3.3. Initiating a New iSCSI Session ......................... 30
3.4. Graceful iSCSI Teardown ................................ 31
3.5. Non-graceful iSCSI Teardown ............................ 31
3.6. Application Layer CRC .................................. 32
4. iFCP and FCIP Security Issues ................................ 34
4.1. iFCP and FCIP Authentication Requirements .............. 34
4.2. iFCP Interaction with IPsec and IKE .................... 34
4.3. FCIP Interaction with IPsec and IKE .................... 35
5. Security Considerations ...................................... 36
5.1. Transport Mode Versus Tunnel Mode ...................... 36
5.2. NAT Traversal .......................................... 39
5.3. IKE Issues ............................................. 40
5.4. Rekeying Issues ........................................ 40
5.5. Transform Issues ....................................... 43
5.6. Fragmentation Issues ................................... 45
5.7. Security Checks ........................................ 46
5.8. Authentication Issues .................................. 47
5.9. Use of AES in Counter Mode ............................. 51
6. IANA Considerations .......................................... 51
6.1. Definition of Terms .................................... 52
6.2. Recommended Registration Policies ...................... 52
7. Normative References ......................................... 52
8. Informative References ....................................... 54
9. Acknowledgments .............................................. 58
Appendix A - Well Known Groups for Use with SRP ................. 59
Appendix B - Software Performance of IPsec Transforms ........... 61
B.1. Authentication Transforms .............................. 61
B.2. Encryption and Authentication Transforms ............... 64
Authors' Addresses ............................................... 69
Full Copyright Statement ......................................... 70
2. Block Storage Protocol Security .............................. 7
2.1. Security Requirements ................................. 7
2.2. Resource Constraints ................................... 10
2.3. Security Protocol ...................................... 12
2.4. iSCSI Authentication ................................... 16
2.5. SLPv2 Security ......................................... 18
2.6. iSNS Security .......................................... 24
3. iSCSI security Inter-Operability Guidelines .................. 28
3.1. iSCSI Security Issues .................................. 28
3.2. iSCSI and IPsec Interaction ............................ 29
3.3. Initiating a New iSCSI Session ......................... 30
3.4. Graceful iSCSI Teardown ................................ 31
3.5. Non-graceful iSCSI Teardown ............................ 31
3.6. Application Layer CRC .................................. 32
4. iFCP and FCIP Security Issues ................................ 34
4.1. iFCP and FCIP Authentication Requirements .............. 34
4.2. iFCP Interaction with IPsec and IKE .................... 34
4.3. FCIP Interaction with IPsec and IKE .................... 35
5. Security Considerations ...................................... 36
5.1. Transport Mode Versus Tunnel Mode ...................... 36
5.2. NAT Traversal .......................................... 39
5.3. IKE Issues ............................................. 40
5.4. Rekeying Issues ........................................ 40
5.5. Transform Issues ....................................... 43
5.6. Fragmentation Issues ................................... 45
5.7. Security Checks ........................................ 46
5.8. Authentication Issues .................................. 47
5.9. Use of AES in Counter Mode ............................. 51
6. IANA Considerations .......................................... 51
6.1. Definition of Terms .................................... 52
6.2. Recommended Registration Policies ...................... 52
7. Normative References ......................................... 52
8. Informative References ....................................... 54
9. Acknowledgments .............................................. 58
Appendix A - Well Known Groups for Use with SRP ................. 59
Appendix B - Software Performance of IPsec Transforms ........... 61
B.1. Authentication Transforms .............................. 61
B.2. Encryption and Authentication Transforms ............... 64
Authors' Addresses ............................................... 69
Full Copyright Statement ......................................... 70
This specification discusses use of the IPsec protocol suite for protecting block storage protocols over IP networks (including iSCSI, iFCP and FCIP), as well as storage discovery protocols (iSNS and SLPv2).
本规范讨论了IPsec协议套件在IP网络上保护块存储协议（包括iSCSI、iFCP和FCIP）以及存储发现协议（iSNS和SLPv2）的使用。
iSCSI, described in [RFC3720], is a connection-oriented command/response protocol that runs over TCP, and is used to access disk, tape and other devices. iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets) and perform an iSCSI login.
[RFC3720]中描述的iSCSI是一种面向连接的命令/响应协议，它运行在TCP上，用于访问磁盘、磁带和其他设备。iSCSI是一种客户端-服务器协议，其中客户端（启动器）打开到服务器（目标）的连接并执行iSCSI登录。
This document uses the SCSI terms initiator and target for clarity and to avoid the common assumption that clients have considerably less computational and memory resources than servers; the reverse is often the case for SCSI, as targets are commonly dedicated devices of some form.
为了清晰起见，本文档使用SCSI术语启动器和目标，并避免客户机的计算和内存资源比服务器少得多的常见假设；SCSI的情况通常相反，因为目标通常是某种形式的专用设备。
The iSCSI protocol has a text based negotiation mechanism as part of its initial (login) procedure. The mechanism is extensible in what can be negotiated (new text keys and values can be defined) and also in the number of negotiation rounds (e.g., to accommodate functionality such as challenge-response authentication).
iSCSI协议具有基于文本的协商机制，作为其初始（登录）过程的一部分。该机制可扩展为可协商的内容（可定义新的文本密钥和值）以及协商轮数（例如，适应挑战-响应身份验证等功能）。
After a successful login, the iSCSI initiator may issue SCSI commands for execution by the iSCSI target, which returns a status response for each command, over the same connection. A single connection is used for both command/status messages as well as transfer of data and/or optional command parameters. An iSCSI session may have multiple connections, but a separate login is performed on each. The iSCSI session terminates when its last connection is closed.
成功登录后，iSCSI启动器可能会发出SCSI命令供iSCSI目标通过同一连接执行，该目标会返回每个命令的状态响应。单个连接用于命令/状态消息以及数据和/或可选命令参数的传输。iSCSI会话可能有多个连接，但每个连接上都会执行单独的登录。iSCSI会话在其最后一个连接关闭时终止。
iSCSI initiators and targets are application layer entities that are independent of TCP ports and IP addresses. Initiators and targets have names whose syntax is defined in [RFC3721]. iSCSI sessions between a given initiator and target are run over one or more TCP connections between those entities. That is, the login process establishes an association between an iSCSI Session and the TCP connection(s) over which iSCSI PDUs will be carried.
iSCSI启动器和目标是独立于TCP端口和IP地址的应用层实体。启动器和目标的名称的语法在[RFC3721]中定义。给定启动器和目标之间的iSCSI会话通过这些实体之间的一个或多个TCP连接运行。也就是说，登录过程在iSCSI会话和将承载iSCSI PDU的TCP连接之间建立关联。
While the iSCSI login may include mutual authentication of the iSCSI endpoints and negotiation of session parameters, iSCSI does not define its own per-packet authentication, integrity, confidentiality or replay protection mechanisms. Rather, it relies upon the IPsec protocol suite to provide per-packet data confidentiality and
虽然iSCSI登录可能包括iSCSI端点的相互身份验证和会话参数协商，但iSCSI不定义其自己的每包身份验证、完整性、机密性或重播保护机制。相反，它依赖IPsec协议套件来提供每包数据的机密性和安全性
integrity and authentication services, with IKE as the key management protocol. iSCSI uses TCP to provide congestion control, error detection and error recovery.
完整性和身份验证服务，使用IKE作为密钥管理协议。iSCSI使用TCP提供拥塞控制、错误检测和错误恢复。
iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which provides transport services to Fibre Channel devices over a TCP/IP network. iFCP allows interconnection and networking of existing Fibre Channel devices at wire speeds over an IP network. iFCP implementations emulate fabric services in order to improve fault tolerance and scalability by fully leveraging IP technology. Each TCP connection is used to support storage traffic between a unique pair of Fibre Channel N_PORTs.
[iFCP]中定义的iFCP是网关到网关协议，它通过TCP/IP网络向光纤通道设备提供传输服务。iFCP允许现有光纤通道设备通过IP网络以线速互连和联网。iFCP实现模拟结构服务，以便通过充分利用IP技术提高容错性和可伸缩性。每个TCP连接都用于支持一对唯一的光纤通道N_端口之间的存储通信。
iFCP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. iFCP uses TCP to provide congestion control, error detection and error recovery.
iFCP没有本机带内安全机制。相反，它依赖IPsec协议套件来提供数据机密性和身份验证服务，并依赖IKE作为密钥管理协议。iFCP使用TCP提供拥塞控制、错误检测和错误恢复。
FCIP, defined in [FCIP], is a pure FC encapsulation protocol that transports FC frames. Current specification work intends this for interconnection of Fibre Channel switches over TCP/IP networks, but the protocol is not inherently limited to connecting FC switches. FCIP differs from iFCP in that no interception or emulation of fabric services is involved. One or more TCP connections are bound to an FCIP Link, which is used to realize Inter-Switch Links (ISLs) between pairs of Fibre Channel entities. FCIP Frame Encapsulation is described in [RFC3643].
FCIP在[FCIP]中定义，是传输FC帧的纯FC封装协议。当前的规范工作旨在通过TCP/IP网络互连光纤通道交换机，但该协议并不局限于连接FC交换机。FCIP与iFCP的不同之处在于不涉及结构服务的拦截或模拟。一个或多个TCP连接绑定到FCIP链路，该链路用于实现光纤通道实体对之间的交换机间链路（ISL）。[RFC3643]中描述了FCIP帧封装。
FCIP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. FCIP uses TCP to provide congestion control, error detection and error recovery.
FCIP没有本机带内安全机制。相反，它依赖IPsec协议套件来提供数据机密性和身份验证服务，并依赖IKE作为密钥管理协议。FCIP使用TCP提供拥塞控制、错误检测和错误恢复。
IPsec is a protocol suite which is used to secure communication at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [RFC2401], IKE [RFC2409][RFC2412], IPsec Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic.
IPsec是一个协议套件，用于在网络层保护两个对等方之间的通信。IPsec协议套件在IP安全体系结构[RFC2401]、IKE[RFC2409][RFC2412]、IPsec身份验证头（AH）[RFC2402]和IPsec封装安全负载（ESP）[RFC2406]文档中指定。IKE是密钥管理协议，AH和ESP用于保护IP流量。
An IPsec SA is a one-way security association, uniquely identified by the 3-tuple: Security Parameter Index (SPI), protocol (ESP) and destination IP. The parameters for an IPsec security association are typically established by a key management protocol. These include the encapsulation mode, encapsulation type, session keys and SPI values.
IPsec SA是单向安全关联，由三元组唯一标识：安全参数索引（SPI）、协议（ESP）和目标IP。IPsec安全关联的参数通常由密钥管理协议建立。这些包括封装模式、封装类型、会话密钥和SPI值。
IKE is a two phase negotiation protocol based on the modular exchange of messages defined by ISAKMP [RFC2408],and the IP Security Domain of Interpretation (DOI) [RFC2407]. IKE has two phases, and accomplishes the following functions:
IKE是一种两阶段协商协议，基于ISAKMP[RFC2408]定义的消息模块交换和IP安全域解释（DOI）[RFC2407]。IKE分为两个阶段，完成以下功能：
[1] Protected cipher suite and options negotiation - using keyed MACs and encryption and anti-replay mechanisms
[1] 受保护的密码套件和选项协商-使用密钥MAC、加密和反重放机制
[2] Master key generation - such as via MODP Diffie-Hellman calculations
[2] 主密钥生成-例如通过MODP Diffie-Hellman计算
[3] Authentication of end-points
[3] 端点认证
[4] IPsec SA management (selector negotiation, options negotiation, create, delete, and rekeying)
[4] IPsec SA管理（选择器协商、选项协商、创建、删除和重新设置密钥）
Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is handled in IKE Phase 2.
项目1至3在IKE阶段1中完成，而项目4在IKE阶段2中处理。
An IKE Phase 2 negotiation is performed to establish both an inbound and an outbound IPsec SA. The traffic to be protected by an IPsec SA is determined by a selector which has been proposed by the IKE initiator and accepted by the IKE Responder. In IPsec transport mode, the IPsec SA selector can be a "filter" or traffic classifier, defined as the 5-tuple: <Source IP address, Destination IP address, transport protocol (UDP/SCTP/TCP), Source port, Destination port>. The successful establishment of a IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <Protocol (ESP/AH), destination address, SPI>.
执行IKE阶段2协商以建立入站和出站IPsec SA。IPsec SA要保护的流量由IKE发起方提出并由IKE响应方接受的选择器确定。在IPsec传输模式下，IPsec SA选择器可以是“过滤器”或流量分类器，定义为5元组：<源IP地址、目标IP地址、传输协议（UDP/SCTP/TCP）、源端口、目标端口>。IKE阶段2 SA的成功建立导致两个单向IPsec SA的创建，它们完全由tuple<协议（ESP/AH）、目标地址SPI>限定。
The session keys for each IPsec SA are derived from a master key, typically via a MODP Diffie-Hellman computation. Rekeying of an existing IPsec SA pair is accomplished by creating two new IPsec SAs, making them active, and then optionally deleting the older IPsec SA pair. Typically the new outbound SA is used immediately, and the old inbound SA is left active to receive packets for some locally defined time, perhaps 30 seconds or 1 minute.
每个IPsec SA的会话密钥通常通过MODP Diffie-Hellman计算从主密钥派生。通过创建两个新的IPsec SA，使其处于活动状态，然后选择性地删除旧的IPsec SA对，可以完成现有IPsec SA对的密钥更新。通常，新的出站SA会立即使用，而旧的入站SA会保持活动状态，以便在本地定义的时间内（可能是30秒或1分钟）接收数据包。
Fibre Channel Fibre Channel (FC) is a gigabit speed networking technology primarily used to implement Storage Area Networks (SANs), although it also may be used to transport other frames types as well, including IP. FC is standardized under American National Standard for Information Systems of the InterNational Committee for Informational Technology Standards (ANSI-INCITS) in its T11 technical committee.
光纤通道光纤通道（FC）是一种千兆速度的网络技术，主要用于实现存储区域网络（SAN），但也可用于传输其他类型的帧，包括IP。FC在其T11技术委员会中根据国际信息技术标准委员会（ANSI-INCITS）的美国信息系统国家标准进行标准化。
FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting Fibre Channel islands over IP Networks so as to form a unified SAN in a single Fibre Channel fabric. The principal FCIP interface point to the IP Network is the FCIP Entity. The FCIP Link represents one or more TCP connections that exist between a pair of FCIP Entities.
FCIP IP IP光纤通道（FCIP）是一种通过IP网络互连光纤通道孤岛的协议，以便在单个光纤通道结构中形成统一的SAN。IP网络的主要FCIP接口点是FCIP实体。FCIP链路表示一对FCIP实体之间存在的一个或多个TCP连接。
HBA Host Bus Adapter (HBA) is a generic term for a SCSI interface to other device(s); it's roughly analogous to the term Network Interface Card (NIC) for a TCP/IP network interface, except that HBAs generally have on-board SCSI implementations, whereas most NICs do not implement TCP, UDP, or IP.
HBA主机总线适配器（HBA）是指向其他设备的SCSI接口的通用术语；它大致类似于TCP/IP网络接口的术语网络接口卡（NIC），只是HBA通常具有板载SCSI实现，而大多数NIC不实现TCP、UDP或IP。
iFCP iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network.
iFCP iFCP是网关到网关协议，它通过TCP/IP网络向光纤通道设备提供光纤通道结构服务。
IP block storage protocol Where used within this document, the term "IP block storage protocol" applies to all block storage protocols running over IP, including iSCSI, iFCP and FCIP.
IP块存储协议在本文档中使用的术语“IP块存储协议”适用于通过IP运行的所有块存储协议，包括iSCSI、iFCP和FCIP。
iSCSI iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets).
iSCSI是一种客户端-服务器协议，在该协议中，客户端（启动器）打开到服务器（目标）的连接。
iSNS The Internet Storage Name Server (iSNS) protocol provides for discovery and management of iSCSI and Fibre Channel (FCP) storage devices. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, providing a consolidated information repository for an integrated IP block storage network. iFCP requires iSNS for discovery and management, while iSCSI may use iSNS for discovery, and FCIP does not use iSNS.
iSNS Internet存储名称服务器（iSNS）协议用于发现和管理iSCSI和光纤通道（FCP）存储设备。iSNS应用程序存储iSCSI和FC设备属性，并监控其可用性和可访问性，为集成IP块存储网络提供整合的信息存储库。iFCP需要iSNS进行发现和管理，而iSCSI可以使用iSNS进行发现，FCIP不使用iSNS。
initiator The iSCSI initiator connects to the target on well-known TCP port 3260. The iSCSI initiator then issues SCSI commands for execution by the iSCSI target.
启动器iSCSI启动器通过众所周知的TCP端口3260连接到目标。然后，iSCSI启动器发出SCSI命令供iSCSI目标执行。
target The iSCSI target listens on a well-known TCP port for incoming connections, and returns a status response for each command issued by the iSCSI initiator, over the same connection.
目标iSCSI目标在已知的TCP端口上侦听传入连接，并通过同一连接返回iSCSI启动器发出的每个命令的状态响应。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
本文件中的关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应”、“不应”、“应”和“不应”应按照[RFC2119]中的说明进行解释。
Note that requirements specified in this document apply only to use of IPsec and IKE with IP block storage protocols. Thus, these requirements do not apply to IPsec implementations in general. Implementation requirements language should therefore be assumed to relate to the availability of features for use with IP block storage security only.
请注意，本文档中规定的要求仅适用于IPsec和IKE与IP块存储协议的使用。因此，这些要求通常不适用于IPsec实现。因此，应假定实现要求语言与仅用于IP块存储安全的功能的可用性相关。
Although the security requirements in this document are already incorporated into the iSCSI [RFC3720], iFCP [iFCP] and FCIP [FCIP] standards track documents, they are reproduced here for convenience. In the event of a discrepancy, the individual protocol standards track documents take precedence.
尽管本文档中的安全要求已经包含在iSCSI[RFC3720]、iFCP[iFCP]和FCIP[FCIP]标准跟踪文档中，但为了方便起见，此处对其进行了复制。如果存在差异，则以各协议标准跟踪文件为准。
IP Block storage protocols such as iSCSI, iFCP and FCIP are used to transmit SCSI commands over IP networks. Therefore, both the control and data packets of these IP block storage protocols are vulnerable to attack. Examples of attacks include:
IP块存储协议（如iSCSI、iFCP和FCIP）用于通过IP网络传输SCSI命令。因此，这些IP块存储协议的控制和数据包都容易受到攻击。攻击的例子包括：
[1] An adversary may attempt to acquire confidential data and identities by snooping data packets.
[1] 对手可能试图通过窥探数据包获取机密数据和身份。
[2] An adversary may attempt to modify packets containing data and control messages.
[2] 对手可能试图修改包含数据和控制消息的数据包。
[3] An adversary may attempt to inject packets into an IP block storage connection.
[3] 对手可能试图将数据包注入IP块存储连接。
[4] An adversary may attempt to hijack TCP connection(s) corresponding to an IP block storage session.
[4] 对手可能试图劫持与IP块存储会话对应的TCP连接。
[5] An adversary may launch denial of service attacks against IP block storage devices such as by sending a TCP reset.
[5] 对手可能会对IP块存储设备发起拒绝服务攻击，例如发送TCP重置。
[6] An adversary may attempt to disrupt security negotiation process, in order to weaken the authentication, or gain access to user passwords. This includes disruption of application-layer authentication negotiations such as iSCSI Login.
[6] 对手可能试图中断安全协商过程，以削弱身份验证或获取用户密码的访问权限。这包括中断应用层身份验证协商，如iSCSI登录。
[7] An adversary may attempt to impersonate a legitimate IP block storage entity.
[7] 对手可能试图模拟合法的IP块存储实体。
[8] An adversary may launch a variety of attacks (packet modification or injection, denial of service) against the discovery (SLPv2 [RFC2608]) or discovery and management (iSNS [iSNS]) process. iSCSI can use SLPv2 or iSNS. FCIP only uses SLPv2, and iFCP only uses iSNS.
[8] 对手可能对发现（SLPv2[RFC2608]）或发现和管理（iSNS[iSNS]）进程发起各种攻击（数据包修改或注入、拒绝服务）。iSCSI可以使用SLPv2或iSNS。FCIP仅使用SLPv2，而iFCP仅使用iSNS。
Since iFCP and FCIP devices are the last line of defense for a whole Fibre Channel island, the above attacks, if successful, could compromise the security of all the Fibre Channel hosts behind the devices.
由于iFCP和FCIP设备是整个光纤通道岛的最后一道防线，因此上述攻击如果成功，可能会危及设备后面所有光纤通道主机的安全。
To address the above threats, IP block storage security protocols must support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis. Confidentiality services are important since IP block storage traffic may traverse insecure public networks. The IP block storage security protocols must support perfect forward secrecy in the rekeying process.
为了解决上述威胁，IP块存储安全协议必须支持每个数据包的机密性、数据源身份验证、完整性和重播保护。保密服务很重要，因为IP块存储流量可能会穿越不安全的公共网络。IP块存储安全协议必须在密钥更新过程中支持完美的前向保密性。
Bi-directional authentication of the communication endpoints MUST be provided. There is no requirement that the identities used in authentication be kept confidential (e.g., from a passive eavesdropper).
必须提供通信端点的双向身份验证。认证中使用的身份无需保密（例如，来自被动窃听者）。
For a security protocol to be useful, CPU overhead and hardware availability must not preclude implementation at 1 Gbps today. Implementation feasibility at 10 Gbps is highly desirable, but may not be demonstrable at this time. These performance levels apply to aggregate throughput, and include all TCP connections used between IP block storage endpoints. IP block storage communications typically involve multiple TCP connections. Performance issues are discussed further in Appendix B.
为了使安全协议发挥作用，CPU开销和硬件可用性不应妨碍目前1 Gbps的实现。10 Gbps的实施可行性非常理想，但目前可能无法证明。这些性能级别适用于聚合吞吐量，并包括IP块存储端点之间使用的所有TCP连接。IP块存储通信通常涉及多个TCP连接。附录B进一步讨论了性能问题。
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from possible security threats. Such networks are often protected by security gateways, which at a minimum provide a shield against denial of service attacks. The IP block storage security architecture should be able to leverage the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and VPN services available on existing security gateways.
企业数据中心网络被视为任务关键型设施，必须隔离并保护其免受可能的安全威胁。这类网络通常由安全网关保护，安全网关至少提供了抵御拒绝服务攻击的屏障。IP块存储安全体系结构应该能够利用现有安全基础架构的保护服务，包括防火墙保护、NAT和NAPT服务，以及现有安全网关上可用的VPN服务。
When iFCP or FCIP devices are deployed within enterprise networks, IP addresses will be typically be statically assigned as is the case with most routers and switches. Consequently, support for dynamic IP address assignment, as described in [RFC3456], will typically not be required, although it cannot be ruled out. Such facilities will also be relevant to iSCSI hosts whose addresses are dynamically assigned. As a result, the IP block storage security protocols must not introduce additional security vulnerabilities where dynamic address assignment is supported.
当iFCP或FCIP设备部署在企业网络中时，IP地址通常会静态分配，就像大多数路由器和交换机一样。因此，通常不需要支持[RFC3456]中所述的动态IP地址分配，尽管不能排除这种可能性。此类设施还将与动态分配地址的iSCSI主机相关。因此，在支持动态地址分配的情况下，IP块存储安全协议不得引入额外的安全漏洞。
While IP block storage security is mandatory to implement, it is not mandatory to use. The security services used depend on the configuration and security policies put in place. For example, configuration will influence the authentication algorithm negotiated within iSCSI Login, as well as the security services (confidentiality, data origin authentication, integrity, replay protection) and transforms negotiated when IPsec is used to protect IP block storage protocols such as iSCSI, iFCP and FCIP.
虽然必须实施IP块存储安全性，但并非必须使用。所使用的安全服务取决于设置的配置和安全策略。例如，配置将影响iSCSI登录中协商的身份验证算法，以及使用IPsec保护IP块存储协议（如iSCSI、iFCP和FCIP）时协商的安全服务（机密性、数据源身份验证、完整性、重播保护）和转换。
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. For iFCP, the granularity corresponds to an iFCP Portal. For iSCSI, the granularity of control is typically that of an iSCSI session, although it is possible to exert control down to the granularity of the destination IP address and TCP port.
FCIP实现可能允许在FCIP链路的粒度上启用和禁用安全机制。对于iFCP，粒度对应于一个iFCP门户。对于iSCSI，控制的粒度通常是iSCSI会话的粒度，但也可以控制目标IP地址和TCP端口的粒度。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that IP block storage connections requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA.
请注意，对于IPsec，安全服务是在IPsec SA的粒度上协商的，因此需要一组不同于与现有IPsec SA协商的安全服务的IP块存储连接将需要协商一个新的IPsec SA。
Separate IPsec SAs are also advisable where quality of service considerations dictate different handling of IP block storage connections. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
如果服务质量考虑因素要求对IP块存储连接进行不同的处理，也建议使用单独的IPsec SA。试图对同一IPsec SA处理的连接应用不同的服务质量可能会导致重新排序，并超出重播窗口。有关这些问题的讨论，请参见[RFC2983]。
IP block storage protocols can be expected to carry sensitive data and provide access to systems and data that require protection against security threats. SCSI and Fibre Channel currently contain little in the way of security mechanisms, and rely on physical security, administrative security, and correct configuration of the communication medium and systems/devices attached to it for their security properties.
IP块存储协议可以承载敏感数据，并提供对需要安全威胁保护的系统和数据的访问。SCSI和光纤通道目前几乎不包含安全机制，并且依靠物理安全性、管理安全性以及通信介质和连接到其上的系统/设备的正确配置来实现其安全属性。
For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used by IP block storage protocols (e.g., iSCSI SHOULD use one of its in-band authentication mechanisms or the authentication provided by IKE) in order to provide a minimal assurance that connections have initially been opened with the intended counterpart.
对于大多数IP网络，假设网络和所有连接节点的物理安全性、管理安全性和正确配置是不合适的（测试实验室中的物理隔离网络可能是例外）。因此，IP块存储协议应使用身份验证（例如，iSCSI应使用其带内身份验证机制之一或IKE提供的身份验证），以提供连接最初已与预期对等方打开的最低保证。
iSNS, described in [iSNS], is required in all iFCP deployments. iSCSI may use iSNS for discovery, and FCIP does not use iSNS. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, providing a consolidated information repository for an integrated IP block storage network. The iSNS specification defines mechanisms to secure communication between an iSNS server and its clients.
[iSNS]中描述的iSNS在所有iFCP部署中都是必需的。iSCSI可以使用iSNS进行查找，而FCIP不使用iSNS。iSNS应用程序存储iSCSI和FC设备属性，并监控其可用性和可访问性，为集成IP块存储网络提供整合的信息存储库。iSNS规范定义了iSNS服务器及其客户端之间安全通信的机制。
Resource constraints and performance requirements for iSCSI are discussed in [RFC3347] Section 3.2. iFCP and FCIP devices will typically be embedded systems deployed on racks in air-conditioned data center facilities. Such embedded systems may include hardware chipsets to provide data encryption, authentication, and integrity processing. Therefore, memory and CPU resources are generally not a constraining factor.
[RFC3347]第3.2节讨论了iSCSI的资源约束和性能要求。iFCP和FCIP设备通常是部署在空调数据中心设施机架上的嵌入式系统。此类嵌入式系统可包括硬件芯片组，以提供数据加密、认证和完整性处理。因此，内存和CPU资源通常不是限制因素。
iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). In general, a host bus adapter is the most constrained iSCSI implementation environment, although an HBA may draw upon the resources of the system to which it is attached in some cases (e.g., authentication computations required for connection
iSCSI将在各种系统上实施，从运行通用操作系统的大型服务器到嵌入式主机总线适配器（HBA）。通常，主机总线适配器是最受约束的iSCSI实施环境，尽管在某些情况下HBA可能会利用其所连接的系统的资源（例如，连接所需的身份验证计算）
setup). More resources should be available to iSCSI implementations for embedded and general purpose operating systems. The following guidelines indicate the approximate level of resources that authentication, keying, and rekeying functionality can reasonably expect to draw upon:
设置）。应为用于嵌入式和通用操作系统的iSCSI实施提供更多资源。以下指南指出了身份验证、密钥设置和重新密钥设置功能可以合理利用的大致资源级别：
- Low power processors with small word size are generally not used, as power is usually not a constraining factor, with the possible exception of HBAs, which can draw upon the computational resources of the system into which they are inserted. Computational horsepower should be available to perform a reasonable amount of exponentiation as part of authentication and key derivation for connection setup. The same is true of rekeying, although the ability to avoid exponentiation for rekeying may be desirable (but is not an absolute requirement).
- 通常不使用字大小较小的低功耗处理器，因为功耗通常不是限制因素，HBA可能例外，它可以利用插入它们的系统的计算资源。作为连接设置的身份验证和密钥推导的一部分，计算马力应可用于执行合理数量的求幂运算。同样的情况也适用于重新设置密钥，尽管避免为重新设置密钥而求幂的能力可能是可取的（但不是绝对要求）。
- RAM and/or flash resources tend to be constrained in embedded implementations. 8-10 MB of code and data for authentication, keying, and rekeying is clearly excessive, 800-1000 KB is clearly larger than desirable, but tolerable if there is no other alternative and 80-100 KB should be acceptable. These sizes are intended as rough order of magnitude guidance, and should not be taken as hard targets or limits (e.g., smaller code sizes are always better). Software implementations for general purpose operating systems may have more leeway.
- 在嵌入式实现中，RAM和/或闪存资源往往受到限制。8-10 MB用于身份验证、键入和重新键入的代码和数据显然过多，800-1000 KB明显大于预期值，但如果没有其他替代方案，则可以接受，80-100 KB应该是可接受的。这些大小旨在作为粗略的数量级指导，不应被视为硬目标或限制（例如，代码大小越小越好）。通用操作系统的软件实现可能有更多的回旋余地。
The primary resource concern for implementation of authentication and keying mechanisms is code size, as iSCSI assumes that the computational horsepower to do exponentiations will be available.
实现身份验证和键控机制的主要资源问题是代码大小，因为iSCSI假定可以使用计算马力进行幂运算。
There is no dominant iSCSI usage scenario - the scenarios range from a single connection constrained only by media bandwidth to hundreds of initiator connections to a single target or communication endpoint. SCSI sessions and hence the connections they use tend to be relatively long lived; for disk storage, a host typically opens a SCSI connection on boot and closes it on shutdown. Tape session length tends to be measured in hours or fractions thereof (i.e., rapid fire sharing of the same tape device among different initiators is unusual), although tape robot control sessions can be short when the robot is shared among tape drives. On the other hand, tape will not see a large number of initiator connections to a single target or communication endpoint, as each tape drive is dedicated to a single use at a single time, and a dozen tape drives is a large tape device.
没有占主导地位的iSCSI使用场景—场景范围从仅受媒体带宽限制的单个连接到数百个到单个目标或通信端点的启动器连接。SCSI会话以及它们使用的连接往往相对较长；对于磁盘存储，主机通常在引导时打开SCSI连接，在关机时关闭。磁带会话长度往往以小时或小时的分数来衡量（即，在不同的启动器之间快速共享同一磁带设备是不寻常的），尽管在磁带驱动器之间共享机器人时，磁带机器人控制会话可能会很短。另一方面，磁带不会看到到单个目标或通信端点的大量启动器连接，因为每个磁带机在同一时间专用于一次使用，而十几个磁带机是一个大型磁带设备。
All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets, as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used.
所有符合IP块存储安全性要求的实现必须支持IPsec ESP[RFC2406]，以便为控制数据包和数据包以及IPsec的重播保护机制提供安全性。当使用ESP时，必须使用每包数据源身份验证、完整性和重播保护。
To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. ESP with NULL encryption MUST be supported for authentication.
为了向ESP提供机密性，必须支持CBC模式[RFC2451][3DESANSI]下带3DES的ESP，并且应支持[RFC3686]中所述的计数器模式下的AES。为了通过ESP提供数据源身份验证和完整性，必须支持HMAC-SHA1[RFC2404]，并且应支持CBC MAC模式下的AES和XCBC扩展[RFC3566]。CBC模式下的DES由于其固有的弱点不应使用。身份验证必须支持使用空加密的ESP。
Conformant IP block storage protocol implementations MUST support ESP [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport mode.
一致性IP块存储协议实现必须在隧道模式下支持ESP[RFC2406]，并且可以在传输模式下通过ESP实现IPsec。
Conformant IP block storage security implementations MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used since it does not provide the necessary rekeying support. Conformant IP block storage security implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used.
一致的IP块存储安全实现必须支持IKE[RFC2409]，以便使用IPsec DOI[RFC2407]进行对等身份验证、安全关联协商和密钥管理。不得使用手动键控，因为它不提供必要的重新键控支持。一致性IP块存储安全实现必须支持使用预共享密钥的对等身份验证，并且可能支持使用数字签名的基于证书的对等身份验证。不应使用IKE第5.2节和第5.3节[RFC2409]中概述的使用公钥加密方法的对等身份验证。
Conformant IP block storage security implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use a dynamically assigned IP address. While Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force use of a group pre-shared key, which is vulnerable to man-in-the-middle attack.
一致的IP块存储安全实现必须支持IKE主模式，并且应该支持攻击模式。当任一对等方使用动态分配的IP地址时，不应使用带有预共享密钥身份验证的IKE主模式。虽然带有预共享密钥身份验证的主模式在许多情况下提供了良好的安全性，但在使用动态分配地址的情况下，强制使用组预共享密钥，这很容易受到中间人攻击。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) must be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
当数字签名用于身份验证时，可以使用IKE主模式或IKE攻击模式。在所有情况下，必须适当限制对本地存储的机密信息（预共享密钥或用于数字签名的私钥）的访问，因为机密信息的泄露会使IKE/IPsec协议的安全属性无效。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
当使用数字签名实现身份验证时，IKE谈判者应使用IKE证书请求有效载荷来指定根据其本地策略受信任的证书颁发机构。IKE谈判者在接受用于IKE认证过程的PKI证书之前，应检查相关的证书撤销列表（CRL）。
The IPsec DOI [RFC2407] provides for several types of identification data. Within IKE Phase 1, for use within the IDii and IDir payloads, conformant IP block storage security implementations MUST support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN Identity Payloads. iSCSI security implementations SHOULD support the ID_USER_FQDN Identity Payload; other IP block storage protocols (iFCP, FCIP) SHOULD NOT use the ID_USER_FQDN Identity Payload. Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be used for IP block storage protocol security; The ID_KEY_ID Identity Payload MUST NOT be used. As described in [RFC2407], within Phase 1 the ID port and protocol fields MUST be set to zero or to UDP port 500. Also, as noted in [RFC2407]:
IPsec DOI[RFC2407]提供了几种类型的标识数据。在IKE阶段1中，为了在IDii和IDir有效载荷中使用，一致的IP块存储安全实现必须支持ID_IPV4_ADDR、ID_IPV6_ADDR（如果协议栈支持IPV6）和ID_FQDN标识有效载荷。iSCSI安全实施应支持ID_USER_FQDN标识负载；其他IP块存储协议（iFCP、FCIP）不应使用ID\U USER\U FQDN标识负载。在使用主动模式以及预共享密钥和动态分配IP地址的情况下，应使用ID_IPV4_ADDR和ID_IPV6_ADDR以外的身份（如ID_FQDN或ID_USER_FQDN）。IP子网、IP地址范围、ID_DER_ASN1_DN、ID_DER_ASN1_GN格式不应用于IP块存储协议安全；不得使用ID\u密钥\u ID标识有效负载。如[RFC2407]所述，在阶段1内，ID端口和协议字段必须设置为零或UDP端口500。此外，如[RFC2407]所述：
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 Phase 2 Quick Mode exchanges used by IP block storage protocol implementations MUST explicitly carry the Identity Payload fields (IDci and IDcr). Each Phase 2 IDci and IDcr Payload SHOULD carry a single IP address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the IP Subnet or IP Address Range formats. Other ID payload formats MUST NOT be used.
IP块存储协议实现所使用的第2阶段快速模式交换必须显式地携带标识有效负载字段（IDci和IDcr）。每个阶段2 IDci和IDcr有效负载应携带单个IP地址（ID_IPV4_ADDR、ID_IPV6_ADDR），并且不应使用IP子网或IP地址范围格式。不得使用其他ID有效负载格式。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down an IP
由于IPsec加速硬件可能只能处理有限数量的活动IKE阶段2 SA，因此可以为空闲SA发送阶段2删除消息，以将活动阶段2 SA的数量保持在最小。收到IKE第2阶段删除消息不能被解释为中断IP的原因
block storage connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down.
阻止存储连接。相反，最好保持连接处于打开状态，如果在连接上发送了额外的通信量，则启动另一个IKE阶段2 SA以保护它。这样就避免了不断地使连接上下移动的可能性。
One of the goals of this specification is to enable a high level of interoperability without requiring extensive configuration. This section provides guidelines on setting of IKE parameters so as to enhance the probability of a successful negotiation. It also describes how information on security policy configuration can be provided so as to further enhance the chances of success.
本规范的目标之一是在不需要大量配置的情况下实现高级别的互操作性。本节提供关于设置IKE参数的指南，以提高协商成功的概率。它还描述了如何提供有关安全策略配置的信息，以进一步提高成功的机会。
To enhance the prospects for interoperability, some of the actions to consider include:
为了提高互操作性的前景，一些需要考虑的行动包括：
[1] Transform restriction. Since support for 3DES-CBC and HMAC-SHA1 is required of all implementations, offering these transforms enhances the probability of a successful negotiation. If AES-CTR [RFC3686] with XCBC-MAC [RFC3566] is supported, this transform combination will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a secondary offer.
[1] 变换限制。由于所有实现都需要对3DES-CBC和HMAC-SHA1的支持，因此提供这些转换可提高协商成功的概率。如果支持AES-CTR[RFC3686]和XCBC-MAC[RFC3566]，则通常会首选此转换组合，并将3DES-CBC/HMAC-SHA1作为辅助选项。
[2] Group Restriction. If 3DES-CBC/HMAC-SHA1 is offered, and DH groups are offered, then it is recommended that a DH group of at least 1024 bits be offered along with it. If AES-CTR/XCBC-MAC is the preferred offer, and DH groups are offered, then it is recommended that a DH group of at least 2048 bits be offered along with it, as noted in [KeyLen]. If perfect forward secrecy is required in Quick Mode, then it is recommended that the QM PFS DH group be the same as the IKE Phase 1 DH group. This reduces the total number of combinations, enhancing the chances for interoperability.
[2] 团体限制。如果提供了3DES-CBC/HMAC-SHA1，并且提供了DH组，则建议提供至少1024位的DH组。如果AES-CTR/XCBC-MAC是首选方案，并且提供了DH组，则建议至少提供2048位的DH组，如[KeyLen]中所述。如果在快速模式下需要完全前向保密，则建议QM PFS DH组与IKE第1阶段DH组相同。这减少了组合的总数，提高了互操作性的机会。
[3] Key lifetimes. If a key lifetime is offered that is longer than desired, then rather than causing the IKE negotiation to fail, it is recommended that the Responder consider the offered lifetime as a maximum, and accept it. The key can then use a lesser value for the lifetime, and utilize a Lifetime Notify in order to inform the other peer of lifetime expiration.
[3] 关键生命周期。如果提供的密钥生存期比期望的长，那么，与其使IKE协商失败，不如建议响应者将提供的生命期视为最大值，并接受它。然后，密钥可以在生存期内使用较小的值，并利用生存期通知来通知另一个对等方生存期到期。
Even when the above advice is taken, it still may be useful to be able to provide additional configuration information in order to enhance the chances of success, and it is useful to be able to manage security configuration regardless of the scale of the deployment.
即使采纳了上述建议，能够提供额外的配置信息以提高成功的机会仍然是有用的，并且无论部署规模如何，能够管理安全配置也是有用的。
For example, it may be desirable to configure the security policy of an IP block storage device. This can be done manually or automatically via a security policy distribution mechanism. Alternatively, it can be supplied via iSNS or SLPv2. If an IP block storage endpoint can obtain the required security policy by other means (manually, or automatically via a security policy distribution mechanism) then it need not request this information via iSNS or SLPv2. However, if the required security policy configuration is not available via other mechanisms, iSNS or SLPv2 can be used to obtain it.
例如，可能希望配置IP块存储设备的安全策略。这可以通过安全策略分发机制手动或自动完成。或者，它可以通过iSNS或SLPv2提供。如果IP块存储端点可以通过其他方式（手动或通过安全策略分发机制自动）获得所需的安全策略，则无需通过iSNS或SLPv2请求此信息。但是，如果所需的安全策略配置无法通过其他机制获得，则可以使用iSNS或SLPv2来获得它。
It may also be helpful to obtain information about the preferences of the peer prior to initiating IKE. While it is generally possible to negotiate security parameters within IKE, there are situations in which incompatible parameters can cause the IKE negotiation to fail. The following information can be provided via SLPv2 or iSNS:
在发起IKE之前获取关于对等方的偏好的信息也可能有帮助。虽然通常可以在IKE内协商安全参数，但在某些情况下，不兼容的参数会导致IKE协商失败。以下信息可通过SLPv2或iSNS提供：
[4] IPsec or cleartext support. The minimum piece of peer configuration required is whether an IP block storage endpoint requires IPsec or cleartext. This cannot be determined from the IKE negotiation alone without risking a long timeout, which is highly undesirable for a disk access protocol.
[4] IPsec或明文支持。所需的最小对等配置是IP块存储端点是否需要IPsec或cleartext。这不能仅通过IKE协商来确定，而不冒长超时的风险，这对于磁盘访问协议来说是非常不可取的。
[5] Perfect Forward Secrecy (PFS) support. It is helpful to know whether a peer allows PFS, since an IKE Phase 2 Quick Mode can fail if an initiator proposes PFS to a Responder that does not allow it.
[5] 完美的前向保密（PFS）支持。了解对等方是否允许PFS是很有帮助的，因为如果发起方向不允许PFS的响应方建议PFS，IKE第2阶段快速模式可能会失败。
[6] Preference for tunnel mode. While it is legal to propose both transport and tunnel mode within the same offer, not all IKE implementations will support this. As a result, it is useful to know whether a peer prefers tunnel mode or transport mode, so that it is possible to negotiate the preferred mode on the first try.
[6] 首选隧道模式。虽然在同一提议中同时提出传输和隧道模式是合法的，但并非所有IKE实现都支持这一点。因此，了解对等方是喜欢隧道模式还是传输模式很有用，这样就可以在第一次尝试时协商首选模式。
[7] Main Mode and Aggressive Mode support. Since the IKE negotiation can fail if a mode is proposed to a peer that doesn't allow it, it is helpful to know which modes a peer allows, so that an allowed mode can be negotiated on the first try.
[7] 主模式和主动模式支持。由于如果向不允许的对等方提出模式，IKE协商可能会失败，因此了解对等方允许的模式很有帮助，以便在第一次尝试时可以协商允许的模式。
Since iSNS or SLPv2 can be used to distribute IPsec security policy and configuration information for use with IP block storage protocols, these discovery protocols would constitute a 'weak link' were they not secured at least as well as the protocols whose security they configure. Since the major vulnerability is packet modification and replay, when iSNS or SLPv2 are used to distribute security policy or configuration information, at a minimum, per-packet data origin authentication, integrity and replay protection MUST be used to protect the discovery protocol.
由于iSNS或SLPv2可用于分发IPsec安全策略和配置信息，以便与IP块存储协议一起使用，因此这些发现协议将构成一个“薄弱环节”，前提是它们至少与它们配置的安全协议一样不安全。由于主要漏洞是数据包修改和重播，因此当使用iSNS或SLPv2分发安全策略或配置信息时，必须至少使用每数据包数据源身份验证、完整性和重播保护来保护发现协议。
Compliant iSCSI implementations MUST implement the CHAP authentication method [RFC1994] (according to [RFC3720], section 11.1.4), which includes support for bi-directional authentication, and the target authentication option.
符合要求的iSCSI实施必须实施CHAP身份验证方法[RFC1994]（根据[RFC3720]，第11.1.4节），其中包括支持双向身份验证和目标身份验证选项。
When CHAP is performed over non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support random CHAP secrets of up to 128 bits, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation.
在非加密通道上执行CHAP时，容易受到离线字典攻击。实现必须支持高达128位的随机CHAP机密，包括生成此类机密并从外部生成源接受这些机密的方法。除随机生成外，实现不得提供秘密生成（或扩展）方法。
If CHAP is used with secret smaller than 96 bits, then IPsec encryption (according to the implementation requirements in [RFC3720] section 8.3.2) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used. When CHAP is used with a secret smaller then 96 bits, a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used to protect the connection.
如果CHAP用于小于96位的机密，则必须使用IPsec加密（根据[RFC3720]第8.3.2节中的实施要求）来保护连接。此外，在这种情况下，不应使用带有组预共享密钥的IKE身份验证。当CHAP与小于96位的密钥一起使用时，除非兼容的实现可以验证IPsec加密正在用于保护连接，否则不能继续使用iSCSI登录。
Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs.
发起人不得将响应者发送的CHAP质询重新用于双向身份验证的另一个方向。响应者必须检查是否存在这种情况，如果出现这种情况，请关闭iSCSI TCP连接。
The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them. It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected. A single CHAP secret MAY be used for authentication of an individual
不应为多个启动器或多个目标的身份验证配置相同的CHAP机密，因为这使任何启动器或目标都能够模拟其中任何一个，而泄露其中一个启动器或目标则使攻击者能够模拟其中任何一个启动器或目标。建议iSCSI实施在检查可行时检查不同对等方是否使用相同的CHAP机密，并在检测到此情况时采取适当措施警告用户和/或管理员。单个CHAP密码可用于个人身份验证
initiator to multiple targets. Likewise, a single CHAP secret MAY be used for authentication of an individual target to multiple initiators.
将启动器连接到多个目标。类似地，单个CHAP密钥可用于向多个启动器验证单个目标。
A Responder MUST NOT send its CHAP response if the initiator has not successfully authenticated. For example, the following exchange:
如果启动器未成功进行身份验证，则响应程序不得发送其CHAP响应。例如，以下交易所：
I->R CHAP_A=<A1,A2,...>
R->I CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
I->R CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>
I->R CHAP_A=<A1,A2,...>
R->I CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
I->R CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>
(Where N, (A1,A2), I, C, and R are correspondingly the Name, Algorithms, Identifier, Challenge, and Response as defined in [RFC1994])
（其中N，（A1，A2），I，C和R对应于[RFC1994]中定义的名称、算法、标识符、质询和响应）
MUST result in the Responder (target) closing the iSCSI TCP connection because the initiator has failed to authenticate (there is no CHAP_R in the third message).
必须导致响应程序（目标）关闭iSCSI TCP连接，因为启动器身份验证失败（第三条消息中没有CHAP）。
Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator. If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions). Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles. The following is an example of the attacks prevented by the above requirements:
不得将用于启动器身份验证的任何CHAP机密配置为任何目标的身份验证，也不得将用于目标身份验证的任何CHAP机密配置为任何启动器的身份验证。如果iSCSI连接的一端接收到的CHAP响应与接收端点为同一CHAP质询生成的CHAP响应相同，则该响应必须视为身份验证失败并导致连接关闭（这可确保同一CHAP机密不会在两个方向上用于身份验证）。此外，如果iSCSI实现可以同时作为启动器和目标，则必须为这两个角色配置不同的CHAP机密和身份。以下是通过上述要求防止的攻击示例：
Rogue wants to impersonate Storage to Alice, and knows that a single secret is used for both directions of Storage-Alice authentication.
Rogue想向Alice模拟存储，并且知道存储Alice身份验证的两个方向都使用一个秘密。
Rogue convinces Alice to open two connections to Rogue, and Rogue identifies itself as Storage on both connections.
Rogue说服Alice打开到Rogue的两个连接，Rogue将自己标识为两个连接上的存储器。
Rogue issues a CHAP challenge on connection 1, waits for Alice to respond, and then reflects Alice's challenge as the initial challenge to Alice on connection 2.
Rogue在连接1上发出CHAP质询，等待Alice响应，然后将Alice的质询反映为连接2上对Alice的初始质询。
If Alice doesn't check for the reflection across connections, Alice's response on connection 2 enables Rogue to impersonate Storage on connection 1, even though Rogue does not know the Alice-Storage CHAP secret.
如果Alice没有检查连接之间的反射，Alice对连接2的响应将使Rogue能够模拟连接1上的存储，即使Rogue不知道Alice存储CHAP秘密。
Note that RADIUS [RFC2865] does not support bi-directional CHAP authentication. Therefore, while a target acting as a RADIUS client will be able to verify the initiator Response, it will not be able to respond to an initiator challenge unless it has access to an appropriate shared secret by some other means.
请注意，RADIUS[RFC2865]不支持双向CHAP身份验证。因此，尽管充当RADIUS客户端的目标将能够验证启动器响应，但它将无法响应启动器质询，除非它能够通过其他方式访问适当的共享机密。
iSCSI implementations MAY implement the SRP authentication method [RFC2945] (see [RFC3720], Section 11.1.3). The strength of SRP security is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) the generator g is a primitive root of GF(n) [SRPNDSS].
iSCSI实施可实施SRP身份验证方法[RFC2945]（请参阅[RFC3720]，第11.1.3节）。SRP安全性的强度取决于所用组的特征（即基本模量N和生成器g）。如[RFC2945]所述，N必须是Sophie-German素数（形式为N=2q+1，其中q也是素数）。生成器g是GF（N）[SRPNDSS]的本原根。
SRP well-known groups are included in Appendix A and additional groups may be registered with IANA. iSCSI implementations MUST use one of these well-known groups. All the groups specified in Appendix A up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.
SRP知名团体见附录A，其他团体可向IANA注册。iSCSI实施必须使用这些众所周知的组之一。附录A中规定的所有组（最多1536位）（即SRP-768、SRP-1024、SRP-1280、SRP-1536）必须由启动器和目标支持。为保证互操作性，目标公司必须始终将“SRP-1536”作为提议的小组之一。
Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer entities and management servers. SLPv2 may also be used to provide information on peer security configuration. When SLPv2 is deployed, the SA advertisements as well as UA requests and/or responses are subject to the following security threats:
iSCSI和FCIP协议都使用SLPv2作为发现对等实体和管理服务器的方法。SLPv2还可用于提供关于对等安全配置的信息。部署SLPv2时，SA播发以及UA请求和/或响应会受到以下安全威胁：
[1] An attacker could insert or alter SA advertisements or a response to a UA request in order to masquerade as the real peer or launch a denial of service attack.
[1] 攻击者可以插入或更改SA广告或对UA请求的响应，以伪装为真实对等方或发起拒绝服务攻击。
[2] An attacker could gain knowledge about an SA or a UA through snooping, and launch an attack against the peer. Given the potential value of iSCSI targets and FCIP entities, leaking of such information not only increases the possibility of an attack over the network; there is also the risk of physical theft.
[2] 攻击者可以通过窥探获得有关SA或UA的信息，并对对等方发起攻击。鉴于iSCSI目标和FCIP实体的潜在价值，此类信息泄漏不仅增加了通过网络进行攻击的可能性；此外，还有实物盗窃的风险。
[3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to use a rogue DAs.
[3] 攻击者可以欺骗一个广告。这可能导致UAs和SAs使用恶意DAs。
To address these threats, the following capabilities are required:
为了应对这些威胁，需要具备以下能力：
[a] Service information, as included in SrvRply, AttrRply, SrvReg and SrvDereg messages, needs to be kept confidential.
[a] SrvRply、ATTRPLY、SrvReg和SrvDereg消息中包含的服务信息需要保密。
[b] The UA has to be able to distinguish between legitimate and illegitimate service information from SrvRply and AttrRply messages. In the SLPv2 security model SAs are trusted to sign data.
[b] UA必须能够从SrvRply和ATTRPLY消息中区分合法和非法的服务信息。在SLPv2安全模型中，信任SA对数据进行签名。
[c] The DA has to be able to distinguish between legitimate and illegitimate SrvReg and SrvDereg messages.
[c] DA必须能够区分合法和非法的SrvReg和SrvDereg消息。
[d] The UA has to be able to distinguish between legitimate and illegitimate DA Advertisements. This allows the UA to avoid rogue DAs that will return incorrect data or no data at all. In the SLPv2 security model, UAs trust DAs to store, answer queries on and forward data on services, but not necessarily to originate it.
[d] UA必须能够区分合法和非法DA广告。这允许UA避免流氓DAs返回错误数据或根本没有数据。在SLPv2安全模型中，UAs信任DAs存储、回答查询和转发服务上的数据，但不一定要发起数据。
[e] SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2 is used. In this case, SAs register with only one DA and trust that this DA will forward the registration to others.
[e] SAs可能必须信任DAs，尤其是在使用“网状增强”SLPv2的情况下。在这种情况下，SAs只向一个DA注册，并相信该DA会将注册转发给其他DA。
By itself, SLPv2 security, defined in [RFC2608], does not satisfy these security requirements. SLPv2 only provides end-to-end authentication, but does not support confidentiality. In SLPv2 authentication there is no way to authenticate "zero result responses". This enables an attacker to mount a denial of service attack by sending UAs a "zero results" SrvRply or AttrRply as if from a DA with whose source address corresponds to a legitimate DAAdvert.
[RFC2608]中定义的SLPv2安全性本身并不满足这些安全要求。SLPv2仅提供端到端身份验证，但不支持机密性。在SLPv2身份验证中，无法对“零结果响应”进行身份验证。这使得攻击者能够通过向UAs发送“零结果”SrvRply或ATTRPLY，就像从源地址对应于合法DAAD的DA发送一样，发起拒绝服务攻击。
In all cases, there is a potential for denial of service attack against protocol service providers, but such an attack is possible even in the absence of SLPv2 based discovery mechanisms.
在所有情况下，都有可能对协议服务提供商进行拒绝服务攻击，但即使在缺乏基于SLPv2的发现机制的情况下，也可能发生这种攻击。
SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 requires that User Agents (UAs) and Service Agents (SAs) support SrvRqst, SrvRply, and DAAdvert. SAs must additionally support SrvReg, SrvAck, and SAAdvert.
SLPv2消息类型包括：SrvRqst、SrvRply、SrvReg、SrvDereg、SrvAck、ATTRQST、ATTRPLY、DAAD、SrvTypeRqst、SrvTypeRply、SAAdvert。SLPv2要求用户代理（UAs）和服务代理（SA）支持SrvRqst、SrvRply和DAAD。SAs还必须支持SrvReg、SrvAck和SAAdvert。
Where no Directory Agent (DA) exists, the SrvRqst is multicast, but the SrvRply is sent via unicast UDP. DAAdverts are also multicast. However, all other SLPv2 messages are sent via UDP unicast.
在不存在目录代理（DA）的情况下，SrvRqst是多播的，但SrvRply是通过单播UDP发送的。DAAD也是多播的。但是，所有其他SLPv2消息都是通过UDP单播发送的。
In order to provide the required security functionality, iSCSI and FCIP implementations supporting SLPv2 security SHOULD protect SLPv2 messages sent via unicast using IPsec ESP with a non-null transform. SLPv2 authentication blocks (carrying digital signatures), described in [RFC2608] MAY also be used to authenticate unicast and multicast messages.
为了提供所需的安全功能，支持SLPv2安全性的iSCSI和FCIP实现应使用IPsec ESP和非空转换保护通过单播发送的SLPv2消息。[RFC2608]中描述的SLPv2认证块（携带数字签名）也可用于认证单播和多播消息。
The usage of SLPv2 by iSCSI is described in [iSCSISLP]. iSCSI initiators and targets may enable IKE mechanisms to establish identity. In addition, a subsequent user-level iSCSI session login can protect the initiator-target nexus. This will protect them from any compromise of security in the SLPv2 discovery process.
[iSCSISLP]中描述了iSCSI使用SLPv2的情况。iSCSI启动器和目标可以使IKE机制建立身份。此外，后续用户级iSCSI会话登录可以保护启动器目标nexus。这将保护它们在SLPv2发现过程中不受任何安全危害。
The usage of SLPv2 by FCIP is described in [FCIPSLP]. FCIP Entities assume that once the IKE identity of a peer is established, the FCIP Entity Name carried in FCIP Short Frame is also implicitly accepted as the authenticated peer. Any such association between the IKE identity and the FCIP Entity Name is administratively established.
[FCIPSLP]中描述了FCIP使用SLPv2的情况。FCIP实体假定，一旦建立了对等方的IKE身份，FCIP短帧中携带的FCIP实体名称也被隐式接受为经过身份验证的对等方。IKE标识和FCIP实体名称之间的任何此类关联都是通过管理方式建立的。
For use in securing SLPv2, when digital signatures are used to achieve authentication in IKE, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures. If key management of SLPv2 DAs needs to be coordinated with the SAs and the UAs as well as the protocol service implementations, one may use certificate based key management, with a shared root Certificate Authority (CA).
为了保护SLPv2的安全，当使用数字签名在IKE中实现身份验证时，IKE谈判人员应使用IKE证书请求有效载荷来指定根据其本地策略受信任的证书颁发机构。IKE谈判者在接受用于IKE认证过程的PKI证书之前，应检查相关的证书撤销列表（CRL）。如果SLPv2 DAs的密钥管理需要与SAs和UAs以及协议服务实现进行协调，则可以使用基于证书的密钥管理，并使用共享根证书颁发机构（CA）。
One of the reasons for utilizing IPsec for SLPv2 security is that is more likely that certificates will be deployed for IPsec than for SLPv2. This both simplifies SLPv2 security and makes it more likely that it will be implemented interoperably and more importantly, that it will be used. As a result, it is desirable that little additional effort be required to enable IPsec protection of SLPv2.
将IPsec用于SLPv2安全性的原因之一是，将为IPsec部署证书的可能性大于为SLPv2部署证书的可能性。这既简化了SLPv2的安全性，也使其更有可能实现互操作，更重要的是，它将被使用。因此，希望只需很少的额外工作即可启用SLPv2的IPsec保护。
However, just because a certificate is trusted for use with IPsec does not necessarily imply that the host is authorized to perform SLPv2 operations. When using IPsec to secure SLPv2, it may be desirable to distinguish between certificates appropriate for use by UAs, SAs, and DAs. For example, while a UA might be allowed to use any certificate conforming to IKE certificate policy, the certificate used by an SA might indicate that it is a legitimate source of service advertisements. Similarly, a DA certificate might indicate that it is a valid DA. This can be accomplished by using special CAs to issue certificates valid for use by SAs and DAs; alternatively, SA and DA authorizations can be employed.
但是，仅因为证书受信任可与IPsec一起使用，并不一定意味着主机有权执行SLPv2操作。当使用IPsec保护SLPv2时，可能需要区分适合UAs、SAs和DAs使用的证书。例如，虽然可能允许UA使用符合IKE证书策略的任何证书，但SA使用的证书可能表明它是服务广告的合法来源。类似地，DA证书可能表示它是有效的DA。这可以通过使用特殊CA颁发SAs和DAs使用的有效证书来实现；或者，可以使用SA和DA授权。
Assume that the policy for issuing and distributing SLPv2 authorized certificates to SAs and DAs limits them only to legitimate SAs and DAs. In this case, IPsec is used to provide SLPv2 security as follows:
假设向SAs和DAs颁发和分发SLPv2授权证书的策略仅将其限制为合法的SAs和DAs。在这种情况下，IPsec用于提供SLPv2安全性，如下所示：
[a] SLPv2 messages sent via unicast are IPsec protected, using ESP with a non-null transform.
[a] 通过单播发送的SLPv2消息受IPsec保护，使用带非空转换的ESP。
[b] SrvRply and AttrRply messages from either a DA or SA are unicast to UAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the IKE Phase 1 SA, or that the DA used a certificate authorized for DA usage, the UA can accept the information sent, even if it has no SLPv2 authentication block.
[b] 来自DA或SA的SrvRply和ATTRPLY消息单播到UAs。假设SA在建立IKE阶段1 SA时使用了授权用于SLPv2服务广告的证书，或者DA使用了授权用于DA的证书，则UA可以接受发送的信息，即使它没有SLPv2认证块。
Note that where SrvRqst messages are multicast, they are not protected. An attacker may attempt to exploit this by spoofing a multicast SrvRqst from the UA, generating a SrvRply from an SA of the attacker's choosing. Although the SrvRply is secured, it does not correspond to a legitimate SrvRqst sent by the UA. To avoid this attack, where SrvRqst messages are multicast, the UA MUST check that SrvRply messages represent a legitimate reply to the SrvRqst that was sent.
请注意，如果SrvRqst消息是多播的，则它们不受保护。攻击者可以通过欺骗UA的多播SrvRqst，从攻击者选择的SA生成SrvRply，从而试图利用此漏洞进行攻击。尽管SrvRply是安全的，但它并不对应于UA发送的合法SrvRqst。为了避免这种攻击，如果SrvRqst消息是多播的，UA必须检查SrvRply消息是否代表对发送的SrvRqst的合法回复。
[c] SrvReg and SrvDereg messages from a SA are unicast to DAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the IKE Phase 1 SA, the DA can accept the de/registration even if it has no SLPv2 authentication block. Typically, the SA will check the DA authorization prior to sending the service advertisement.
[c] 来自SA的SrvReg和SrvDereg消息单播到DAs。假设SA在建立IKE阶段1 SA时使用了经SLPv2服务广告授权的证书，则DA即使没有SLPv2认证块也可以接受取消/注册。通常，SA将在发送服务广告之前检查DA授权。
[d] Multicast DAAdverts can be considered advisory. The UA will attempt to contact DAs via unicast. Assuming that the DA used a certificate authorized for SLPv2 DAAdverts in establishing the IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no SLPv2 authentication block.
[d] 多播广告可被视为咨询。UA将尝试通过单播与DAs联系。假设DA在建立IKE阶段1 SA时使用了为SLPv2 DAAdverts授权的证书，UA可以接受DAAdverte，即使它没有SLPv2身份验证块。
[e] SAs can accept DAAdverts as described in [d].
[e] SAs可以接受[d]中所述的DAAD。
Since SLPv2 messages can contain information that can potentially reveal the vendor of the device or its other associated characteristics, revealing service information constitutes a security risk. As an example, the FCIP Entity Name may reveal a WWN from which an attacker can learn potentially useful information about the Entity's characteristics.
由于SLPv2消息可能包含可能泄露设备供应商或其其他相关特征的信息，因此泄露服务信息构成安全风险。例如，FCIP实体名称可能会显示WWN，攻击者可以从中了解有关实体特征的潜在有用信息。
The SLPv2 security model assumes that service information is public, and therefore does not provide for confidentiality. However, storage devices represent mission critical infrastructure of substantial value, and so iSCSI and FCIP security implementations supporting SLPv2 security SHOULD encrypt as well as authenticate and integrity-protect unicast SLPv2 messages.
SLPv2安全模型假定服务信息是公开的，因此不提供机密性。但是，存储设备代表了具有重大价值的关键任务基础架构，因此支持SLPv2安全性的iSCSI和FCIP安全实施应加密、身份验证和完整性保护单播SLPv2消息。
Assuming that all unicast SLPv2 messages are protected by IPsec, and that confidentiality is provided, then the risk of disclosure can be limited to SLPv2 messages sent via multicast, namely the SrvRqst and DAAdvert.
假设所有单播SLPv2消息都受IPsec保护，并且提供了机密性，那么泄露的风险可以限制为通过多播发送的SLPv2消息，即SrvRqst和DAAD。
The information leaked in a multicast SrvRqst depends on the level of detail in the query. If leakage is a concern, then a DA can be provided. If this is not feasible, then a general query can be sent via multicast, and then further detail can be obtained from the replying entities via additional unicast queries, protected by IPsec.
多播SrvRqst中泄漏的信息取决于查询中的详细程度。如果存在泄漏问题，则可以提供DA。如果这不可行，则可通过多播发送一般查询，然后可通过受IPsec保护的附加单播查询从应答实体获取更多详细信息。
Information leakage via a multicast DAAdvert is less of a concern than the authenticity of the message, since knowing that a DA is present on the network only enables an attacker to know that SLPv2 is in use, and possibly that a directory service is also present. This information is not considered very valuable.
与消息的真实性相比，通过多播DAAdvert的信息泄漏更令人担忧，因为知道网络上存在DA只能使攻击者知道SLPv2正在使用，并且可能还存在目录服务。这些信息被认为不是很有价值。
Through the definition of security attributes, it is possible to use SLPv2 to distribute information about security settings for IP block storage entities. SLPv2 distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via SLPv2.
通过定义安全属性，可以使用SLPv2分发有关IP块存储实体安全设置的信息。如果可以通过其他方式（如手动配置或IPsec安全策略分发）确定安全设置，则不需要安全策略的SLPv2分发。如果实体已通过其他机制获得其安全配置，则不得通过SLPv2请求安全策略。
Where SLPv2 is used to provide security policy information for use with IP block storage protocols, SLPv2 MUST be protected by IPsec as described in this document. Where SLPv2 is not used to distribute security policy information, implementations MAY implement SLPv2 security as described in this document.
如果SLPv2用于提供与IP块存储协议一起使用的安全策略信息，则SLPv2必须按照本文档中的说明受IPsec保护。如果SLPv2不用于分发安全策略信息，则实施可能会实现本文档中所述的SLPv2安全性。
Where SLPv2 is used, but security is not implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
在使用SLPv2但未实现安全性的情况下，IP块存储协议实现必须支持身份验证失败的负缓存。这允许实现避免在IPsec内或在应用程序层（在iSCSI登录的情况下）不断联系发现的未通过身份验证的端点。负缓存不需要在IPsec实现中维护，而是在IP块存储协议实现中维护。
Since this document proposes that hop-by-hop security be used as the primary mechanism to protect SLPv2, UAs have to trust DAs to accurately relay data from SAs. This is a change to the SLPv2 security model described in [RFC2608]. However, SLPv2 authentication as defined in [RFC2608] does not provide a way to authenticate "zero result responses", leaving SLPv2 vulnerable to a denial of service attack. Such an attack can be carried out on a UA by sending it a "zero results" SrvRply or AttrRply, sent from a source address corresponding to a DA issuing a legitimate DAAdvert.
由于本文档建议将逐跳安全性用作保护SLPv2的主要机制，UAs必须信任DAs来准确地从SAs中继数据。这是对[RFC2608]中描述的SLPv2安全模型的更改。但是，[RFC2608]中定义的SLPv2身份验证未提供对“零结果响应”进行身份验证的方法，使SLPv2容易受到拒绝服务攻击。这种攻击可以通过向UA发送“零结果”SrvRply或ATTRPLY来执行，该SrvRply或ATTRPLY是从与发出合法DAAD的DA对应的源地址发送的。
In addition, SLPv2 security as defined in [RFC2608] does not support confidentiality. When IPsec with ESP and a non-null transform is used to protect SLPv2, not only can unicast requests and replies be authenticated, but confidentiality can also be provided. This includes unicast requests to DAs and SAs as well as replies. It is also possible to actively discover SAs using multicast SA discovery, and then to send unicast requests to the discovered SAs.
此外，[RFC2608]中定义的SLPv2安全性不支持保密性。当使用带ESP的IPsec和非空转换来保护SLPv2时，不仅可以对单播请求和应答进行身份验证，还可以提供机密性。这包括对DAs和SAs的单播请求以及回复。还可以使用多播SA发现主动发现SA，然后向发现的SA发送单播请求。
As a result, for use with IP block storage protocols, it is believed that use of IPsec for security is more appropriate than the SLPv2 security model defined in [RFC2608].
因此，对于与IP块存储协议一起使用，人们认为使用IPsec进行安全保护比[RFC2608]中定义的SLPv2安全模型更合适。
Using IPsec to secure SLPv2 has performance implications. Security associations established between:
使用IPsec保护SLPv2会影响性能。在以下各方之间建立的安全协会：
- UAs and SAs may be reused (the client on the UA host will use the service on the SA host).
- 可以重用UAs和SAs（UA主机上的客户端将使用SA主机上的服务）。
- SAs and DAs may be reused (the SAs will reregister services)
- 可以重用SAs和DAs（SAs将重新注册服务）
- UAs and DAs will probably not be reused (many idle security associations are likely to result, and build up on the DA).
- UAs和DAs可能不会被重用（可能会导致许多空闲的安全关联，并在DA上建立）。
When IPsec is used to protect SLPv2, it is not necessarily appropriate for all hosts with whom an IPsec security association can be established to be trusted to originate SLPv2 service advertisements. This is particularly the case in environments where it is easy to obtain certificates valid for use with IPsec (for example, where anyone with access to the network can obtain a machine certificate valid for use with IPsec). If not all hosts are authorized to originate service advertisements, then it is necessary to distinguish between authorized and unauthorized hosts.
当IPsec用于保护SLPv2时，并不一定适合所有可以与之建立IPsec安全关联的主机发起SLPv2服务播发。在容易获得与IPsec一起使用的有效证书的环境中尤其如此（例如，任何可以访问网络的人都可以获得与IPsec一起使用的有效机器证书）。如果并非所有主机都有权发起服务广告，则有必要区分授权主机和未授权主机。
This can be accomplished by the following mechanisms:
这可以通过以下机制实现：
[1] Configuring SAs with the identities or certificate characteristics of valid DAs, and configuring DAs with the identities of SAs allowed to advertise IP block storage
[1] 使用有效DAs的标识或证书特征配置SAs，并使用允许播发IP块存储的SAs标识配置DAs
services. The DAs are then trusted to enforce policies on service registration. This approach involves manual configuration, but avoids certificate customization for SLPv2.
服务。然后信任DAs来实施服务注册策略。此方法涉及手动配置，但避免了SLPv2的证书定制。
[2] Restricting the issuance of certificates valid for use in SLPv2 service advertisement. While all certificates allowed for use with IPsec will chain to a trusted root, certificates for hosts authorized to originate service advertisements could be signed by an SLPv2-authorized CA, or could contain explicit SLPv2 authorizations within the certificate. After the IPsec security association is set up between the SLPv2 entities, the SLPv2 implementations can then retrieve the certificates used in the negotiation in order to determine whether the entities are authorized for the operations that are being performed. This approach requires less configuration, but requires some certificate customization for use with SLPv2.
[2] 限制签发可在SLPv2服务广告中使用的有效证书。虽然允许与IPsec一起使用的所有证书都将链接到受信任的根，但授权发起服务播发的主机的证书可以由SLPv2授权CA签名，或者可以在证书中包含明确的SLPv2授权。在SLPv2实体之间建立IPsec安全关联后，SLPv2实现可以检索协商中使用的证书，以确定实体是否被授权执行正在执行的操作。这种方法需要较少的配置，但需要一些证书定制以用于SLPv2。
The iSCSI protocol may use iSNS for discovery and management services, while the iFCP protocol is required to use iSNS for such services. In addition, iSNS can be used to store and distribute security policy and authorization information to iSCSI and iFCP devices. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients are subject to the following additional security threats:
iSCSI协议可以将iSNS用于发现和管理服务，而iFCP协议需要将iSNS用于此类服务。此外，iSNS还可用于将安全策略和授权信息存储和分发到iSCSI和iFCP设备。部署iSNS协议时，iSNS服务器和iSNS客户端之间的交互会受到以下附加安全威胁：
[1] An attacker can alter iSNS protocol messages, directing iSCSI and iFCP devices to establish connections with rogue devices, or weakening IPsec protection for iSCSI or iFCP traffic.
[1] 攻击者可以更改iSNS协议消息，指示iSCSI和iFCP设备与恶意设备建立连接，或削弱对iSCSI或iFCP流量的IPsec保护。
[2] An attacker can masquerade as the real iSNS server by sending false iSNS heartbeat messages. This could deceive iSCSI and iFCP devices into using rogue iSNS servers.
[2] 攻击者可以通过发送虚假的iSNS心跳消息伪装成真实的iSNS服务器。这可能会欺骗iSCSI和iFCP设备使用流氓iSNS服务器。
[3] An attacker can gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft.
[3] 攻击者可以通过窥探iSNS协议消息获得有关iSCSI和iFCP设备的信息。此类信息可能有助于攻击者对iSCSI和iFCP设备发起直接攻击，例如拒绝服务攻击或彻底的物理盗窃。
To address these threats, the following capabilities are needed:
为了应对这些威胁，需要具备以下能力：
[a] Unicast iSNS protocol messages may need to be authenticated. In addition, to protect against threat [3] above, confidentiality support is desirable, and REQUIRED when certain functions of iSNS are used.
[a] 单播iSNS协议消息可能需要进行身份验证。此外，为了防止上述威胁[3]，需要保密支持，并且在使用iSNS的某些功能时需要保密支持。
[b] Multicast iSNS protocol messages such as the iSNS heartbeat message need to be authenticated. These messages need not be confidential since they do not leak critical information.
[b] 需要对多播iSNS协议消息（如iSNS心跳消息）进行身份验证。这些信息不需要保密，因为它们不会泄露关键信息。
There is no requirement that the identities of iSNS entities be kept confidential. Specifically, the identity and location of the iSNS server need not be kept confidential.
没有要求对iSNS实体的身份保密。具体而言，iSNS服务器的身份和位置无需保密。
In order to protect against an attacker masquerading as an iSNS server, client devices MUST support authentication of broadcast or multicast messages such as the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) MAY be used for this purpose. Note that the authentication block is used only for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages.
为了防止伪装成iSNS服务器的攻击者，客户端设备必须支持广播或多播消息（如iSNS心跳）的身份验证。iSNS认证块（其格式与SLP认证块相同）可用于此目的。请注意，身份验证块仅用于iSNS广播或多播消息，不应用于单播iSNS消息。
Since iSNS is used to distribute authorizations determining which client devices can communicate, IPsec authentication and data integrity MUST be supported. In addition, if iSNS is used to distribute security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality MUST be supported and used.
由于iSNS用于分发授权，以确定哪些客户端设备可以通信，因此必须支持IPsec身份验证和数据完整性。此外，如果iSNS用于为iFCP和iSCSI设备分发安全策略，则必须支持并使用身份验证、数据完整性和机密性。
Where iSNS is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
在使用iSNS时没有安全性，IP块存储协议实现必须支持身份验证失败的负缓存。这允许实现避免在IPsec内或在应用程序层（在iSCSI登录的情况下）不断联系发现的未通过身份验证的端点。负缓存不需要在IPsec实现中维护，而是在IP块存储协议实现中维护。
In practice, within a single installation, iSCSI and/or iFCP devices may have different security settings. For example, some devices may be configured to initiate secure communication, while other devices may be configured to respond to a request for secure communication, but not to require security. Still other devices, while security capable, may neither initiate nor respond securely.
实际上，在单个安装中，iSCSI和/或iFCP设备可能具有不同的安全设置。例如，一些设备可以配置为发起安全通信，而其他设备可以配置为响应安全通信的请求，但不需要安全性。还有一些设备虽然具有安全功能，但可能无法安全启动或响应。
In practice, these variations in configuration can result in devices being unable to communicate with each other. For example, a device that is configured to always initiate secure communication will experience difficulties in communicating with a device that neither initiates nor responds securely.
实际上，这些配置变化可能导致设备无法相互通信。例如，配置为始终启动安全通信的设备在与既不安全启动也不安全响应的设备通信时将遇到困难。
The iSNS protocol is used to transfer naming, discovery, and management information between iSCSI devices, iFCP gateways, management stations, and the iSNS server. This includes the ability to enable discovery of security settings used for communication via the iSCSI and/or iFCP protocols.
iSNS协议用于在iSCSI设备、iFCP网关、管理站和iSNS服务器之间传输命名、发现和管理信息。这包括能够发现用于通过iSCSI和/或iFCP协议进行通信的安全设置。
The iSNS server stores security settings for each iSCSI and iFCP device interface. These security settings, which can be retrieved by authorized hosts, include use or non-use of IPsec, IKE, Main Mode, Aggressive Mode, PFS, Pre-shared Key, and certificates.
iSNS服务器存储每个iSCSI和iFCP设备接口的安全设置。这些安全设置可由授权主机检索，包括使用或不使用IPsec、IKE、主模式、攻击模式、PFS、预共享密钥和证书。
For example, IKE may not be enabled for a particular device interface. If a peer device can learn of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE Phase 1 SA with that device interface.
例如，可能无法为特定设备接口启用IKE。如果对等设备可以通过咨询iSNS服务器提前了解到这一点，则无需浪费时间和资源尝试使用该设备接口启动IKE阶段1 SA。
If iSNS is used to distribute security policy, then the minimum information that should be learned from the iSNS server is the use or non-use of IKE and IPsec by each iFCP or iSCSI peer device interface. This information is encoded in the Security Bitmap field of each Portal of the peer device, and is applicable on a per-interface basis for the peer device. iSNS queries to acquire security configuration data about peer devices MUST be protected by IPsec/ESP authentication.
如果iSNS用于分发安全策略，则应从iSNS服务器了解的最低信息是每个iFCP或iSCSI对等设备接口是否使用IKE和IPsec。该信息编码在对等设备的每个入口的安全位图字段中，并且适用于对等设备的每个接口。获取对等设备安全配置数据的iSNS查询必须受到IPsec/ESP身份验证的保护。
Once communication between iSNS clients and the iSNS server are secured through use of IPsec, iSNS clients have the capability to discover the security settings required for communication via the iSCSI and/or iFCP protocols. Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and decrease the probability of communications failures due to incompatible security policies. If iSNS is used to distribute security policies, then IPsec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages.
一旦iSNS客户端和iSNS服务器之间的通信通过IPsec得到保护，iSNS客户端就能够发现通过iSCSI和/或iFCP协议进行通信所需的安全设置。使用iSNS分发安全策略有可能减轻手动设备配置的负担，并降低由于安全策略不兼容而导致通信失败的概率。如果iSNS用于分发安全策略，则必须使用IPsec身份验证、数据完整性和机密性来保护所有iSNS协议消息。
The complete IKE/IPsec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies that are used for IKE Phase 1 and Phase 2 negotiations between client devices. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to use to protect iSCSI or iFCP traffic.
每个iFCP和/或iSCSI设备的完整IKE/IPsec配置可以存储在iSNS服务器中，包括用于客户端设备之间IKE阶段1和阶段2协商的策略。IKE有效负载格式包括一系列一个或多个方案，iSCSI或iFCP设备将在协商用于保护iSCSI或iFCP流量的适当IPsec策略时使用这些方案。
Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS.
请注意，如果可以通过其他方式（如手动配置或IPsec安全策略分发）确定安全设置，则无需分发安全策略的iSNS。如果实体已通过其他机制获得其安全配置，则不得通过iSNS请求安全策略。
For further details on how to store and retrieve IKE policy proposals in the iSNS server, see [iSNS].
有关如何在iSNS服务器中存储和检索IKE策略建议的更多详细信息，请参阅[iSNS]。
When IPsec security is enabled, each iSNS client that is registered in the iSNS database maintains at least one Phase 1 and one Phase 2 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server are to be protected by a phase-2 security association.
启用IPsec安全性时，在iSNS数据库中注册的每个iSNS客户端都与iSNS服务器保持至少一个阶段1和阶段2安全关联。iSNS客户端和iSNS服务器之间的所有iSNS协议消息都将受到第2阶段安全关联的保护。
All iSNS implementations MUST support the replay protection mechanisms of IPsec. ESP in tunnel mode MUST be implemented, and IPsec with ESP in transport mode MAY be implemented.
所有iSNS实施都必须支持IPsec的重播保护机制。必须在隧道模式下实现ESP，并且可以在传输模式下实现带有ESP的IPsec。
To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. When confidentiality is implemented, 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. If confidentiality is not required but data origin authentication and integrity is enabled, ESP with NULL Encryption MUST be used.
为了通过ESP提供数据源身份验证和完整性，必须支持HMAC-SHA1，并且应支持CBC MAC模式下的AES和XCBC扩展[RFC3566]。当实现机密性时，必须支持CBC模式下的3DE，并且应支持[RFC3686]中所述的计数器模式下的AES。CBC模式下的DES由于其固有的弱点不应使用。如果不需要保密性，但启用了数据源身份验证和完整性，则必须使用带有空加密的ESP。
Conformant iSNS implementations MUST support IKE for authentication, negotiation of security associations, and key management, using the IPsec DOI, described in [RFC2407]. IP block storage protocols can be expected to send data in high volumes, thereby requiring rekey. Since manual keying does not provide rekeying support, its use is prohibited with IP block storage protocols. Although iSNS does not send a high volume of data, and therefore rekey is not a major concern, manual keying SHOULD NOT be used. This is for consistency, since dynamic keying support is already required in IP storage security implementations.
一致的iSNS实现必须支持IKE，以便使用[RFC2407]中描述的IPsec DOI进行身份验证、安全关联协商和密钥管理。IP块存储协议可能会发送大量数据，因此需要重新密钥。由于手动键控不提供重新键控支持，因此IP块存储协议禁止使用手动键控。虽然iSNS不会发送大量数据，因此重新设置密钥不是主要问题，但不应使用手动密钥。这是为了一致性，因为在IP存储安全实现中已经需要动态密钥支持。
Conformant iSNS security implementations MUST support authentication using a pre- shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in [RFC2409] sections 5.2 and 5.3 SHOULD NOT be used.
一致的iSNS安全实现必须支持使用预共享密钥的身份验证，并且可能支持使用数字签名的基于证书的对等身份验证。不应使用[RFC2409]第5.2节和第5.3节中概述的使用公钥加密方法的对等身份验证。
Conformant iSNS implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use dynamically assigned IP addresses. While Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force use of a group pre-shared key, which is vulnerable to man-in-the-middle attack.
一致的iSNS实现必须支持IKE主模式，并且应该支持主动模式。当任一对等方使用动态分配的IP地址时，不应使用带有预共享密钥身份验证的IKE主模式。虽然带有预共享密钥身份验证的主模式在许多情况下提供了良好的安全性，但在使用动态分配地址的情况下，强制使用组预共享密钥，这很容易受到中间人攻击。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
当数字签名用于身份验证时，可以使用IKE主模式或IKE攻击模式。在所有情况下，必须适当限制对本地存储的秘密信息（预共享密钥或用于数字签名的私钥）的访问，因为泄露秘密信息会使IKE/IPsec协议的安全属性无效。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
当使用数字签名实现身份验证时，IKE谈判者应使用IKE证书请求有效载荷来指定根据其本地策略受信任的证书颁发机构。IKE谈判者在接受用于IKE认证过程的PKI证书之前，应检查相关的证书撤销列表（CRL）。
The following guidelines are established to meet iSCSI security requirements using IPsec in practical situations.
制定以下准则是为了在实际情况下使用IPsec满足iSCSI安全要求。
iSCSI provides for iSCSI Login, outlined in [RFC3720], which includes support for application-layer authentication. This authentication is logically between the iSCSI initiator and the iSCSI target (as opposed to between the TCP/IP communication endpoints). The intent of the iSCSI design is that the initiator and target represent the systems (e.g., host and disk array or tape system) participating in the communication, as opposed to network communication interfaces or endpoints.
iSCSI提供了iSCSI登录，如[RFC3720]所述，其中包括对应用层身份验证的支持。此身份验证在逻辑上在iSCSI启动器和iSCSI目标之间进行（而不是在TCP/IP通信端点之间）。iSCSI设计的目的是，启动器和目标代表参与通信的系统（例如，主机和磁盘阵列或磁带系统），而不是网络通信接口或端点。
The iSCSI protocol and iSCSI Login authentication do not meet the security requirements for iSCSI. iSCSI Login authentication provides mutual authentication between the iSCSI initiator and target at connection origination, but does not protect control and data traffic on a per packet basis, leaving the iSCSI connection vulnerable to attack. iSCSI Login authentication can mutually authenticate the initiator to the target, but does not by itself provide per-packet authentication, integrity, confidentiality or replay protection. In
iSCSI协议和iSCSI登录身份验证不符合iSCSI的安全要求。iSCSI登录身份验证在连接发起时提供iSCSI启动器和目标之间的相互身份验证，但不保护每个数据包的控制和数据流量，使iSCSI连接容易受到攻击。iSCSI登录身份验证可以相互验证启动器与目标的身份，但它本身不提供每个数据包的身份验证、完整性、机密性或重播保护。在里面
addition, iSCSI Login authentication does not provide for a protected ciphersuite negotiation. Therefore, iSCSI Login provides a weak security solution.
此外，iSCSI登录身份验证不提供受保护的密码套件协商。因此，iSCSI登录提供了一个弱安全性解决方案。
An iSCSI session [RFC3720], comprised of one or more TCP connections, is identified by the 2-tuple of the initiator-defined identifier and the target-defined identifier, <ISID, TSIH>. Each connection within a given session is assigned a unique Connection Identification, CID. The TCP connection is identified by the 5-tuple <Source IP address, Destination IP address, Protocol (TCP), Source Port, Destination Port>. An IPsec Phase 2 SA is identified by the 3-tuple <Protocol (ESP),destination address, SPI>.
由一个或多个TCP连接组成的iSCSI会话[RFC3720]由启动器定义的标识符和目标定义的标识符的2元组<ISID，TSIH>标识。给定会话中的每个连接都被分配一个唯一的连接标识CID。TCP连接由5元组<Source IP address，Destination IP address，Protocol（TCP），Source Port，Destination Port>标识。IPsec阶段2 SA由三元组<协议（ESP），目标地址，SPI>标识。
The iSCSI session and connection information is carried within the iSCSI Login Commands, transported over TCP. Since an iSCSI initiator may have multiple interfaces, iSCSI connections within an iSCSI session may be initiated from different IP addresses. Similarly, multiple iSCSI targets may exist behind a single IP address, so that there may be multiple iSCSI sessions between a given <source IP address, destination IP address> pair.
iSCSI会话和连接信息包含在iSCSI登录命令中，通过TCP传输。由于iSCSI启动器可能具有多个接口，因此iSCSI会话中的iSCSI连接可以从不同的IP地址启动。类似地，单个IP地址后面可能存在多个iSCSI目标，因此在给定的<源IP地址，目标IP地址>对之间可能存在多个iSCSI会话。
When multiple iSCSI sessions are active between a given <initiator, target> pair, the set of TCP connections used by a given iSCSI session must be disjoint from those used by all other iSCSI sessions between the same <initiator, target> pair. Therefore a TCP connection can be associated with one and only one iSCSI session.
当给定<启动器，目标>对之间的多个iSCSI会话处于活动状态时，给定iSCSI会话使用的TCP连接集必须与同一<启动器，目标>对之间的所有其他iSCSI会话使用的TCP连接集不相交。因此，TCP连接只能与一个iSCSI会话关联。
The relationship between iSCSI sessions, TCP connections and IKE Phase 1 and Phase 2 SAs is as follows:
iSCSI会话、TCP连接和IKE阶段1和阶段2 SAs之间的关系如下：
[1] An iSCSI initiator or target may have more than one interface, and therefore may have multiple IP addresses. Also, multiple iSCSI initiators and targets may exist behind a single IP address. As a result, an iSCSI Session may correspond to multiple IKE Phase 1 Security Associations, though typically a single IKE Phase 1 security association will exist for an <initiator IP address, target IP address> tuple.
[1] iSCSI启动器或目标可能有多个接口，因此可能有多个IP地址。此外，单个IP地址后面可能存在多个iSCSI启动器和目标。因此，iSCSI会话可能对应于多个IKE阶段1安全关联，尽管通常对于<initiator IP address，target IP address>元组存在单个IKE阶段1安全关联。
[2] Each TCP connection within an iSCSI Session is protected by an IKE Phase 2 SA. The selectors may be specific to that TCP connection or may cover multiple connections. While each IKE Phase 2 SA may protect multiple TCP connections, each TCP connection is transported under only one IKE Phase 2 SA.
[2] iSCSI会话中的每个TCP连接都受IKE阶段2 SA的保护。选择器可能特定于该TCP连接，也可能覆盖多个连接。虽然每个IKE阶段2 SA可以保护多个TCP连接，但每个TCP连接仅在一个IKE阶段2 SA下传输。
Given this, all the information needed for the iSCSI/IPsec binding is contained within the iSCSI Login messages from the iSCSI initiator and target. This includes the binding between an IKE Phase 1 SA and the corresponding iSCSI sessions, as well as the binding between a TCP connection, an IKE Phase 2 SA and the iSCSI connection ID.
因此，iSCSI/IPsec绑定所需的所有信息都包含在来自iSCSI启动器和目标的iSCSI登录消息中。这包括IKE阶段1 SA和相应iSCSI会话之间的绑定，以及TCP连接、IKE阶段2 SA和iSCSI连接ID之间的绑定。
In order to create a new iSCSI Session, if an IKE Phase 1 SA does not already exist, then it is established by an initiator implementing iSCSI security. Subsequent iSCSI connections established within the iSCSI session will typically be protected by IKE Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase 1 SAs can also be brought up.
为了创建新的iSCSI会话，如果IKE阶段1 SA不存在，则由实施iSCSI安全的启动器建立。在iSCSI会话中建立的后续iSCSI连接通常将受到来自该IKE阶段1 SA的IKE阶段2 SA的保护，尽管也可以启动其他IKE阶段1 SA。
The initiator and target implementations successfully complete the IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator contacts the target on well-known TCP port 3260, and sends the iSCSI Login command over the TCP connection. IPsec implementations configured with the correct policies (e.g., use ESP with non-null transform for all traffic destined for the iSCSI well-known TCP port 3260) will handle this automatically.
在iSCSI启动器通过众所周知的TCP端口3260联系目标并通过TCP连接发送iSCSI登录命令之前，启动器和目标实现成功完成IKE阶段1和阶段2协商。配置了正确策略的IPsec实施（例如，对所有发送到iSCSI著名TCP端口3260的流量使用带非空转换的ESP）将自动处理此问题。
The initiator fills in the ISID field, and leaves the TSIH field set to zero, to indicate that it is the first message of a new session establishment exchange. The initiator also fills in a CID value, that identifies the TCP connection over which the Login command is being exchanged. When the iSCSI target replies with its Login Command, both iSCSI devices will know the TSIH, and therefore the iSCSI session identifier <ISID, TSIH>.
启动器填写ISID字段，并将TSIH字段设置为零，以指示它是新会话建立交换的第一条消息。启动器还填写一个CID值，该值标识正在交换登录命令的TCP连接。当iSCSI目标使用其登录命令进行响应时，两个iSCSI设备都将知道TSIH，从而知道iSCSI会话标识符<ISID，TSIH>。
A single iSCSI session identifier may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session identifiers. Each iSCSI connection (identified by the connection identifier) corresponds to a single TCP connection (identified by the 5-tuple). Each IKE Phase 2 SA is identified by the <Protocol (ESP), destination address, SPI> combination. A Phase 2 SA may protect multiple TCP connections, and corresponds to a single IKE Phase 1 SA.
单个iSCSI会话标识符可以具有多个关联的IKE阶段1 SA，并且每个IKE阶段1 SA可以对应于多个iSCSI会话标识符。每个iSCSI连接（由连接标识符标识）对应一个TCP连接（由5元组标识）。每个IKE阶段2 SA由<协议（ESP）、目标地址、SPI>组合标识。阶段2 SA可保护多个TCP连接，并对应于单个IKE阶段1 SA。
Within IKE, each key refresh requires that a new security association be established. In practice there is a time interval during which an old, about-to-expire SA and newly established SA will both be valid. The IPsec implementation will choose which security association to use based on local policy, and iSCSI concerns play no role in this selection process.
在IKE中，每次密钥刷新都需要建立新的安全关联。在实践中，有一个时间间隔，在此期间，旧的、即将到期的SA和新建立的SA都将有效。IPsec实现将根据本地策略选择要使用的安全关联，iSCSI关注点在此选择过程中不起作用。
Mechanisms within iSCSI provide for both graceful and non-graceful teardown of iSCSI Sessions or individual TCP connections within a given session. The iSCSI Logout command is used to effect graceful teardown. This command allows the iSCSI initiator to request that:
iSCSI中的机制为给定会话中iSCSI会话或单个TCP连接的正常和非正常断开提供了支持。iSCSI注销命令用于实现优雅的拆卸。此命令允许iSCSI启动器请求：
[a] the session be closed
[a] 会议将闭幕
[b] a specific connection within the session be closed
[b] 无法关闭会话中的特定连接
[c] a specific connection be marked for recovery
[c] 必须将特定连接标记为要恢复
When the iSCSI implementation wishes to close a session, it uses the appropriate iSCSI commands to accomplish this. After exchanging the appropriate iSCSI control messages for session closure, the iSCSI security implementation will typically initiate a half-close of each TCP connection within the iSCSI session.
当iSCSI实现希望关闭会话时，它将使用适当的iSCSI命令来完成此操作。在为会话关闭交换适当的iSCSI控制消息后，iSCSI安全实施通常会启动iSCSI会话中每个TCP连接的半关闭。
When the iSCSI security implementation wishes to close an individual TCP connection while leaving the parent iSCSI session active, it should half-close the TCP connection. After the expiration of the TIME_WAIT timeout, the TCP connection is closed.
当iSCSI安全实施希望在保持父iSCSI会话处于活动状态的同时关闭单个TCP连接时，它应该一半关闭TCP连接。等待超时时间到期后，TCP连接关闭。
If a given TCP connection unexpectedly fails, the associated iSCSI connection is torn down. There is no requirement that an IKE Phase 2 delete immediately follow iSCSI connection tear down or Phase 1 deletion. Since an IKE Phase 2 SA may correspond to multiple TCP connections, such a deletion might be inappropriate. Similarly, if the IKE implementation receives a Phase 2 Delete message for a security association corresponding to a TCP connection, this does not necessarily imply that the TCP or iSCSI connection is to be torn down.
如果给定的TCP连接意外失败，则关联的iSCSI连接将断开。无需在iSCSI连接断开或阶段1删除之后立即执行IKE阶段2删除。由于IKE阶段2 SA可能对应于多个TCP连接，因此这样的删除可能不合适。类似地，如果IKE实现接收到与TCP连接对应的安全关联的第2阶段删除消息，则这并不一定意味着TCP或iSCSI连接将被中断。
If a Logout Command/Logout Response sequence marks a connection for removal from the iSCSI session, then after the iSCSI peer has executed an iSCSI teardown process for the connection, the TCP connection will be closed. The iSCSI connection state can then be safely removed.
如果注销命令/注销响应序列标记要从iSCSI会话中删除的连接，则在iSCSI对等方为该连接执行iSCSI断开过程后，TCP连接将关闭。然后可以安全地删除iSCSI连接状态。
Since an IKE Phase 2 SA may be used by multiple TCP connections, an iSCSI implementation should not depend on receiving the IPsec Phase 2 delete as confirmation that the iSCSI peer has executed an iSCSI teardown process for the connection.
由于IKE第2阶段SA可由多个TCP连接使用，因此iSCSI实现不应依赖于接收IPsec第2阶段删除来确认iSCSI对等方已为该连接执行iSCSI断开过程。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down the corresponding iSCSI connection if no Logout Command/Logout Receive has been executed on the connection. Rather, it is preferable to leave the iSCSI connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing iSCSI connections up and down.
由于IPsec加速硬件可能只能处理有限数量的活动IKE阶段2 SA，因此可以为空闲SA发送阶段2删除消息，以将活动阶段2 SA的数量保持在最小。如果未对连接执行注销命令/注销接收，则接收IKE第2阶段删除消息不得解释为断开相应iSCSI连接的原因。相反，最好保持iSCSI连接处于打开状态，如果在其上发送了额外的流量，则启动另一个IKE阶段2 SA以保护它。这样就避免了不断地使iSCSI连接上下移动的可能性。
iSCSI's error detection and recovery assumes that the TCP and IP checksums provide inadequate integrity protection for high speed communications. As described in [CRCTCP], when operating at high speeds, the 16-bit TCP checksum [RFC793] will not necessarily detect all errors, resulting in possible data corruption. iSCSI [RFC3720] therefore incorporates a 32-bit CRC to protect its headers and data.
iSCSI的错误检测和恢复假定TCP和IP校验和为高速通信提供的完整性保护不足。如[CRCTCP]中所述，在高速运行时，16位TCP校验和[RFC793]不一定会检测到所有错误，从而导致可能的数据损坏。因此，iSCSI[RFC3720]采用了32位CRC来保护其标头和数据。
When a CRC check fails (i.e., CRC computed at receiver does not match the received CRC), the iSCSI PDU covered by that CRC is discarded. Since presumably the error was not detected by the TCP checksum, TCP retransmission will not occur and thus cannot assist in recovering from the error. iSCSI contains both data and command retry mechanisms to deal with the resulting situations, including SNACK, the ability to reissue R2T commands, and the retry (X) bit for commands.
当CRC检查失败时（即，在接收器处计算的CRC与接收到的CRC不匹配），该CRC覆盖的iSCSI PDU将被丢弃。由于TCP校验和可能未检测到错误，因此不会发生TCP重新传输，因此无法帮助从错误中恢复。iSCSI包含数据和命令重试机制来处理结果情况，包括SNACK、重新发出R2T命令的能力以及命令的重试（X）位。
IPsec offers protection against an attacker attempting to modify packets in transit, as well as unintentional packet modifications caused by network malfunctions or other errors. In general, IPsec authentication transforms afford stronger integrity protection than both the 16-bit TCP checksum and the 32-bit application-layer CRC specified for use with iSCSI. Since IPsec integrity protection occurs below TCP, if an error is discovered, then the packet will be discarded and TCP retransmission will occur, so that no recovery action need be taken at the iSCSI layer.
IPsec提供保护，防止攻击者试图修改传输中的数据包，以及因网络故障或其他错误而导致的无意数据包修改。通常，IPsec身份验证转换提供了比指定用于iSCSI的16位TCP校验和和和32位应用层CRC更强的完整性保护。由于IPsec完整性保护发生在TCP以下，因此如果发现错误，则数据包将被丢弃，并将发生TCP重新传输，因此无需在iSCSI层执行恢复操作。
Where IPsec integrity protection is known to be in place end-to-end between iSCSI endpoints (or the portion that requires additional integrity protection), portions of iSCSI can be simplified. For example, mechanisms to recover from CRC check failures are not necessary.
如果已知iSCSI端点（或需要额外完整性保护的部分）之间存在端到端的IPsec完整性保护，则可以简化iSCSI的部分。例如，不需要从CRC检查失败中恢复的机制。
If the iSCSI CRC is negotiated, the recovery logic can be simplified to regard any CRC check failure as fatal (e.g., generate a SCSI CHECK CONDITION on data error, close the corresponding TCP connection on header error) because it will be very rare for errors undetected by IPsec integrity protection to be detected by the iSCSI CRC.
如果协商iSCSI CRC，恢复逻辑可以简化为将任何CRC检查失败视为致命（例如，在数据错误时生成SCSI检查条件，在报头错误时关闭相应的TCP连接），因为iSCSI CRC很少检测到IPsec完整性保护未检测到的错误。
In some situations where IPsec is employed, the iSCSI CRC will not provide additional protection and can be omitted.
在使用IPsec的某些情况下，iSCSI CRC不会提供额外的保护，可以省略。
For example, where IPsec processing as well as TCP checksum and iSCSI CRC verification are offloaded within the NIC, each of these checks will be verified prior to transferring data across the bus, so that subsequent errors will not be detected by these mechanisms. As a result, where IPsec processing is offloaded to the NIC, the iSCSI CRC is not necessary and the implementations may wish not to negotiate it.
例如，在NIC内卸载IPsec处理以及TCP校验和和和iSCSI CRC验证的情况下，将在通过总线传输数据之前验证这些检查，以便这些机制不会检测到后续错误。因此，在将IPsec处理卸载到NIC的情况下，iSCSI CRC是不必要的，实施可能不希望协商它。
However, in other circumstances, the TCP checksum and iSCSI CRC will provide additional error coverage because they are computed and checked at a different point in the protocol stack or in devices different from those that implement the IPsec integrity checks. The resulting coverage of additional possible errors may make it desirable to negotiate use of the iSCSI CRC even when IPsec integrity protection is in use. Examples of these situations include where:
但是，在其他情况下，TCP校验和和和iSCSI CRC将提供额外的错误覆盖率，因为它们是在协议堆栈中的不同点或在不同于实现IPsec完整性检查的设备中计算和检查的。即使在使用IPsec完整性保护时，也可能需要协商iSCSI CRC的使用，从而覆盖其他可能的错误。这些情况的示例包括：
[1] IPsec, TCP and iSCSI are implemented purely in software. Here, additional failure modes may be detected by the TCP checksum and/or iSCSI CRC. For example, after the IPsec message integrity check is successfully verified, the segment is copied as part of TCP processing, and a memory error during this process might cause the TCP checksum or iSCSI CRC verification to fail.
[1] IPsec、TCP和iSCSI完全在软件中实现。这里，TCP校验和和/或iSCSI CRC可能检测到其他故障模式。例如，成功验证IPsec消息完整性检查后，该段将作为TCP处理的一部分进行复制，在此过程中出现内存错误可能会导致TCP校验和或iSCSI CRC验证失败。
[2] The implementation is an iSCSI-iSCSI proxy or gateway. Here the iSCSI CRC can be propagated from one iSCSI connection to another. In this case, the iSCSI CRC is useful to protect iSCSI data against memory, bus, or software errors within the proxy or gateway, and requesting it is desirable.
[2] 该实现是iSCSI代理或网关。在这里，iSCSI CRC可以从一个iSCSI连接传播到另一个iSCSI连接。在这种情况下，iSCSI CRC有助于保护iSCSI数据免受代理或网关中的内存、总线或软件错误的影响，因此需要请求iSCSI数据。
[3] IPsec is provided by a device external to the actual iSCSI device. Here the iSCSI header and data CRCs can be kept across the part of the connection that is not protected by IPsec. For instance, the iSCSI connection could traverse an extra bus, interface card, network, interface card, and bus between the
[3] IPsec由实际iSCSI设备外部的设备提供。在这里，iSCSI标头和数据CRC可以跨不受IPsec保护的连接部分保存。例如，iSCSI连接可能会在服务器之间穿过一条额外的总线、接口卡、网络、接口卡和总线
iSCSI device and the device providing IPsec. In this case, the iSCSI CRC is desirable, and the iSCSI implementation behind the IPsec device may request it.
iSCSI设备和提供IPsec的设备。在这种情况下，需要iSCSI CRC，并且IPsec设备后面的iSCSI实现可能会请求它。
Note that if both ends of the connection are on the same segment, then traffic will be effectively protected by the layer 2 CRC, so that negotiation of the iSCSI CRC is not necessary to protect against NIC and network errors, although it may be desirable for other reasons (e.g., [1] and [2] above).
请注意，如果连接的两端位于同一段上，则流量将由第2层CRC有效保护，因此iSCSI CRC的协商对于防止NIC和网络错误是不必要的，尽管出于其他原因（例如，上面的[1]和[2]）可能是可取的。
iFCP and FCIP are peer-to-peer protocols. iFCP and FCIP sessions may be initiated by either or both peer gateways. Consequently, bi-directional authentication of peer gateways MUST be provided.
iFCP和FCIP是对等协议。iFCP和FCIP会话可以由一个或两个对等网关启动。因此，必须提供对等网关的双向认证。
iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre Channel frames over IP. Therefore, Fibre Channel, operating system, and user identities are transparent to the iFCP and FCIP protocols.
iFCP和FCIP是通过IP封装SCSI和光纤通道帧的传输协议。因此，光纤通道、操作系统和用户身份对iFCP和FCIP协议是透明的。
iFCP gateways use Discovery Domain information obtained from the iSNS server to determine whether the initiating Fibre Channel N_PORT should be allowed access to the target N_PORT. N_PORT identities used in the Port Login (PLOGI) process will be considered authenticated provided that they are received over a connection whose security complies with the local security policy.
iFCP网关使用从iSNS服务器获得的发现域信息来确定是否应允许启动光纤通道N_端口访问目标N_端口。N_端口登录（PLOGI）过程中使用的端口标识将被视为经过身份验证，前提是它们是通过安全性符合本地安全策略的连接接收的。
There is no requirement that the identities used in authentication be kept confidential.
认证中使用的身份无需保密。
A conformant iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized, or may be deferred until the first TCP connection with security requirements is established.
一致性iFCP门户能够建立一个或多个IKE第一阶段安全关联（SA）到对等iFCP门户。第一阶段SA可以在初始化iFCP门户时建立，也可以推迟到建立具有安全要求的第一个TCP连接时建立。
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, the successful establishment of an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <SPI, destination IP address, ESP>. These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. Each of the TCP connections protected by an SA is either in the unbound state, or is bound to a specific iFCP session.
IKE阶段2 SA保护同一iFCP门户内的一个或多个TCP连接。更具体地说，成功建立IKE阶段2 SA导致创建两个完全由tuple<SPI，destination IP address，ESP>限定的单向IPsec SA。这些SA保护底层TCP连接的设置过程及其所有后续TCP流量。SA保护的每个TCP连接要么处于未绑定状态，要么绑定到特定的iFCP会话。
In summary, at any point in time:
总之，在任何时间点：
[1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals
[2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs
[3] Each IKE Phase-2 SA protects 0..Z TCP connections
[1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals
[2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs
[3] Each IKE Phase-2 SA protects 0..Z TCP connections
The creation of an IKE Phase-2 SA may be triggered by security policy rules retrieved from an iSNS server. Alternately, the creation of an SA may be triggered by policy rules configured through a management interface, reflecting iSNS-resident policy rules. Likewise, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be driven by security policy rules retrieved from the iSNS server, or set through a management interface.
IKE阶段2 SA的创建可能由从iSNS服务器检索的安全策略规则触发。或者，SA的创建也可以由通过管理界面配置的策略规则触发，以反映iSNS驻留的策略规则。类似地，在快速模式下使用密钥交换有效负载以实现完美的前向保密性可能是由从iSNS服务器检索的安全策略规则驱动的，或通过管理接口设置的。
If an iFCP implementation makes use of unbound TCP connections, and such connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times just like bound connections.
如果iFCP实现使用未绑定的TCP连接，并且此类连接属于具有安全要求的iFCP门户，则未绑定的连接必须始终由SA保护，就像绑定的连接一样。
Upon receiving an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating such connections might in fact be inappropriate and untimely.
收到IKE第2阶段删除消息后，无需终止受保护的TCP连接或删除相关IKE第1阶段SA。由于IKE阶段2 SA可能与多个TCP连接相关联，因此终止此类连接实际上可能是不适当和不及时的。
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.
为了尽量减少活动的第2阶段SA的数量，可以为TCP连接有一段时间没有处理数据通信的第2阶段SA发送IKE第2阶段删除消息。为了在相关TCP连接空闲时尽量减少SA资源的使用，应推迟创建新SA，直到通过连接发送新数据。
FCIP Entities establish tunnels with other FCIP Entities in order to transfer IP encapsulated FC frames. Each tunnel is a separate FCIP Link, and can encapsulate multiple TCP connections. The binding of TCP connections to an FCIP Link is performed using the Fibre Channel World Wide Names (WWNs) of the two FCIP Entities.
FCIP实体与其他FCIP实体建立隧道，以便传输IP封装的FC帧。每个隧道都是一个单独的FCIP链路，可以封装多个TCP连接。TCP连接到FCIP链路的绑定使用两个FCIP实体的光纤通道全球通用名称（WWN）执行。
FCIP Entities may have more than one interface and IP address, and it is possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is typically established for each FCIP endpoint IP Address pair. For the purposes of establishing an IKE Phase 1 SA, static IP addresses are typically used for identification.
FCIP实体可能有多个接口和IP地址，FCIP链路可能包含多个TCP连接，其FCIP端点IP地址不同。在这种情况下，通常为每个FCIP端点IP地址对建立IKE阶段1 SA。为了建立IKE阶段1 SA，静态IP地址通常用于标识。
Each TCP connection within an FCIP Link corresponds to an IKE Phase 2 (Quick Mode) SA. This is established prior to sending the initial TCP SYN packet and applies to the life of the connection. Phase 2 negotiation is also required for rekeying, in order to protect against replay attacks.
FCIP链路中的每个TCP连接对应于IKE阶段2（快速模式）SA。这是在发送初始TCP SYN数据包之前建立的，适用于连接的生命周期。第2阶段协商还需要重新设置密钥，以防止重播攻击。
FCIP implementations MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
FCIP实施可提供机密性使用的管理。这些管理接口应以安全的方式提供，以防止攻击者通过攻击管理接口破坏安全过程。
FCIP Entities do not require any user-level authentication, since all FCIP Entities participate in a machine-level tunnel function. FCIP uses SLP for discovery, but not to distribute security policies.
FCIP实体不需要任何用户级身份验证，因为所有FCIP实体都参与机器级隧道功能。FCIP使用SLP进行发现，但不分发安全策略。
With respect to block storage protocols, the major differences between the IPsec tunnel mode and transport mode are as follows:
关于块存储协议，IPsec隧道模式和传输模式之间的主要区别如下：
[1] MTU considerations. Tunnel mode introduces an additional IP header into the datagram that reflects itself in a corresponding decrease in the path MTU seen by packets traversing the tunnel. This may result in a decrease in the maximum segment size of TCP connections running over the tunnel.
[1] MTU考虑因素。隧道模式在数据报中引入一个额外的IP报头，该报头反映在通过隧道的数据包所看到的路径MTU的相应减少中。这可能导致在隧道上运行的TCP连接的最大段大小减小。
[2] Address assignment and configuration. Within IPsec tunnel mode, it is necessary for inner and outer source addresses to be configured, and for inner and outer destination addresses to be discovered. Within transport mode it is only necessary to discover a single destination address and configure a single source address. IPsec tunnel mode address usage considerations are discussed in more detail below.
[2] 地址分配和配置。在IPsec隧道模式中，必须配置内部和外部源地址，并查找内部和外部目标地址。在传输模式中，只需发现单个目标地址并配置单个源地址。下面将更详细地讨论IPsec隧道模式地址使用注意事项。
[3] NAT traversal. As noted in [RFC3715], IPsec tunnel mode ESP can traverse NAT in limited circumstances, whereas transport mode ESP cannot traverse NAT. To enable NAT traversal in the general case, the IPsec NAT traversal functionality described in [RFC3715], [UDPIPsec] and [NATIKE] can be implemented. More details are provided in the next section.
[3] NAT遍历。如[RFC3715]中所述，IPsec隧道模式ESP可以在有限的情况下遍历NAT，而传输模式ESP不能遍历NAT。为了在一般情况下启用NAT遍历，可以实现[RFC3715]、[UDPIPsec]和[NATIKE]中描述的IPsec NAT遍历功能。下一节将提供更多详细信息。
[4] Firewall traversal. Where a block storage protocol is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for the block storage protocol. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end-to-end security, so that they can also verify authenticity and integrity of each packet for themselves.
[4] 防火墙穿越。当块存储协议要穿越管理域时，防火墙管理员可能希望验证每个传输数据包的完整性和真实性，而不是在防火墙上为块存储协议打开一个洞。IPsec隧道模式有助于此类验证，因为防火墙可以终止隧道模式连接，同时仍允许端点端到端通信。如果需要，端点还可以利用IPsec传输模式实现端到端安全性，以便它们还可以为自己验证每个数据包的真实性和完整性。
In contrast, carrying out this verification with IPsec transport mode is more complex, since the firewall will need to terminate the IPsec transport mode connection and will need to act as an iSCSI, iFCP or FCIP gateway or TCP proxy, originating a new IPsec transport mode connection from the firewall to the internal endpoint. Such an implementation cannot provide end-to-end authenticity or integrity protection, and an application-layer CRC (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and FCIP) is necessary to protect against errors introduced by the firewall.
相比之下，使用IPsec传输模式执行此验证更为复杂，因为防火墙需要终止IPsec传输模式连接，并且需要充当iSCSI、iFCP或FCIP网关或TCP代理，从防火墙到内部端点发起新的IPsec传输模式连接。这种实现无法提供端到端的真实性或完整性保护，需要应用层CRC（iSCSI）或光纤通道帧CRC（iFCP和FCIP）的转发来防止防火墙引入的错误。
[5] IPsec-application integration. Where IPsec and the application layer protocol are implemented on the same device or host, it is possible to enable tight integration between them. For example, the application layer can request and verify that connections are protected by IPsec, and can obtain attributes of the IPsec security association. While in transport mode implementations the IPsec and application protocol implementations typically reside on the same host, with IPsec tunnel mode they may reside on different hosts. Where IPsec is implemented on an external gateway, integration between the application and IPsec is typically not possible. This limits the ability of the application to control and verify IPsec behavior.
[5] IPsec应用程序集成。如果IPsec和应用层协议在同一设备或主机上实现，则可以实现它们之间的紧密集成。例如，应用层可以请求并验证连接是否受IPsec保护，并可以获取IPsec安全关联的属性。在传输模式实施中，IPsec和应用程序协议实施通常位于同一主机上，而在IPsec隧道模式下，它们可能位于不同的主机上。如果IPsec是在外部网关上实现的，则应用程序和IPsec之间的集成通常是不可能的。这限制了应用程序控制和验证IPsec行为的能力。
IPsec tunnels include both inner and outer source as well as destination addresses.
IPsec隧道包括内部和外部源地址以及目标地址。
When used with IP block storage protocols, the inner destination address represents the address of the IP block storage protocol peer (e.g., the ultimate destination for the packet). The inner destination address can be discovered using SLPv2 or iSNS, or can be resolved from an FQDN via DNS, so that obtaining this address is typically not an issue.
当与IP块存储协议一起使用时，内部目的地地址表示IP块存储协议对等方的地址（例如，数据包的最终目的地）。内部目标地址可以使用SLPv2或iSNS查找，也可以通过DNS从FQDN解析，因此获取此地址通常不是问题。
The outer destination address represents the address of the IPsec security gateway used to reach the peer. Several mechanisms have been proposed for discovering the IPsec security gateway used to reach a particular peer. [RFC2230] discusses the use of KX Resource Records (RRs) for IPsec gateway discovery. However, while KX RRs are supported by many DNS server implementations, they have not yet been widely deployed. Alternatively, DNS SRV [RFC2782] can be used for this purpose. Where DNS is used for gateway location, DNS security mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple Secure Dynamic Update [RFC3007] are advisable.
外部目标地址表示用于到达对等方的IPsec安全网关的地址。已经提出了几种机制来发现用于到达特定对等方的IPsec安全网关。[RFC2230]讨论了用于IPsec网关发现的KX资源记录（RRs）的使用。然而，尽管许多DNS服务器实现都支持KX RRs，但它们尚未得到广泛部署。或者，DNS SRV[RFC2782]可用于此目的。当DNS用于网关位置时，建议使用DNS安全机制，如DNSSEC（[RFC2535]、[RFC2931]）、TSIG[RFC2845]和简单安全动态更新[RFC3007]。
When used with IP block storage protocols, the outer source address is configured either statically or dynamically, using mechanisms such as DHCPv4 [RFC2131], DHCPV6 [RFC3315], or stateless address autoconfiguration [RFC2373].
当与IP块存储协议一起使用时，使用诸如DHCPv4[RFC2131]、DHCPV6[RFC3315]或无状态地址自动配置[RFC2373]等机制，以静态或动态方式配置外部源地址。
The inner source address SHOULD be included in the Quick Mode ID payload when the peer establishes a tunnel mode SA with the IPsec security gateway. This enables the IPsec security gateway to properly route packets back to the remote peer. The inner source address can be configured via a variety of mechanisms, depending on the scenario. Where the IP block storage peers are located within the same administrative domain, it is typically possible for the inner and outer source addresses to be the same. This will work because the outer source address is presumably assigned from within a prefix assigned to the administrative domain, and is therefore routable within the domain. Assuming that the IPsec security gateway is aware of the inner source address used by the connecting peer and plumbs a host route for it, then packets arriving at the IPsec security gateway destined for the address can be correctly encapsulated and sent down the correct tunnel.
当对等方与IPsec安全网关建立隧道模式SA时，内部源地址应包含在快速模式ID有效负载中。这使IPsec安全网关能够正确地将数据包路由回远程对等方。内部源地址可以通过多种机制进行配置，具体取决于场景。如果IP块存储对等点位于同一管理域中，则通常可能内部和外部源地址相同。这将起作用，因为外部源地址可能是从分配给管理域的前缀中分配的，因此可以在域中路由。假设IPsec安全网关知道连接对等方所使用的内部源地址，并为其提供主机路由，则到达IPsec安全网关的以该地址为目的地的数据包可以正确封装并发送到正确的隧道。
Where IP block storage peers are located within different administrative domains, it may be necessary for the inner source address to be assigned by the IPsec security gateway, effectively "joining" the remote host to the LAN attached to the IPsec security gateway. For example, if the remote peer were to use its assigned (outer) source address as the inner source address, then a number of problems might result:
如果IP块存储对等方位于不同的管理域中，则可能需要由IPsec安全网关分配内部源地址，从而有效地将远程主机“连接”到连接到IPsec安全网关的LAN。例如，如果远程对等方将其分配的（外部）源地址用作内部源地址，则可能会导致许多问题：
[1] Intrusion detection systems sniffing the LAN behind the IPsec security gateway would notice source addresses originating outside the administrative domain.
[1] 在IPsec安全网关后面嗅探LAN的入侵检测系统会注意到源地址来自管理域之外。
[2] Reply packets might not reach their destination, since the IPsec security gateway typically does not advertise the default route, but rather only the prefix that it allocates addresses from. Since the remote peer's address does not originate from with a
[2] 回复数据包可能无法到达目的地，因为IPsec安全网关通常不公布默认路由，而只公布其分配地址的前缀。因为远程对等方的地址不是源于
prefix native to the administrative domain, it is likely that routers within the domain would not have a route for it, and would send the packet off to the router advertising the default route (perhaps a border router) instead of to the IPsec security gateway.
前缀为管理域的本机前缀，域内的路由器可能没有路由，并且会将数据包发送到公布默认路由的路由器（可能是边界路由器），而不是IPsec安全网关。
For these reasons, for inter-domain use, assignment of inner source addresses may be needed. At present this is not a very common scenario; however, if address assignment is provided, then DHCP-based address assignment within IPsec tunnel mode [RFC3456] MUST be supported. Note that this mechanism is not yet widely deployed within IPsec security gateways; existing IPsec tunnel mode servers typically implement this functionality via proprietary extensions to IKE.
由于这些原因，对于域间使用，可能需要分配内部源地址。目前这种情况并不常见；但是，如果提供了地址分配，则必须支持IPsec隧道模式[RFC3456]中基于DHCP的地址分配。请注意，此机制尚未在IPsec安全网关中广泛部署；现有的IPsec隧道模式服务器通常通过IKE的专有扩展来实现此功能。
As noted in [RFC3715], tunnel mode ESP can traverse NAT in a limited set of circumstances. For example, if there is only one protocol endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver does not perform source address validation, then tunnel mode ESP may successfully traverse NATs. Since ignoring source address validation introduces new security vulnerabilities, and negotiation of specific selectors is desirable so as to limit the traffic that can be sent down the tunnel, these conditions may not necessarily apply, and tunnel mode NAT traversal will not always be possible.
如[RFC3715]所述，隧道模式ESP可以在有限的环境中穿越NAT。例如，如果NAT后面只有一个协议端点，则协商“任意对任意”选择器，并且接收方不执行源地址验证，则隧道模式ESP可以成功地穿越NAT。由于忽略源地址验证会引入新的安全漏洞，并且需要协商特定选择器以限制可沿隧道发送的通信量，因此这些条件可能不一定适用，并且隧道模式NAT穿越并不总是可能的。
TCP carried within Transport mode ESP cannot traverse NAT, even though ESP itself does not include IP header fields within its message integrity check. This is because the 16-bit TCP checksum is calculated based on a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec ESP message integrity check. As a result, the TCP checksum will be invalidated by a NAT located between the two endpoints.
传输模式ESP中携带的TCP无法穿越NAT，即使ESP本身在其消息完整性检查中不包含IP头字段。这是因为16位TCP校验和是基于包含IP头字段的“伪头”计算的，并且校验和受IPsec ESP消息完整性检查的保护。因此，位于两个端点之间的NAT将使TCP校验和无效。
Since TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, it is not possible to omit checksum verification while remaining standards compliant. In order to enable traversal of NATs existing while remaining in compliance, iSCSI, iFCP or FCIP security implementations can implement IPsec/IKE NAT traversal, as described in [RFC3715], [UDPIPsec], and [NATIKE].
由于TCP校验和计算和验证在IPv4和IPv6中都是强制性的，因此在保持符合标准的情况下，不可能忽略校验和验证。为了能够遍历现有的NAT，同时保持遵从性，iSCSI、iFCP或FCIP安全实现可以实现IPsec/IKE NAT遍历，如[RFC3715]、[UDPIPsec]和[NATIKE]中所述。
The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications enable UDP encapsulation of IPsec to be negotiated if a NAT is detected in the path. By determining the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header including the NAT-adjusted address and ports. If this is done prior to calculating the IPsec message integrity check, TCP checksum verification will not fail.
IKE[NATIKE]和IPsec[UDPIPsec]NAT遍历规范允许在路径中检测到NAT时协商IPsec的UDP封装。通过确定NAT的IP地址，可以基于包括NAT调整地址和端口的伪报头计算TCP校验和。如果在计算IPsec消息完整性检查之前执行此操作，则TCP校验和验证不会失败。
There are situations where it is necessary for IKE to be implemented in firmware. In such situations, it is important to keep the size of the IKE implementation within strict limits. An upper bound on the size of an IKE implementation might be considered to be 800 KB, with 80 KB enabling implementation in a wide range of situations.
在某些情况下，需要在固件中实现IKE。在这种情况下，重要的是将IKE实现的大小保持在严格的限制范围内。IKE实现的大小上限可能被认为是800 KB，其中80 KB支持在各种情况下的实现。
As noted in Table 5.3-1 on the next page, IKE implementations currently exist which meet the requirements. Therefore, while removal of seldom used IKE functionality (such as the nonce authentication methods) would reduce complexity, implementations typically will not require this in order to fit within the code size budget.
如下一页表5.3-1所示，目前存在满足要求的IKE实现。因此，虽然删除很少使用的IKE功能（如nonce身份验证方法）将降低复杂性，但实现通常不需要这样做才能满足代码大小预算。
It is expected that IP block storage implementations will need to operate at high speed. For example, implementations operating at 1 Gbps are currently in design, with 10 Gbps implementations to follow shortly thereafter. At these speeds, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space.
预计IP块存储实现将需要高速运行。例如，目前正在设计以1 Gbps运行的实现，随后不久将实施10 Gbps的实现。在这些速度下，单个IPsec SA可以在32位IPsec序列号空间中快速循环。
For example, a single SA operating at 1 Gbps line rate and sending 64 octet packets would exhaust the 32-bit sequence number space in 2200 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur in 14.5 hours. At 10 Gbps, exhaustion would occur in 220 seconds or 3.67 minutes. With 1518 octet packets, this would occur within 1.45 hours.
例如，以1 Gbps线速率运行并发送64个八位数据包的单个SA将在2200秒或37分钟内耗尽32位序列号空间。对于1518个八位组数据包，耗尽将在14.5小时内发生。在10 Gbps时，耗尽将在220秒或3.67分钟内发生。对于1518个八位组数据包，这将在1.45小时内发生。
In the future, it may be desirable for implementations operating at speeds of 1 Gbps or greater to implement IPsec sequence number extension, described in [Seq]. Note that depending on the transform in use, it is possible that rekeying will be required prior to exhaustion of the sequence number space.
在未来，可能希望以1 Gbps或更高速度运行的实现实现IPsec序列号扩展，如[Seq]所述。注意，根据所使用的变换，在序列号空间耗尽之前可能需要重新键控。
In CBC-mode ciphers the ciphertext of one block depends on the plaintext of that block as well as the ciphertext of the previous block. This implies that if the ciphertext of two blocks are identical, and the plaintext of the next block is also identical,
在CBC模式密码中，一个块的密文取决于该块的明文以及前一块的密文。这意味着如果两个块的密文相同，而下一个块的明文也相同，
then the ciphertext of the next block will be identical. Thus, if identical ciphertext blocks can be found with matching subsequent blocks, an attacker can determine the existence of matching plaintext.
那么下一个块的密文将是相同的。因此，如果可以找到具有匹配后续块的相同密文块，则攻击者可以确定匹配明文的存在。
Such "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. On average, a ciphertext block of size n bits will be expected to repeat every 2^[n/2] blocks. Although a single "birthday attack" does not provide much information to an attacker, multiple such attacks might provide useful information. To make this unlikely, it is recommended that a rekey occur before 2^[n/2] blocks have been sent on a given SA. Bellare et. al. have formalized this in [DESANALY], showing that the insecurity of CBC mode increases as O(s^2/2^n), where n is the block size in bits, and s is the total number of blocks encrypted. These conclusions do not apply to counter mode.
Bellare等人在[DESANALY]对这种“生日袭击”进行了研究。平均而言，大小为n位的密文块将每2^[n/2]个块重复一次。虽然单个“生日攻击”不会向攻击者提供太多信息，但多个此类攻击可能会提供有用的信息。为了避免这种情况发生，建议在给定SA上发送2^[n/2]个块之前进行密钥更新。Bellare等人在[DESANALY]中对此进行了形式化，表明CBC模式的不安全性随着O（s^2/2^n）的增加而增加，其中n是以位为单位的块大小，s是加密的块总数。这些结论不适用于计数器模式。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code size | |
|Implementation | (octets) | Release |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Linux |
| Pluto | 258KB | FreeSWAN |
|(FreeSWAN) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Racoon | 400KB | NetBSD 1.5 |
| (KAME) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Isakmpd | 283KB | NetBSD 1.5 |
| (Erickson) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| WindRiver | 142KB | PowerPC |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 222KB | PowerPC |
| VPN1700 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 350K | PowerPC |
| VPN3000 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 228KB | MIPS |
| VPN7200 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code size | |
|Implementation | (octets) | Release |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Linux |
| Pluto | 258KB | FreeSWAN |
|(FreeSWAN) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Racoon | 400KB | NetBSD 1.5 |
| (KAME) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Isakmpd | 283KB | NetBSD 1.5 |
| (Erickson) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| WindRiver | 142KB | PowerPC |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 222KB | PowerPC |
| VPN1700 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 350K | PowerPC |
| VPN3000 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 228KB | MIPS |
| VPN7200 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 5.3-1 - Code Size for IKE implementations
表5.3-1——IKE实现的代码大小
The formula below sets a limit on the bytes that can be sent on a CBC SA before a rekey is required:
下面的公式设置了在需要重新密钥之前可以在CBC SA上发送的字节数限制：
B = (n/8) * 2^[n/2]
Where:
B = maximum bytes sent on the SA
n = block size in bits
B = (n/8) * 2^[n/2]
Where:
B = maximum bytes sent on the SA
n = block size in bits
This means that cipher block size as well as key length needs to be considered in the rekey decision. 3DES uses a block size n = 64 bits (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey is required every 27.5 seconds.
这意味着在重新密钥决定中需要考虑密码块大小和密钥长度。3DES使用块大小n=64位（2^3字节）；这意味着在发送B=（64/8）*（2^32）=2^35字节之前，必须重新设置SA的密钥。在1 Gbps时，这意味着每274.9秒（4.6分钟）需要重新密钥；在10 Gbps时，每27.5秒需要重新密钥。
In terms of the sequence number space, for a 3DES encrypted message of 512 = 2^9 bytes (2^6 blocks) this implies that the key has become insecure after about 2^26 messages.
就序列号空间而言，对于512=2^9字节（2^6个块）的3DES加密消息，这意味着在大约2^26条消息之后密钥变得不安全。
Since IP block storage implementations may operate at speeds of 1 Gbps or greater, the ability to offer IPsec security services at high speeds is of intense concern. Since support for multiple algorithms multiplies the complexity and expense of hardware design, one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms implementable in hardware at speeds of up to 10 Gbps, as well as being efficient for implementation in software at speeds of 100 Mbps or slower.
由于IP块存储实现可能以1 Gbps或更高的速度运行，因此高速提供IPsec安全服务的能力备受关注。由于对多种算法的支持增加了硬件设计的复杂性和费用，转换选择工作的目标之一是找到一组最小的可在硬件中以高达10 Gbps的速度实现的保密性和身份验证算法，以及以100Mbps或更低的速度在软件中高效实现。
In this specification, we primarily concern ourselves with IPsec transforms that have already been specified, and for which parts are available that can run at 1 Gbps line rate. Where existing algorithms do not gracefully scale to 10 Gbps, we further consider algorithms for which transform specifications are not yet complete, but for which parts are expected to be available for inclusion in products shipping within the next 12 months. As the state of the art advances, the range of feasible algorithms will broaden and additional mandatory-to-implement algorithms may be considered.
在本规范中，我们主要关注已经指定的IPsec转换，以及可以以1 Gbps线速率运行的可用部分。在现有算法不优雅地缩放到10 Gbps的情况下，我们进一步考虑变换规范尚未完成的算法，但是预期哪些部分可以在未来12个月内包含在产品运输中。随着最新技术的发展，可行算法的范围将扩大，可能会考虑额外的强制算法来实现。
Section 5 of [RFC2406] states:
[RFC2406]第5节规定：
"A compliant ESP implementation MUST support the following mandatory-to-implement algorithms:
“符合要求的ESP实施必须支持以下强制算法：
- DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 - NULL Authentication algorithm - NULL Encryption algorithm"
- CBC模式下的DES-带MD5的HMAC-带SHA-1的HMAC-空身份验证算法-空加密算法”
The DES algorithm is specified in [FIPS46-3]; implementation guidelines are found in [FIPS74], and security issues are discussed in [DESDIFF],[DESINT], [DESCRACK]. The DES IPsec transform is defined in [RFC2405] and the 3DES in CBC mode IPsec transform is specified in [RFC2451].
DES算法在[FIPS46-3]中有规定；实现指南见[FIPS74]，安全问题见[DESDIFF]、[DESINT]、[DesTrack]。DES IPsec转换在[RFC2405]中定义，CBC模式下的3DES IPsec转换在[RFC2451]中指定。
The MD5 algorithm is specified in [RFC1321]; HMAC is defined in [RFC2104] and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 IPsec transform is specified in [RFC2403]. The HMAC-SHA1 IPsec transform is specified in [RFC2404].
[RFC1321]中规定了MD5算法；HMAC在[RFC2104]中定义，MD5的安全问题在[MD5Attack]中讨论。[RFC2403]中指定了HMAC-MD5 IPsec转换。[RFC2404]中指定了HMAC-SHA1 IPsec转换。
In addition to these existing algorithms, NIST is currently evaluating the following modes [NSPUE2] of AES, defined in [FIPS197]:
除这些现有算法外，NIST目前正在评估[FIPS197]中定义的AES的以下模式[NSPUE2]：
AES in Electronic Codebook (ECB) confidentiality mode AES in Cipher Block Chaining (CBC) confidentiality mode AES in Cipher Feedback (CFB) confidentiality mode AES in Output Feedback (OFB) confidentiality mode AES in Counter (CTR) confidentiality mode AES CBC-MAC authentication mode
电子码本中的AES（ECB）保密模式密码分组链接中的AES（CBC）保密模式密码反馈中的AES（CFB）保密模式输出反馈中的AES（OFB）保密模式计数器中的AES（CTR）保密模式AES CBC-MAC身份验证模式
When utilizing AES modes, it may be necessary to use larger public keys; the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526].
当使用AES模式时，可能需要使用较大的公钥；[KeyLen]中描述了这些权衡。[RFC3526]中描述了用于IKE的其他MODP Diffie-Hellman组。
The Modes [NSPUE2] effort is also considering a number of additional algorithms, including the following:
模式[NSPUE2]工作还考虑了许多其他算法，包括以下算法：
PMAC
PMAC
To provide authentication, integrity and replay protection, IP block storage security implementations MUST support HMAC-SHA1 [RFC2404] for authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be supported [RFC3566].
为了提供身份验证、完整性和重播保护，IP块存储安全实现必须支持HMAC-SHA1[RFC2404]进行身份验证，并且应支持CBC MAC模式下带有XCBC扩展的AES[RFC3566]。
HMAC-SHA1 [RFC2404] is to be preferred to HMAC-MD5, due to concerns that have been raised about the security of MD5 [MD5Attack]. HMAC-SHA1 parts are currently available that run at 1 Gbps, the algorithm is implementable in hardware at speeds up to 10 Gbps, and an IPsec transform specification [RFC2404] exists. As a result, it is most practical to utilize HMAC-SHA1 as the authentication algorithm for products shipping in the near future. AES in CBC-MAC authentication mode with XCBC extensions was selected since it avoids adding substantial additional code if AES is already being implemented for encryption; an IPsec transform document is available [RFC3566].
HMAC-SHA1[RFC2404]比HMAC-MD5更受欢迎，因为有人担心MD5[MD5Attack]的安全性。HMAC-SHA1部件目前可用，运行速度为1 Gbps，该算法可在硬件中以高达10 Gbps的速度实现，并且存在IPsec转换规范[RFC2404]。因此，在不久的将来，将HMAC-SHA1用作产品装运的认证算法是最实际的。选择了带有XCBC扩展的CBC-MAC认证模式中的AES，因为如果AES已经被用于加密，它可以避免添加大量额外代码；IPsec转换文档可用[RFC3566]。
Authentication transforms also exist that are considerably more efficient to implement than HMAC-SHA1, or AES in CBC-MAC authentication mode. UMAC [UMAC],[UMACKR] is more efficient to implement in software and PMAC [PMAC] is more efficient to implement in hardware. PMAC is currently being evaluated as part of the NIST modes effort [NSPUE2] but an IPsec transform does not yet exist; neither does a UMAC transform.
还存在比HMAC-SHA1或CBC-MAC身份验证模式下的AES更高效的身份验证转换。UMAC[UMAC]，[UMACKR]在软件中实现更高效，而PMAC[PMAC]在硬件中实现更高效。PMAC目前正在作为NIST模式工作[NSPUE2]的一部分进行评估，但IPsec转换尚不存在；UMAC也不会转换。
For confidentiality, the ESP mandatory-to-implement algorithm (DES) is unacceptable. As noted in [DESCRACK], DES is crackable with modest computation resources, and so is inappropriate for use in situations requiring high levels of security.
为保密起见，ESP强制实施算法（DES）是不可接受的。如[DESCRACK]中所述，DES可以使用有限的计算资源进行破解，因此不适合在需要高安全级别的情况下使用。
To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC mode [RFC2451] MUST be supported and AES in Counter Mode [RFC3686] SHOULD be supported. For use in high speed implementations, 3DES has significant disadvantages. However, a 3DES IPsec transform has been specified and parts are available that can run at 1 Gbps, so implementing 3DES in products is practical for the short term.
要为iSCSI、iFCP和FCIP提供机密性，必须支持CBC模式[RFC2451]下的3DE，并支持计数器模式[RFC3686]下的AES。在高速实现中使用3DES有很大的缺点。但是，已经指定了3DES IPsec转换，并且提供了可以以1 Gbps速度运行的部件，因此在产品中实现3DES在短期内是可行的。
As described in Appendix B, 3DES software implementations make excessive computational demands at speeds of 100 Mbps or greater, effectively ruling out software-only implementations. In addition, 3DES implementations require rekeying prior to exhaustion of the current 32-bit IPsec sequence number space, and thus would not be able to make use of sequence space extensions if they were available. This means that 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. Thus, 3DES is inconvenient for use at very high speeds, as well as being impractical for implementation in software at slower speeds (100+ Mbps).
如附录B所述，3DES软件实现在100 Mbps或更高的速度下会产生过多的计算需求，从而有效地排除了纯软件实现。此外，3DES实现需要在耗尽当前32位IPsec序列号空间之前重新设置密钥，因此如果序列空间扩展可用，将无法使用它们。这意味着3DE将需要以10 Gbps或更快的速度进行非常频繁的密钥更新。因此，3DES在非常高的速度下使用是不方便的，并且在低速（100+Mbps）的软件中实现也是不切实际的。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size or size of other certificate fields (such as the distinguished name and other OIDs) is large enough. Many Network Address Translators (NATs) and firewalls do not handle fragments properly, dropping them on inbound and/or outbound.
使用证书身份验证时，可能会遇到IKE碎片。当使用证书链时，或者如果密钥大小或其他证书字段（如可分辨名称和其他OID）的大小足够大，甚至在交换单个证书时，都可能发生这种情况。许多网络地址转换器（NAT）和防火墙不能正确处理片段，将它们丢弃在入站和/或出站。
Routers in the path will also frequently discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an Access List.
路径中的路由器也会经常丢弃初始片段之后的片段，因为它们通常不包含可以与访问列表进行比较的完整IP头。
As a result, where IKE fragmentation occurs, the endpoints will often be unable to establish an IPsec security association. The solution to this problem is to install NAT, firewall or router code load that can properly support fragments. If this cannot be done, then the following alternatives can be considered:
因此，当IKE碎片出现时，端点通常无法建立IPsec安全关联。这个问题的解决方案是安装NAT、防火墙或路由器代码加载，它们可以正确地支持片段。如果无法做到这一点，则可以考虑以下替代方案：
[1] Obtaining certificates by other means.
[1] 以其他方式取得证书。
[2] Reducing the size of the certificate chain.
[2] 减少证书链的大小。
[3] Reducing the size of fields within the certificates. This includes reduction in the key size, the distinguished name or other fields. This should be considered only as a last resort.
[3] 减少证书中字段的大小。这包括减少密钥大小、可分辨名称或其他字段。这只能作为最后手段考虑。
Fragmentation can become a concern when prepending IPsec headers to a frame. One mechanism that can be used to reduce this problem is to utilize path MTU discovery. For example, when TCP is used as the transport for iSCSI, iFCP or FCIP then path MTU discovery, described in [RFC1191], [RFC1435], [RFC1981], can be used to enable the TCP endpoints to discover the correct MTU, including effects due to IPsec encapsulation.
在将IPsec头预先添加到帧时，碎片可能会成为一个问题。可用于减少此问题的一种机制是利用路径MTU发现。例如，当TCP用作iSCSI、iFCP或FCIP的传输时，[RFC1191]、[RFC1435]、[RFC1981]中描述的路径MTU发现可用于使TCP端点发现正确的MTU，包括IPsec封装产生的影响。
However, Path MTU discovery fails when appropriate ICMP messages are not received by the host. This occurs in IPsec implementations that drop unauthenticated ICMP packets. This can result in blackholing in naive TCP implementations, as described in [RFC2923]. Appropriate TCP behavior is described in section 2.1 of [RFC2923]:
但是，当主机未接收到适当的ICMP消息时，路径MTU发现失败。这发生在丢弃未经验证的ICMP数据包的IPsec实现中。如[RFC2923]所述，这可能会导致原始TCP实现中的黑洞。[RFC2923]第2.1节描述了适当的TCP行为：
"TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed."
“TCP应该注意到连接正在超时。在几次超时后，TCP应该尝试发送较小的数据包，可能会关闭每个数据包的DF标志。如果成功，它应该在一段合理的时间内继续关闭连接的PMTUD，然后它应该再次探测，以确定路径是否正确。”他变了。”
If an ICMP PMTU is received by an IPsec implementation that processes unauthenticated ICMP packets, this value should be stored in the SA as proposed in [RFC2401], and IPsec should also provide notification of this event to TCP so that the new MTU value can be correctly reflected.
如果处理未经验证的ICMP数据包的IPsec实现接收到ICMP PMTU，则该值应按照[RFC2401]中的建议存储在SA中，IPsec还应向TCP提供此事件的通知，以便正确反映新的MTU值。
When a connection is opened which requires security, IP block storage security implementations may wish to check that the connection is protected by IPsec. If security is desired and IPsec protection is removed on a connection, it is reinstated before non-protected IP block storage packets are sent. Since IPsec verifies that each packet arrives on the correct SA, as long as it can be ensured that IPsec protection is in place, then IP block storage implementations can be assured that each received packet was sent by a trusted peer.
当打开需要安全性的连接时，IP块存储安全实施可能希望检查该连接是否受IPsec保护。如果需要安全性，并且删除了连接上的IPsec保护，则会在发送未受保护的IP块存储数据包之前将其恢复。由于IPsec验证每个数据包是否到达正确的SA，只要可以确保IPsec保护到位，那么IP块存储实现就可以确保每个接收到的数据包都是由受信任的对等方发送的。
When used with IP block storage protocols, each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. IP block storage security implementations need not verify that the IP addresses and TCP port values in the packet match the socket
当与IP块存储协议一起使用时，每个TCP连接必须由IKE阶段2 SA保护。来自一个或多个TCP连接的流量可能在每个IPsec阶段2 SA内流动。IP块存储安全实现不需要验证数据包中的IP地址和TCP端口值是否与套接字匹配
information that was used to setup the connection. This check will be performed by IPsec, preventing malicious peers from sending commands on inappropriate Quick Mode SAs.
用于设置连接的信息。此检查将由IPsec执行，以防止恶意对等方在不适当的快速模式SAs上发送命令。
The certificate credentials provided by the iSCSI initiator during the IKE negotiation may be those of the machine or of the iSCSI entity. When machine authentication is used, the machine certificate is typically stored on the iSCSI initiator and target during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard. For iFCP and FCIP, the certificate credentials provided will almost always be those of the device and will be stored on the device.
在IKE协商期间，iSCSI启动器提供的证书凭据可以是计算机或iSCSI实体的证书凭据。使用机器身份验证时，机器证书通常在注册过程中存储在iSCSI启动器和目标上。使用用户证书时，用户证书可以存储在计算机上或智能卡上。对于iFCP和FCIP，提供的证书凭据几乎总是设备的证书凭据，并将存储在设备上。
Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate.
由于机器证书的值与攻击者在虚假情况下获取证书的难易程度成反比，因此建议严格控制机器证书注册过程。例如，只有管理员才能使用计算机证书注册计算机。
While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided within iSCSI login (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. Since iFCP and FCIP have no equivalent of iSCSI Login, for these protocols only the machine is authenticated.
虽然智能卡证书存储减少了私钥泄露的可能性，但并非所有情况下都需要智能卡。例如，一些部署计算机证书的组织使用这些证书来限制使用未经批准的硬件。由于可以在iSCSI登录中提供用户身份验证（请记住前面描述的弱点），因此在IPsec中对机器身份验证的支持使得可以对机器和用户进行身份验证。由于iFCP和FCIP没有等效的iSCSI登录，因此对于这些协议，只有计算机经过身份验证。
In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable.
在这种双重保证被认为是有价值的情况下，如果机器证书存储在智能卡上，则可能不希望机器证书从一台机器移动到另一台机器。
Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be
同样，在部署用户证书时，建议严格控制用户注册过程。例如，如果可以随时使用用户密码来获取证书（临时证书或长期证书），则该证书的安全值不超过密码。为了限制攻击者从被盗密码获取用户证书的能力，可以限制注册期，注册期过后将禁止密码访问
turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired.
关掉。这样的策略将防止攻击者在注册期到期后获取未使用帐户的密码，从而获取用户证书。
Use of pre-shared keys in IKE Main Mode is vulnerable to man-in-the-middle attacks when used with dynamically addressed hosts (such as with iSCSI initiators). In Main Mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, where dynamic IP address assignment is typical, it is often not possible to identify the required pre-shared key based on the IP address.
在IKE主模式下使用预共享密钥在与动态寻址主机（如iSCSI启动器）一起使用时容易受到中间人攻击。在主模式下，必须在接收识别有效载荷之前使用SKEYID_e。因此，预共享密钥的选择可能仅基于IP报头中包含的信息。然而，在典型的动态IP地址分配情况下，通常不可能基于IP地址识别所需的预共享密钥。
Thus when pre-shared key authentication is used in Main Mode along with entities whose address is dynamically assigned, the same pre-shared key is shared by a group and is no longer able to function as an effective shared secret. In this situation, neither the initiator nor Responder identifies itself during IKE Phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle. This vulnerability is typically not of concern where IP addresses are typically statically assigned (such as with iFCP and FCIP), since in this situation individual pre-shared keys are possible within IKE Main Mode.
因此，当在主模式下使用预共享密钥身份验证以及动态分配地址的实体时，相同的预共享密钥由组共享，并且不再能够作为有效的共享密钥发挥作用。在这种情况下，在IKE阶段1期间，发起者和响应者都不能识别自己；只知道双方都是了解预共享密钥的小组成员。这允许任何有权访问组预共享密钥的人充当中间人。当IP地址通常是静态分配的（例如使用iFCP和FCIP）时，此漏洞通常不受关注，因为在这种情况下，IKE主模式中可能存在单独的预共享密钥。
However, where IP addresses are dynamically assigned and Main Mode is used along with pre-shared keys, the Responder is not authenticated unless application-layer mutual authentication is performed (e.g., iSCSI login authentication). This enables an attacker in possession of the group pre-shared key to masquerade as the Responder. In addition to enabling the attacker to present false data, the attacker would also be able to mount a dictionary attack on legacy authentication methods such as CHAP [RFC1994], potentially compromising many passwords at a time. This vulnerability is widely present in existing IPsec implementations.
但是，如果IP地址是动态分配的，并且主模式与预共享密钥一起使用，则除非执行应用层相互身份验证（例如iSCSI登录身份验证），否则不会对响应者进行身份验证。这使拥有组预共享密钥的攻击者能够伪装成响应者。除了使攻击者能够提供虚假数据外，攻击者还能够对传统身份验证方法（如CHAP[RFC1994]）发起字典攻击，一次可能破坏许多密码。此漏洞广泛存在于现有IPsec实现中。
Group pre-shared keys are not required in Aggressive Mode since the identity payload is sent earlier in the exchange, and therefore the pre-shared key can be selected based on the identity. However, when Aggressive Mode is used the user identity is exposed and this is often considered undesirable.
在主动模式下不需要组预共享密钥，因为身份有效负载在交换中较早地发送，因此可以根据身份选择预共享密钥。然而，当使用攻击模式时，用户身份被暴露，这通常被认为是不可取的。
Note that care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned,
注意，需要注意IKE阶段1身份有效负载选择，以便即使在攻击模式下也能将身份映射到预共享密钥。其中使用了ID_IPV4_ADDR或ID_IPV6_ADDR标识有效载荷并动态分配了地址，
mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned.
身份到密钥的映射是不可能的，因此组预共享密钥仍然是实际需要的。因此，在使用主动模式以及预共享密钥和动态分配IP地址的情况下，应使用ID_IPV4_ADDR和ID_IPV6_ADDR以外的身份（如ID_FQDN或ID_USER_FQDN）。
In addition to IKE authentication, iSCSI implementations utilize their own authentication methods. Currently, work is underway on Fibre Channel security, so that a similar authentication process may eventually also apply to iFCP and FCIP as well.
除了IKE身份验证之外，iSCSI实施还利用自己的身份验证方法。目前，光纤通道安全方面的工作正在进行中，因此类似的身份验证过程可能最终也适用于iFCP和FCIP。
While iSCSI provides initial authentication, it does not provide per-packet authentication, integrity or replay protection. This implies that the identity verified in the iSCSI Login is not subsequently verified on reception of each packet.
虽然iSCSI提供初始身份验证，但它不提供每包身份验证、完整性或重播保护。这意味着在接收到每个数据包时，不会随后验证iSCSI登录中验证的身份。
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet.
对于IPsec，当IKE中声明的身份经过身份验证时，生成的派生密钥用于提供每个数据包的身份验证、完整性和重播保护。结果，随后在接收到每个分组时验证在IKE会话中验证的身份。
Let us assume that the identity claimed in iSCSI Login is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way for the recipient to verify that only the user authenticated via iSCSI Login is using the IPsec SA.
假设iSCSI登录中声明的身份是用户身份，而IKE中声明的身份是机器身份。由于每个数据包只验证机器标识，因此收件人无法验证只有通过iSCSI登录进行身份验证的用户才使用IPsec SA。
In fact, IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once an IPsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. This is true for both transport mode and tunnel mode SAs.
事实上，仅支持机器身份验证的IPsec实现通常无法区分内核中的用户流量。因此，在使用机器身份验证的情况下，一旦打开IPsec SA，多用户机器上的另一个用户可能能够向IPsec SA发送通信量。这对于传输模式和隧道模式SAs都适用。
To limit the potential vulnerability, IP block storage implementations MUST do the following:
为了限制潜在的漏洞，IP块存储实现必须执行以下操作：
[1] Ensure that socket access is appropriately controlled. On a multi-user operating system, this implies that sockets opened for use by IP block storage protocols MUST be exclusive.
[1] 确保插座访问得到适当控制。在多用户操作系统上，这意味着为IP块存储协议使用而打开的套接字必须是独占的。
[2] In the case of iSCSI, implementations MUST also ensure that application layer login credentials (such as iSCSI login credentials) are protected from unauthorized access.
[2] 对于iSCSI，实施还必须确保应用层登录凭据（如iSCSI登录凭据）受到保护，以防止未经授权的访问。
If these directives are followed, then a rogue process will not be able to access an IP block storage volume.
如果遵循这些指令，则恶意进程将无法访问IP块存储卷。
While the identity asserted within IKE is verified on a per-packet basis, to avoid interference between users on a given machine, operating system support is required. In order to segregate traffic between users when user authentication is supported, the IPsec endpoints must ensure that only traffic from that particular user is sent or received within the IPsec SA. Enforcement of this restriction is the responsibility of the operating system.
虽然IKE中声明的身份是基于每个数据包进行验证的，但为了避免给定机器上用户之间的干扰，需要操作系统支持。为了在支持用户身份验证时隔离用户之间的通信，IPsec端点必须确保在IPsec SA内仅发送或接收来自该特定用户的通信。执行此限制是操作系统的责任。
In kernel mode iSCSI drivers there typically is no user context to perform user authentication. In this case the authentication is closer to machine authentication. In most operating systems device permissions would control the ability to read/write to the device prior to mounting. Once the device is mounted, ACLs set by the filesystem control access to the device. An administrator can access the blocks on the device directly (for instance, by sending pass through requests to the port driver directly such as in Windows NT). In the same way, an administrator can open a raw socket and send IPsec protected packets to an iSCSI target. The situation is analogous, and in this respect no new vulnerability is created that didn't previously exist. The Operating system's ACLs need to be effective to protect a device (whether it is a SCSI device or an iSCSI device).
在内核模式iSCSI驱动程序中，通常没有执行用户身份验证的用户上下文。在这种情况下，身份验证更接近于机器身份验证。在大多数操作系统中，设备权限将控制在安装之前读取/写入设备的能力。安装设备后，文件系统设置的ACL将控制对设备的访问。管理员可以直接访问设备上的块（例如，通过直接向端口驱动程序发送直通请求，如在Windows NT中）。同样，管理员可以打开原始套接字并向iSCSI目标发送受IPsec保护的数据包。情况类似，在这方面，不会产生以前不存在的新漏洞。操作系统的ACL需要有效地保护设备（无论是SCSI设备还是iSCSI设备）。
IP block storage protocols can use a variety of mechanisms for authorization. Where ID_FQDN is used as the Identity Payload, IP block storage endpoints can be configured with a list of authorized FQDNs. The configuration can occur manually, or automatically via iSNS or the iSCSI MIB, defined in [AuthMIB].
IP块存储协议可以使用多种授权机制。当ID_FQDN用作标识有效负载时，可以使用授权FQDN列表配置IP块存储端点。配置可以手动进行，也可以通过iSNS或[AuthMIB]中定义的iSCSI MIB自动进行。
Assuming that IPsec authentication is successful, this list of FQDNs can be examined to determine authorization levels. Where certificate authentication is used, it is possible to configure IP block storage protocol endpoints with trusted roots. The trusted roots used with IP block storage protocols might be different from the trusted roots used for other purposes. If this is the case, then the burden of negotiating use of the proper certificates lies with the IPsec initiator.
Assuming that IPsec authentication is successful, this list of FQDNs can be examined to determine authorization levels. Where certificate authentication is used, it is possible to configure IP block storage protocol endpoints with trusted roots. The trusted roots used with IP block storage protocols might be different from the trusted roots used for other purposes. If this is the case, then the burden of negotiating use of the proper certificates lies with the IPsec initiator.translate error, please retry
Note that because IKE does not deal well with certificate chains, and is typically configured with a limited set of trusted roots, it is most appropriate for intra-domain usage.
请注意，由于IKE不能很好地处理证书链，并且通常配置有一组有限的受信任根，因此它最适合于域内使用。
Since iSCSI supports Login authentication, it is also possible to use the identities presented within the iSCSI Login for authorization purposes.
由于iSCSI支持登录身份验证，因此还可以使用iSCSI登录中显示的身份进行授权。
In iFCP, basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains in iSNS yields access control schemas of greater complexity.
在iFCP中，基本访问控制属性源于一个或多个iSNS服务器在进行iFCP交换之前必须知道两个正在通信的iFCP网关。在iSNS中选择性地使用发现域会产生更复杂的访问控制模式。
When utilizing AES modes, it may be necessary to use larger public keys; the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526].
当使用AES模式时，可能需要使用较大的公钥；[KeyLen]中描述了这些权衡。[RFC3526]中描述了用于IKE的其他MODP Diffie-Hellman组。
When AES in counter mode is used, it is important to avoid reuse of the counter with the same key, even across all time. Counter mode creates ciphertext by XORing generated key stream with plaintext. It is fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing together the two packets. The implication of this is that it is an error to use IPsec manual keying with counter mode, except when the implementation takes heroic measures to maintain state across sessions. In any case, manual keying MUST NOT be used since it does not provide the necessary rekeying support.
使用计数器模式下的AES时，重要的是避免重复使用具有相同密钥的计数器，即使是在所有时间。计数器模式通过将生成的密钥流与明文异或生成密文。只需将两个数据包XORing在一起，就可以很容易地从以相同计数器值加密的两个消息计数器模式中恢复明文。这意味着在计数器模式下使用IPsec手动键控是错误的，除非实现采取了大胆的措施来维护会话间的状态。在任何情况下，不得使用手动键控，因为它不提供必要的重新键控支持。
Another counter mode issue is it makes forgery of correct packets trivial. Counter mode should therefore never be used without also using data authentication.
另一个计数器模式问题是，它使得伪造正确的数据包变得微不足道。因此，在不使用数据身份验证的情况下，决不能使用计数器模式。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values of the SRP_GROUP key parameter within iSCSI, in accordance with BCP 26, [RFC2434].
本节根据BCP 26[RFC2434]的规定，就在iSCSI中注册SRP_组密钥参数的值向Internet分配号码管理局（IANA）提供指导。
IANA considerations for the iSCSI protocol are described in [RFC3720], Section 13; for the iFCP protocol in [iFCP], Section 12; and for the FCIP protocol in [FCIP], Appendix B.
[RFC3720]第13节描述了iSCSI协议的IANA注意事项；对于[iFCP]第12节中的iFCP协议；对于[FCIP]中的FCIP协议，见附录B。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
以下术语的含义见BCP 26：“名称空间”、“赋值”、“注册”。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
此处使用以下政策，其含义见BCP 26：“私人使用”、“先到先得”、“专家评审”、“所需规范”、“IETF共识”、“标准行动”。
For registration requests where a Designated Expert should be consulted, the responsible IESG Area Director should appoint the Designated Expert.
对于需要咨询指定专家的注册请求，IESG区域负责人应任命指定专家。
For registration requests requiring Expert Review, the IPS mailing list should be consulted, or if the IPS WG is disbanded, to a mailing list designated by the IESG Area Director.
对于需要专家审查的注册请求，应咨询IPS邮件列表，或者如果IPS工作组解散，则应咨询IESG区域总监指定的邮件列表。
This document defines the following SRP_GROUP keys:
本文档定义了以下SRP_组密钥：
SRP-768, SRP-1024, SRP-1280, SRP-1536, SRP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192
SRP-768、SRP-1024、SRP-1280、SRP-1536、SRP-2048、MODP-3072、MODP-4096、MODP-6144、MODP-8192
New SRP_GROUP keys MUST conform to the iSCSI extension item-label format described in [RFC3720] Section 13.5.4.
新的SRP_组密钥必须符合[RFC3720]第13.5.4节中描述的iSCSI扩展项标签格式。
Registration of new SRP_GROUP keys is by Designated Expert with Specification Required. The request is posted to the IPS WG mailing list or its successor for comment and security review, and MUST include a non-probabalistic proof of primality for the proposed SRP group. After a period of one month as passed, the Designated Expert will either approve or deny the registration request.
新SRP_组密钥的注册由指定专家按照要求的规格进行。该请求被发布到IPS工作组邮件列表或其后续邮件列表中，以供评论和安全审查，并且必须包括拟议SRP组的非概率首要性证明。一个月后，指定专家将批准或拒绝注册请求。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]Knowles，S.，“来自Path MTU发现经验的IESG建议”，RFC 1435，1993年3月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控-哈希”，RFC 2104，1997年2月。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年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 of ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)," RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]Wu，T.，“SRP认证和密钥交换系统”，RFC 29452000年9月。
[RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，，B.，Lemon，T.，Perkins，C.和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 33152003年7月。
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456]Patel，B.，Aboba，B.，Kelly，S.和V.Gupta，“IPsec隧道模式的动态主机配置协议（DHCPv4）配置”，RFC 3456，2003年1月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[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月。
[RFC3643] Weber, R., Rajagopal, M., Trovostino, F., O'Donnel., M, Monia, C.and M. Mehrar, "Fibre Channel (FC) Frame Encapsuation", RFC 3643, December 2003.
[RFC3643]韦伯，R.，拉贾戈帕尔，M.，特罗沃斯蒂诺，F.，O'Donnel.，M，莫尼亚，C.和M.梅拉尔，“光纤通道（FC）帧封装”，RFC 36432003年12月。
[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月。
[3DESANSI] American National Standard for Financial Services X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation", American Bankers Association, Washington, D.C., July 29, 1998
[3DESANSI]美国金融服务国家标准X9.52-1998，“三重数据加密算法操作模式”，美国银行家协会，华盛顿特区，1998年7月29日
[SRPNDSS] Wu, T., "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111
[SRPNDSS]Wu，T.，“安全远程密码协议”，1998年互联网协会网络和分布式系统安全研讨会论文集，加利福尼亚州圣地亚哥，第97-111页
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[RFC2230]阿特金森，R.，“DNS的密钥交换委托记录”，RFC 2230，1997年11月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.，Atkinson，R.，“IP认证头”，RFC 2402，1998年11月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]Madson，C.和R.Glenn，“HMAC-MD5-96在ESP和AH中的使用”，RFC 2403，1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.“差异化服务和隧道”，RFC 29832000年10月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“简单安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3347] Krueger, M. and R. Haagens, "Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations", RFC 3347, July 2002.
[RFC3347]Krueger，M.和R.Haagens，“互联网上的小型计算机系统接口协议（iSCSI）要求和设计考虑”，RFC 3347，2002年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月。
[AESPERF] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions", http://www.counterpane.com/aes-performance.html
[AESPERF]Schneier，B.，J.Kelsey，D.Whiting，D.Wagner，C.Hall和N.Ferguson，“AES提交文件的性能比较”，http://www.counterpane.com/aes-performance.html
[AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for iSCSI", Work in Progress, September 2002.
[AuthMIB]Bakke，M.，等人，“iSCSI托管对象的定义”，正在进行的工作，2002年9月。
[CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000.
[CRCTCP]Stone J.，Partridge，C.，“当CRC和TCP校验和不一致时”，ACM Sigcomm，2000年9月。
[DESANALY] Bellare, Desai, Jokippi, Rogaway, "A Concrete
Treatment of Symmetric Encryption: Analysis of the DES
Modes of Operation", 1997, http://www-
cse.ucsd.edu/users/mihir/papers/sym-enc.html
[DESANALY] Bellare, Desai, Jokippi, Rogaway, "A Concrete
Treatment of Symmetric Encryption: Analysis of the DES
Modes of Operation", 1997, http://www-
cse.ucsd.edu/users/mihir/papers/sym-enc.html
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
[描述]加利福尼亚州塞巴斯塔波尔市奥雷利联合公司Cracking DES，O'Reilly&Associates，2000年。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.
[DESDIFF]Biham，E.，Shamir，A.，“类DES密码系统的差分密码分析”，《密码学杂志》第4卷，1991年1月。
[DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995
[设计]Bellovin，S.，“DES-CBC在使用时不具有强完整性的问题”，第32届IETF会议记录，马萨诸塞州丹弗斯，1995年4月
[FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", Work in Progress, August 2002.
[FCIP]Rajagopal，M.等人，“TCP/IP上的光纤通道（FCIP）”，正在进行的工作，2002年8月。
[FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLPv2", Work in Progress, September 2002.
[FCIPSLP]Petersen，D.，“使用SLPv2查找FCIP实体”，正在进行的工作，2002年9月。
[FIPS46-3] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 25, 1999.
[FIPS46-3]美国文件/NIST，“数据加密标准（DES）”，FIPS 46-3，1999年10月25日。
[FIPS74] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data encryption standard", FIPS 74, Apr 1981.
[FIPS74]美国DoC/NIST，“实施和使用nbs数据加密标准的指南”，FIPS 74，1981年4月。
[FIPS197] U.S. DoC/NIST, "Advanced Encryption Standard (AES)",
FIPS 197, November 2001,
http://csrc.nist.gov/CryptoToolkit/aes
[FIPS197] U.S. DoC/NIST, "Advanced Encryption Standard (AES)",
FIPS 197, November 2001,
http://csrc.nist.gov/CryptoToolkit/aes
[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress, August 2002.
[iFCP]Monia，C.等人，“iFCP-互联网光纤通道存储网络协议”，正在进行的工作，2002年8月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[iSCSISLP] Bakke, M., "Finding iSCSI targets and Name Servers Using SLP", Work in Progress, March 2002.
[iSCSISLP]Bakke，M.，“使用SLP查找iSCSI目标和名称服务器”，正在进行的工作，2002年3月。
[iSNS] Gibbons, K., et al., "iSNS Internet Storage Name Service", Work in Progress, August 2002.
[iSNS]Gibbons，K.等人，“iSNS互联网存储名称服务”，正在进行的工作，2002年8月。
[KeyLen] Orman, H., Hoffman, P., "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", Work in Progress, December 2001.
[KeyLen]Orman，H.，Hoffman，P.，“确定用于交换对称密钥的公钥的强度”，正在进行的工作，2001年12月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996
[MD5Attack]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes第2卷第2期，1996年夏季
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002.
[NATIKE]Kivinen，T.等人，“IKE中NAT穿越的协商”，正在进行的工作，2002年6月。
[NSPUE2] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-38A, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001.
[NSPUE2]“分组密码操作模式建议”，国家标准与技术研究所（NIST）特别出版物800-38A，代码：NSPUE2，美国政府印刷局，华盛顿特区，2001年7月。
[PENTPERF] A. Bosselaers, "Performance of Pentium
implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[PENTPERF] A. Bosselaers, "Performance of Pentium
implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[PMAC] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a
parallelizable message authentication code",
http://csrc.nist.gov/encryption/modes/proposedmodes/
pmac/pmac-spec.pdf
[PMAC] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a
parallelizable message authentication code",
http://csrc.nist.gov/encryption/modes/proposedmodes/
pmac/pmac-spec.pdf
[Seq] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, July 2002.
[Seq]Kent，S.，“IP封装安全有效负载（ESP）”，正在进行的工作，2002年7月。
[SRPDIST] Wu, T., "SRP Distribution", http://www-cs-
students.stanford.edu/~tjw/srp/download.html
[SRPDIST] Wu, T., "SRP Distribution", http://www-cs-
students.stanford.edu/~tjw/srp/download.html
[UDPIPsec] Huttunen, A., et. al., "UDP Encapsulation of IPsec Packets", Work in Progress, June 2002.
[UDPIPsec]Huttunen，A.，等人，“IPsec数据包的UDP封装”，正在进行的工作，2002年6月。
[UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T.,
Rogaway, P., "UMAC: Fast and provably secure message
authentication", Advances in Cryptology - CRYPTO '99,
LNCS vol. 1666, pp. 216-233. Full version available
from http://www.cs.ucdavis.edu/~rogaway/umac
[UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T.,
Rogaway, P., "UMAC: Fast and provably secure message
authentication", Advances in Cryptology - CRYPTO '99,
LNCS vol. 1666, pp. 216-233. Full version available
from http://www.cs.ucdavis.edu/~rogaway/umac
[UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A.,
Krawczyk, H., Rogaway, P., "UMAC: Message
Authentication Code using Universal Hashing", Work in
Progress, October 2000. Also available
at:http://www.cs.ucdavis.edu/~rogaway/umac/draft-
krovetz-umac-01.txt
[UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A.,
Krawczyk, H., Rogaway, P., "UMAC: Message
Authentication Code using Universal Hashing", Work in
Progress, October 2000. Also available
at:http://www.cs.ucdavis.edu/~rogaway/umac/draft-
krovetz-umac-01.txt
[UMACPERF] Rogaway, P., "UMAC Performance",
http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
[UMACPERF] Rogaway, P., "UMAC Performance",
http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
Thanks to Steve Bellovin of AT&T Research, William Dixon of V6 Security, David Black of EMC, Joseph Tardo and Uri Elzur of Broadcom, Julo Satran, Ted Ts'o, Ofer Biran, and Charles Kunzinger of IBM, Allison Mankin of ISI, Mark Bakke and Steve Senum of Cisco, Erik Guttman of Sun Microsystems and Howard Herbert of Intel for useful discussions of this problem space.
感谢AT&T Research的Steve Bellovin、V6 Security的William Dixon、EMC的David Black、Broadcom的Joseph Tardo和Uri Elzur、IBM的Julo Satran、Ted Ts'o、Ofer Biran和Charles Kunzinger、ISI的Allison Mankin、思科的Mark Bakke和Steve Senum，太阳微系统公司的埃里克·古特曼和英特尔公司的霍华德·赫伯特对这个问题空间进行了有益的讨论。
Appendix A - Well Known Groups for Use with SRP
附录A-与SRP一起使用的知名团体
Modulus (N) and generator (g) values for various modulus lengths are given below. The values below are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [SRPDIST], and subsequently rigorously verified to be prime. Implementations supporting SRP authentication MUST support groups up to 1536 bits, with 1536 bits being the default.
不同模量长度的模量（N）和生成器（g）值如下所示。以下数值取自Tom Wu和Eugene Jhong为斯坦福SRP发行版[SRPDIST]开发的软件，随后经过严格验证为prime。支持SRP身份验证的实现必须支持最多1536位的组，默认为1536位。
iSCSI Key="SRP-768" [768 bits] Modulus (base 16) = B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator = 2
iSCSI Key=“SRP-768”[768位]模（基16）=B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA680B1093E94B9A528C6C2BE33E0867C60C326B生成器=2
iSCSI Key="SRP-1024" [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2
iSCSI Key=“SRP-1024”[1024位]模数（基数16）=EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D696E0D5D8E250B98BE48E49C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D492559B297BCF1885C529F5666E57EC 68EDBC3C05726CC02FD4C4976EA513FE839FCD2069EB43502生成器
iSCSI Key="SRP-1280" [1280 bits] Modulus (base 16) = D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator = 2
iSCSI Key=“SRP-1280”[1280位]模数（基数16）=D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BB90BD3A9C980F5FC0DE744B1CDE1891 69089BC1F6500DE15B4B2AA6D87100C9ECC7E4EB84257B12049B1877B1087B9CF60567B9B9C5677B9B9B9B9B9B9B9B9B9B9B9B9B9B107070707070701677B9B9B9B9B9B9B9B9B9B9B9B9B9B9B9B
iSCSI Key="SRP-1536" [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2
iSCSI Key=“SRP-1536”[1536位]模数（基数16）=9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEA9614B19CC4D 5F4F5F56E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E03BAB63D4754388BC5BC 764F4F5B5D5D5D5D5D9CF567CF567EDF0195349627D2FD2F8D538B7B7CF567CF567CF567CFED019539348B7B7B7B8B7CF647CF647CF647EC8B7B7B7E5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB发电机=2
iSCSI Key="SRP-2048" [2048 bits] Modulus (base 16) = AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 Generator = 2
iSCSI Key=“SRP-2048”[2048位]模数（基数16）=AC6BD41324A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13D52312AB4B0310DCD7F48A9DA04FD50 E8083969EDB767BF6095A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF7459D041D5CF3310DCD7E80737B417B417B417B417B417B41787B417B477B41788B487B417B417B417B417B417B417B41787B417B417B417B417B417B417B417B417B417B417B417B417544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB37886160279004E57AE6 AF874E7303CE5329CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435D525F54759B65E372FCD68EF20FA7111F9E4AFf73发电机=2
In addition to these groups, the following groups MAY be supported, each of which has also been rigorously proven to be prime:
除这些组外，还可以支持以下组，每个组都已被严格证明是主要的：
[1] iSCSI Key="MODP-3072": the 3072-bit [RFC3526] group, generator: 5
[1] iSCSI Key=“MODP-3072”：3072位[RFC3526]组，生成器：5
[2] iSCSI Key="MODP-4096": the 4096-bit [RFC3526] group, generator: 5
[2] iSCSI Key=“MODP-4096”：4096位[RFC3526]组，生成器：5
[3] iSCSI Key="MODP-6144": the 6144-bit [RFC3526] group, generator: 5
[3] iSCSI Key=“MODP-6144”：6144位[RFC3526]组，生成器：5
[4] iSCSI Key="MODP-8192": the 8192-bit [RFC3526] group, generator: 19
[4] iSCSI Key=“MODP-8192”：8192位[RFC3526]组，生成器：19
Appendix B - Software Performance of IPsec Transforms
附录B-IPsec转换的软件性能
This Appendix provides data on the performance of IPsec encryption and authentication transforms in software. Since the performance of IPsec transforms is heavily implementation dependent, the data presented here may not be representative of performance in a given situation, and are presented solely for purposes of comparison. Other performance data is available in [AESPERF], [PENTPERF] and [UMACPERF].
本附录提供了有关软件中IPsec加密和身份验证转换性能的数据。由于IPsec转换的性能严重依赖于实现，因此此处提供的数据可能无法代表给定情况下的性能，仅用于比较。[AESPERF]、[PENTPERF]和[UMACPERF]中提供了其他性能数据。
Table B-1 presents the cycles/byte required by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet sizes, implemented in software.
表B-1给出了软件实现的AES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5和HMAC-SHA1算法在不同数据包大小下所需的周期/字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at various packet sizes.
表B-1:AES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5和HMAC-SHA1认证算法在不同数据包大小下消耗的周期/字节。
Source: Jesse Walker, Intel
资料来源：杰西·沃克，英特尔
Table B-2 presents the cycles/second required by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in software, assuming a 1500 byte packet.
表B-2给出了在软件中实现的AES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5和HMAC-SHA1算法（假设数据包为1500字节）所需的周期/秒。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B |
| (8 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B |
| (20 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B |
| (8 octets) | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B |
| (8 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B |
| (20 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B |
| (8 octets) | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
表B-2:HMAC-SHA1、HMAC-MD5、AES-CBC-MAC和AES-PMAC认证算法在100 Mbps、1 Gbps和10 Gbps线路速率（1500字节数据包）下的软件性能。
Source: Jesse Walker, Intel
资料来源：杰西·沃克，英特尔
At speeds of 100 Mbps, AES-UMAC is implementable with only a modest processor, and the other algorithms are implementable, assuming that a single high-speed processor can be dedicated to the task. At 1 Gbps, only AES-UMAC is implementable on a single high-speed processor; multiple high speed processors (1+ Ghz) will be required for the other algorithms. At 10 Gbps, only AES-UMAC is implementable even with multiple high speed processors; the other algorithms will require a prodigious number of cycles/second. Thus at 10 Gbps, hardware acceleration will be required for all algorithms with the possible exception of AES-UMAC.
在100 Mbps的速度下，AES-UMAC只需一个普通的处理器即可实现，其他算法也可以实现，前提是一个高速处理器可以专用于该任务。在1 Gbps时，只有AES-UMAC可在单个高速处理器上实现；其他算法需要多个高速处理器（1+Ghz）。在10 Gbps时，即使使用多个高速处理器，也只能实现AES-UMAC；其他算法将需要大量的周期/秒。因此，在10 Gbps时，除AES-UMAC外，所有算法都需要硬件加速。
Table B-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, for various packet sizes.
表B-3给出了在软件中实现的AES-CBC、AES-CTR和3DES-CBC加密算法（无MAC）对于不同数据包大小所需的周期/字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data size | AES-CBC | AES-CTR | 3DES-CBC |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 156.09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 31.22 | 28.62 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 31.22 | 27.75 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 28.62 | 27.32 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 29.14 | 28.1 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 28.62 | 27.75 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 28.99 | 27.5 | 149.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 28.62 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 28.33 | 27.75 | 147.72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 28.62 | 27.06 | 147.77 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 28.18 | 27.32 | 147.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 28.25 | 27.5 | 147.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 27.97 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 28.33 | 27.46 | 147.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 28.1 | 27.58 | 146.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 27.91 | 27.43 | 147.34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 27.97 | 27.53 | 147.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data size | AES-CBC | AES-CTR | 3DES-CBC |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 156.09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 31.22 | 28.62 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 31.22 | 27.75 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 28.62 | 27.32 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 29.14 | 28.1 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 28.62 | 27.75 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 28.99 | 27.5 | 149.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 28.62 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 28.33 | 27.75 | 147.72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 28.62 | 27.06 | 147.77 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 28.18 | 27.32 | 147.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 28.25 | 27.5 | 147.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 27.97 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 28.33 | 27.46 | 147.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 28.1 | 27.58 | 146.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 27.91 | 27.43 | 147.34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 27.97 | 27.53 | 147.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms at various packet sizes, implemented in software.
表B-3：AES-CBC、AES-CTR和3DES-CBC加密算法在不同数据包大小下消耗的周期/字节，在软件中实现。
Source: Jesse Walker, Intel
资料来源：杰西·沃克，英特尔
Table B-4 presents the cycles/second required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet).
表B-4给出了AES-CBC、AES-CTR和3DES-CBC加密算法（无MAC）所需的周期/秒，这些算法以100 Mbps、1 Gbps和10 Gbps的线速率（假设数据包为1500字节）在软件中实现。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-4: Software performance of the AES-CBC, AES-CTR, and 3DES encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
表B-4:AES-CBC、AES-CTR和3DES加密算法在100 Mbps、1 Gbps和10 Gbps线路速率（1500字节数据包）下的软件性能。
Source: Jesse Walker, Intel
资料来源：杰西·沃克，英特尔
At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a high-speed processor, while 3DES would require multiple high speed processors. At speeds of 1 Gbps, multiple high speed processors are required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, and 10 Gbps for all algorithms, implementation in software is infeasible, and hardware acceleration is required.
在100 Mbps的速度下，AES-CBC和AES-CTR模式可通过高速处理器实现，而3DE需要多个高速处理器。在1 Gbps的速度下，AES-CBC和AES-CTR模式需要多个高速处理器。对于3DES，速度为1+Gbps，对于所有算法，速度为10 Gbps，在软件中实现是不可行的，需要硬件加速。
Table B-5 presents the cycles/byte required for combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software.
表B-5给出了组合加密/身份验证算法所需的周期/字节：AES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC和AES-OCB，在软件中实现的不同数据包大小。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 119.67 | 52.03 | 52.03 | 57.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 70.24 | 57.23 | 39.02 | 44.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 58.97 | 55.5 | 36.42 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 57.23 | 55.93 | 35.12 | 40.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 57.23 | 55.15 | 33.3 | 38.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 57.23 | 55.5 | 32.95 | 37.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 58.72 | 55 | 32.71 | 37.17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 58.54 | 55.28 | 32.52 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 57.81 | 55.5 | 31.8 | 37 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 57.75 | 55.15 | 31.74 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 57.67 | 55.5 | 31.65 | 35.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 57.61 | 55.75 | 31.22 | 35.68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 57.56 | 55.61 | 31.22 | 35.45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 57.52 | 55.21 | 31.22 | 35.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 119.67 | 52.03 | 52.03 | 57.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 70.24 | 57.23 | 39.02 | 44.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 58.97 | 55.5 | 36.42 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 57.23 | 55.93 | 35.12 | 40.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 57.23 | 55.15 | 33.3 | 38.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 57.23 | 55.5 | 32.95 | 37.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 58.72 | 55 | 32.71 | 37.17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 58.54 | 55.28 | 32.52 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 57.81 | 55.5 | 31.8 | 37 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 57.75 | 55.15 | 31.74 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 57.67 | 55.5 | 31.65 | 35.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 57.61 | 55.75 | 31.22 | 35.68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 57.56 | 55.61 | 31.22 | 35.45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 57.52 | 55.21 | 31.22 | 35.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 57.75 | 55.15 | 31.22 | 36.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 57.47 | 55.34 | 30.75 | 35.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 57.72 | 55.5 | 30.86 | 35.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 57.75 | 55.15 | 31.22 | 36.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 57.47 | 55.34 | 30.75 | 35.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 57.72 | 55.5 | 30.86 | 35.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-5: Cycles/byte of combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software.
表B-5：组合加密/认证算法的周期/字节：AES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC和AES-OCB在不同数据包大小下，在软件中实现。
Table B-6 presents the cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 byte packets.
表B-6给出了AES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC和AES-OCB加密和认证算法所需的周期/秒，这些算法以100 Mbps、1 Gbps和10 Gbps的线速率运行，假设数据包为1500字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
| CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| | | | | |
| AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
| CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| | | | | |
| AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 octet packets.
表B-6:AES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC和AES-OCB加密和认证算法所需的周期/秒，以100 Mbps、1 Gbps和10 Gbps的线速率运行，假设1500个八位字节数据包。
Source: Jesse Walker, Intel
资料来源：杰西·沃克，英特尔
At speeds of 100 Mbps, the algorithms are implementable on a high speed processor. At speeds of 1 Gbps, multiple high speed processors are required, and none of the algorithms are implementable in software at 10 Gbps line rate.
在100 Mbps的速度下，这些算法可以在高速处理器上实现。在1 Gbps的速度下，需要多个高速处理器，并且没有一个算法能够以10 Gbps的线速率在软件中实现。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Joshua Tseng McDATA Corporation 3850 North First Street San Jose, CA 95134-1702
Joshua Tseng McDATA Corporation加利福尼亚州圣何塞北第一街3850号95134-1702
Phone: +1 650 207 8012
EMail: joshtseng@yahoo.com
Phone: +1 650 207 8012
EMail: joshtseng@yahoo.com
Jesse Walker Intel Corporation 2211 NE 25th Avenue Hillboro, OR 97124
杰西·沃克英特尔公司希尔伯勒东北25大道2211号，邮编：97124
Phone: +1 503 712 1849
Fax: +1 503 264 4843
EMail: jesse.walker@intel.com
Phone: +1 503 712 1849
Fax: +1 503 264 4843
EMail: jesse.walker@intel.com
Venkat Rangan Brocade Communications Systems Inc. 1745 Technology Drive, San Jose, CA 95110
Venkat Rangan Brocade通信系统公司，地址：加利福尼亚州圣何塞市技术大道1745号，邮编：95110
Phone: +1 408 333 7318
Fax: +1 408 333 7099
EMail: vrangan@brocade.com
Phone: +1 408 333 7318
Fax: +1 408 333 7099
EMail: vrangan@brocade.com
Franco Travostino Director, Content Internetworking Lab Nortel Networks 3 Federal Street Billerica, MA 01821
Franco Travostino内容互联实验室主任Nortel Networks 3 Federal Street Billerica，马萨诸塞州01821
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。