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
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
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）は、主にストレージネットワーキングに使用するギガビット高速ネットワーク技術です。 Fibre Channelは、情報技術規格国際委員会のT11 [T11]技術委員会（INCITS）、米国国家規格協会（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（ファイバチャネルセキュリティプロトコル）は、「ファイバチャネルセキュリティプロトコル」標準[FC-SP]、ファイバチャネルネットワークのためのセキュリティアーキテクチャを開発したT11技術委員会のワーキンググループです。
The FC-SP standard defines a set of protocols for Fibre Channel networks that provides:
FC-SP標準は提供するファイバ・チャネル・ネットワークのためのプロトコルのセットを定義します。
2. management and establishment of secrets and security associations;
2.管理と秘密とセキュリティアソシエーションの確立。
3. data origin authentication, integrity, anti-replay protection, confidentiality; and
3.データ発信元認証、整合性、リプレイ保護、機密性;そして
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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つのセキュリティプロトコルを定義：ESP_Headerは、[FC-GS-4]で定義され、[FC-FS]と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プロトコルは、その制御情報を伝達するために使用されている共通トランスポート情報単位のためのセキュリティ・サービスの同じセットを提供変換です。制御トラフィックからのファイバチャネルデータトラフィックの分離の結果として、一つだけのプロトコル（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]に基づいて、一般的なプロトコルによって交渉されています。
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は、[RFC3643]、[RFC3821] IP上で転送されているファイバーチャネル[RFC4338]およびファイバチャネル/ SCSI上で転送されるためのIKEv2はIPとFCトラフィックの両方に使用されて混乱する可能性があります。この文書では、IP上でのIKEv2 / FCのいずれかの誤った使用方法は、（FCオーバーと同様のIKEv2 / IPのための）許容可能な提案がないため、交渉の障害につながることを保証した方法でFC上のIKEv2のための識別子を指定します。このドキュメントはフレームを保護し、SAをネゴシエートするために使用されるセキュリティプロトコルを含む、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.
ファイバチャネルプロトコルは、5つのレベルに編成ネットワークアーキテクチャとして[FC-FS]に記載されています。 FC-2レベルは、情報転送のために必要な（図1に示す）FCフレームフォーマット、トランスポート・サービス、および制御機能を定義します。
+-----+-----------+-----------+--------//-------+-----+-----+
| | | 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は、オプションのベンダー固有プリアンブルおよび追加情報によって完成されます。
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
ふぃぐれ ２： ＣＴ＿いう
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_Headerプロトコル、およびFC-4レベルでの共通トランスポートを保護CT_Authenticationプロトコル：2つのセキュリティプロトコルは、ファイバチャネルのために定義されています。
Security Associations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol.
ESP_HeaderとCT_Authenticationプロトコルのためのセキュリティアソシエーションは、ファイバチャネルセキュリティアソシエーション管理プロトコルによって交渉されています。
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ファイバチャネルフレームのためのセキュリティプロトコルです。 ESP_Headerは、FC-2フレームの第1オプションヘッダとして実行され、その存在は、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フレームのフォーマットを示します。カプセル化フォーマットは、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) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
CT_Authenticationは、発信元の認証、整合性、およびアンチリプレイ保護を提供共通トランスポートFC-4情報単位のセキュリティプロトコルです。 CT_Authenticationプロトコルは、オプションの拡張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プリアンブルは、認証セキュリティアソシエーション識別子（SAID）、トランザクション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.
認証ハッシュブロックの範囲は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つの変換が定義されている：暗号ハッシュ関数MD5 [RFC1321]に基づいて暗号ハッシュ関数SHA1 [NIST.180-1.1995]に基づいてHMAC-SHA1-160、および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メッセージを転送するために、ファイバチャネルAUTHプロトコルを使用します。
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.
追加のSAをネゴシエートするIKE SAと第一子SA、CREATE_CHILD_SA交換を作成するための最初の交換、および通知、削除、およびベンダーIDペイロードを含むINFORMATIONAL交換：プロトコルは、IKEv2の唯一の基本的な機能をサポートしています。ファイバチャネルのためにサポートされていないのIKEv2機能は次のとおりです。同じ提案内の複数のプロトコルの交渉、複数の未処理のリクエスト、クッキー、設定ペイロード、および拡張認証プロトコル（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バイトの名前で識別されます。この名前のフォーマットのサポートはすでに[RFC4306]のセクション3.5で定義されたものを超えた新しいIDのタイプを導入する、IKEv2のIDペイロードに追加されました。このIDタイプは、ファイバチャネルセキュリティアソシエーション管理プロトコルのいずれかの実装でサポートしなければなりません。
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].
[RFC4306]のセクション3.3.1で定義されているのIKEv2によって交渉のセキュリティプロトコルは、SAペイロードの提案下部構造に含まれるプロトコル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値は意図的FCセキュリティアソシエーションのIPセキュリティアソシエーションのIKEv2の提案と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整合性暗号化、DHグループ
The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are:
CT_Authenticationはタイプ3（インテグリティアルゴリズム）変換用に定義された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.
これらの変換は、単に96ビットにHMACの出力の切捨ての漏れのIPsecで使用される対応する_96変換異なります。代わりに、全体の出力（MD5 128ビットSHA-1 160ビット）が送信されます。 MD5のサポートが原因CT_Authenticationで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アドレスおよびプロトコルの範囲のリストとして[FC-SP]で定義されています。
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:
次の表は、ファイバチャネルトラフィックセレクタTypeフィールドのために割り当てられた値を示しています。
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).
開始および終了アドレスフィールドは、（例えば、スイッチドファイバーチャネルファブリックの、エンドノードがファブリックログイン、FLOGIからこれらの識別子を取得する）、ファイバーチャネル通信の初期化の一部として、ファイバチャネル名に割り当てられた24ビットのアドレスです。
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.
制御トラフィックからのファイバチャネルデータトラフィックの分離の結果として、一つだけのプロトコル（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フラグメンテーションに関連するものを除いて、適用されます。 IPは、ファイバチャネルセキュリティアソシエーション管理プロトコルメッセージを運ぶために使用されていないため、NATトラバーサルとEAP、実際には、（IKEv2のに基づいています）、ファイバチャネルセキュリティアソシエーション管理プロトコルによってサポートされていない、と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ギガバイトまで運ぶことができます。 IKEv2のメッセージのサイズには、理論的な制限はありません。しかし、いくつかのファイバー・チャネル・エンドポイントの実装では、ファイバチャネル経由のIKEv2メッセージをマップするために使用される特定のフレームのシーケンシング機能が制限されています。これらの制限に対処するために、ファイバチャネルセキュリティ協会管理プロトコルは、IKEv2のメッセージ（[FC-SP]のセクション5.9を参照）の断片化をサポートしています。 IKEv2のメッセージが断片化を誘発するのに十分な長さであるならば、攻撃者が再アセンブリバッファを排出することによって完了することからのIKEv2交換を妨げる可能性があります。この可能性は、（[RFC4306]のセクション3.6を参照）は、ハッシュとURLエンコーディングを使用して、代わりに証明書を送信することによって最小限に抑えることができます。
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のインテグリティアルゴリズムIDがレジストリ（[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]アメリカ国立標準技術研究所は、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.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ウェーバー、R.、Rajagopal、M.、Travostino、F.、オドネル、M.、モニア、C.、およびM. Merhar、 "ファイバチャネル（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]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（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.、カールソン、C.、およびR.ニクソン、 "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東タスマン・ドライブサンノゼ、CA 95134米国
Phone: +1 408 853 7530 EMail: fmaino@cisco.com URI: http://www.cisco.com/
電話：+1 408 853 7530 Eメール：fmaino@cisco.com URI：http://www.cisco.com/
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 US
デビッドL.ブラックEMCコーポレーション176サウスストリートホプキントン、MA 01748米国
Phone: +1 508 293-7953 EMail: black_david@emc.com URI: http://www.emc.com/
電話：+1 508 293-7953 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。