[要約] 要約：RFC 4595は、Fibre Channel Security Association Management Protocol（FC-SAMP）でIKEv2を使用する方法について説明しています。 目的：このRFCの目的は、FC-SAMPでのIKEv2の使用に関するガイドラインを提供し、Fibre Channelネットワークのセキュリティを向上させることです。
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、Fiber Channel Security Association Management Protocolの一部として、セキュリティプロトコルとファイバーチャネルの変換を交渉するためにIKEV2の使用について説明します。この使用には、IKEV2をFibre-Channel固有のセキュリティプロトコル、変換、および名前タイプで拡張する必要があります。このドキュメントは、これらの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
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.
Fiber Channel（FC）は、主にストレージネットワーキングに使用されるギガビットスピードネットワークテクノロジーです。ファイバーチャネルは、米国国立標準研究所（ANSI）認定標準委員会である国際情報技術基準委員会（INCITS）のT11 [T11]技術委員会に標準化されています。
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（ファイバーチャネルセキュリティプロトコル）は、ファイバーチャネルネットワークのセキュリティアーキテクチャである「ファイバーチャネルセキュリティプロトコル」標準[FC-SP]を開発したT11テクニカル委員会のワーキンググループです。
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.
このフレームワーク内で、ファイバーチャネルデバイスは、別のファイバーチャネルデバイスのIDを検証し、ファイバーチャネルフレームと情報ユニットに適用されるセキュリティプロトコルのセキュリティ協会を交渉するために使用される共有秘密を確立することができます。同じフレームワークにより、ファブリックが実施するポリシーのファイバーチャネル構造内の分布が可能になります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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].
ファイバーチャネルは、ファイバーチャネルトラフィックのさまざまな部分にセキュリティサービスを提供する2つのセキュリティプロトコルを定義します。[FC-FS]で定義されているESP_Headerと[FC-GS-4]で定義されているCT_Authenticationです。
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_Headerプロトコルは、FC-2ファイバーチャネルフレームに適用される変換です。IPカプセル化セキュリティペイロード[RFC4303]に基づいて、原点認証、整合性、アンチレプレイ保護、および一般的なファイバーチャネルフレームにオプションの機密性を提供します。CT_Authentication Protocolは、コントロール情報の伝達に使用される一般的な輸送情報ユニットに同じセキュリティサービスセットを提供する変換です。ファイバーチャネルデータトラフィックが制御トラフィックから分離された結果、1つのプロトコル（ESP_HeaderまたはCT_Authentication）のみが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].
2つのファイバーチャネルエンティティ（ホスト、ディスク、またはスイッチ）間のESP_HeaderおよびCT_Authenticationプロトコルのセキュリティ関連は、IKEV2 [RFC4306]に基づく一般的なプロトコルであるFiber Channel Security Association Management Management Protocolによって交渉されます。
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のIKEV2/FCがIPを介して誤って使用されると、許容可能な提案がないために交渉障害をもたらすことを保証する方法で、FCを超えるIKEV2の識別子を指定します（同様にFCを超えるIKEV2/IPの場合）。このドキュメントは、フレームを保護し、SASの交渉に使用されるセキュリティプロトコルを含むFC-SP標準で定義されたセキュリティアーキテクチャの概要を示し、新しい識別子が割り当てられたエンティティを指定します。
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 | | |
+-----+-----------+-----------+--------//-------+-----+-----+
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_IUSに共通の情報が含まれる前文が含まれています。オプションの拡張CT_IUプリアンブルには、認証、およびオプションでCT_IUSに機密性を提供するCT_Authenticationプロトコルが搭載されています。CT_IUは、オプションのベンダー固有のプリアンブルと、Preambleで定義されている追加情報によって完了します。
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.
ファイバーチャネルで2つのセキュリティプロトコルが定義されています。FC-2レベルを保護するESP_HEADERプロトコルと、FC-4レベルで共通輸送を保護するCT_Authenticationプロトコルです。
Security Associations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol.
ESP_HeaderおよびCT_Authenticationプロトコルのセキュリティ協会は、Fiber Channel Security Association Management Protocolによって交渉されます。
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_Headerは、FC-2ファイバーチャネルフレームのセキュリティプロトコルであり、Origin Authentication、Integrity、Anti Replay保護、および機密性を提供します。ESP_Headerは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_Headerでカプセル化されたFC-2フレームの形式を示しています。カプセル化形式は、セキュリティペイロード[RFC4303]をカプセル化するIPと同等ですが、認証の範囲は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) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ESP_Header Encapsulation
図3：ESP_HEADERカプセル化
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.
AES-CBC [RFC3602]など、セキュリティペイロードをカプセル化するIPに定義されているすべてのセキュリティ変換は、ESP_Headerプロトコルに適用できます。
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 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.
CT_Authenticationは、原点認証、整合性、およびレプレイ防止防止を提供する一般的なトランスポートFC-4情報ユニットのセキュリティプロトコルです。CT_Authenticationプロトコルは、図4に示すオプションの拡張CT_IUプリアンブルで実施されます。攻撃、および認証ハッシュブロック。
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.
認証ハッシュブロックの範囲は、frame_headerを除き、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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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計算の出力全体は、切り捨てなしで認証ハッシュブロックに含まれています。2つの変換が定義されています：暗号化ハッシュ関数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]の修正されたサブセットであり、FiberチャネルAUTHプロトコルを使用して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を作成するためのIKEV2：初期交換、追加のSASを交渉するCreate_Child_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]で定義されているように、Fiber Channel Security Association Management Management Protocolに必要な追加の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識別ペイロードに追加され、[RFC4306]のセクション3.5で既に定義されているものを超えて新しいIDタイプを導入しています。このIDタイプは、Fiber Channel Security Association Management Protocolの実装によってサポートする必要があります。
The FC_Name_Identifier is then defined as a single 8-octet Fibre Channel Name:
FC_NAME_IDENTIFIERは、単一の8オクテットファイバーチャネル名として定義されます。
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_HeaderとCT_Authenticationセキュリティプロトコルを識別するために定義されています。
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
FC_CT_AUTHENTICATION 5
fc_ct_authentication 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
FC_CT_AUTHENTICATION Integrity Encryption, DH Groups
fc_ct_authentication Integrity Encryption、dhグループ
The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are:
transform type 3（Integrity Algorithm）に対して定義されたCT_Authentication変換IDは次のとおりです。
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.
これらの変換は、HMAC出力の切り捨ての省略のみにおいて、IPSECで使用される対応する_96変換とは異なります。代わりに、出力全体（MD5で128ビット、SHA-1で160ビット）が送信されます。CT_Authenticationにおける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.
図5に示すように、ファイバーチャネルトラフィックセレクターは[FC-SP]でFCアドレスおよびプロトコル範囲のリストとして定義されています。
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
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フィールドは、カテゴリ、場合によってはFCフレームの関数を定義する8ビットルーティング制御識別子です。詳細については、[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.
ファイバーチャネルデータトラフィックが制御トラフィックから分離された結果、1つのプロトコル（ESP_HeaderまたはCT_Authentication）のみがFCセキュリティ協会に適用できます。ファイバーチャネルトラフィックセレクターがESP_Headerプロトコルに対して定義されている場合、開始型および終了タイプフィールドは、選択するFC-2プロトコルの範囲を識別します。ファイバーチャネルトラフィックセレクターがCT_Authenticationプロトコルに対して定義されている場合、FC-2タイプはct_authentication情報単位を識別する値 '20h'に暗黙的に設定され、ジェネリックサービスサブタイプの範囲を識別します。GS_SUBTYPE）選択します。詳細については、[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_HeaderおよびCT_Authenticationプロトコルは、ファイバーチャネルフレームのみに適用されるファイバーチャネル固有のセキュリティプロトコルです。このドキュメントで定義されているセキュリティプロトコル、変換、セレクター、および名前のタイプを識別する値は、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の断片化に関連するものを除き、適用されます。実際、NATトラバーサルとEAPは、Fiber Channel Security Association Management Protocol（IKEV2に基づいています）でサポートされておらず、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]).
ファイバーチャネルセキュリティアソシエーション管理プロトコルメッセージは、ファイバーチャネルシーケンスにマッピングされます。シーケンスは、最大4 GBのデータを伝達できます。IKEV2メッセージのサイズに理論的な制限はありません。ただし、一部のファイバーチャネルエンドポイントの実装では、ファイバーチャネル上のIKEV2メッセージをマッピングするために使用される特定のフレームのシーケンス機能が制限されています。これらの制限に対処するために、Fiber Channel Security Association Management Protocolは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].
このドキュメントの標準アクションは、IKEV2 [RFC4306]用に作成されたレジストリでIANAによって割り当てられた以下の値を確立します。
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
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
FC_CT_AUTHENTICATION 5
fc_ct_authentication 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 Integrity Algorithm Transform IDSレジストリ（[RFC4306]のセクション3.3.2）の変換タイプ3（整合性アルゴリズム）に次の値を割り当てました：
Name Number
---- ------
AUTH_HMAC_MD5_128 6
AUTH_HMAC_SHA1_160 7
auth_hmac_sha1_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
[NIST.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", NIST 180-1, April 1995.
[Nist.180-1.1995]国立標準技術研究所、「Secure Hash Standard」、Nist 180-1、1995年4月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年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]フランケル、S。、グレン、R。、およびS.ケリー、「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] Weber、R.、Rajagopal、M.、Travostino、F.、O'Donnell、M.、Monia、C。、およびM. Merhar、「Fiber Channel（FC）フレームカプセル化」、RFC 3643、2003年12月。
[RFC3821] Rajagopal, M., E. Rodriguez, E., and R. Weber, "Fibre Channel Over TCP/IP (FCIP)", RFC 3602, July 2004.
[RFC3821] Rajagopal、M.、E。ロドリゲス、E。、およびR.ウェーバー、「TCP/IP（FCIP）上のファイバーチャネル」、RFC 3602、2004年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年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]テクニカル委員会T11を挿入し、ANSIは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]技術委員会T11を挿入し、ANSIは387-2004、「ファイバーチャネル - ジェネリックサービス4（FC-GS-4）」を挿入します。
[FC-SP] INCITS Technical Committee T11, ANSI INCITS xxx-200x, "Fibre Channel - Security Protocols (FC-SP)".
[FC-SP]テクニカル委員会T11を挿入し、ANSIはXXX-200Xを挿入します。「ファイバーチャネル - セキュリティプロトコル（FC-SP）」。
[T11] INCITS Technical Commitee T11, "Home Page of the INCITS Technical Committee T11", <http://www.t11.org>.
[T11]は、技術委員会T11、「Incits Technical Committee T11のホームページ」、<http://www.t11.org>。
Authors' Addresses
著者のアドレス
Fabio Maino Cisco Systems 375 East Tasman Drive San Jose, CA 95134 US
Fabio Maino Cisco Systems 375 East Tasman Drive San Jose、CA 95134 US
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
David L. Black EMC Corporation 176 South Street Hopkinton、MA 01748 US
Phone: +1 508 293-7953
EMail: black_david@emc.com
URI: http://www.emc.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。