Network Working Group F. Maino
Request for Comments: 4595 Cisco Systems
Category: Informational D. Black
EMC Corporation
July 2006
Network Working Group F. Maino
Request for Comments: 4595 Cisco Systems
Category: Informational D. Black
EMC Corporation
July 2006
Use of IKEv2 in the Fibre Channel Security Association Management Protocol
IKEv2在光纤通道安全关联管理协议中的使用
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel.
本文档介绍了使用IKEv2协商光纤通道的安全协议和转换，作为光纤通道安全关联管理协议的一部分。这种用法要求使用光纤通道特定的安全协议、转换和名称类型扩展IKEv2。本文档指定这些IKEv2扩展并为它们分配标识符。为光纤通道安全协议使用新的IKEv2标识符可以避免IP网络的IKEv2协商和光纤通道的IKEv2协商之间可能出现的任何混淆。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. Overview ........................................................4
3. Fibre Channel Security Protocols ................................5
3.1. ESP_Header Protocol ........................................6
3.2. CT_Authentication Protocol .................................7
4. The FC SA Management Protocol ...................................9
4.1. Fibre Channel Name Identifier ..............................9
4.2. ESP_Header and CT_Authentication Protocol ID ...............9
4.3. CT_Authentication Protocol Transform Identifiers ..........10
4.4. Fibre Channel Traffic Selectors ...........................10
4.5. Negotiating Security Associations for FC and IP ...........12
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. Overview ........................................................4
3. Fibre Channel Security Protocols ................................5
3.1. ESP_Header Protocol ........................................6
3.2. CT_Authentication Protocol .................................7
4. The FC SA Management Protocol ...................................9
4.1. Fibre Channel Name Identifier ..............................9
4.2. ESP_Header and CT_Authentication Protocol ID ...............9
4.3. CT_Authentication Protocol Transform Identifiers ..........10
4.4. Fibre Channel Traffic Selectors ...........................10
4.5. Negotiating Security Associations for FC and IP ...........12
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Fibre Channel (FC) is a gigabit-speed network technology primarily used for Storage Networking. Fibre Channel is standardized in the T11 [T11] Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), an American National Standard Institute (ANSI) accredited standards committee.
光纤通道（FC）是一种主要用于存储网络的千兆速度网络技术。光纤通道由国际信息技术标准委员会（INCITS）的T11[T11]技术委员会标准化，该委员会是美国国家标准协会（ANSI）认可的标准委员会。
FC-SP (Fibre Channel Security Protocols) is a T11 Technical Committee working group that has developed the "Fibre Channel Security Protocols" standard [FC-SP], a security architecture for Fibre Channel networks.
FC-SP（光纤通道安全协议）是一个T11技术委员会工作组，该工作组开发了“光纤通道安全协议”标准[FC-SP]，这是一种用于光纤通道网络的安全体系结构。
The FC-SP standard defines a set of protocols for Fibre Channel networks that provides:
FC-SP标准为光纤通道网络定义了一组协议，这些协议提供：
1. device-to-device (hosts, disks, switches) authentication;
1. 设备到设备（主机、磁盘、交换机）身份验证；
2. management and establishment of secrets and security associations;
2. 管理和建立保密和安全协会；
3. data origin authentication, integrity, anti-replay protection, confidentiality; and
3. 数据源认证、完整性、防重放保护、保密性；和
4. security policies distribution.
4. 安全策略分发。
Within this framework, a Fibre Channel device can verify the identity of another Fibre Channel device and establish a shared secret that will be used to negotiate security associations for security protocols applied to Fibre Channel frames and information units. The same framework allows for distributions within a Fibre Channel fabric of policies that will be enforced by the fabric.
在此框架内，光纤通道设备可以验证另一个光纤通道设备的身份，并建立一个共享秘密，用于协商应用于光纤通道帧和信息单元的安全协议的安全关联。相同的框架允许在光纤通道结构中分发将由该结构强制实施的策略。
FC-SP has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and setup of security associations.
FC-SP修改了IKEv2协议[RFC4306]，以提供光纤通道实体的身份验证和安全关联的设置。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Fibre Channel defines two security protocols that provide security services for different portions of Fibre Channel traffic: the ESP_Header defined in [FC-FS] and CT_Authentication defined in [FC-GS-4].
光纤通道定义了两种安全协议，它们为光纤通道流量的不同部分提供安全服务：在[FC-FS]中定义的ESP_头和在[FC-GS-4]中定义的CT_身份验证。
The ESP_Header protocol is a transform applied to FC-2 Fibre Channel frames. It is based on the IP Encapsulation Security Payload [RFC4303] to provide origin authentication, integrity, anti-replay protection, and optional confidentiality to generic fibre channel frames. The CT_Authentication protocol is a transform that provides the same set of security services for Common Transport Information Units, which are used to convey control information. As a result of the separation of Fibre Channel data traffic from control traffic, only one protocol (either ESP_Header or CT_Authentication) is applicable to any FC Security Association (SA).
ESP_头协议是应用于FC-2光纤通道帧的转换。它基于IP封装安全负载[RFC4303]，为通用光纤通道帧提供原始身份验证、完整性、防重放保护和可选保密性。CT_身份验证协议是一种转换，它为用于传输控制信息的公共传输信息单元提供相同的安全服务集。由于光纤通道数据通信量与控制通信量的分离，只有一种协议（ESP_头或CT_身份验证）适用于任何FC安全关联（SA）。
Security associations for the ESP_Header and CT_Authentication protocols between two Fibre Channel entities (hosts, disks, or switches) are negotiated by the Fibre Channel Security Association Management Protocol, a generic protocol based on IKEv2 [RFC4306].
两个光纤通道实体（主机、磁盘或交换机）之间的ESP_头和CT_身份验证协议的安全关联由光纤通道安全关联管理协议协商，该协议是基于IKEv2[RFC4306]的通用协议。
Since IP is transported over Fibre Channel [RFC4338] and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is the potential for confusion when IKEv2 is used for both IP and FC traffic. This document specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP will result in a negotiation failure due to the absence of an acceptable proposal (and likewise for IKEv2/IP over FC). This document gives an overview of the security architecture defined by the FC-SP standard, including the security protocols used to protect frames and to negotiate SAs, and it specifies the entities for which new identifiers have been assigned.
由于IP是通过光纤通道[RFC4338]传输的，而光纤通道/SCSI是通过IP[RFC3643]传输的，[RFC3821]当IKEv2同时用于IP和FC流量时，可能会出现混淆。本文件规定了IKEv2 over FC的标识符，以确保IKEv2/FC over IP的任何错误使用都会由于缺乏可接受的提案而导致协商失败（同样，IKEv2/IP over FC也是如此）。本文档概述了FC-SP标准定义的安全体系结构，包括用于保护帧和协商SA的安全协议，并指定了已分配新标识符的实体。
The Fibre Channel protocol is described in [FC-FS] as a network architecture organized in 5 levels. The FC-2 level defines the FC frame format (shown in Figure 1), the transport services, and control functions required for information transfer.
光纤通道协议在[FC-FS]中描述为按5个级别组织的网络体系结构。FC-2级别定义了信息传输所需的FC帧格式（如图1所示）、传输服务和控制功能。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Figure 1: Fibre Channel Frame Format
图1：光纤通道帧格式
Fibre Channel Generic Services share a Common Transport (CT) at the FC-4 level defined in [FC-GS-4]. The CT provides access to a Service (e.g., Directory Service) with a set of service parameters that facilitates the usage of Fibre Channel constructs.
光纤通道通用服务在[FC-GS-4]中定义的FC-4级别共享一个公共传输（CT）。CT通过一组服务参数提供对服务（例如目录服务）的访问，这些参数有助于使用光纤通道结构。
A Common Transport Information Unit (CT_IU) is the common Fibre Channel Sequence used to transfer all information between a Client and a Server. The first part of the CT_IU, shown in Figure 2, contains a preamble with information common to all CT_IUs. An optional Extended CT_IU Preamble carries the CT_Authentication protocol that provides authentication and, optionally, confidentiality to CT_IUs. The CT_IU is completed by an optional Vendor-Specific Preamble and by additional information as defined by the preamble.
公共传输信息单元（CT_IU）是用于在客户端和服务器之间传输所有信息的公共光纤通道序列。如图2所示，CT_IU的第一部分包含一个前导，其中包含所有CT_IU共有的信息。可选的扩展CT_IU前导携带CT_身份验证协议，该协议为CT_IU提供身份验证以及可选的保密性。CT_IU由可选的供应商特定序言和序言中定义的附加信息完成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Basic CT_IU Preamble ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extended CT_IU Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Vendor Specific Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Information ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Basic CT_IU Preamble ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extended CT_IU Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Vendor Specific Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Information ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CT_IU
图2:CT_IU
Two security protocols are defined for Fibre Channel: the ESP_Header protocol that protects the FC-2 level, and the CT_Authentication protocol that protects the Common Transport at the FC-4 level.
为光纤通道定义了两种安全协议：保护FC-2级别的ESP_头协议和保护FC-4级别的公共传输的CT_身份验证协议。
Security Associations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol.
ESP_头和CT_身份验证协议的安全关联由光纤通道安全关联管理协议协商。
ESP_Header is a security protocol for FC-2 Fibre Channel frames that provides origin authentication, integrity, anti-replay protection, and confidentiality. ESP_Header is carried as the first optional header in the FC-2 frame, and its presence is signaled by a flag in the DF_CTL field of the FC-2 header.
ESP_头是FC-2光纤通道帧的安全协议，它提供源身份验证、完整性、防重播保护和机密性。ESP_头作为FC-2帧中的第一个可选头携带，其存在由FC-2头的DF_CTL字段中的标志表示。
Figure 3 shows the format of an FC-2 frame encapsulated with an ESP_Header. The encapsulation format is equivalent to the IP Encapsulating Security Payload [RFC4303], but the scope of the authentication covers the entire FC-2 header. The Destination and Source Fibre Channel addresses (D_ID and S_ID) and the CS_CTL/ Priority field are normalized before computation of the Integrity Check value to allow for address translation.
图3显示了用ESP_头封装的FC-2帧的格式。封装格式相当于IP封装安全有效负载[RFC4303]，但认证范围涵盖整个FC-2报头。在计算完整性检查值之前，将标准化目标和源光纤通道地址（D_ID和S_ID）以及CS_CTL/优先级字段，以便进行地址转换。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| R_CTL |////////////////D_ID///////////////////////////| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|//CS_CTL/Pri.//|////////////////S_ID///////////////////////////| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type | F_CTL |Auth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cov-
| SEQ_ID | DF_CTL | SEQ_CNT |era-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ge
| OX_ID | RX_ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Parameter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Security Parameters Index (SPI) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--
| Payload Data (variable) | |^
~ ~ ||
~ ~Conf
| |Cov-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+era-
| | Padding (0-255 bytes) |ge
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| | Pad Length | Reserved | vv
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
| Integrity Check Value (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| R_CTL |////////////////D_ID///////////////////////////| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|//CS_CTL/Pri.//|////////////////S_ID///////////////////////////| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type | F_CTL |Auth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cov-
| SEQ_ID | DF_CTL | SEQ_CNT |era-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ge
| OX_ID | RX_ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Parameter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Security Parameters Index (SPI) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--
| Payload Data (variable) | |^
~ ~ ||
~ ~Conf
| |Cov-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+era-
| | Padding (0-255 bytes) |ge
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| | Pad Length | Reserved | vv
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
| Integrity Check Value (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ESP_Header Encapsulation
图3:ESP_头封装
All the security transforms that are defined for the IP Encapsulating Security Payload, such as AES-CBC [RFC3602], can be applied to the ESP_Header protocol.
为IP封装安全负载定义的所有安全转换，如AES-CBC[RFC3602]，都可以应用于ESP_头协议。
CT_Authentication is a security protocol for Common Transport FC-4 Information Units that provides origin authentication, integrity, and anti-replay protection. The CT_Authentication protocol is carried in the optional extended CT_IU preamble
CT_身份验证是一种通用传输FC-4信息单元的安全协议，可提供原始身份验证、完整性和防重放保护。CT_认证协议包含在可选的扩展CT_IU前导中
The extended CT_IU preamble, shown in Figure 4, includes an Authentication Security Association Identifier (SAID), a transaction ID, the N_port name of the requesting node, a Time Stamp used to prevent replay attacks, and an Authentication Hash Block.
图4所示的扩展CT_IU前导码包括身份验证安全关联标识符（SAED）、事务ID、请求节点的N_端口名、用于防止重播攻击的时间戳和身份验证哈希块。
The scope of the Authentication Hash Block Covers all data words of the CT_IU, with the exception of the frame_header, the IN_ID field in the basic CT_IU preamble, the Authentication Hash Block itself, and the frame CRC field.
身份验证哈希块的范围包括CT_IU的所有数据字，但帧_头、基本CT_IU前导中的IN_ID字段、身份验证哈希块本身和帧CRC字段除外。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Requesting_CT N_Port Name +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Stamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Hash Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Requesting_CT N_Port Name +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Stamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Hash Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extended CT_IU Preamble
图4：扩展CT_IU前导
The Authentication Hash Block is computed as an HMAC keyed hash of the CT_IU, as defined in [RFC2104]. The entire output of the HMAC computation is included in the Authentication Hash Block, without any truncation. Two transforms are defined: HMAC-SHA1-160 that is based on the cryptographic hash function SHA1 [NIST.180-1.1995], and HMAC-MD5-128 that is based on the cryptographic hash function MD5 [RFC1321].
如[RFC2104]中所定义，认证散列块被计算为CT_IU的HMAC键控散列。HMAC计算的整个输出包括在身份验证哈希块中，没有任何截断。定义了两种转换：基于加密哈希函数SHA1[NIST.180-1.1995]的HMAC-SHA1-160和基于加密哈希函数MD5[RFC1321]的HMAC-MD5-128。
Fibre Channel entities negotiate security associations for the protocols described above by using the Fibre Channel Security Association Management protocol, as defined in [FC-SP]. The protocol is a modified subset of the IKEv2 protocol [RFC4306] that performs the same core operations, and it uses the Fibre Channel AUTH protocol to transport IKEv2 messages.
光纤通道实体通过使用[FC-SP]中定义的光纤通道安全关联管理协议协商上述协议的安全关联。该协议是执行相同核心操作的IKEv2协议[RFC4306]的修改子集，它使用光纤通道身份验证协议传输IKEv2消息。
The protocol supports only the basic features of IKEv2: initial exchange to create an IKE SA and the first child SA, the CREATE_CHILD_SA exchange to negotiate additional SAs, and the INFORMATIONAL exchange, including notification, delete, and vendor ID payloads. IKEv2 features that are not supported for Fibre Channels include: negotiation of multiple protocols within the same proposal, capability to handle multiple outstanding requests, cookies, configuration payload, and the Extended Authentication Protocol (EAP) payload.
该协议仅支持IKEv2的基本功能：创建IKE SA和第一个子SA的初始交换、协商其他SA的创建子SA交换以及信息交换，包括通知、删除和供应商ID有效负载。光纤通道不支持的IKEv2功能包括：在同一提案中协商多个协议、处理多个未完成请求的能力、cookie、配置负载和扩展身份验证协议（EAP）负载。
The following subsections describe the additional IANA assigned values required by the Fibre Channel Security Association Management protocol, as defined in [FC-SP]. All the values have been allocated from the new registries created for the IKEv2 protocol [RFC4306].
以下小节描述了[FC-SP]中定义的光纤通道安全关联管理协议所需的其他IANA分配值。所有值都已从为IKEv2协议[RFC4306]创建的新注册表中分配。
Fibre Channels entities that negotiate security associations are identified by an 8-byte Name. Support for this name format has been added to the IKEv2 Identification Payload, introducing a new ID type beyond the ones already defined in Section 3.5 of [RFC4306]. This ID Type MUST be supported by any implementation of the Fibre Channel Security Association Management Protocol.
协商安全关联的光纤通道实体由8字节名称标识。对该名称格式的支持已添加到IKEv2标识有效负载中，引入了一种新的ID类型，超出了[RFC4306]第3.5节中已经定义的ID类型。光纤通道安全关联管理协议的任何实现都必须支持此ID类型。
The FC_Name_Identifier is then defined as a single 8-octet Fibre Channel Name:
然后将FC_名称_标识符定义为一个8位字节光纤通道名称：
ID Type Value
------- -----
ID_FC_NAME 12
ID Type Value
------- -----
ID_FC_NAME 12
Security protocols negotiated by IKEv2 are identified by the Protocol ID field contained in the proposal substructure of a Security Association Payload, as defined in Section 3.3.1 of [RFC4306].
IKEv2协商的安全协议由[RFC4306]第3.3.1节中定义的安全关联有效载荷提案子结构中包含的协议ID字段标识。
The following protocol IDs have been defined to identify the Fibre Channel ESP_Header and the CT_Authentication security protocols:
已定义以下协议ID来标识光纤通道ESP_头和CT_身份验证安全协议：
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
FC_CT_AUTHENTICATION 5
FC_CT_认证5
The existing IKEv2 value for ESP (3) is deliberately not reused in order to avoid any possibility of confusion between IKEv2 proposals for IP security associations and IKEv2 proposals for FC security associations.
ESP（3）的现有IKEv2值故意不重复使用，以避免在IP安全关联的IKEv2建议和FC安全关联的IKEv2建议之间产生混淆。
The number and type of transforms that accompany an SA payload are dependent on the protocol in the SA itself. An SA payload proposing the establishment of a Fibre Channel SA has the following mandatory and optional transform types.
SA有效负载附带的转换的数量和类型取决于SA本身中的协议。建议建立光纤通道SA的SA有效负载具有以下强制和可选转换类型。
Protocol Mandatory Types Optional Types
-------- --------------- --------------
FC_ESP_HEADER Integrity Encryption, DH Groups
Protocol Mandatory Types Optional Types
-------- --------------- --------------
FC_ESP_HEADER Integrity Encryption, DH Groups
FC_CT_AUTHENTICATION Integrity Encryption, DH Groups
FC_CT_身份验证完整性加密，DH组
The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are:
为转换类型3（完整性算法）定义的CT_身份验证转换ID为：
Name Number Defined in
---- ------ ----------
AUTH_HMAC_MD5_128 6 FC-SP
Name Number Defined in
---- ------ ----------
AUTH_HMAC_MD5_128 6 FC-SP
AUTH_HMAC_SHA1_160 7 FC-SP
AUTH_HMAC_SHA1_160 7 FC-SP
These transforms differ from the corresponding _96 transforms used in IPsec solely in the omission of the truncation of the HMAC output to 96 bits; instead, the entire output (128 bits for MD5, 160 bits for SHA-1) is transmitted. MD5 support is required due to existing usage of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new implementations.
这些变换与IPsec中使用的对应的_96变换的不同之处仅在于省略了将HMAC输出截断为96位；而是传输整个输出（MD5为128位，SHA-1为160位）。由于在CT_身份验证中使用MD5，因此需要MD5支持；在所有新的实现中建议使用SHA-1。
Fibre Channel Traffic Selectors allow peers to identify packet flows for processing by Fibre Channel security services. A new Traffic Selector Type has been added to the IKEv2 Traffic Selector Types Registry defined in Section 3.13.1 of [RFC4306]. This Traffic Selector Type MUST be supported by any implementation of the Fibre Channel Security Association Management Protocol.
光纤通道流量选择器允许对等方识别数据包流，以便由光纤通道安全服务进行处理。[RFC4306]第3.13.1节中定义的IKEv2交通选择器类型注册表中添加了新的交通选择器类型。光纤通道安全关联管理协议的任何实现都必须支持此流量选择器类型。
Fibre Channel traffic selectors are defined in [FC-SP] as a list of FC address and protocol ranges, as shown in Figure 5.
光纤通道流量选择器在[FC-SP]中定义为FC地址和协议范围的列表，如图5所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS TYPE | Reserved | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Starting Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Ending Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting R_CTL| Ending R_CTL | Starting Type | Ending Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS TYPE | Reserved | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Starting Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Ending Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting R_CTL| Ending R_CTL | Starting Type | Ending Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Fibre Channel Traffic Selector
图5：光纤通道流量选择器
The following table lists the assigned value for the Fibre Channel Traffic Selector Type field:
下表列出了光纤通道流量选择器类型字段的分配值：
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
The Starting and Ending Address fields are 24-bit addresses assigned to Fibre Channel names as part of initializing Fibre Channel communications (e.g., for a switched Fibre Channel Fabric, end nodes acquire these identifiers from Fabric Login, FLOGI).
起始和结束地址字段是分配给光纤通道名称的24位地址，作为初始化光纤通道通信的一部分（例如，对于交换光纤通道结构，终端节点从结构登录FLOGI获取这些标识符）。
The Starting and Ending R_CTL fields are the 8-bit Routing Control identifiers that define the category and, in some cases, the function of the FC frame; see [FC-FS] for details.
起始和结束R_CTL字段是8位路由控制标识符，定义类别，在某些情况下，定义FC帧的功能；有关详细信息，请参见[FC-FS]。
As a result of the separation of Fibre Channel data traffic from control traffic, only one protocol (either ESP_Header or CT_Authentication) is applicable to any FC Security Association. When the Fibre Channel Traffic Selector is defined for the ESP_Header protocol, the Starting Type and Ending Type fields identify the range of FC-2 protocols to be selected. When the Fibre Channel Traffic Selector is defined for the CT_Authentication protocol, the FC-2 Type is implicitly set to the value '20h', which identifies CT_Authentication information units, and the Starting Type and Ending Type fields identify the range of Generic Service subtypes (GS_Subtype) to be selected. See [FC-FS] and [FC-GS-4] for details.
由于光纤通道数据通信量与控制通信量的分离，只有一种协议（ESP_头或CT_身份验证）适用于任何FC安全关联。为ESP_头协议定义光纤通道流量选择器时，起始类型和结束类型字段标识要选择的FC-2协议的范围。当为CT_身份验证协议定义光纤通道流量选择器时，FC-2类型将隐式设置为值“20h”，该值标识CT_身份验证信息单元，起始类型和结束类型字段标识要选择的通用服务子类型（GS_子类型）的范围。详见[FC-FS]和[FC-GS-4]。
The ESP_header and CT_Authentication protocols are Fibre-Channel-specific security protocols that apply to Fibre Channel frames only. The values identifying security protocols, transforms, selectors, and name types defined in this document MUST NOT be used during IKEv2 negotiation for IPsec protocols.
ESP_头和CT_身份验证协议是光纤通道特定的安全协议，仅适用于光纤通道帧。在IPsec协议的IKEv2协商期间，不得使用本文档中定义的标识安全协议、转换、选择器和名称类型的值。
The security considerations in IKEv2 [RFC4306] apply, with the exception of those related to NAT traversal, EAP, and IP fragmentation. NAT traversal and EAP, in fact, are not supported by the Fibre Channel Security Association Management Protocol (which is based on IKEv2), and IP fragmentation cannot occur because IP is not used to carry the Fibre Channel Security Association Management Protocol messages.
IKEv2[RFC4306]中的安全注意事项适用，但与NAT遍历、EAP和IP分段相关的注意事项除外。事实上，光纤通道安全关联管理协议（基于IKEv2）不支持NAT遍历和EAP，并且由于IP不用于承载光纤通道安全关联管理协议消息，因此无法发生IP碎片。
Fibre Channel Security Association Management Protocol messages are mapped over Fibre Channel Sequences. A Sequence is able to carry up to 4 GB of data; there are no theoretical limitations to the size of IKEv2 messages. However, some Fibre Channel endpoint implementations have limited sequencing capabilities for the particular frames used to map IKEv2 messages over Fibre Channel. To address these limitations, the Fibre Channel Security Association Management Protocol supports fragmentation of IKEv2 messages (see Section 5.9 of [FC-SP]). If the IKEv2 messages are long enough to trigger fragmentation, it is possible that attackers could prevent the IKEv2 exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encodings instead of sending certificates (see Section 3.6 of [RFC4306]).
光纤通道安全关联管理协议消息映射到光纤通道序列。一个序列最多可以承载4GB的数据；IKEv2消息的大小在理论上没有限制。但是，某些光纤通道端点实现对用于在光纤通道上映射IKEv2消息的特定帧的排序能力有限。为了解决这些限制，光纤通道安全关联管理协议支持IKEv2消息的分段（请参阅[FC-SP]第5.9节）。如果IKEv2消息足够长，足以触发碎片，则攻击者可能会通过耗尽重组缓冲区来阻止IKEv2交换完成。通过使用哈希和URL编码，而不是发送证书，可以最大限度地减少这种情况的发生（参见[RFC4306]第3.6节）。
The standards action of this document establishes the following values allocated by IANA in the registries created for IKEv2 [RFC4306].
本文件的标准行动确定了IANA在为IKEv2[RFC4306]创建的注册表中分配的以下值。
Allocated the following value for the IKEv2 Identification Payload ID Types Registry (Section 3.5 of [RFC4306]):
为IKEv2标识有效负载ID类型注册表（RFC4306第3.5节）分配了以下值：
ID Type Value
------- -----
ID_FC_NAME 12
ID Type Value
------- -----
ID_FC_NAME 12
Allocated the following values for the IKEv2 Security Protocol Identifiers Registry (Section 3.3.1 of [RFC4306]):
为IKEv2安全协议标识符注册表（RFC4306第3.3.1节）分配了以下值：
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
FC_CT_AUTHENTICATION 5
FC_CT_认证5
Allocated the following values for Transform Type 3 (Integrity Algorithm) for the IKEv2 Integrity Algorithm Transform IDs Registry (Section 3.3.2 of [RFC4306]):
为IKEv2完整性算法转换ID注册表（RFC4306第3.3.2节）的转换类型3（完整性算法）分配了以下值：
Name Number
---- ------
AUTH_HMAC_MD5_128 6
Name Number
---- ------
AUTH_HMAC_MD5_128 6
AUTH_HMAC_SHA1_160 7
认证HMAC\U SHA1\U 160 7
Allocated the following value for the IKEv2 Traffic Selector Types Registry (Section 3.13.1 of [RFC4306]):
为IKEv2交通选择器类型注册表分配了以下值（RFC4306第3.13.1节）：
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
[NIST.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", NIST 180-1, April 1995.
[NIST.180-1.1995]国家标准与技术研究所，“安全哈希标准”，NIST 180-11995年4月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[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月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3643] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C., and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[RFC3643]韦伯，R.，拉贾戈帕尔，M.，特拉沃斯蒂诺，F.，O'Donnell，M.，莫尼亚，C.，和M.梅哈尔，“光纤通道（FC）帧封装”，RFC 36432003年12月。
[RFC3821] Rajagopal, M., E. Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3602, July 2004.
[RFC3821]Rajagopal，M.，E.Rodriguez，E.，和R.Weber，“TCP/IP上的光纤通道（FCIP）”，RFC 3602，2004年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006.
[RFC4338]DeSanti，C.，Carlson，C.，和R.Nixon，“通过光纤通道传输IPv6，IPv4和地址解析协议（ARP）数据包”，RFC 4338，2006年1月。
[FC-FS] INCITS Technical Committee T11, ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)".
[FC-FS]INCITS技术委员会T11，ANSI INCITS 373-2003，“光纤通道-帧和信令（FC-FS）”。
[FC-GS-4] INCITS Technical Committee T11, ANSI INCITS 387-2004, "Fibre Channel - Generic Services 4 (FC-GS-4)".
[FC-GS-4]INCITS技术委员会T11，ANSI INCITS 387-2004，“光纤通道-通用服务4（FC-GS-4）”。
[FC-SP] INCITS Technical Committee T11, ANSI INCITS xxx-200x, "Fibre Channel - Security Protocols (FC-SP)".
[FC-SP]INCITS技术委员会T11，ANSI INCITS xxx-200x，“光纤通道-安全协议（FC-SP）”。
[T11] INCITS Technical Commitee T11, "Home Page of the INCITS Technical Committee T11", <http://www.t11.org>.
[T11]INCITS技术委员会T11，“INCITS技术委员会T11主页”<http://www.t11.org>.
Authors' Addresses
作者地址
Fabio Maino Cisco Systems 375 East Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞市东塔斯曼大道375号法比奥美诺思科系统公司95134
Phone: +1 408 853 7530
EMail: fmaino@cisco.com
URI: http://www.cisco.com/
Phone: +1 408 853 7530
EMail: fmaino@cisco.com
URI: http://www.cisco.com/
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 US
美国马萨诸塞州霍普金顿南街176号David L.Black EMC Corporation 01748
Phone: +1 508 293-7953
EMail: black_david@emc.com
URI: http://www.emc.com/
Phone: +1 508 293-7953
EMail: black_david@emc.com
URI: http://www.emc.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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.
本文件受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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。