RFC4595 日本語訳
4595 Use of IKEv2 in the Fibre Channel Security Association ManagementProtocol. F. Maino, D. Black. July 2006. (Format: TXT=32268 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Maino
Request for Comments: 4595 Cisco Systems
Category: Informational D. Black
EMC Corporation
July 2006
Mainoがコメントのために要求するワーキンググループF.をネットワークでつないでください: 4595年のシスコシステムズカテゴリ: 情報の黒いD.EMC社の2006年7月
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)インターネット協会(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の使用について説明して、Fibre ChannelのためにFibre Channel Security Association Managementプロトコルの一部として変形します。 この用法は、IKEv2がFibreチャンネル詳細セキュリティプロトコル、変換、および名前タイプで広げられるのを必要とします。 このドキュメントは、これらのIKEv2拡張子を指定して、それらのための識別子を割り当てます。 Fibre Channelセキュリティプロトコルに新しいIKEv2識別子を使用すると、IPネットワークのためのIKEv2交渉とFibre ChannelのためのIKEv2交渉の間のどんな可能な混乱も避けられます。
Maino & Black Informational [Page 1] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[1ページ]のRFC4595IKEv2
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. 序論…3 1.1. 要件記法…3 2. 概要…4 3. 繊維チャンネルセキュリティプロトコル…5 3.1. 超能力_ヘッダープロトコル…6 3.2. コネチカット_認証プロトコル…7 4. FC SA管理は議定書を作ります…9 4.1. 繊維チャンネル名前識別子…9 4.2. 超能力_ヘッダーとコネチカットの_認証はIDについて議定書の中で述べます…9 4.3. コネチカット_認証プロトコル変換識別子…10 4.4. 繊維チャンネルトラフィックセレクタ…10 4.5. FCとIPのためにセキュリティ協会を交渉します…12 5. セキュリティ問題…12 6. IANA問題…13 7. 参照…14 7.1. 標準の参照…14 7.2. 有益な参照…14
Maino & Black Informational [Page 2] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[2ページ]のRFC4595IKEv2
1. Introduction
1. 序論
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.
繊維Channel(FC)はStorage Networkingに主として使用されるギガビット速度ネットワーク技術です。 繊維Channelは情報Technology Standards(INCITS)(米国標準規格のInstituteの(ANSI)公認の規格委員会)のためにInterNational CommitteeのT11[T11]の技術的なCommitteeで標準化されます。
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(繊維Channel Securityプロトコル)は「繊維チャンネルセキュリティプロトコル」規格[FC-SP](Fibre Channelネットワークのためのセキュリティー体系)を開発したT11 Technical Committeeワーキンググループです。
The FC-SP standard defines a set of protocols for Fibre Channel networks that provides:
FC-SP規格はFibre Channelネットワークのための提供される1セットのプロトコルを定義します:
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.
このフレームワークの中では、Fibre Channelデバイスは、Fibre Channelフレームと情報ユニットに適用されたセキュリティプロトコルのためにセキュリティ協会を交渉するために別のFibre Channelデバイスのアイデンティティについて確かめて、使用される共有秘密キーを確立できます。 同じフレームワークは骨組みによって励行される方針のFibre Channel骨組みの中で配を考慮します。
FC-SP has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and setup of security associations.
FC-SPは、Fibre Channel実体の認証とセキュリティ協会のセットアップを提供するために、IKEv2プロトコル[RFC4306]を適合させました。
1.1. Requirements Notation
1.1. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Maino & Black Informational [Page 3] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[3ページ]のRFC4595IKEv2
2. Overview
2. 概要
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].
繊維ChannelはFibre Channelトラフィックの異なった部分のためのセキュリティー・サービスを提供する2つのセキュリティプロトコルを定義します: 超能力_Headerは[FC-FS]とコネチカット_で[FC GS4]で定義された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).
超能力_HeaderプロトコルはFC-2 Fibre Channelフレームに適用された変換です。 それは発生源認証を提供するためにIP Encapsulation Security有効搭載量[RFC4303]に基づいています、保全、ジェネリック繊維チャンネルフレームへの反反復操作による保護の、そして、任意の秘密性。 コネチカット_Authenticationプロトコルは制御情報を伝えるのに使用されるCommon Transport情報Unitsに同じセットのセキュリティー・サービスを供給する変換です。 コントロールトラフィックからのFibre Channelデータ通信量の分離の結果、1つのプロトコル(_超能力Headerか_コネチカットAuthenticationのどちらか)だけがどんなFC Security Association(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].
Fibre Channel Security Association Managementプロトコル(IKEv2[RFC4306]に基づくジェネリックプロトコル)によって_超能力Headerのためのセキュリティ協会と2つのFibre Channel実体の間のコネチカット_Authenticationプロトコル(ホスト、ディスク、またはスイッチ)は交渉されます。
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がFibre Channel[RFC4338]の上で輸送されて、Fibre Channel/SCSIがIP[RFC3643]の上で輸送されるので、IKEv2がIPとFCトラフィックの両方に使用されるとき、そこの[RFC3821]は混乱の可能性です。 このドキュメントはFCの上でIPの上のIKEv2/FCのどんな間違われた使用法も受諾できる提案(そして同様にFCの上のIKEv2/IPのために)の欠如のため交渉失敗をもたらすのを確実にするファッションでIKEv2のための識別子を指定します。 このドキュメントはフレームを保護して、SAsを交渉するのに使用されるセキュリティプロトコルを含むFC-SP規格によって定義されたセキュリティー体系の概要を与えます、そして、それは新しい識別子を割り当ててある実体を指定します。
Maino & Black Informational [Page 4] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[4ページ]のRFC4595IKEv2
3. Fibre Channel Security Protocols
3. 繊維チャンネルセキュリティプロトコル
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つのレベルで結団されたので、Fibre Channelプロトコルは[FC-FS]で説明されます。 FC-2レベルはFCフレーム形式(図1では、目立つ)、輸送サービス、および機能が情報転送のために必要としたコントロールを定義します。
+-----+-----------+-----------+--------//-------+-----+-----+ | | | Data Field | | | | SOF | FC Header |<--------------------------->| CRC | EOF | | | | Optional | Frame | | | | | | Header(s) | Payload | | | +-----+-----------+-----------+--------//-------+-----+-----+
+-----+-----------+-----------+--------//-------+-----+-----+ | | | データ・フィールド| | | | SOF| FCヘッダー| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CRC| EOF| | | | 任意| フレーム| | | | | | ヘッダー| 有効搭載量| | | +-----+-----------+-----------+--------//-------+-----+-----+
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.
繊維Channel Generic Servicesは[FC GS4]で定義されたFC-4レベルでCommon Transport(コネチカット)を共有します。 コネチカットはFibre Channel構造物の使用法を容易にする1セットのサービスパラメタにService(例えば、ディレクトリサービス)へのアクセスを提供します。
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.
Common Transport情報Unit(コネチカット_IU)はClientとServerの間にすべての情報を移すのに使用される一般的なFibre Channel Sequenceです。図2で見せられたコネチカット_IUの最初の部分はすべてのコネチカット_IUsに共通の情報がある序文を含んでいます。 任意のExtendedコネチカット_IU Preambleは認証と任意に秘密性をコネチカット_IUsに供給するコネチカット_Authenticationプロトコルを運びます。 コネチカット_IUは序文によって定義されるように任意のVendor特有のPreambleと追加情報で完成します。
Maino & Black Informational [Page 5] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[5ページ]のRFC4595IKEv2
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 基本のコネチカット_IU序文~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 拡張コネチカット_IU序文(任意の)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ベンダーの特定の序文(任意の)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 追加情報~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CT_IU
図2: コネチカット_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つのセキュリティプロトコルがFibre Channelのために定義されます: FC-2レベルを保護する超能力_Headerプロトコル、およびFC-4レベルでCommon Transportを保護するコネチカット_Authenticationプロトコル。
Security Associations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol.
_超能力HeaderのためのセキュリティAssociationsとコネチカット_AuthenticationプロトコルはFibre Channel Security Association Managementプロトコルによって交渉されます。
3.1. ESP_Header Protocol
3.1. 超能力_ヘッダープロトコル
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.
超能力_HeaderはFC-2 Fibre Channelフレームへの発生源認証、保全、反反復操作による保護、および秘密性を提供するセキュリティプロトコルです。 超能力_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は、FC-2フレームの形式が、超能力で_がHeaderであるとカプセル化したのを示します。 カプセル化形式はIP Encapsulating Security有効搭載量[RFC4303]に同等ですが、認証の範囲は全体のFC-2ヘッダーをカバーしています。 Destination、Source Fibre Channelアドレス(D_IDとS_ID)、およびCS_CTL/優先権分野は、Integrity Check価値の計算の前にアドレス変換を考慮するために正常にされます。
Maino & Black Informational [Page 6] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[6ページ]のRFC4595IKEv2
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///////////////////////////| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | タイプ| F_CTL|Auth+++++++++++++++++++++++++++++++++Cov、-| SEQ_ID| DF_CTL| SEQ_CNT|時代+++++++++++++++++++++++++++++++++ge| 雄牛_ID| RX_ID| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | パラメタ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | セキュリティパラメタインデックス(SPI)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 一連番号| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- | 有効搭載量データ(可変)| |^ ~ ~ || ~ ~Conf| |Cov++-++++++++++++++++++++++++、時代、-| | (0-255バイト)を水増しします。|ge++++++++++++++++++++++++++|| | | パッドの長さ| 予約されます。| vv+++++++++++++++++++++++++++++++++---- | 保全チェック価値(可変)| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ESP_Header Encapsulation
図3: 超能力_ヘッダーカプセル化
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 Encapsulating Security有効搭載量のために定義されるAES-CBCなどのすべてのセキュリティ変換[RFC3602]は超能力_Headerプロトコルに適用できます。
3.2. CT_Authentication Protocol
3.2. コネチカット_認証プロトコル
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
コネチカット_Authenticationは発生源認証、保全、および反反復操作による保護を提供するCommon Transport FC-4情報Unitsのためのセキュリティプロトコルです。 コネチカット_Authenticationプロトコルは任意の拡張コネチカット_IU序文で運ばれます。
Maino & Black Informational [Page 7] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[7ページ]のRFC4595IKEv2
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に示された拡張コネチカット_IU序文はAuthentication Security Association Identifier(サイード)を含んでいます、トランザクションID、要求ノードのN_ポート名、反射攻撃、およびAuthentication Hash Blockを防ぐのにおいて中古のTime Stamp。
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.
すべてのデータが言い表すCRCがさばくフレーム_ヘッダー、基本のコネチカット_IU序文のIN_ID分野、Authentication Hash Block自身、およびフレーム以外のコネチカット_IUのAuthentication Hash Block Coversの範囲。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証は言いました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | トランザクション_イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + _ct N_が名前+を移植するよう要求すること。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + タイムスタンプ+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 認証ハッシュブロック~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extended CT_IU Preamble
図4: 拡張コネチカット_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].
HMACがコネチカット_IU[RFC2104]で定義されるようにハッシュを合わせたので、Authentication Hash Blockは計算されます。 HMAC計算の全体の出力はAuthentication Hash Blockに少しもトランケーションなしで含まれています。 2つの変換が定義されます: 暗号のハッシュ関数SHA1に基づいているHMAC-SHA1-160[NIST.180-1.1995]、および暗号のハッシュ関数MD5に基づいているHMAC-MD5-128[RFC1321]。
Maino & Black Informational [Page 8] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[8ページ]のRFC4595IKEv2
4. The FC SA Management Protocol
4. FC SA管理プロトコル
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.
繊維Channel実体は上でFibre Channel Security Association Managementプロトコルを使用することによって説明されたプロトコルのためにセキュリティ協会を交渉します、[FC-SP]で定義されるように。 プロトコルは同じ中核事業を実行するIKEv2プロトコル[RFC4306]の変更された部分集合です、そして、それはIKEv2メッセージを輸送するのにFibre Channel 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.
プロトコルはIKEv2に関する基本的特徴だけをサポートします: 通知を含むSA、SAが追加SAsを交渉するために交換するCREATE_CHILD_、およびINFORMATIONAL交換が削除するIKE SAと最初の子供を創造する交換、およびベンダーIDペイロードに頭文字をつけてください。 Fibre ChannelsのためにサポートされないIKEv2の特徴は: 同じ提案(複数の傑出している要求、クッキー、構成ペイロード、およびExtended Authenticationプロトコル(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].
以下の小区分はFibre Channel Security Association Managementプロトコルによって必要とされた追加IANA割り当てられた値について説明します、[FC-SP]で定義されるように。 IKEv2プロトコル[RFC4306]のために作成された新しい登録からすべての値を割り当てました。
4.1. Fibre Channel Name Identifier
4.1. 繊維チャンネル名前識別子
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.
セキュリティ協会を交渉する繊維Channels実体が8バイトのNameによって特定されます。 この名前形式のサポートはIKEv2 Identification有効搭載量に加えられます、[RFC4306]のセクション3.5で既に定義されたものを超えて新しいIDタイプを導入して。 Fibre Channel Security Association Managementプロトコルのどんな実装でもこのID Typeをサポートしなければなりません。
The FC_Name_Identifier is then defined as a single 8-octet Fibre Channel Name:
次に、FC_Name_Identifierは独身の8八重奏のFibre Channel Nameと定義されます:
ID Type Value
------- -----
ID_FC_NAME 12
IDタイプ価値------- ----- ID_FC_名12
4.2. ESP_Header and CT_Authentication Protocol ID
4.2. 超能力_ヘッダーとコネチカット_認証プロトコルID
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によって交渉されたセキュリティプロトコルはSecurity Association有効搭載量の提案基礎に含まれたプロトコルID分野によって特定されます、.1セクション3.3[RFC4306]で定義されるように。
The following protocol IDs have been defined to identify the Fibre Channel ESP_Header and the CT_Authentication security protocols:
以下のプロトコルIDはFibre Channel超能力_Headerとコネチカット_Authenticationセキュリティプロトコルを特定するために定義されました:
Maino & Black Informational [Page 9] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[9ページ]のRFC4595IKEv2
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
プロトコルID価値----------- ----- FC_超能力_ヘッダー4
FC_CT_AUTHENTICATION 5
FC_コネチカットの_認証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.
超能力(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自身のプロトコルに依存しています。 Fibre Channel SAの設立を提案するSAペイロードには、以下の義務的で任意の変換タイプがあります。
Protocol Mandatory Types Optional Types
-------- --------------- --------------
FC_ESP_HEADER Integrity Encryption, DH Groups
任意の状態で義務的なタイプについて議定書の中で述べてください、タイプ-------- --------------- -------------- FC_超能力_ヘッダー保全暗号化、DHグループ
FC_CT_AUTHENTICATION Integrity Encryption, DH Groups
FC_コネチカットの_認証保全暗号化、DHグループ
4.3. CT_Authentication Protocol Transform Identifiers
4.3. コネチカット_認証プロトコル変換識別子
The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are:
Transform Type3(保全Algorithm)のために定義されたコネチカット_Authentication Transform IDは以下の通りです。
Name Number Defined in
---- ------ ----------
AUTH_HMAC_MD5_128 6 FC-SP
中で定義された名前番号---- ------ ---------- AUTH_HMAC_MD5_128 6FC-SP
AUTH_HMAC_SHA1_160 7 FC-SP
AUTH_HMAC_SHA1_160 7FC-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の変換がIPsecで唯一HMAC出力のトランケーションの省略に96ビットまで使用した対応する_と異なっています。 代わりに、全体の出力(MD5のための128ビット、SHA-1のための160ビット)は伝えられます。 MD5サポートがMD5の既存の使用法のため_コネチカットAuthenticationで必要です。 SHA-1はすべての新しい実装でRECOMMENDEDです。
4.4. Fibre Channel Traffic Selectors
4.4. 繊維チャンネルトラフィックセレクタ
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.
繊維Channel Traffic Selectorsは同輩に処理のためにFibre Channelセキュリティー・サービスでパケット流れを特定させます。 新しいTraffic Selector Typeは.1セクション3.13[RFC4306]で定義されたIKEv2 Traffic Selector Types Registryに加えられます。 Fibre Channel Security Association Managementプロトコルのどんな実装でもこのTraffic Selector Typeをサポートしなければなりません。
Maino & Black Informational [Page 10] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[10ページ]のRFC4595IKEv2
Fibre Channel traffic selectors are defined in [FC-SP] as a list of FC address and protocol ranges, as shown in Figure 5.
繊維Channelトラフィックセレクタは[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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tタイプ| 予約されます。| セレクタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 開始アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 終了アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 始めのR_CTL| 終わりのR_CTL| 始めのタイプ| 終わりのタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Fibre Channel Traffic Selector
図5: 繊維チャンネルトラフィックセレクタ
The following table lists the assigned value for the Fibre Channel Traffic Selector Type field:
以下のテーブルはFibre Channel Traffic Selector Type分野に割り当てられた値を記載します:
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
tは値をタイプします。------- ----- t_FC_ADDR_範囲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).
StartingとEnding Address分野は初期値設定Fibre Channelコミュニケーションの一部としてFibre Channel名に割り当てられた24ビットのアドレス(例えば、切り換えられたFibre Channel Fabricに関して、エンドノードはFabric Loginからこれらの識別子を取得します、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.
StartingとEnding R_CTL分野はFCフレームのカテゴリといくつかの場合機能を定義する8ビットのルート設定Control識別子です。 詳細に関して[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.
コントロールトラフィックからのFibre Channelデータ通信量の分離の結果、1つのプロトコル(_超能力Headerか_コネチカットAuthenticationのどちらか)だけがどんなFC Security Associationにも適切です。 Fibre Channel Traffic Selectorが超能力_Headerプロトコルのために定義されるとき、Starting TypeとEnding Type分野は、選択されるためにFC-2プロトコルの範囲を特定します。 Fibre Channel Traffic Selectorがコネチカット_Authenticationプロトコルのために定義されるとき、FC-2 Typeはそれとなくコネチカット_Authentication情報ユニットを特定する値の'20h'とStarting Typeに用意ができています、そして、Ending Type分野は選択されるためにGeneric Service血液型亜型(GS_Subtype)の範囲を特定します。 詳細に関して[FC-FS]と[FC GS4]を見てください。
Maino & Black Informational [Page 11] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[11ページ]のRFC4595IKEv2
4.5. Negotiating Security Associations for FC and IP
4.5. FCとIPのためにセキュリティ協会を交渉します。
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.
超能力_ヘッダーとコネチカット_AuthenticationプロトコルはFibre Channelフレームだけに適用されるFibre-チャンネル特有のセキュリティプロトコルです。 IPsecプロトコルにIKEv2交渉の間、本書では定義されたセキュリティプロトコルを特定する値、変換、セレクタ、および名前タイプを使用してはいけません。
5. Security Considerations
5. セキュリティ問題
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.
NAT縦断に関連するものを除いて、IKEv2[RFC4306]のセキュリティ問題はEAP、およびIP断片化を当てはまります。 Fibre Channel Security Association Managementプロトコル(IKEv2に基づいている)によって事実上、NAT縦断とEAPはサポートされません、そして、IPがFibre Channel Security Association Managementプロトコルメッセージを伝えるのに使用されないので、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]).
繊維Channel Security Association ManagementプロトコルメッセージはFibre Channel Sequencesの上で写像されます。 Sequenceは最大4GBのデータを運ぶことができます。 IKEv2メッセージのサイズへのどんな理論上の制限もありません。 しかしながら、特定のフレームに能力を配列する実装が制限したいくつかのFibre Channel終点が以前はFibre Channelの上でよくIKEv2メッセージを写像していました。 これらの制限を扱うために、Fibre Channel Security Association ManagementプロトコルはIKEv2メッセージの断片化をサポートします([FC-SP]のセクション5.9を見てください)。 IKEv2メッセージが断片化の引き金となることができるくらい長いなら、攻撃者が再アセンブリバッファを消耗させることによって完成からのIKEv2交換を防ぐことができるだろうというのは、可能です。 証明書を送ることの代わりにHashとURL encodingsを使用することによって、この機会を最小にすることができます([RFC4306]のセクション3.6を見てください)。
Maino & Black Informational [Page 12] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[12ページ]のRFC4595IKEv2
6. IANA Considerations
6. IANA問題
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 Identificationのために、有効搭載量ID Types Registry([RFC4306]のセクション3.5)を評価します:
ID Type Value
------- -----
ID_FC_NAME 12
IDタイプ価値------- ----- ID_FC_名12
Allocated the following values for the IKEv2 Security Protocol Identifiers Registry (Section 3.3.1 of [RFC4306]):
IKEv2 SecurityプロトコルIdentifiers Registry(.1セクション3.3[RFC4306])のために以下の値を割り当てます:
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
プロトコルID価値----------- ----- FC_超能力_ヘッダー4
FC_CT_AUTHENTICATION 5
FC_コネチカットの_認証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 ID Registry(.2セクション3.3[RFC4306])のためのTransform Type3(保全Algorithm)のために以下の値を割り当てます:
Name Number
---- ------
AUTH_HMAC_MD5_128 6
名前番号---- ------ 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 Traffic Selector Types Registryのために(.1セクション3.13[RFC4306])を評価します:
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9
tは値をタイプします。------- ----- t_FC_ADDR_範囲9
Maino & Black Informational [Page 13] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[13ページ]のRFC4595IKEv2
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[NIST.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", NIST 180-1, April 1995.
[NIST.180-1.1995]米国商務省標準技術局、「安全なハッシュ規格」、NIST180-1、1995年4月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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と共にアルゴリズムとその使用を解きます」、RFC3602、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.、Monia、C.、およびM.Merhar、「繊維チャンネル(FC)はカプセル化を縁どっています」、RFC3643、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)の上の繊維チャンネル」、RFC3602、2004年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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)パケットのトランスミッション」RFC4338(2006年1月)。
7.2. Informative References
7.2. 有益な参照
[FC-FS] INCITS Technical Committee T11, ANSI INCITS 373-2003,
"Fibre Channel - Framing and Signaling (FC-FS)".
[FC-FS] INCITS専門委員会T11、ANSI INCITS373-2003、「縁どっていて合図(FC-FS)である繊維チャンネル。」
[FC-GS-4] INCITS Technical Committee T11, ANSI INCITS 387-2004,
"Fibre Channel - Generic Services 4 (FC-GS-4)".
[FC GS4] INCITS専門委員会T11、ANSI INCITS387-2004、「繊維は精神を集中します--ジェネリックサービス4(FC GS4)。」
Maino & Black Informational [Page 14] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[14ページ]のRFC4595IKEv2
[FC-SP] INCITS Technical Committee T11, ANSI INCITS xxx-200x,
"Fibre Channel - Security Protocols (FC-SP)".
[FC-SP] INCITS Technical Committee 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の技術的なCommitee T11、「INCITS専門委員会T11"、<http://www.t11.org>のホームページ。」
Authors' Addresses
作者のアドレス
Fabio Maino Cisco Systems 375 East Tasman Drive San Jose, CA 95134 US
東タスマン・DriveファビオMainoシスコシステムズ375カリフォルニア95134サンノゼ(米国)
Phone: +1 408 853 7530 EMail: fmaino@cisco.com URI: http://www.cisco.com/
以下に電話をしてください。 +1 7530年の408 853メール: fmaino@cisco.com ユリ: http://www.cisco.com/
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 US
デヴィッドL.黒のEMC社176の南通りMA01748ホプキントン(米国)
Phone: +1 508 293-7953 EMail: black_david@emc.com URI: http://www.emc.com/
以下に電話をしてください。 +1 508 293-7953 メールしてください: black_david@emc.com ユリ: http://www.emc.com/
Maino & Black Informational [Page 15] RFC 4595 IKEv2 in FC-SP July 2006
FC-SP2006年7月のMainoと黒い情報[15ページ]のRFC4595IKEv2
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Maino & Black Informational [Page 16]
Mainoと黒の情報です。[16ページ]
一覧
スポンサーリンク
