[要約] 要約：RFC 3723は、IP上でブロックストレージプロトコルを安全にするためのガイドラインを提供しています。 目的：このRFCの目的は、ブロックストレージプロトコルのセキュリティを向上させ、データの機密性と整合性を確保することです。
Network Working Group B. Aboba
Request for Comments: 3723 Microsoft
Category: Standards Track J. Tseng
McDATA Corporation
J. Walker
Intel
V. Rangan
Brocade Communications Systems Inc.
F. Travostino
Nortel Networks
April 2004
Securing Block Storage Protocols over IP
IPを介したBlock Storage Protocolsの保護
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（C）The Internet Society（2004）。全著作権所有。
Abstract
概要
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.
このドキュメントでは、IPsecとIKE（インターネットキーエクスチェンジ）を使用して、IP（インターネットプロトコル）で実行されるブロックストレージとストレージ検出プロトコルを保護する方法について説明します。脅威モデルとセキュリティプロトコルは、iSCSI（インターネットプロトコルスモールコンピューターシステムインターフェイス）、iFCP（インターネットファイバーチャネルストレージネットワーク）、FCIP（ファイバーチャネルオーバーTCP / IP）、およびiSNS（インターネットストレージネームサーバー）とSLPv2用に開発されています（Service Location Protocol v2）検出プロトコル。パフォーマンスの問題とリソースの制約が分析されます。
Table of Contents
目次
1. Introduction ................................................. 3
1.1. iSCSI Overview ......................................... 3
1.2. iFCP Overview .......................................... 4
1.3. FCIP Overview .......................................... 4
1.4. IPsec Overview ......................................... 4
1.5. Terminology ............................................ 6
1.6. Requirements Language .................................. 7
2. Block Storage Protocol Security .............................. 7
2.1. Security Requirements ................................. 7
2.2. Resource Constraints ................................... 10
2.3. Security Protocol ...................................... 12
2.4. iSCSI Authentication ................................... 16
2.5. SLPv2 Security ......................................... 18
2.6. iSNS Security .......................................... 24
3. iSCSI security Inter-Operability Guidelines .................. 28
3.1. iSCSI Security Issues .................................. 28
3.2. iSCSI and IPsec Interaction ............................ 29
3.3. Initiating a New iSCSI Session ......................... 30
3.4. Graceful iSCSI Teardown ................................ 31
3.5. Non-graceful iSCSI Teardown ............................ 31
3.6. Application Layer CRC .................................. 32
4. iFCP and FCIP Security Issues ................................ 34
4.1. iFCP and FCIP Authentication Requirements .............. 34
4.2. iFCP Interaction with IPsec and IKE .................... 34
4.3. FCIP Interaction with IPsec and IKE .................... 35
5. Security Considerations ...................................... 36
5.1. Transport Mode Versus Tunnel Mode ...................... 36
5.2. NAT Traversal .......................................... 39
5.3. IKE Issues ............................................. 40
5.4. Rekeying Issues ........................................ 40
5.5. Transform Issues ....................................... 43
5.6. Fragmentation Issues ................................... 45
5.7. Security Checks ........................................ 46
5.8. Authentication Issues .................................. 47
5.9. Use of AES in Counter Mode ............................. 51
6. IANA Considerations .......................................... 51
6.1. Definition of Terms .................................... 52
6.2. Recommended Registration Policies ...................... 52
7. Normative References ......................................... 52
8. Informative References ....................................... 54
9. Acknowledgments .............................................. 58
Appendix A - Well Known Groups for Use with SRP ................. 59
Appendix B - Software Performance of IPsec Transforms ........... 61
B.1. Authentication Transforms .............................. 61
B.2. Encryption and Authentication Transforms ............... 64
Authors' Addresses ............................................... 69
Full Copyright Statement ......................................... 70
This specification discusses use of the IPsec protocol suite for protecting block storage protocols over IP networks (including iSCSI, iFCP and FCIP), as well as storage discovery protocols (iSNS and SLPv2).
この仕様では、IPネットワーク（iSCSI、iFCP、FCIPを含む）を介してブロックストレージプロトコルを保護するためのIPsecプロトコルスイート、およびストレージ検出プロトコル（iSNSおよびSLPv2）の使用について説明します。
iSCSI, described in [RFC3720], is a connection-oriented command/response protocol that runs over TCP, and is used to access disk, tape and other devices. iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets) and perform an iSCSI login.
[RFC3720]で説明されているiSCSIは、TCPで実行される接続指向のコマンド/応答プロトコルであり、ディスク、テープ、その他のデバイスへのアクセスに使用されます。 iSCSIは、クライアント（イニシエーター）がサーバー（ターゲット）への接続を開き、iSCSIログインを実行するクライアントサーバープロトコルです。
This document uses the SCSI terms initiator and target for clarity and to avoid the common assumption that clients have considerably less computational and memory resources than servers; the reverse is often the case for SCSI, as targets are commonly dedicated devices of some form.
このドキュメントでは、明確にするため、およびクライアントがサーバーよりもかなり少ない計算およびメモリリソースを持っているという一般的な仮定を避けるために、SCSI用語のイニシエーターおよびターゲットを使用しています。ターゲットは一般的に何らかの形の専用デバイスであるため、SCSIの場合はその逆がよくあります。
The iSCSI protocol has a text based negotiation mechanism as part of its initial (login) procedure. The mechanism is extensible in what can be negotiated (new text keys and values can be defined) and also in the number of negotiation rounds (e.g., to accommodate functionality such as challenge-response authentication).
iSCSIプロトコルには、最初の（ログイン）手順の一部として、テキストベースのネゴシエーションメカニズムがあります。このメカニズムは、ネゴシエートできるもの（新しいテキストキーと値を定義できます）およびネゴシエーションラウンドの数（チャレンジ/レスポンス認証などの機能に対応するため）で拡張可能です。
After a successful login, the iSCSI initiator may issue SCSI commands for execution by the iSCSI target, which returns a status response for each command, over the same connection. A single connection is used for both command/status messages as well as transfer of data and/or optional command parameters. An iSCSI session may have multiple connections, but a separate login is performed on each. The iSCSI session terminates when its last connection is closed.
ログインに成功すると、iSCSIイニシエーターは、iSCSIターゲットが実行するSCSIコマンドを発行し、同じ接続を介して各コマンドのステータス応答を返します。 1つの接続が、コマンド/ステータスメッセージと、データやオプションのコマンドパラメータの転送の両方に使用されます。 iSCSIセッションには複数の接続がある場合がありますが、それぞれに個別のログインが実行されます。最後の接続が閉じられると、iSCSIセッションは終了します。
iSCSI initiators and targets are application layer entities that are independent of TCP ports and IP addresses. Initiators and targets have names whose syntax is defined in [RFC3721]. iSCSI sessions between a given initiator and target are run over one or more TCP connections between those entities. That is, the login process establishes an association between an iSCSI Session and the TCP connection(s) over which iSCSI PDUs will be carried.
iSCSIイニシエーターとターゲットは、TCPポートとIPアドレスに依存しないアプリケーションレイヤーエンティティです。イニシエータとターゲットには、[RFC3721]で構文が定義されている名前があります。特定のイニシエータとターゲット間のiSCSIセッションは、それらのエンティティ間の1つ以上のTCP接続で実行されます。つまり、ログインプロセスは、iSCSIセッションと、iSCSI PDUが伝送されるTCP接続との間の関連付けを確立します。
While the iSCSI login may include mutual authentication of the iSCSI endpoints and negotiation of session parameters, iSCSI does not define its own per-packet authentication, integrity, confidentiality or replay protection mechanisms. Rather, it relies upon the IPsec protocol suite to provide per-packet data confidentiality and integrity and authentication services, with IKE as the key management protocol. iSCSI uses TCP to provide congestion control, error detection and error recovery.
iSCSIログインには、iSCSIエンドポイントの相互認証とセッションパラメータのネゴシエーションが含まれる場合がありますが、iSCSIは独自のパケットごとの認証、整合性、機密性、または再生保護メカニズムを定義していません。むしろ、IPsecプロトコルスイートに依存して、IKEをキー管理プロトコルとして使用して、パケットごとのデータの機密性と整合性、および認証サービスを提供します。 iSCSIはTCPを使用して、輻輳制御、エラー検出、およびエラー回復を提供します。
iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which provides transport services to Fibre Channel devices over a TCP/IP network. iFCP allows interconnection and networking of existing Fibre Channel devices at wire speeds over an IP network. iFCP implementations emulate fabric services in order to improve fault tolerance and scalability by fully leveraging IP technology. Each TCP connection is used to support storage traffic between a unique pair of Fibre Channel N_PORTs.
[iFCP]で定義されているiFCPは、ゲートウェイ間プロトコルであり、TCP / IPネットワークを介してファイバーチャネルデバイスにトランスポートサービスを提供します。 iFCPを使用すると、IPネットワークを介して既存のファイバーチャネルデバイスをワイヤスピードで相互接続およびネットワーキングできます。 iFCP実装はファブリックサービスをエミュレートし、IPテクノロジーを完全に活用してフォールトトレランスとスケーラビリティを向上させます。各TCP接続は、ファイバーチャネルN_PORTの一意のペア間のストレージトラフィックをサポートするために使用されます。
iFCP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. iFCP uses TCP to provide congestion control, error detection and error recovery.
iFCPには、ネイティブのインバンドセキュリティメカニズムがありません。むしろ、IPsecプロトコルスイートに依存してデータの機密性と認証サービスを提供し、IKEをキー管理プロトコルとして使用します。 iFCPはTCPを使用して、輻輳制御、エラー検出、およびエラー回復を提供します。
FCIP, defined in [FCIP], is a pure FC encapsulation protocol that transports FC frames. Current specification work intends this for interconnection of Fibre Channel switches over TCP/IP networks, but the protocol is not inherently limited to connecting FC switches. FCIP differs from iFCP in that no interception or emulation of fabric services is involved. One or more TCP connections are bound to an FCIP Link, which is used to realize Inter-Switch Links (ISLs) between pairs of Fibre Channel entities. FCIP Frame Encapsulation is described in [RFC3643].
[FCIP]で定義されているFCIPは、FCフレームを転送する純粋なFCカプセル化プロトコルです。現在の仕様では、これはTCP / IPネットワーク上のファイバーチャネルスイッチの相互接続を目的としていますが、プロトコルは本質的にFCスイッチの接続に限定されていません。 FCIPは、ファブリックサービスのインターセプトまたはエミュレーションが含まれないという点でiFCPとは異なります。 1つ以上のTCP接続がFCIPリンクにバインドされます。これは、ファイバーチャネルエンティティのペア間のスイッチ間リンク（ISL）を実現するために使用されます。 FCIPフレームカプセル化は、[RFC3643]で説明されています。
FCIP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. FCIP uses TCP to provide congestion control, error detection and error recovery.
FCIPには、ネイティブのインバンドセキュリティメカニズムがありません。むしろ、IPsecプロトコルスイートに依存してデータの機密性と認証サービスを提供し、IKEをキー管理プロトコルとして使用します。 FCIPはTCPを使用して、輻輳制御、エラー検出、およびエラー回復を提供します。
IPsec is a protocol suite which is used to secure communication at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [RFC2401], IKE [RFC2409][RFC2412], IPsec Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic.
IPsecは、2つのピア間のネットワーク層での通信を保護するために使用されるプロトコルスイートです。 IPsecプロトコルスイートは、IPセキュリティアーキテクチャ[RFC2401]、IKE [RFC2409] [RFC2412]、IPsec認証ヘッダー（AH）[RFC2402]、およびIPsecカプセル化セキュリティペイロード（ESP）[RFC2406]のドキュメントで指定されています。 IKEはキー管理プロトコルであり、AHおよびESPはIPトラフィックを保護するために使用されます。
An IPsec SA is a one-way security association, uniquely identified by the 3-tuple: Security Parameter Index (SPI), protocol (ESP) and destination IP. The parameters for an IPsec security association are typically established by a key management protocol. These include the encapsulation mode, encapsulation type, session keys and SPI values.
IPsec SAは一方向のセキュリティアソシエーションであり、セキュリティパラメータインデックス（SPI）、プロトコル（ESP）、および宛先IPの3タプルによって一意に識別されます。 IPsecセキュリティアソシエーションのパラメータは、通常、キー管理プロトコルによって確立されます。これらには、カプセル化モード、カプセル化タイプ、セッションキー、SPI値が含まれます。
IKE is a two phase negotiation protocol based on the modular exchange of messages defined by ISAKMP [RFC2408],and the IP Security Domain of Interpretation (DOI) [RFC2407]. IKE has two phases, and accomplishes the following functions:
IKEは、ISAKMP [RFC2408]、およびIP Security Domain of Interpretation（DOI）[RFC2407]によって定義されたメッセージのモジュラー交換に基づく2フェーズネゴシエーションプロトコルです。 IKEには2つのフェーズがあり、次の機能を実行します。
[1] Protected cipher suite and options negotiation - using keyed MACs and encryption and anti-replay mechanisms
[1] 保護された暗号スイートとオプションのネゴシエーション-キー付きMACと暗号化およびアンチリプレイメカニズムの使用
[2] Master key generation - such as via MODP Diffie-Hellman calculations
[2] マスターキーの生成-MODP Diffie-Hellman計算などによる
[3] Authentication of end-points
[3] エンドポイントの認証
[4] IPsec SA management (selector negotiation, options negotiation, create, delete, and rekeying)
[4] IPsec SA管理（セレクターネゴシエーション、オプションネゴシエーション、作成、削除、およびキーの再生成）
Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is handled in IKE Phase 2.
項目1〜3はIKEフェーズ1で実行され、項目4はIKEフェーズ2で処理されます。
An IKE Phase 2 negotiation is performed to establish both an inbound and an outbound IPsec SA. The traffic to be protected by an IPsec SA is determined by a selector which has been proposed by the IKE initiator and accepted by the IKE Responder. In IPsec transport mode, the IPsec SA selector can be a "filter" or traffic classifier, defined as the 5-tuple: <Source IP address, Destination IP address, transport protocol (UDP/SCTP/TCP), Source port, Destination port>. The successful establishment of a IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <Protocol (ESP/AH), destination address, SPI>.
IKEフェーズ2ネゴシエーションが実行され、着信IPsec SAと発信IPsec SAの両方が確立されます。 IPsec SAによって保護されるトラフィックは、IKEイニシエーターによって提案され、IKEレスポンダーによって受け入れられたセレクターによって決定されます。 IPsecトランスポートモードでは、IPsec SAセレクターは、5つのタプルとして定義された「フィルター」またはトラフィック分類子にすることができます。<送信元IPアドレス、宛先IPアドレス、トランスポートプロトコル（UDP / SCTP / TCP）、送信元ポート、宛先ポート>。 IKEフェーズ2 SAが正常に確立されると、<プロトコル（ESP / AH）、宛先アドレス、SPI>というタプルで完全修飾された2つの単方向IPsec SAが作成されます。
The session keys for each IPsec SA are derived from a master key, typically via a MODP Diffie-Hellman computation. Rekeying of an existing IPsec SA pair is accomplished by creating two new IPsec SAs, making them active, and then optionally deleting the older IPsec SA pair. Typically the new outbound SA is used immediately, and the old inbound SA is left active to receive packets for some locally defined time, perhaps 30 seconds or 1 minute.
各IPsec SAのセッションキーは、通常はMODP Diffie-Hellman計算を介して、マスターキーから取得されます。既存のIPsec SAペアの鍵の更新は、2つの新しいIPsec SAを作成し、それらをアクティブにしてから、オプションで古いIPsec SAペアを削除することによって行われます。通常、新しいアウトバウンドSAはすぐに使用され、古いインバウンドSAは、ローカルで定義された時間（おそらく30秒または1分）の間パケットを受信するためにアクティブのままになります。
Fibre Channel Fibre Channel (FC) is a gigabit speed networking technology primarily used to implement Storage Area Networks (SANs), although it also may be used to transport other frames types as well, including IP. FC is standardized under American National Standard for Information Systems of the InterNational Committee for Informational Technology Standards (ANSI-INCITS) in its T11 technical committee.
ファイバーチャネルファイバーチャネル（FC）は、主にストレージエリアネットワーク（SAN）の実装に使用されるギガビット速度のネットワーキングテクノロジーですが、IPを含む他の種類のフレームの転送にも使用できます。 FCは、国際情報技術標準委員会（ANSI-INCITS）のT11技術委員会の米国情報システム標準に基づいて標準化されています。
FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting Fibre Channel islands over IP Networks so as to form a unified SAN in a single Fibre Channel fabric. The principal FCIP interface point to the IP Network is the FCIP Entity. The FCIP Link represents one or more TCP connections that exist between a pair of FCIP Entities.
FCIP Fibre Channel over IP（FCIP）は、単一のファイバーチャネルファブリックで統合SANを形成するために、IPネットワークを介してファイバーチャネルアイランドを相互接続するためのプロトコルです。 IPネットワークを指す主要なFCIPインターフェイスは、FCIPエンティティです。 FCIPリンクは、FCIPエンティティのペア間に存在する1つ以上のTCP接続を表します。
HBA Host Bus Adapter (HBA) is a generic term for a SCSI interface to other device(s); it's roughly analogous to the term Network Interface Card (NIC) for a TCP/IP network interface, except that HBAs generally have on-board SCSI implementations, whereas most NICs do not implement TCP, UDP, or IP.
HBAホストバスアダプター（HBA）は、他のデバイスへのSCSIインターフェイスの総称です。ほとんどのNICがTCP、UDP、またはIPを実装していないのに対し、HBAは一般にオンボードSCSI実装を備えていることを除いて、TCP / IPネットワークインターフェースの用語であるネットワークインターフェースカード（NIC）とほぼ同じです。
iFCP iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network.
iFCP iFCPはゲートウェイ間プロトコルであり、TCP / IPネットワークを介してファイバーチャネルデバイスにファイバーチャネルファブリックサービスを提供します。
IP block storage protocol Where used within this document, the term "IP block storage protocol" applies to all block storage protocols running over IP, including iSCSI, iFCP and FCIP.
IPブロックストレージプロトコルこのドキュメント内で使用されている場合、「IPブロックストレージプロトコル」という用語は、iSCSI、iFCP、FCIPを含む、IPを介して実行されるすべてのブロックストレージプロトコルに適用されます。
iSCSI iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets).
iSCSI iSCSIは、クライアント（イニシエーター）がサーバー（ターゲット）への接続を開くクライアントサーバープロトコルです。
iSNS The Internet Storage Name Server (iSNS) protocol provides for discovery and management of iSCSI and Fibre Channel (FCP) storage devices. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, providing a consolidated information repository for an integrated IP block storage network. iFCP requires iSNS for discovery and management, while iSCSI may use iSNS for discovery, and FCIP does not use iSNS.
iSNSインターネットストレージネームサーバー（iSNS）プロトコルは、iSCSIおよびファイバーチャネル（FCP）ストレージデバイスの検出と管理を提供します。 iSNSアプリケーションは、iSCSIおよびFCデバイスの属性を保存し、それらの可用性と到達可能性を監視して、統合されたIPブロックストレージネットワークに統合された情報リポジトリを提供します。 iFCPでは検出と管理にiSNSが必要ですが、iSCSIでは検出にiSNSを使用でき、FCIPではiSNSを使用しません。
initiator The iSCSI initiator connects to the target on well-known TCP port 3260. The iSCSI initiator then issues SCSI commands for execution by the iSCSI target.
イニシエータiSCSIイニシエータは、既知のTCPポート3260でターゲットに接続します。次に、iSCSIイニシエータは、SCSIコマンドを発行して、iSCSIターゲットで実行します。
target The iSCSI target listens on a well-known TCP port for incoming connections, and returns a status response for each command issued by the iSCSI initiator, over the same connection.
ターゲットiSCSIターゲットは、着信接続を既知のTCPポートでリッスンし、同じ接続を介して、iSCSIイニシエーターによって発行された各コマンドのステータス応答を返します。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「OPTIONAL」、「RECOMMENDED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」は解釈されます[RFC2119]で説明されています。
Note that requirements specified in this document apply only to use of IPsec and IKE with IP block storage protocols. Thus, these requirements do not apply to IPsec implementations in general. Implementation requirements language should therefore be assumed to relate to the availability of features for use with IP block storage security only.
このドキュメントで指定されている要件は、IPブロックストレージプロトコルでのIPsecおよびIKEの使用にのみ適用されることに注意してください。したがって、これらの要件は一般にIPsec実装には適用されません。したがって、実装要件言語は、IPブロックストレージセキュリティでのみ使用できる機能の可用性に関連していると想定する必要があります。
Although the security requirements in this document are already incorporated into the iSCSI [RFC3720], iFCP [iFCP] and FCIP [FCIP] standards track documents, they are reproduced here for convenience. In the event of a discrepancy, the individual protocol standards track documents take precedence.
このドキュメントのセキュリティ要件は、iSCSI [RFC3720]、iFCP [iFCP]、およびFCIP [FCIP]の標準トラックドキュメントにすでに組み込まれていますが、便宜上ここで再現されています。不一致が発生した場合は、個々のプロトコル標準トラックドキュメントが優先されます。
IP Block storage protocols such as iSCSI, iFCP and FCIP are used to transmit SCSI commands over IP networks. Therefore, both the control and data packets of these IP block storage protocols are vulnerable to attack. Examples of attacks include:
iSCSI、iFCP、FCIPなどのIPブロックストレージプロトコルは、IPネットワーク経由でSCSIコマンドを送信するために使用されます。したがって、これらのIPブロックストレージプロトコルの制御パケットとデータパケットの両方が攻撃に対して脆弱です。攻撃の例は次のとおりです。
[1] An adversary may attempt to acquire confidential data and identities by snooping data packets.
[1] 攻撃者は、データパケットをスヌーピングして、機密データとIDを取得しようと試みる可能性があります。
[2] An adversary may attempt to modify packets containing data and control messages.
[2] 攻撃者は、データと制御メッセージを含むパケットを変更しようと試みる可能性があります。
[3] An adversary may attempt to inject packets into an IP block storage connection.
[3] 攻撃者は、IPブロックストレージ接続にパケットを挿入しようとする可能性があります。
[4] An adversary may attempt to hijack TCP connection(s) corresponding to an IP block storage session.
[4] 攻撃者は、IPブロックストレージセッションに対応するTCP接続をハイジャックしようとする可能性があります。
[5] An adversary may launch denial of service attacks against IP block storage devices such as by sending a TCP reset.
[5] 攻撃者は、TCPリセットを送信するなどして、IPブロックストレージデバイスに対してサービス拒否攻撃を仕掛けることがあります。
[6] An adversary may attempt to disrupt security negotiation process, in order to weaken the authentication, or gain access to user passwords. This includes disruption of application-layer authentication negotiations such as iSCSI Login.
[6] 攻撃者は、認証を弱めたり、ユーザーのパスワードにアクセスしたりするために、セキュリティネゴシエーションプロセスを妨害しようと試みる可能性があります。これには、iSCSIログインなどのアプリケーション層認証ネゴシエーションの中断が含まれます。
[7] An adversary may attempt to impersonate a legitimate IP block storage entity.
[7] 敵対者が正当なIPブロックストレージエンティティになりすまそうとする可能性があります。
[8] An adversary may launch a variety of attacks (packet modification or injection, denial of service) against the discovery (SLPv2 [RFC2608]) or discovery and management (iSNS [iSNS]) process. iSCSI can use SLPv2 or iSNS. FCIP only uses SLPv2, and iFCP only uses iSNS.
[8] 攻撃者は、発見（SLPv2 [RFC2608]）または発見と管理（iSNS [iSNS]）プロセスに対してさまざまな攻撃（パケットの変更またはインジェクション、サービス拒否）を実行する可能性があります。 iSCSIはSLPv2またはiSNSを使用できます。 FCIPはSLPv2のみを使用し、iFCPはiSNSのみを使用します。
Since iFCP and FCIP devices are the last line of defense for a whole Fibre Channel island, the above attacks, if successful, could compromise the security of all the Fibre Channel hosts behind the devices.
iFCPおよびFCIPデバイスは、ファイバーチャネルアイランド全体の最後の防御線であるため、上記の攻撃が成功した場合、デバイスの背後にあるすべてのファイバーチャネルホストのセキュリティが侵害される可能性があります。
To address the above threats, IP block storage security protocols must support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis. Confidentiality services are important since IP block storage traffic may traverse insecure public networks. The IP block storage security protocols must support perfect forward secrecy in the rekeying process.
上記の脅威に対処するには、IPブロックストレージセキュリティプロトコルが、機密性、データ発信元認証、整合性、およびパケット単位のリプレイ保護をサポートする必要があります。 IPブロックストレージトラフィックは安全でないパブリックネットワークを通過する可能性があるため、機密性サービスは重要です。 IPブロックストレージセキュリティプロトコルは、鍵更新プロセスで完全転送秘密をサポートする必要があります。
Bi-directional authentication of the communication endpoints MUST be provided. There is no requirement that the identities used in authentication be kept confidential (e.g., from a passive eavesdropper).
通信エンドポイントの双方向認証を提供する必要があります。認証で使用されるIDを（たとえば、受動的な盗聴者から）秘密にしておく必要はありません。
For a security protocol to be useful, CPU overhead and hardware availability must not preclude implementation at 1 Gbps today. Implementation feasibility at 10 Gbps is highly desirable, but may not be demonstrable at this time. These performance levels apply to aggregate throughput, and include all TCP connections used between IP block storage endpoints. IP block storage communications typically involve multiple TCP connections. Performance issues are discussed further in Appendix B.
セキュリティプロトコルが役立つためには、CPUのオーバーヘッドとハードウェアの可用性によって、今日の1 Gbpsでの実装が妨げられてはなりません。 10 Gbpsでの実装の実現可能性は非常に望ましいですが、現時点では実証できない場合があります。これらのパフォーマンスレベルは総スループットに適用され、IPブロックストレージエンドポイント間で使用されるすべてのTCP接続が含まれます。 IPブロックストレージ通信には通常、複数のTCP接続が含まれます。パフォーマンスの問題については、付録Bで詳しく説明します。
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from possible security threats. Such networks are often protected by security gateways, which at a minimum provide a shield against denial of service attacks. The IP block storage security architecture should be able to leverage the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and VPN services available on existing security gateways.
エンタープライズデータセンターネットワークは、セキュリティ上の脅威から隔離および保護する必要があるミッションクリティカルな設備と見なされています。このようなネットワークは、多くの場合、最低でもサービス拒否攻撃に対するシールドを提供するセキュリティゲートウェイによって保護されています。 IPブロックストレージセキュリティアーキテクチャは、ファイアウォール保護、NATおよびNAPTサービス、既存のセキュリティゲートウェイで利用可能なVPNサービスなど、既存のセキュリティインフラストラクチャの保護サービスを活用できる必要があります。
When iFCP or FCIP devices are deployed within enterprise networks, IP addresses will be typically be statically assigned as is the case with most routers and switches. Consequently, support for dynamic IP address assignment, as described in [RFC3456], will typically not be required, although it cannot be ruled out. Such facilities will also be relevant to iSCSI hosts whose addresses are dynamically assigned. As a result, the IP block storage security protocols must not introduce additional security vulnerabilities where dynamic address assignment is supported.
企業ネットワーク内にiFCPまたはFCIPデバイスが配備されている場合、ほとんどのルーターやスイッチの場合と同様に、IPアドレスは通常静的に割り当てられます。したがって、[RFC3456]で説明されているように、動的IPアドレス割り当てのサポートは、除外することはできませんが、通常は必要ありません。このような機能は、アドレスが動的に割り当てられるiSCSIホストにも関連します。その結果、IPブロックストレージセキュリティプロトコルは、動的なアドレス割り当てがサポートされている場合、セキュリティ上の脆弱性を追加してはなりません。
While IP block storage security is mandatory to implement, it is not mandatory to use. The security services used depend on the configuration and security policies put in place. For example, configuration will influence the authentication algorithm negotiated within iSCSI Login, as well as the security services (confidentiality, data origin authentication, integrity, replay protection) and transforms negotiated when IPsec is used to protect IP block storage protocols such as iSCSI, iFCP and FCIP.
IPブロックストレージセキュリティの実装は必須ですが、使用は必須ではありません。使用されるセキュリティサービスは、配置されている構成とセキュリティポリシーによって異なります。たとえば、構成は、iSCSIログイン内でネゴシエートされた認証アルゴリズムとセキュリティサービス（機密性、データ発信元認証、整合性、リプレイ保護）に影響し、IPsecがiSCSI、iFCPなどのIPブロックストレージプロトコルを保護するためにネゴシエートされたときに変換されます。およびFCIP。
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. For iFCP, the granularity corresponds to an iFCP Portal. For iSCSI, the granularity of control is typically that of an iSCSI session, although it is possible to exert control down to the granularity of the destination IP address and TCP port.
FCIP実装では、FCIPリンクの粒度でセキュリティメカニズムを有効または無効にできる場合があります。 iFCPの場合、粒度はiFCPポータルに対応します。 iSCSIの場合、制御の細分性は通常、iSCSIセッションの細分性ですが、宛先IPアドレスとTCPポートの細分性まで制御することも可能です。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that IP block storage connections requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA.
IPsecでは、セキュリティサービスはIPsec SAの粒度でネゴシエートされるため、既存のIPsec SAとネゴシエートされたものとは異なるセキュリティサービスのセットを必要とするIPブロックストレージ接続は、新しいIPsec SAをネゴシエートする必要があります。
Separate IPsec SAs are also advisable where quality of service considerations dictate different handling of IP block storage connections. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
サービス品質の考慮によりIPブロックストレージ接続の処理が異なる場合は、個別のIPsec SAも推奨されます。同じIPsec SAで処理される接続に異なるサービス品質を適用しようとすると、並べ替えが発生し、再生ウィンドウの範囲外になる可能性があります。問題の議論については、[RFC2983]を見てください。
IP block storage protocols can be expected to carry sensitive data and provide access to systems and data that require protection against security threats. SCSI and Fibre Channel currently contain little in the way of security mechanisms, and rely on physical security, administrative security, and correct configuration of the communication medium and systems/devices attached to it for their security properties.
IPブロックストレージプロトコルは、機密データを伝送し、セキュリティの脅威に対する保護を必要とするシステムおよびデータへのアクセスを提供することが期待できます。現在、SCSIとファイバーチャネルにはセキュリティメカニズムがほとんど含まれておらず、物理的なセキュリティ、管理セキュリティ、および通信メディアとそれに接続されているシステム/デバイスの正しいプロパティに基づいてセキュリティプロパティを設定しています。
For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used by IP block storage protocols (e.g., iSCSI SHOULD use one of its in-band authentication mechanisms or the authentication provided by IKE) in order to provide a minimal assurance that connections have initially been opened with the intended counterpart.
ほとんどのIPネットワークでは、物理的なセキュリティ、管理セキュリティ、およびネットワークと接続されているすべてのノードの正しい構成を想定することは不適切です（テストラボで物理的に分離されたネットワークは例外になる場合があります）。したがって、意図した相手との接続が最初に開かれたことを最小限に保証するために、IPブロックストレージプロトコルで認証を使用する必要があります（たとえば、iSCSIは、そのインバンド認証メカニズムの1つまたはIKEによって提供される認証を使用する必要があります）。
iSNS, described in [iSNS], is required in all iFCP deployments. iSCSI may use iSNS for discovery, and FCIP does not use iSNS. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, providing a consolidated information repository for an integrated IP block storage network. The iSNS specification defines mechanisms to secure communication between an iSNS server and its clients.
[iSNS]で説明されているiSNSは、すべてのiFCP展開で必要です。 iSCSIはiSNSを検出に使用でき、FCIPはiSNSを使用しません。 iSNSアプリケーションは、iSCSIおよびFCデバイスの属性を保存し、それらの可用性と到達可能性を監視して、統合されたIPブロックストレージネットワークに統合された情報リポジトリを提供します。 iSNS仕様では、iSNSサーバーとそのクライアント間の通信を保護するメカニズムを定義しています。
Resource constraints and performance requirements for iSCSI are discussed in [RFC3347] Section 3.2. iFCP and FCIP devices will typically be embedded systems deployed on racks in air-conditioned data center facilities. Such embedded systems may include hardware chipsets to provide data encryption, authentication, and integrity processing. Therefore, memory and CPU resources are generally not a constraining factor.
iSCSIのリソース制約とパフォーマンス要件については、[RFC3347]セクション3.2で説明しています。 iFCPおよびFCIPデバイスは、通常、空調されたデータセンター施設のラックに配置される組み込みシステムです。このような組み込みシステムには、データの暗号化、認証、および整合性処理を提供するハードウェアチップセットが含まれる場合があります。したがって、メモリとCPUリソースは一般に制約要因ではありません。
iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). In general, a host bus adapter is the most constrained iSCSI implementation environment, although an HBA may draw upon the resources of the system to which it is attached in some cases (e.g., authentication computations required for connection setup). More resources should be available to iSCSI implementations for embedded and general purpose operating systems. The following guidelines indicate the approximate level of resources that authentication, keying, and rekeying functionality can reasonably expect to draw upon:
iSCSIは、汎用オペレーティングシステムを実行している大規模サーバーから組み込みホストバスアダプター（HBA）に至るまで、さまざまなシステムに実装されます。一般に、ホストバスアダプターは最も制約の多いiSCSI実装環境ですが、HBAは、接続されているシステムのリソース（接続のセットアップに必要な認証計算など）を利用する場合があります。組み込みおよび汎用オペレーティングシステムのiSCSI実装では、より多くのリソースを利用できる必要があります。次のガイドラインは、認証、キーイング、およびキー再生成機能が合理的に利用できるリソースのおおよそのレベルを示しています。
- Low power processors with small word size are generally not used, as power is usually not a constraining factor, with the possible exception of HBAs, which can draw upon the computational resources of the system into which they are inserted. Computational horsepower should be available to perform a reasonable amount of exponentiation as part of authentication and key derivation for connection setup. The same is true of rekeying, although the ability to avoid exponentiation for rekeying may be desirable (but is not an absolute requirement).
- 電力は通常制約要因ではないため、ワードサイズの小さい低電力プロセッサは通常使用されません。ただし、HBAは例外であり、それらが挿入されるシステムの計算リソースを利用する可能性があります。接続セットアップの認証およびキー導出の一部として、適度な指数を実行するために計算馬力が利用可能である必要があります。同じことがキーの再生成にも当てはまりますが、キーの再生成の累乗を回避する機能が望ましい場合があります（ただし、これは絶対的な要件ではありません）。
- RAM and/or flash resources tend to be constrained in embedded implementations. 8-10 MB of code and data for authentication, keying, and rekeying is clearly excessive, 800-1000 KB is clearly larger than desirable, but tolerable if there is no other alternative and 80-100 KB should be acceptable. These sizes are intended as rough order of magnitude guidance, and should not be taken as hard targets or limits (e.g., smaller code sizes are always better). Software implementations for general purpose operating systems may have more leeway.
- 組み込み実装では、RAMおよび/またはフラッシュリソースが制約される傾向があります。認証、キーイング、リキーイング用の8〜10 MBのコードとデータは明らかに過剰であり、800〜1000 KBは明らかに望ましいサイズよりも大きくなりますが、他に代替手段がなく、80〜100 KBを許容できる場合は許容できます。これらのサイズは、大まかな規模のガイダンスとして意図されており、ハードターゲットや制限として解釈されるべきではありません（たとえば、コードサイズが小さいほど常に優れています）。汎用オペレーティングシステムのソフトウェア実装には、より多くの余裕があります。
The primary resource concern for implementation of authentication and keying mechanisms is code size, as iSCSI assumes that the computational horsepower to do exponentiations will be available.
iSCSIは指数を実行するための計算能力が利用可能であると想定しているため、認証およびキーイングメカニズムの実装に関する主なリソースの問題はコードサイズです。
There is no dominant iSCSI usage scenario - the scenarios range from a single connection constrained only by media bandwidth to hundreds of initiator connections to a single target or communication endpoint. SCSI sessions and hence the connections they use tend to be relatively long lived; for disk storage, a host typically opens a SCSI connection on boot and closes it on shutdown. Tape session length tends to be measured in hours or fractions thereof (i.e., rapid fire sharing of the same tape device among different initiators is unusual), although tape robot control sessions can be short when the robot is shared among tape drives. On the other hand, tape will not see a large number of initiator connections to a single target or communication endpoint, as each tape drive is dedicated to a single use at a single time, and a dozen tape drives is a large tape device.
主要なiSCSIの使用シナリオはありません。シナリオには、メディアの帯域幅によってのみ制限される単一の接続から、単一のターゲットまたは通信エンドポイントへの何百ものイニシエーター接続までの範囲があります。 SCSIセッション、したがってそれらが使用する接続は、比較的長持ちする傾向があります。ディスクストレージの場合、ホストは通常、起動時にSCSI接続を開き、シャットダウン時にそれを閉じます。テープセッションの長さは、時間またはその分数で測定される傾向があります（つまり、異なるイニシエーター間での同じテープデバイスの迅速なファイアシェアリングは異常です）。一方、各テープドライブは一度に1回の使用専用であり、1ダースのテープドライブは大きなテープデバイスであるため、テープは単一のターゲットまたは通信エンドポイントへの多数のイニシエーター接続を認識しません。
All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets, as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used.
すべてのIPブロックストレージセキュリティ準拠の実装は、IPsec ESP [RFC2406]をサポートして、制御パケットとデータパケットの両方にセキュリティを提供するとともに、IPsecのリプレイ保護メカニズムを提供する必要があります。 ESPを利用する場合、パケットごとのデータ発信元認証、整合性、およびリプレイ保護を使用する必要があります。
To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. ESP with NULL encryption MUST be supported for authentication.
ESPで機密性を提供するには、CBCモードで3DESを使用するESP [RFC2451] [3DESANSI]をサポートする必要があり、[RFC3686]で説明されているように、カウンターモードでAESをサポートする必要があります（SHOULD）。 ESPでデータ発信元認証と整合性を提供するには、HMAC-SHA1 [RFC2404]をサポートする必要があり、XCBC拡張を使用したCBC MACモードのAES [RFC3566]をサポートする必要があります（SHOULD）。 CBCモードのDESは、固有の弱点があるため使用しないでください。 NULL暗号化のESPは、認証でサポートされている必要があります。
Conformant IP block storage protocol implementations MUST support ESP [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport mode.
適合IPブロックストレージプロトコルの実装は、トンネルモードでESP [RFC2406]をサポートしなければならず（MUST）、トランスポートモードでESPを使用してIPsecを実装してもよい（MAY）。
Conformant IP block storage security implementations MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used since it does not provide the necessary rekeying support. Conformant IP block storage security implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used.
適合IPブロックストレージセキュリティ実装は、IPsec DOI [RFC2407]を使用して、ピア認証、セキュリティアソシエーションのネゴシエーション、およびキー管理のためにIKE [RFC2409]をサポートする必要があります。手動のキーイングは、必要なキーイングのサポートを提供しないため、使用しないでください。適合IPブロックストレージセキュリティの実装は、事前共有キーを使用したピア認証をサポートする必要があり、デジタル署名を使用した証明書ベースのピア認証をサポートする場合があります（MAY）。 IKEのセクション5.2および5.3で概説されている公開鍵暗号化方式を使用したピア認証[RFC2409]は使用しないでください。
Conformant IP block storage security implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use a dynamically assigned IP address. While Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force use of a group pre-shared key, which is vulnerable to man-in-the-middle attack.
適合IPブロックストレージセキュリティ実装は、IKEメインモードをサポートする必要があり、アグレッシブモードをサポートする必要があります（SHOULD）。事前共有キー認証を使用するIKEメインモードは、いずれかのピアが動的に割り当てられたIPアドレスを使用する場合は使用しないでください。事前共有キー認証を使用するメインモードは多くの場合に優れたセキュリティを提供しますが、動的に割り当てられたアドレスが使用される状況では、グループ事前共有キーが強制的に使用されます。これは中間者攻撃に対して脆弱です。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) must be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
認証にデジタル署名が使用される場合、IKEメインモードまたはIKEアグレッシブモードのいずれかが使用される場合があります。すべての場合において、ローカルに保存された秘密情報（事前共有キー、またはデジタル署名用の秘密キー）へのアクセスは適切に制限する必要があります。秘密情報の侵害により、IKE / IPsecプロトコルのセキュリティプロパティが無効になるためです。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
認証を達成するためにデジタル署名が使用される場合、IKEネゴシエーターはIKE証明書要求ペイロードを使用して、そのローカルポリシーに従って信頼される認証局を指定する必要があります（SHOULD）。 IKEネゴシエーターは、IKEの認証手順で使用するPKI証明書を受け入れる前に、関連する証明書失効リスト（CRL）を確認する必要があります（SHOULD）。
The IPsec DOI [RFC2407] provides for several types of identification data. Within IKE Phase 1, for use within the IDii and IDir payloads, conformant IP block storage security implementations MUST support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN Identity Payloads. iSCSI security implementations SHOULD support the ID_USER_FQDN Identity Payload; other IP block storage protocols (iFCP, FCIP) SHOULD NOT use the ID_USER_FQDN Identity Payload. Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be used for IP block storage protocol security; The ID_KEY_ID Identity Payload MUST NOT be used. As described in [RFC2407], within Phase 1 the ID port and protocol fields MUST be set to zero or to UDP port 500. Also, as noted in [RFC2407]:
IPsec DOI [RFC2407]は、いくつかのタイプの識別データを提供します。 IKEフェーズ1内で、IDiiおよびIDirペイロード内で使用するために、適合IPブロックストレージセキュリティ実装は、ID_IPV4_ADDR、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）およびID_FQDN IDペイロードをサポートする必要があります。 iSCSIセキュリティ実装は、ID_USER_FQDN IDペイロードをサポートする必要があります（SHOULD）。他のIPブロックストレージプロトコル（iFCP、FCIP）は、ID_USER_FQDN IDペイロードを使用しないでください。 ID_IPV4_ADDRおよびID_IPV6_ADDR以外のID（ID_FQDNやID_USER_FQDNなど）は、事前共有キーと一緒にアグレッシブモードが使用され、IPアドレスが動的に割り当てられる状況で使用する必要があります。 IPサブネット、IPアドレス範囲、ID_DER_ASN1_DN、ID_DER_ASN1_GN形式は、IPブロックストレージプロトコルのセキュリティには使用しないでください。 ID_KEY_ID IDペイロードは使用してはなりません（MUST NOT）。 [RFC2407]で説明されているように、フェーズ1内では、IDポートとプロトコルフィールドをゼロまたはUDPポート500に設定する必要があります。
When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange.
IKE交換が（任意の形式の）証明書を使用して認証される場合、ローカルポリシー決定への入力に使用されるすべてのIDは、交換の認証で使用される証明書に含まれる必要があります（SHOULD）。
The Phase 2 Quick Mode exchanges used by IP block storage protocol implementations MUST explicitly carry the Identity Payload fields (IDci and IDcr). Each Phase 2 IDci and IDcr Payload SHOULD carry a single IP address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the IP Subnet or IP Address Range formats. Other ID payload formats MUST NOT be used.
IPブロックストレージプロトコルの実装で使用されるフェーズ2クイックモード交換は、IDペイロードフィールド（IDciおよびIDcr）を明示的に運ぶ必要があります。各フェーズ2 IDciおよびIDcrペイロードは単一のIPアドレス（ID_IPV4_ADDR、ID_IPV6_ADDR）を伝送する必要があり（SHOULD）、IPサブネットまたはIPアドレス範囲の形式を使用してはなりません（SHOULD NOT）。他のIDペイロード形式を使用してはなりません（MUST NOT）。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down an IP block storage connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down.
IPsecアクセラレーションハードウェアは限られた数のアクティブなIKEフェーズ2 SAしか処理できないため、アクティブなフェーズ2 SAの数を最小限に抑える手段として、フェーズ2削除メッセージをアイドルSAに送信できます。 IKEフェーズ2削除メッセージの受信は、IPブロックストレージ接続を切断する理由として解釈してはなりません（MUST NOT）。むしろ、接続を維持したままにし、追加のトラフィックが送信される場合は、別のIKEフェーズ2 SAを起動して接続を保護することをお勧めします。これにより、接続が継続的にアップおよびダウンする可能性が回避されます。
One of the goals of this specification is to enable a high level of interoperability without requiring extensive configuration. This section provides guidelines on setting of IKE parameters so as to enhance the probability of a successful negotiation. It also describes how information on security policy configuration can be provided so as to further enhance the chances of success.
この仕様の目標の1つは、大規模な構成を必要とせずに高レベルの相互運用性を実現することです。このセクションでは、ネゴシエーションが成功する確率を高めるためのIKEパラメータの設定に関するガイドラインを示します。また、成功の可能性をさらに高めるために、セキュリティポリシーの構成に関する情報を提供する方法についても説明します。
To enhance the prospects for interoperability, some of the actions to consider include:
相互運用性の見通しを高めるために、考慮すべきいくつかのアクションは次のとおりです。
[1] Transform restriction. Since support for 3DES-CBC and HMAC-SHA1 is required of all implementations, offering these transforms enhances the probability of a successful negotiation. If AES-CTR [RFC3686] with XCBC-MAC [RFC3566] is supported, this transform combination will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a secondary offer.
[1] 変換の制限。すべての実装で3DES-CBCおよびHMAC-SHA1のサポートが必要であるため、これらの変換を提供すると、ネゴシエーションが成功する確率が高まります。 XCBC-MAC [RFC3566]を備えたAES-CTR [RFC3686]がサポートされている場合、この変換の組み合わせが一般的に優先され、2DESとして3DES-CBC / HMAC-SHA1が提供されます。
[2] Group Restriction. If 3DES-CBC/HMAC-SHA1 is offered, and DH groups are offered, then it is recommended that a DH group of at least 1024 bits be offered along with it. If AES-CTR/XCBC-MAC is the preferred offer, and DH groups are offered, then it is recommended that a DH group of at least 2048 bits be offered along with it, as noted in [KeyLen]. If perfect forward secrecy is required in Quick Mode, then it is recommended that the QM PFS DH group be the same as the IKE Phase 1 DH group. This reduces the total number of combinations, enhancing the chances for interoperability.
[2] グループ制限。 3DES-CBC / HMAC-SHA1が提供され、DHグループが提供される場合は、少なくとも1024ビットのDHグループを一緒に提供することをお勧めします。 AES-CTR / XCBC-MACが推奨されるオファーであり、DHグループが提供されている場合、[KeyLen]に記載されているように、少なくとも2048ビットのDHグループを一緒に提供することをお勧めします。クイックモードで完全転送秘密が必要な場合は、QM PFS DHグループをIKEフェーズ1 DHグループと同じにすることをお勧めします。これにより、組み合わせの総数が減り、相互運用性の可能性が高まります。
[3] Key lifetimes. If a key lifetime is offered that is longer than desired, then rather than causing the IKE negotiation to fail, it is recommended that the Responder consider the offered lifetime as a maximum, and accept it. The key can then use a lesser value for the lifetime, and utilize a Lifetime Notify in order to inform the other peer of lifetime expiration.
[3] 鍵のライフタイム。希望よりも長いキーのライフタイムが提供された場合、IKEネゴシエーションが失敗するのではなく、レスポンダが提供されたライフタイムを最大と見なして受け入れることをお勧めします。その後、キーはライフタイムに小さい値を使用し、ライフタイムの通知を利用して、他のピアにライフタイムの期限切れを通知できます。
Even when the above advice is taken, it still may be useful to be able to provide additional configuration information in order to enhance the chances of success, and it is useful to be able to manage security configuration regardless of the scale of the deployment.
上記のアドバイスが取られた場合でも、成功の可能性を高めるために追加の構成情報を提供できると便利であり、展開の規模に関係なくセキュリティ構成を管理できると便利です。
For example, it may be desirable to configure the security policy of an IP block storage device. This can be done manually or automatically via a security policy distribution mechanism. Alternatively, it can be supplied via iSNS or SLPv2. If an IP block storage endpoint can obtain the required security policy by other means (manually, or automatically via a security policy distribution mechanism) then it need not request this information via iSNS or SLPv2. However, if the required security policy configuration is not available via other mechanisms, iSNS or SLPv2 can be used to obtain it.
たとえば、IPブロックストレージデバイスのセキュリティポリシーを構成することが望ましい場合があります。これは、手動またはセキュリティポリシー配布メカニズムを介して自動的に実行できます。または、iSNSまたはSLPv2を介して提供することもできます。 IPブロックストレージエンドポイントが他の方法で（手動で、またはセキュリティポリシー配布メカニズムを介して自動的に）必要なセキュリティポリシーを取得できる場合、iSNSまたはSLPv2を介してこの情報を要求する必要はありません。ただし、必要なセキュリティポリシー構成が他のメカニズムで利用できない場合は、iSNSまたはSLPv2を使用して取得できます。
It may also be helpful to obtain information about the preferences of the peer prior to initiating IKE. While it is generally possible to negotiate security parameters within IKE, there are situations in which incompatible parameters can cause the IKE negotiation to fail. The following information can be provided via SLPv2 or iSNS:
IKEを開始する前に、ピアの設定に関する情報を取得すると役立つ場合もあります。一般に、IKE内でセキュリティパラメータをネゴシエートすることは可能ですが、互換性のないパラメータが原因でIKEネゴシエーションが失敗する場合があります。以下の情報は、SLPv2またはiSNSを介して提供できます。
[4] IPsec or cleartext support. The minimum piece of peer configuration required is whether an IP block storage endpoint requires IPsec or cleartext. This cannot be determined from the IKE negotiation alone without risking a long timeout, which is highly undesirable for a disk access protocol.
[4] IPsecまたはクリアテキストのサポート。必要なピア構成の最小部分は、IPブロックストレージエンドポイントにIPsecまたはクリアテキストが必要かどうかです。これは、長いタイムアウトを危険にさらさずにIKEネゴシエーションだけで決定することはできません。これは、ディスクアクセスプロトコルにとって非常に望ましくないことです。
[5] Perfect Forward Secrecy (PFS) support. It is helpful to know whether a peer allows PFS, since an IKE Phase 2 Quick Mode can fail if an initiator proposes PFS to a Responder that does not allow it.
[5] Perfect Forward Secrecy（PFS）のサポート。イニシエーターがPFSを許可していないレスポンダに提案した場合、IKEフェーズ2クイックモードは失敗する可能性があるため、ピアがPFSを許可しているかどうかを知ることは役に立ちます。
[6] Preference for tunnel mode. While it is legal to propose both transport and tunnel mode within the same offer, not all IKE implementations will support this. As a result, it is useful to know whether a peer prefers tunnel mode or transport mode, so that it is possible to negotiate the preferred mode on the first try.
[6] トンネルモードの設定。同じオファー内でトランスポートモードとトンネルモードの両方を提案することは合法ですが、すべてのIKE実装がこれをサポートするわけではありません。その結果、ピアがトンネルモードとトランスポートモードのどちらを優先するかを知っておくと、最初の試行で優先モードをネゴシエートできるため便利です。
[7] Main Mode and Aggressive Mode support. Since the IKE negotiation can fail if a mode is proposed to a peer that doesn't allow it, it is helpful to know which modes a peer allows, so that an allowed mode can be negotiated on the first try.
[7] メインモードとアグレッシブモードのサポート。許可されていないモードがピアに提案された場合、IKEネゴシエーションは失敗する可能性があるため、ピアが許可しているモードを確認しておくと、許可されたモードを最初の試行でネゴシエートできるようになります。
Since iSNS or SLPv2 can be used to distribute IPsec security policy and configuration information for use with IP block storage protocols, these discovery protocols would constitute a 'weak link' were they not secured at least as well as the protocols whose security they configure. Since the major vulnerability is packet modification and replay, when iSNS or SLPv2 are used to distribute security policy or configuration information, at a minimum, per-packet data origin authentication, integrity and replay protection MUST be used to protect the discovery protocol.
iSNSまたはSLPv2はIPsecセキュリティポリシーとIPブロックストレージプロトコルで使用する構成情報を配布するために使用できるため、これらの検出プロトコルは、少なくともセキュリティが構成されているプロトコルと同様に保護されていなければ、「弱いリンク」を構成します。主要な脆弱性はパケットの変更と再生であるため、iSNSまたはSLPv2を使用してセキュリティポリシーまたは構成情報を配布する場合、少なくとも、パケットごとのデータ発信元認証、整合性、および再生保護を使用して、検出プロトコルを保護する必要があります。
Compliant iSCSI implementations MUST implement the CHAP authentication method [RFC1994] (according to [RFC3720], section 11.1.4), which includes support for bi-directional authentication, and the target authentication option.
準拠iSCSI実装は、双方向認証のサポートとターゲット認証オプションを含むCHAP認証方式[RFC1994]（[RFC3720]、セクション11.1.4に従って）を実装する必要があります。
When CHAP is performed over non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support random CHAP secrets of up to 128 bits, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation.
暗号化されていないチャネルでCHAPを実行すると、オフラインの辞書攻撃に対して脆弱になります。実装は、128ビットまでのランダムなCHAPシークレットをサポートする必要があります。これには、そのようなシークレットを生成し、外部の生成ソースからそれらを受け入れる手段も含まれます。実装は、ランダムな生成以外の秘密の生成（または拡張）手段を提供してはなりません（MUST NOT）。
If CHAP is used with secret smaller than 96 bits, then IPsec encryption (according to the implementation requirements in [RFC3720] section 8.3.2) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used. When CHAP is used with a secret smaller then 96 bits, a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used to protect the connection.
CHAPが96ビット未満のシークレットで使用される場合、IPsec暗号化（[RFC3720]セクション8.3.2の実装要件による）を使用して接続を保護する必要があります。さらに、この場合、グループ事前共有キーを使用したIKE認証は使用しないでください。 CHAPが96ビット未満のシークレットで使用される場合、IPsec暗号化が接続の保護に使用されていることを確認できない限り、準拠した実装はiSCSIログインを続行してはなりません（MUST NOT）。
Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs.
発信者は、双方向認証の別の方向でレスポンダによって送信されたCHAPチャレンジを再利用してはなりません（MUST NOT）。レスポンダはこの状態をチェックし、発生した場合はiSCSI TCP接続を閉じる必要があります。
The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them. It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected. A single CHAP secret MAY be used for authentication of an individual initiator to multiple targets. Likewise, a single CHAP secret MAY be used for authentication of an individual target to multiple initiators.
同じCHAPシークレットを複数のイニシエーターまたは複数のターゲットの認証用に構成しないでください。これにより、それらのいずれかが他のイニシエーターになりすますことが可能になり、それらの1つが侵害されると攻撃者がそれらのいずれかになりすますことができます。この実装が可能である場合、iSCSI実装は異なるピアによる同一のCHAPシークレットの使用をチェックし、これが検出されたときにユーザーや管理者に警告するための適切な措置を講じることをお勧めします。単一のCHAPシークレットを使用して、複数のターゲットに対する個々のイニシエーターの認証を行うことができます。同様に、単一のCHAPシークレットを使用して、複数のイニシエーターに対する個々のターゲットを認証できます。
A Responder MUST NOT send its CHAP response if the initiator has not successfully authenticated. For example, the following exchange:
イニシエータが正常に認証されなかった場合、レスポンダはそのCHAP応答を送信してはなりません（MUST NOT）。たとえば、次の交換：
I->R CHAP_A=<A1,A2,...>
R->I CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
I->R CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>
(Where N, (A1,A2), I, C, and R are correspondingly the Name, Algorithms, Identifier, Challenge, and Response as defined in [RFC1994])
（ここで、N、（A1、A2）、I、C、およびRは、[RFC1994]で定義されている名前、アルゴリズム、識別子、チャレンジ、および応答に対応しています）
MUST result in the Responder (target) closing the iSCSI TCP connection because the initiator has failed to authenticate (there is no CHAP_R in the third message).
イニシエーターが認証に失敗したため、レスポンダー（ターゲット）がiSCSI TCP接続を閉じる必要があります（3番目のメッセージにCHAP_Rはありません）。
Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator. If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions). Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles. The following is an example of the attacks prevented by the above requirements:
イニシエーター認証に使用されるCHAPシークレットは、ターゲットの認証用に構成されてはならず（MUST NOT）、ターゲット認証に使用されるCHAPシークレットは、イニシエーターの認証用に構成されてはなりません（MUST NOT）。 iSCSI接続の一方の端で受信されたCHAP応答が、受信側エンドポイントが同じCHAPチャレンジに対して生成したCHAP応答と同じである場合、応答は認証失敗として扱われ、接続を閉じる必要があります（これにより、同じCHAPシークレットが両方向の認証に使用されないことに注意してください）。また、iSCSI実装がイニシエーターとターゲットの両方として機能できる場合は、これら2つの役割に対して異なるCHAPシークレットとIDを構成する必要があります。上記の要件によって防止される攻撃の例を次に示します。
Rogue wants to impersonate Storage to Alice, and knows that a single secret is used for both directions of Storage-Alice authentication.
ローグはストレージをアリスに偽装したいと考えており、単一のシークレットがストレージアリス認証の両方向に使用されていることを知っています。
Rogue convinces Alice to open two connections to Rogue, and Rogue identifies itself as Storage on both connections.
ローグはアリスにローグへの2つの接続を開くように説得し、ローグは両方の接続で自身をストレージとして識別します。
Rogue issues a CHAP challenge on connection 1, waits for Alice to respond, and then reflects Alice's challenge as the initial challenge to Alice on connection 2.
ローグは接続1でCHAPチャレンジを発行し、アリスが応答するのを待って、アリスのチャレンジを接続2でのアリスへの最初のチャレンジとして反映します。
If Alice doesn't check for the reflection across connections, Alice's response on connection 2 enables Rogue to impersonate Storage on connection 1, even though Rogue does not know the Alice-Storage CHAP secret.
Aliceが接続全体の反射をチェックしない場合、RogueはAlice-Storage CHAPシークレットを知らなくても、接続2でのAliceの応答により、Rogueは接続1でストレージを偽装できます。
Note that RADIUS [RFC2865] does not support bi-directional CHAP authentication. Therefore, while a target acting as a RADIUS client will be able to verify the initiator Response, it will not be able to respond to an initiator challenge unless it has access to an appropriate shared secret by some other means.
RADIUS [RFC2865]は双方向CHAP認証をサポートしないことに注意してください。したがって、RADIUSクライアントとして機能するターゲットはイニシエーターの応答を確認できますが、他の手段で適切な共有シークレットにアクセスできない限り、イニシエーターのチャレンジに応答できません。
iSCSI implementations MAY implement the SRP authentication method [RFC2945] (see [RFC3720], Section 11.1.3). The strength of SRP security is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) the generator g is a primitive root of GF(n) [SRPNDSS].
iSCSI実装は、SRP認証方式[RFC2945]を実装する場合があります（[RFC3720]、セクション11.1.3を参照）。 SRPセキュリティの強度は、使用されているグループの特性（つまり、素数モジュラスNとジェネレーターg）に依存します。 [RFC2945]で説明されているように、Nはソフィー-ドイツ語の素数（N = 2q + 1、qも素数の形式）である必要があります。ジェネレータgはGF（n）の原始根[SRPNDSS]です。
SRP well-known groups are included in Appendix A and additional groups may be registered with IANA. iSCSI implementations MUST use one of these well-known groups. All the groups specified in Appendix A up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.
SRPの既知のグループは付録Aに含まれており、追加のグループをIANAに登録できます。 iSCSI実装では、これらのよく知られたグループの1つを使用する必要があります。付録Aで指定されている1536ビットまでのすべてのグループ（SRP-768、SRP-1024、SRP-1280、SRP-1536）は、イニシエーターとターゲットでサポートされている必要があります。相互運用性を保証するために、ターゲットは常に「SRP-1536」を提案されたグループの1つとして提供する必要があります。
Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer entities and management servers. SLPv2 may also be used to provide information on peer security configuration. When SLPv2 is deployed, the SA advertisements as well as UA requests and/or responses are subject to the following security threats:
iSCSIプロトコルとFCIPプロトコルはどちらも、ピアエンティティと管理サーバーを検出する方法としてSLPv2を使用します。 SLPv2は、ピアのセキュリティ構成に関する情報を提供するためにも使用できます。 SLPv2が展開されている場合、SAアドバタイズメントとUA要求および/または応答は、次のセキュリティ脅威の影響を受けます。
[1] An attacker could insert or alter SA advertisements or a response to a UA request in order to masquerade as the real peer or launch a denial of service attack.
[1] 攻撃者は、SAアドバタイズメントまたはUA要求への応答を挿入または変更して、実際のピアになりすますか、サービス拒否攻撃を開始する可能性があります。
[2] An attacker could gain knowledge about an SA or a UA through snooping, and launch an attack against the peer. Given the potential value of iSCSI targets and FCIP entities, leaking of such information not only increases the possibility of an attack over the network; there is also the risk of physical theft.
[2] 攻撃者は、スヌーピングによってSAまたはUAに関する知識を獲得し、ピアに対して攻撃を開始する可能性があります。 iSCSIターゲットとFCIPエンティティの潜在的な価値を考えると、そのような情報の漏洩はネットワークを介した攻撃の可能性を高めるだけではありません。物理的な盗難のリスクもあります。
[3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to use a rogue DAs.
[3] 攻撃者はDAAdvertを偽装する可能性があります。これにより、UAとSAが不正なDAを使用する可能性があります。
To address these threats, the following capabilities are required:
これらの脅威に対処するには、次の機能が必要です。
[a] Service information, as included in SrvRply, AttrRply, SrvReg and SrvDereg messages, needs to be kept confidential.
[a] SrvRply、AttrRply、SrvReg、およびSrvDeregメッセージに含まれるサービス情報は、機密情報として保持する必要があります。
[b] The UA has to be able to distinguish between legitimate and illegitimate service information from SrvRply and AttrRply messages. In the SLPv2 security model SAs are trusted to sign data.
[b] UAは、SrvRplyおよびAttrRplyメッセージからの正規および不正なサービス情報を区別できる必要があります。 SLPv2セキュリティモデルでは、SAはデータに署名することが信頼されています。
[c] The DA has to be able to distinguish between legitimate and illegitimate SrvReg and SrvDereg messages.
[c] DAは、正当なSrvRegメッセージと不正なSrvDeregメッセージを区別できる必要があります。
[d] The UA has to be able to distinguish between legitimate and illegitimate DA Advertisements. This allows the UA to avoid rogue DAs that will return incorrect data or no data at all. In the SLPv2 security model, UAs trust DAs to store, answer queries on and forward data on services, but not necessarily to originate it.
[d] UAは、合法的なDA広告と非合法なDA広告を区別できる必要があります。これにより、UAは不正なデータを返すか、まったくデータを返さない不正なDAを回避できます。 SLPv2セキュリティモデルでは、UAはDAを信頼して、サービスへのデータの格納、クエリへの応答、およびデータの転送を行いますが、必ずしもそれを発信する必要はありません。
[e] SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2 is used. In this case, SAs register with only one DA and trust that this DA will forward the registration to others.
[e] 特に「メッシュ拡張」SLPv2が使用されている場合、SAはDAを信頼する必要があります。この場合、SAはDAを1つだけ登録し、このDAが登録を他のDAに転送することを信頼します。
By itself, SLPv2 security, defined in [RFC2608], does not satisfy these security requirements. SLPv2 only provides end-to-end authentication, but does not support confidentiality. In SLPv2 authentication there is no way to authenticate "zero result responses". This enables an attacker to mount a denial of service attack by sending UAs a "zero results" SrvRply or AttrRply as if from a DA with whose source address corresponds to a legitimate DAAdvert.
[RFC2608]で定義されているSLPv2セキュリティ自体は、これらのセキュリティ要件を満たしていません。 SLPv2はエンドツーエンド認証のみを提供し、機密性はサポートしていません。 SLPv2認証では、「ゼロの結果応答」を認証する方法はありません。これにより、攻撃者は、正当なDAAdvertに対応するソースアドレスを持つDAからのように、UAに「ゼロの結果」のSrvRplyまたはAttrRplyを送信することにより、サービス拒否攻撃を仕掛けることができます。
In all cases, there is a potential for denial of service attack against protocol service providers, but such an attack is possible even in the absence of SLPv2 based discovery mechanisms.
すべての場合において、プロトコルサービスプロバイダーに対するサービス拒否攻撃の可能性がありますが、そのような攻撃はSLPv2ベースの検出メカニズムがなくても可能です。
SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 requires that User Agents (UAs) and Service Agents (SAs) support SrvRqst, SrvRply, and DAAdvert. SAs must additionally support SrvReg, SrvAck, and SAAdvert.
SLPv2メッセージタイプには、SrvRqst、SrvRply、SrvReg、SrvDereg、SrvAck、AttrRqst、AttrRply、DAAdvert、SrvTypeRqst、SrvTypeRply、SAAdvertがあります。 SLPv2では、ユーザーエージェント（UA）およびサービスエージェント（SA）がSrvRqst、SrvRply、およびDAAdvertをサポートする必要があります。 SAはさらにSrvReg、SrvAck、およびSAAdvertをサポートする必要があります。
Where no Directory Agent (DA) exists, the SrvRqst is multicast, but the SrvRply is sent via unicast UDP. DAAdverts are also multicast. However, all other SLPv2 messages are sent via UDP unicast.
Directory Agent（DA）が存在しない場合、SrvRqstはマルチキャストですが、SrvRplyはユニキャストUDP経由で送信されます。 DAAdvertsもマルチキャストされます。ただし、他のすべてのSLPv2メッセージはUDPユニキャストを介して送信されます。
In order to provide the required security functionality, iSCSI and FCIP implementations supporting SLPv2 security SHOULD protect SLPv2 messages sent via unicast using IPsec ESP with a non-null transform. SLPv2 authentication blocks (carrying digital signatures), described in [RFC2608] MAY also be used to authenticate unicast and multicast messages.
必要なセキュリティ機能を提供するために、SLPv2セキュリティをサポートするiSCSIおよびFCIP実装は、IPsec ESPを使用してユニキャスト経由で送信されたSLPv2メッセージをnull以外の変換で保護する必要があります。 [RFC2608]で説明されているSLPv2認証ブロック（デジタル署名を運ぶ）は、ユニキャストおよびマルチキャストメッセージの認証にも使用できます（MAY）。
The usage of SLPv2 by iSCSI is described in [iSCSISLP]. iSCSI initiators and targets may enable IKE mechanisms to establish identity. In addition, a subsequent user-level iSCSI session login can protect the initiator-target nexus. This will protect them from any compromise of security in the SLPv2 discovery process.
iSCSIによるSLPv2の使用法は、[iSCSISLP]で説明されています。 iSCSIイニシエーターとターゲットにより、IKEメカニズムでIDを確立できる場合があります。さらに、その後のユーザーレベルのiSCSIセッションログインで、イニシエーターとターゲットのネクサスを保護できます。これにより、SLPv2検出プロセスでのセキュリティの侵害から保護されます。
The usage of SLPv2 by FCIP is described in [FCIPSLP]. FCIP Entities assume that once the IKE identity of a peer is established, the FCIP Entity Name carried in FCIP Short Frame is also implicitly accepted as the authenticated peer. Any such association between the IKE identity and the FCIP Entity Name is administratively established.
FCIPによるSLPv2の使用法は、[FCIPSLP]で説明されています。 FCIPエンティティは、ピアのIKE IDが確立されると、FCIPショートフレームで伝送されるFCIPエンティティ名も、認証されたピアとして暗黙的に受け入れられることを前提としています。 IKE IDとFCIPエンティティ名の間のそのような関連付けは、管理上確立されます。
For use in securing SLPv2, when digital signatures are used to achieve authentication in IKE, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures. If key management of SLPv2 DAs needs to be coordinated with the SAs and the UAs as well as the protocol service implementations, one may use certificate based key management, with a shared root Certificate Authority (CA).
SLPv2のセキュリティ保護に使用する場合、IKEで認証を行うためにデジタル署名を使用する場合、IKEネゴシエーターは、IKE証明書要求ペイロードを使用して、ローカルポリシーに従って信頼される認証局を指定する必要があります（SHOULD）。 IKEネゴシエーターは、IKEの認証手順で使用するPKI証明書を受け入れる前に、関連する証明書失効リスト（CRL）を確認する必要があります（SHOULD）。 SLPv2 DAのキー管理をプロトコルサービスの実装と同様にSAとUAと調整する必要がある場合は、共有ルート認証局（CA）で証明書ベースのキー管理を使用できます。
One of the reasons for utilizing IPsec for SLPv2 security is that is more likely that certificates will be deployed for IPsec than for SLPv2. This both simplifies SLPv2 security and makes it more likely that it will be implemented interoperably and more importantly, that it will be used. As a result, it is desirable that little additional effort be required to enable IPsec protection of SLPv2.
SLPv2セキュリティにIPsecを使用する理由の1つは、証明書がSLPv2よりもIPsecに展開される可能性が高いことです。これにより、SLPv2のセキュリティが簡素化され、相互運用可能に実装される可能性が高まり、重要なことに、SLPv2が使用されるようになります。その結果、SLPv2のIPsec保護を有効にするために追加の労力をほとんど必要としないことが望ましいです。
However, just because a certificate is trusted for use with IPsec does not necessarily imply that the host is authorized to perform SLPv2 operations. When using IPsec to secure SLPv2, it may be desirable to distinguish between certificates appropriate for use by UAs, SAs, and DAs. For example, while a UA might be allowed to use any certificate conforming to IKE certificate policy, the certificate used by an SA might indicate that it is a legitimate source of service advertisements. Similarly, a DA certificate might indicate that it is a valid DA. This can be accomplished by using special CAs to issue certificates valid for use by SAs and DAs; alternatively, SA and DA authorizations can be employed.
ただし、証明書がIPsecでの使用が信頼されているからといって、必ずしもホストがSLPv2操作の実行を許可されているとは限りません。 IPsecを使用してSLPv2を保護する場合、UA、SA、およびDAによる使用に適した証明書を区別することが望ましい場合があります。たとえば、UAはIKE証明書ポリシーに準拠する任意の証明書の使用を許可されている場合がありますが、SAが使用する証明書は、それがサービスアドバタイズメントの正当なソースであることを示している場合があります。同様に、DA証明書は、それが有効なDAであることを示す場合があります。これは、特別なCAを使用して、SAおよびDAでの使用に有効な証明書を発行することによって実現できます。あるいは、SAおよびDAの承認を使用できます。
Assume that the policy for issuing and distributing SLPv2 authorized certificates to SAs and DAs limits them only to legitimate SAs and DAs. In this case, IPsec is used to provide SLPv2 security as follows:
SLPv2承認済み証明書を発行およびSAとDAに配布するためのポリシーは、それらを正当なSAとDAにのみ制限するとします。この場合、IPsecは次のようにSLPv2セキュリティを提供するために使用されます。
[a] SLPv2 messages sent via unicast are IPsec protected, using ESP with a non-null transform.
[a] ユニキャストを介して送信されるSLPv2メッセージは、非ヌル変換を伴うESPを使用してIPsec保護されています。
[b] SrvRply and AttrRply messages from either a DA or SA are unicast to UAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the IKE Phase 1 SA, or that the DA used a certificate authorized for DA usage, the UA can accept the information sent, even if it has no SLPv2 authentication block.
[b] DAまたはSAからのSrvRplyおよびAttrRplyメッセージは、UAにユニキャストされます。 SAがIKEフェーズ1 SAの確立時にSLPv2サービスアドバタイズメントに許可された証明書を使用した場合、またはDAがDA使用に許可された証明書を使用した場合、UAはSLPv2認証ブロックがない場合でも送信された情報を受け入れることができます。
Note that where SrvRqst messages are multicast, they are not protected. An attacker may attempt to exploit this by spoofing a multicast SrvRqst from the UA, generating a SrvRply from an SA of the attacker's choosing. Although the SrvRply is secured, it does not correspond to a legitimate SrvRqst sent by the UA. To avoid this attack, where SrvRqst messages are multicast, the UA MUST check that SrvRply messages represent a legitimate reply to the SrvRqst that was sent.
SrvRqstメッセージがマルチキャストである場合、それらは保護されないことに注意してください。攻撃者は、UAからマルチキャストSrvRqstを偽装し、攻撃者が選択したSAからSrvRplyを生成することにより、これを悪用しようとする可能性があります。 SrvRplyは保護されていますが、UAから送信された正当なSrvRqstには対応していません。この攻撃を回避するには、SrvRqstメッセージがマルチキャストされる場合、UAは、SrvRplyメッセージが送信されたSrvRqstへの正当な応答であることを確認する必要があります。
[c] SrvReg and SrvDereg messages from a SA are unicast to DAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the IKE Phase 1 SA, the DA can accept the de/registration even if it has no SLPv2 authentication block. Typically, the SA will check the DA authorization prior to sending the service advertisement.
[c] SAからのSrvRegおよびSrvDeregメッセージはDAにユニキャストされます。 SAがIKEフェーズ1 SAの確立時にSLPv2サービスアドバタイズメントに許可された証明書を使用すると仮定すると、DAはSLPv2認証ブロックがない場合でも登録解除を受け入れることができます。通常、SAはサービス通知を送信する前にDA承認をチェックします。
[d] Multicast DAAdverts can be considered advisory. The UA will attempt to contact DAs via unicast. Assuming that the DA used a certificate authorized for SLPv2 DAAdverts in establishing the IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no SLPv2 authentication block.
[d] マルチキャストDAAdvertsは助言と見なすことができます。 UAはユニキャストを介してDAに接続しようとします。 DAがIKEフェーズ1 SAの確立時にSLPv2 DAAdvertsに許可された証明書を使用したと仮定すると、UAはSLPv2認証ブロックがない場合でもDAAdvertを受け入れることができます。
[e] SAs can accept DAAdverts as described in [d].
[e] SAは、[d]で説明されているようにDAAdvertsを受け入れることができます。
Since SLPv2 messages can contain information that can potentially reveal the vendor of the device or its other associated characteristics, revealing service information constitutes a security risk. As an example, the FCIP Entity Name may reveal a WWN from which an attacker can learn potentially useful information about the Entity's characteristics.
SLPv2メッセージには、デバイスのベンダーやその他の関連する特性を明らかにする可能性のある情報が含まれている可能性があるため、サービス情報を明らかにすることはセキュリティリスクとなります。例として、FCIPエンティティ名はWWNを明らかにし、そこから攻撃者はエンティティの特性に関する潜在的に有用な情報を知ることができます。
The SLPv2 security model assumes that service information is public, and therefore does not provide for confidentiality. However, storage devices represent mission critical infrastructure of substantial value, and so iSCSI and FCIP security implementations supporting SLPv2 security SHOULD encrypt as well as authenticate and integrity-protect unicast SLPv2 messages.
SLPv2セキュリティモデルは、サービス情報が公開されていることを前提としているため、機密性は提供されません。ただし、ストレージデバイスは重要な価値のあるミッションクリティカルなインフラストラクチャを表すため、SLPv2セキュリティをサポートするiSCSIおよびFCIPセキュリティの実装では、ユニキャストSLPv2メッセージを暗号化し、認証して整合性を保護する必要があります（SHOULD）。
Assuming that all unicast SLPv2 messages are protected by IPsec, and that confidentiality is provided, then the risk of disclosure can be limited to SLPv2 messages sent via multicast, namely the SrvRqst and DAAdvert.
すべてのユニキャストSLPv2メッセージがIPsecによって保護され、機密性が提供されると仮定すると、開示のリスクは、マルチキャストを介して送信されるSLPv2メッセージ、つまりSrvRqstとDAAdvertに限定できます。
The information leaked in a multicast SrvRqst depends on the level of detail in the query. If leakage is a concern, then a DA can be provided. If this is not feasible, then a general query can be sent via multicast, and then further detail can be obtained from the replying entities via additional unicast queries, protected by IPsec.
マルチキャストSrvRqstでリークされる情報は、クエリの詳細レベルによって異なります。漏れが懸念される場合は、DAを提供できます。これが不可能な場合は、一般的なクエリをマルチキャストで送信し、IPsecで保護された追加のユニキャストクエリを介して応答エンティティから詳細を取得できます。
Information leakage via a multicast DAAdvert is less of a concern than the authenticity of the message, since knowing that a DA is present on the network only enables an attacker to know that SLPv2 is in use, and possibly that a directory service is also present. This information is not considered very valuable.
マルチキャストDAAdvertを介した情報漏えいは、DAがネットワーク上に存在することを知っていても、攻撃者はSLPv2が使用されていること、およびおそらくディレクトリサービスも存在していることを知ることができるため、メッセージの信憑性よりも重要ではありません。この情報は非常に価値があるとは見なされていません。
Through the definition of security attributes, it is possible to use SLPv2 to distribute information about security settings for IP block storage entities. SLPv2 distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via SLPv2.
セキュリティ属性の定義により、SLPv2を使用して、IPブロックストレージエンティティのセキュリティ設定に関する情報を配布できます。手動構成やIPsecセキュリティポリシーの配布など、他の方法でセキュリティ設定を決定できる場合は、セキュリティポリシーのSLPv2配布は不要です。エンティティが他のメカニズムを介してセキュリティ構成をすでに取得している場合、SLPv2を介してセキュリティポリシーを要求してはなりません（MUST NOT）。
Where SLPv2 is used to provide security policy information for use with IP block storage protocols, SLPv2 MUST be protected by IPsec as described in this document. Where SLPv2 is not used to distribute security policy information, implementations MAY implement SLPv2 security as described in this document.
IPブロックストレージプロトコルで使用するセキュリティポリシー情報を提供するためにSLPv2が使用される場合、SLPv2はこのドキュメントで説明されているようにIPsecで保護されている必要があります。 SLPv2がセキュリティポリシー情報の配布に使用されない場合、実装はこのドキュメントで説明されているようにSLPv2セキュリティを実装してもよい（MAY）。
Where SLPv2 is used, but security is not implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
SLPv2が使用されているが、セキュリティが実装されていない場合、IPブロックストレージプロトコルの実装は、認証失敗のネガティブキャッシュをサポートする必要があります。これにより、実装は、IPsec内またはアプリケーション層（iSCSIログインの場合）で認証に失敗した検出されたエンドポイントに継続的に接続することを回避できます。ネガティブキャッシュは、IPsec実装内ではなく、IPブロックストレージプロトコル実装内で維持する必要があります。
Since this document proposes that hop-by-hop security be used as the primary mechanism to protect SLPv2, UAs have to trust DAs to accurately relay data from SAs. This is a change to the SLPv2 security model described in [RFC2608]. However, SLPv2 authentication as defined in [RFC2608] does not provide a way to authenticate "zero result responses", leaving SLPv2 vulnerable to a denial of service attack. Such an attack can be carried out on a UA by sending it a "zero results" SrvRply or AttrRply, sent from a source address corresponding to a DA issuing a legitimate DAAdvert.
このドキュメントでは、SLPv2を保護するための主要なメカニズムとしてホップバイホップのセキュリティを使用することを提案しているため、UAはDAを信頼して、SAからのデータを正確に中継する必要があります。これは、[RFC2608]で説明されているSLPv2セキュリティモデルへの変更です。ただし、[RFC2608]で定義されているSLPv2認証は、「ゼロの結果応答」を認証する方法を提供していないため、SLPv2はサービス不能攻撃に対して脆弱です。このような攻撃は、正当なDAAdvertを発行するDAに対応するソースアドレスから送信される「ゼロの結果」のSrvRplyまたはAttrRplyを送信することにより、UAで実行できます。
In addition, SLPv2 security as defined in [RFC2608] does not support confidentiality. When IPsec with ESP and a non-null transform is used to protect SLPv2, not only can unicast requests and replies be authenticated, but confidentiality can also be provided. This includes unicast requests to DAs and SAs as well as replies. It is also possible to actively discover SAs using multicast SA discovery, and then to send unicast requests to the discovered SAs.
さらに、[RFC2608]で定義されているSLPv2セキュリティは機密性をサポートしていません。 SLPv2を保護するためにESPと非ヌルトランスフォームを使用したIPsecを使用すると、ユニキャスト要求と応答を認証できるだけでなく、機密性も提供できます。これには、DAおよびSAへのユニキャスト要求と応答が含まれます。マルチキャストSA検出を使用してSAをアクティブに検出し、検出されたSAにユニキャスト要求を送信することもできます。
As a result, for use with IP block storage protocols, it is believed that use of IPsec for security is more appropriate than the SLPv2 security model defined in [RFC2608].
その結果、IPブロックストレージプロトコルで使用する場合、[RFC2608]で定義されているSLPv2セキュリティモデルよりも、セキュリティにIPsecを使用する方が適切であると考えられています。
Using IPsec to secure SLPv2 has performance implications. Security associations established between:
IPsecを使用してSLPv2を保護すると、パフォーマンスに影響があります。以下の間に確立されたセキュリティアソシエーション：
- UAs and SAs may be reused (the client on the UA host will use the service on the SA host).
- UAとSAは再利用できます（UAホスト上のクライアントはSAホスト上のサービスを使用します）。
- SAs and DAs may be reused (the SAs will reregister services)
- SAとDAは再利用できます（SAはサービスを再登録します）
- UAs and DAs will probably not be reused (many idle security associations are likely to result, and build up on the DA).
- UAとDAはおそらく再利用されません（多くのアイドル状態のセキュリティアソシエーションが発生し、DAに蓄積される可能性があります）。
When IPsec is used to protect SLPv2, it is not necessarily appropriate for all hosts with whom an IPsec security association can be established to be trusted to originate SLPv2 service advertisements. This is particularly the case in environments where it is easy to obtain certificates valid for use with IPsec (for example, where anyone with access to the network can obtain a machine certificate valid for use with IPsec). If not all hosts are authorized to originate service advertisements, then it is necessary to distinguish between authorized and unauthorized hosts.
IPsecを使用してSLPv2を保護する場合、IPsecセキュリティアソシエーションを確立できるすべてのホストを信頼してSLPv2サービスアドバタイズを発信することは必ずしも適切ではありません。これは特に、IPsecでの使用に有効な証明書を簡単に取得できる環境（たとえば、ネットワークにアクセスできる誰でもIPsecでの使用に有効なマシン証明書を取得できる環境）に当てはまります。すべてのホストがサービスアドバタイズの発信を許可されていない場合は、許可されたホストと許可されていないホストを区別する必要があります。
This can be accomplished by the following mechanisms:
これは、次のメカニズムによって実現できます。
[1] Configuring SAs with the identities or certificate characteristics of valid DAs, and configuring DAs with the identities of SAs allowed to advertise IP block storage services. The DAs are then trusted to enforce policies on service registration. This approach involves manual configuration, but avoids certificate customization for SLPv2.
[1] 有効なDAのIDまたは証明書の特性を使用してSAを構成し、IPブロックストレージサービスをアドバタイズできるSAのIDを使用してDAを構成します。その後、DAはサービス登録に関するポリシーを実施するために信頼されます。このアプローチには手動構成が含まれますが、SLPv2の証明書のカスタマイズは回避されます。
[2] Restricting the issuance of certificates valid for use in SLPv2 service advertisement. While all certificates allowed for use with IPsec will chain to a trusted root, certificates for hosts authorized to originate service advertisements could be signed by an SLPv2-authorized CA, or could contain explicit SLPv2 authorizations within the certificate. After the IPsec security association is set up between the SLPv2 entities, the SLPv2 implementations can then retrieve the certificates used in the negotiation in order to determine whether the entities are authorized for the operations that are being performed. This approach requires less configuration, but requires some certificate customization for use with SLPv2.
[2] SLPv2サービスアドバタイズメントでの使用に有効な証明書の発行を制限します。 IPsecでの使用が許可されているすべての証明書は信頼されたルートにチェーンしますが、サービスアドバタイズメントを開始することを承認されたホストの証明書は、SLPv2承認CAによって署名されるか、証明書内に明示的なSLPv2承認を含むことができます。 SLPv2エンティティ間にIPsecセキュリティアソシエーションがセットアップされた後、SLPv2実装は、エンティティが実行中の操作に対して承認されているかどうかを判断するために、ネゴシエーションで使用される証明書を取得できます。このアプローチでは構成が少なくて済みますが、SLPv2で使用するには証明書をカスタマイズする必要があります。
The iSCSI protocol may use iSNS for discovery and management services, while the iFCP protocol is required to use iSNS for such services. In addition, iSNS can be used to store and distribute security policy and authorization information to iSCSI and iFCP devices. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients are subject to the following additional security threats:
iSCSIプロトコルはディスカバリーおよび管理サービスにiSNSを使用できますが、iFCPプロトコルはそのようなサービスにiSNSを使用する必要があります。さらに、iSNSを使用して、セキュリティポリシーと承認情報を保存し、iSCSIおよびiFCPデバイスに配布できます。 iSNSプロトコルが展開されている場合、iSNSサーバーとiSNSクライアント間の相互作用は、次のセキュリティ上の脅威にさらされます。
[1] An attacker can alter iSNS protocol messages, directing iSCSI and iFCP devices to establish connections with rogue devices, or weakening IPsec protection for iSCSI or iFCP traffic.
[1] 攻撃者は、iSNSプロトコルメッセージを変更し、iSCSIおよびiFCPデバイスに不正なデバイスとの接続を確立するように指示したり、iSCSIまたはiFCPトラフィックのIPsec保護を弱めたりできます。
[2] An attacker can masquerade as the real iSNS server by sending false iSNS heartbeat messages. This could deceive iSCSI and iFCP devices into using rogue iSNS servers.
[2] 攻撃者は、偽のiSNSハートビートメッセージを送信することにより、実際のiSNSサーバーになりすますことができます。これは、iSCSIおよびiFCPデバイスを欺いて、不正なiSNSサーバーを使用する可能性があります。
[3] An attacker can gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft.
[3] 攻撃者は、iSNSプロトコルメッセージをスヌーピングすることにより、iSCSIおよびiFCPデバイスに関する知識を得ることができます。このような情報は、サービス拒否攻撃や完全な物理的盗難など、攻撃者がiSCSIおよびiFCPデバイスに直接攻撃を仕掛けるのに役立ちます。
To address these threats, the following capabilities are needed:
これらの脅威に対処するには、次の機能が必要です。
[a] Unicast iSNS protocol messages may need to be authenticated. In addition, to protect against threat [3] above, confidentiality support is desirable, and REQUIRED when certain functions of iSNS are used.
[a] ユニキャストiSNSプロトコルメッセージは認証が必要な場合があります。さらに、上記の脅威[3]から保護するために、機密性のサポートが望ましく、iSNSの特定の機能を使用する場合は必須です。
[b] Multicast iSNS protocol messages such as the iSNS heartbeat message need to be authenticated. These messages need not be confidential since they do not leak critical information.
[b] iSNSハートビートメッセージなどのマルチキャストiSNSプロトコルメッセージは認証される必要があります。これらのメッセージは重要な情報を漏らさないため、機密である必要はありません。
There is no requirement that the identities of iSNS entities be kept confidential. Specifically, the identity and location of the iSNS server need not be kept confidential.
iSNSエンティティのIDを秘密にしておく必要はありません。具体的には、iSNSサーバーのIDと場所を機密にする必要はありません。
In order to protect against an attacker masquerading as an iSNS server, client devices MUST support authentication of broadcast or multicast messages such as the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) MAY be used for this purpose. Note that the authentication block is used only for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages.
攻撃者がiSNSサーバーを装った攻撃から保護するために、クライアントデバイスはブロードキャストまたはマルチキャストメッセージ（iSNSハートビートなど）の認証をサポートする必要があります。 iSNS認証ブロック（形式はSLP認証ブロックと同じ）をこの目的に使用できます。認証ブロックはiSNSブロードキャストまたはマルチキャストメッセージに対してのみ使用され、ユニキャストiSNSメッセージでは使用されるべきではないことに注意してください。
Since iSNS is used to distribute authorizations determining which client devices can communicate, IPsec authentication and data integrity MUST be supported. In addition, if iSNS is used to distribute security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality MUST be supported and used.
iSNSは、どのクライアントデバイスが通信できるかを決定する承認を配布するために使用されるため、IPsec認証とデータの整合性をサポートする必要があります。さらに、iSNSを使用してiFCPおよびiSCSIデバイスのセキュリティポリシーを配布する場合は、認証、データの整合性、および機密性をサポートして使用する必要があります。
Where iSNS is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
セキュリティなしでiSNSを使用する場合、IPブロックストレージプロトコルの実装は、認証失敗のネガティブキャッシュをサポートする必要があります。これにより、実装は、IPsec内またはアプリケーション層（iSCSIログインの場合）で認証に失敗した検出されたエンドポイントに継続的に接続することを回避できます。ネガティブキャッシュは、IPsec実装内ではなく、IPブロックストレージプロトコル実装内で維持する必要があります。
In practice, within a single installation, iSCSI and/or iFCP devices may have different security settings. For example, some devices may be configured to initiate secure communication, while other devices may be configured to respond to a request for secure communication, but not to require security. Still other devices, while security capable, may neither initiate nor respond securely.
実際には、単一のインストール内で、iSCSIおよび/またはiFCPデバイスのセキュリティ設定が異なる場合があります。例えば、いくつかのデバイスは、安全な通信を開始するように構成され得るが、他のデバイスは、安全な通信の要求に応答するが、セキュリティを必要としないように構成され得る。さらに他のデバイスは、セキュリティは有効ですが、安全に開始したり応答したりすることはできません。
In practice, these variations in configuration can result in devices being unable to communicate with each other. For example, a device that is configured to always initiate secure communication will experience difficulties in communicating with a device that neither initiates nor responds securely.
実際には、これらの構成の変化により、デバイスが互いに通信できなくなる可能性があります。たとえば、常に安全な通信を開始するように構成されているデバイスは、安全に開始も応答もしないデバイスとの通信が困難になります。
The iSNS protocol is used to transfer naming, discovery, and management information between iSCSI devices, iFCP gateways, management stations, and the iSNS server. This includes the ability to enable discovery of security settings used for communication via the iSCSI and/or iFCP protocols.
iSNSプロトコルは、iSCSIデバイス、iFCPゲートウェイ、管理ステーション、およびiSNSサーバー間での命名、検出、および管理情報の転送に使用されます。これには、iSCSIおよび/またはiFCPプロトコルを介した通信に使用されるセキュリティ設定の検出を有効にする機能が含まれます。
The iSNS server stores security settings for each iSCSI and iFCP device interface. These security settings, which can be retrieved by authorized hosts, include use or non-use of IPsec, IKE, Main Mode, Aggressive Mode, PFS, Pre-shared Key, and certificates.
iSNSサーバーは、各iSCSIおよびiFCPデバイスインターフェイスのセキュリティ設定を保存します。許可されたホストが取得できるこれらのセキュリティ設定には、IPsec、IKE、メインモード、アグレッシブモード、PFS、事前共有キー、および証明書の使用または非使用が含まれます。
For example, IKE may not be enabled for a particular device interface. If a peer device can learn of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE Phase 1 SA with that device interface.
たとえば、IKEは特定のデバイスインターフェイスに対して有効になっていない場合があります。ピアデバイスがiSNSサーバーに問い合わせることで事前にこれを知ることができれば、そのデバイスインターフェイスでIKEフェーズ1 SAを開始しようとする時間とリソースを無駄にする必要はありません。
If iSNS is used to distribute security policy, then the minimum information that should be learned from the iSNS server is the use or non-use of IKE and IPsec by each iFCP or iSCSI peer device interface. This information is encoded in the Security Bitmap field of each Portal of the peer device, and is applicable on a per-interface basis for the peer device. iSNS queries to acquire security configuration data about peer devices MUST be protected by IPsec/ESP authentication.
iSNSを使用してセキュリティポリシーを配布する場合、iSNSサーバーから学習する必要がある最低限の情報は、各iFCPまたはiSCSIピアデバイスインターフェイスによるIKEおよびIPsecの使用または非使用です。この情報は、ピアデバイスの各ポータルのセキュリティビットマップフィールドにエンコードされ、ピアデバイスのインターフェイスごとに適用されます。ピアデバイスに関するセキュリティ構成データを取得するためのiSNSクエリは、IPsec / ESP認証によって保護する必要があります。
Once communication between iSNS clients and the iSNS server are secured through use of IPsec, iSNS clients have the capability to discover the security settings required for communication via the iSCSI and/or iFCP protocols. Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and decrease the probability of communications failures due to incompatible security policies. If iSNS is used to distribute security policies, then IPsec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages.
iSNSクライアントとiSNSサーバー間の通信がIPsecを使用して保護されると、iSNSクライアントは、iSCSIおよび/またはiFCPプロトコルを介した通信に必要なセキュリティ設定を検出することができます。セキュリティポリシーの配布にiSNSを使用すると、手動のデバイス設定の負担が軽減され、互換性のないセキュリティポリシーが原因で通信障害が発生する可能性が低くなります。 iSNSを使用してセキュリティポリシーを配布する場合は、IPsec認証、データの整合性、および機密性を使用して、すべてのiSNSプロトコルメッセージを保護する必要があります。
The complete IKE/IPsec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies that are used for IKE Phase 1 and Phase 2 negotiations between client devices. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to use to protect iSCSI or iFCP traffic.
各iFCPまたはiSCSIデバイス、あるいはその両方の完全なIKE / IPsec構成は、クライアントデバイス間のIKEフェーズ1およびフェーズ2ネゴシエーションに使用されるポリシーを含め、iSNSサーバーに保存できます。 IKEペイロード形式には、iSCSIまたはiFCPトラフィックを保護するために使用する適切なIPsecポリシーをネゴシエートするときにiSCSIまたはiFCPデバイスが使用する一連の1つ以上の提案が含まれています。
Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS.
手動構成やIPsecセキュリティポリシーの配布など、他の方法でセキュリティ設定を決定できる場合は、セキュリティポリシーのiSNS配布は不要です。エンティティが他のメカニズムを介してセキュリティ構成をすでに取得している場合、iSNSを介してセキュリティポリシーを要求してはなりません（MUST NOT）。
For further details on how to store and retrieve IKE policy proposals in the iSNS server, see [iSNS].
IKEポリシープロポーザルをiSNSサーバーに保存および取得する方法の詳細については、[iSNS]を参照してください。
When IPsec security is enabled, each iSNS client that is registered in the iSNS database maintains at least one Phase 1 and one Phase 2 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server are to be protected by a phase-2 security association.
IPsecセキュリティーが有効になっている場合、iSNSデータベースに登録されている各iSNSクライアントは、iSNSサーバーとの少なくとも1つのフェーズ1および1つのフェーズ2セキュリティー関連付けを維持します。 iSNSクライアントとiSNSサーバー間のすべてのiSNSプロトコルメッセージは、フェーズ2セキュリティアソシエーションによって保護されます。
All iSNS implementations MUST support the replay protection mechanisms of IPsec. ESP in tunnel mode MUST be implemented, and IPsec with ESP in transport mode MAY be implemented.
すべてのiSNS実装は、IPsecのリプレイ保護メカニズムをサポートする必要があります。トンネルモードのESPを実装する必要があり、トランスポートモードのESPを使用したIPsecを実装することができます（MAY）。
To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. When confidentiality is implemented, 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. If confidentiality is not required but data origin authentication and integrity is enabled, ESP with NULL Encryption MUST be used.
ESPでデータ発信元認証と整合性を提供するには、HMAC-SHA1をサポートする必要があり、XCBC拡張を使用したCBC MACモードのAESをサポートする必要があります[RFC3566]。機密性が実装されている場合、[RFC3686]で説明されているように、CBCモードの3DESをサポートする必要があり、カウンターモードのAESをサポートする必要があります（SHOULD）。 CBCモードのDESは、固有の弱点があるため使用しないでください。機密性は必要ありませんが、データ発信元の認証と整合性が有効になっている場合は、NULL暗号化のESPを使用する必要があります。
Conformant iSNS implementations MUST support IKE for authentication, negotiation of security associations, and key management, using the IPsec DOI, described in [RFC2407]. IP block storage protocols can be expected to send data in high volumes, thereby requiring rekey. Since manual keying does not provide rekeying support, its use is prohibited with IP block storage protocols. Although iSNS does not send a high volume of data, and therefore rekey is not a major concern, manual keying SHOULD NOT be used. This is for consistency, since dynamic keying support is already required in IP storage security implementations.
[RFC2407]で説明されているように、IPsec DOIを使用して、認証、セキュリティアソシエーションのネゴシエーション、およびキー管理のために、適合iSNS実装はIKEをサポートする必要があります。 IPブロックストレージプロトコルは大量のデータを送信することが予想されるため、鍵の再生成が必要です。手動キーイングはキーイングのサポートを提供しないため、IPブロックストレージプロトコルでの使用は禁止されています。 iSNSは大量のデータを送信しないため、キーの再生成は大きな懸念事項ではありませんが、手動でのキー入力は使用しないでください。これは、IPストレージセキュリティの実装で動的キーイングサポートがすでに必要であるため、一貫性を保つためです。
Conformant iSNS security implementations MUST support authentication using a pre- shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in [RFC2409] sections 5.2 and 5.3 SHOULD NOT be used.
適合iSNSセキュリティ実装は、事前共有キーを使用した認証をサポートする必要があり、デジタル署名を使用した証明書ベースのピア認証をサポートする場合があります（MAY）。 [RFC2409]セクション5.2および5.3で概説されている公開鍵暗号化方式を使用したピア認証は使用しないでください。
Conformant iSNS implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use dynamically assigned IP addresses. While Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force use of a group pre-shared key, which is vulnerable to man-in-the-middle attack.
適合iSNS実装はIKEメインモードをサポートする必要があり、アグレッシブモードをサポートする必要があります（SHOULD）。事前共有キー認証を使用するIKEメインモードは、いずれかのピアが動的に割り当てられたIPアドレスを使用する場合は使用しないでください。事前共有キー認証を使用するメインモードは多くの場合に優れたセキュリティを提供しますが、動的に割り当てられたアドレスが使用される状況では、グループ事前共有キーが強制的に使用されます。これは中間者攻撃に対して脆弱です。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
認証にデジタル署名が使用される場合、IKEメインモードまたはIKEアグレッシブモードのいずれかが使用される場合があります。すべての場合において、ローカルに保存された秘密情報（デジタル署名用の事前共有キーまたは秘密キー）へのアクセスは、IKE / IPsecプロトコルのセキュリティプロパティを無効にするため、適切に制限する必要があります。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
認証を達成するためにデジタル署名が使用される場合、IKEネゴシエーターはIKE証明書要求ペイロードを使用して、そのローカルポリシーに従って信頼される認証局を指定する必要があります（SHOULD）。 IKEネゴシエーターは、IKEの認証手順で使用するPKI証明書を受け入れる前に、関連する証明書失効リスト（CRL）を確認する必要があります（SHOULD）。
The following guidelines are established to meet iSCSI security requirements using IPsec in practical situations.
次のガイドラインは、実際の状況でIPsecを使用するiSCSIセキュリティ要件を満たすために確立されています。
iSCSI provides for iSCSI Login, outlined in [RFC3720], which includes support for application-layer authentication. This authentication is logically between the iSCSI initiator and the iSCSI target (as opposed to between the TCP/IP communication endpoints). The intent of the iSCSI design is that the initiator and target represent the systems (e.g., host and disk array or tape system) participating in the communication, as opposed to network communication interfaces or endpoints.
iSCSIは、[RFC3720]で概説されているiSCSIログインを提供します。これには、アプリケーション層認証のサポートが含まれます。この認証は、（TCP / IP通信エンドポイント間ではなく）iSCSIイニシエーターとiSCSIターゲット間で論理的に行われます。 iSCSI設計の目的は、イニシエーターとターゲットが、ネットワーク通信インターフェースやエンドポイントではなく、通信に参加しているシステム（ホストとディスクアレイやテープシステムなど）を表すことです。
The iSCSI protocol and iSCSI Login authentication do not meet the security requirements for iSCSI. iSCSI Login authentication provides mutual authentication between the iSCSI initiator and target at connection origination, but does not protect control and data traffic on a per packet basis, leaving the iSCSI connection vulnerable to attack. iSCSI Login authentication can mutually authenticate the initiator to the target, but does not by itself provide per-packet authentication, integrity, confidentiality or replay protection. In addition, iSCSI Login authentication does not provide for a protected ciphersuite negotiation. Therefore, iSCSI Login provides a weak security solution.
iSCSIプロトコルとiSCSIログイン認証は、iSCSIのセキュリティ要件を満たしていません。 iSCSIログイン認証は、接続の開始時にiSCSIイニシエーターとターゲット間の相互認証を提供しますが、パケットごとの制御およびデータトラフィックを保護しないため、iSCSI接続は攻撃に対して脆弱です。 iSCSIログイン認証は、ターゲットに対してイニシエーターを相互認証できますが、それ自体では、パケットごとの認証、整合性、機密性、またはリプレイ保護を提供しません。さらに、iSCSIログイン認証は、保護された暗号スイートネゴシエーションを提供しません。したがって、iSCSIログインは弱いセキュリティソリューションを提供します。
An iSCSI session [RFC3720], comprised of one or more TCP connections, is identified by the 2-tuple of the initiator-defined identifier and the target-defined identifier, <ISID, TSIH>. Each connection within a given session is assigned a unique Connection Identification, CID. The TCP connection is identified by the 5-tuple <Source IP address, Destination IP address, Protocol (TCP), Source Port, Destination Port>. An IPsec Phase 2 SA is identified by the 3-tuple <Protocol (ESP),destination address, SPI>.
1つ以上のTCP接続で構成されるiSCSIセッション[RFC3720]は、イニシエーター定義の識別子とターゲット定義の識別子の2つのタプル<ISID、TSIH>によって識別されます。特定のセッション内の各接続には、一意の接続ID、CIDが割り当てられます。 TCP接続は、5つのタプル<送信元IPアドレス、宛先IPアドレス、プロトコル（TCP）、送信元ポート、宛先ポート>で識別されます。 IPsecフェーズ2 SAは、3タプル<プロトコル（ESP）、宛先アドレス、SPI>によって識別されます。
The iSCSI session and connection information is carried within the iSCSI Login Commands, transported over TCP. Since an iSCSI initiator may have multiple interfaces, iSCSI connections within an iSCSI session may be initiated from different IP addresses. Similarly, multiple iSCSI targets may exist behind a single IP address, so that there may be multiple iSCSI sessions between a given <source IP address, destination IP address> pair.
iSCSIセッションおよび接続情報は、iSCSIログインコマンド内で伝達され、TCPを介して転送されます。 iSCSIイニシエーターには複数のインターフェースがあるため、iSCSIセッション内のiSCSI接続は、異なるIPアドレスから開始できます。同様に、単一のIPアドレスの背後に複数のiSCSIターゲットが存在する可能性があるため、特定の<ソースIPアドレス、宛先IPアドレス>ペア間に複数のiSCSIセッションが存在する可能性があります。
When multiple iSCSI sessions are active between a given <initiator, target> pair, the set of TCP connections used by a given iSCSI session must be disjoint from those used by all other iSCSI sessions between the same <initiator, target> pair. Therefore a TCP connection can be associated with one and only one iSCSI session.
特定の<イニシエーター、ターゲット>ペア間で複数のiSCSIセッションがアクティブな場合、特定のiSCSIセッションで使用されるTCP接続のセットは、同じ<イニシエーター、ターゲット>ペア間の他のすべてのiSCSIセッションで使用されるものから切り離す必要があります。したがって、TCP接続は1つだけのiSCSIセッションに関連付けることができます。
The relationship between iSCSI sessions, TCP connections and IKE Phase 1 and Phase 2 SAs is as follows:
iSCSIセッション、TCP接続、IKEフェーズ1およびフェーズ2 SAの関係は次のとおりです。
[1] An iSCSI initiator or target may have more than one interface, and therefore may have multiple IP addresses. Also, multiple iSCSI initiators and targets may exist behind a single IP address. As a result, an iSCSI Session may correspond to multiple IKE Phase 1 Security Associations, though typically a single IKE Phase 1 security association will exist for an <initiator IP address, target IP address> tuple.
[1] iSCSIイニシエーターまたはターゲットには複数のインターフェースがあり、複数のIPアドレスを持つ場合があります。また、単一のIPアドレスの背後に複数のiSCSIイニシエーターとターゲットが存在する場合があります。その結果、iSCSIセッションは複数のIKEフェーズ1セキュリティアソシエーションに対応する可能性がありますが、通常、<イニシエーターIPアドレス、ターゲットIPアドレス>タプルに対して単一のIKEフェーズ1セキュリティアソシエーションが存在します。
[2] Each TCP connection within an iSCSI Session is protected by an IKE Phase 2 SA. The selectors may be specific to that TCP connection or may cover multiple connections. While each IKE Phase 2 SA may protect multiple TCP connections, each TCP connection is transported under only one IKE Phase 2 SA.
[2] iSCSIセッション内の各TCP接続は、IKEフェーズ2 SAによって保護されています。セレクターは、そのTCP接続に固有の場合もあれば、複数の接続をカバーする場合もあります。各IKEフェーズ2 SAは複数のTCP接続を保護する場合がありますが、各TCP接続は1つのIKEフェーズ2 SAの下でのみ転送されます。
Given this, all the information needed for the iSCSI/IPsec binding is contained within the iSCSI Login messages from the iSCSI initiator and target. This includes the binding between an IKE Phase 1 SA and the corresponding iSCSI sessions, as well as the binding between a TCP connection, an IKE Phase 2 SA and the iSCSI connection ID.
これにより、iSCSI / IPsecバインディングに必要なすべての情報は、iSCSIイニシエーターとターゲットからのiSCSIログインメッセージに含まれます。これには、IKEフェーズ1 SAと対応するiSCSIセッション間のバインディング、およびTCP接続、IKEフェーズ2 SAとiSCSI接続ID間のバインディングが含まれます。
In order to create a new iSCSI Session, if an IKE Phase 1 SA does not already exist, then it is established by an initiator implementing iSCSI security. Subsequent iSCSI connections established within the iSCSI session will typically be protected by IKE Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase 1 SAs can also be brought up.
新しいiSCSIセッションを作成するために、IKEフェーズ1 SAがまだ存在しない場合は、iSCSIセキュリティを実装するイニシエーターによって確立されます。 iSCSIセッション内で確立される後続のiSCSI接続は、通常、そのIKEフェーズ1 SAから派生したIKEフェーズ2 SAによって保護されますが、追加のIKEフェーズ1 SAを起動することもできます。
The initiator and target implementations successfully complete the IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator contacts the target on well-known TCP port 3260, and sends the iSCSI Login command over the TCP connection. IPsec implementations configured with the correct policies (e.g., use ESP with non-null transform for all traffic destined for the iSCSI well-known TCP port 3260) will handle this automatically.
イニシエーターとターゲットの実装は、iSCSIイニシエーターがウェルノウンTCPポート3260でターゲットに接続し、TCP接続を介してiSCSIログインコマンドを送信する前に、IKEフェーズ1およびフェーズ2ネゴシエーションを正常に完了します。正しいポリシーで構成されたIPsec実装（たとえば、iSCSIウェルノウンTCPポート3260宛てのすべてのトラフィックにnull以外の変換でESPを使用する）は、これを自動的に処理します。
The initiator fills in the ISID field, and leaves the TSIH field set to zero, to indicate that it is the first message of a new session establishment exchange. The initiator also fills in a CID value, that identifies the TCP connection over which the Login command is being exchanged. When the iSCSI target replies with its Login Command, both iSCSI devices will know the TSIH, and therefore the iSCSI session identifier <ISID, TSIH>.
イニシエーターはISIDフィールドに入力し、TSIHフィールドをゼロに設定したままにします。これは、それが新しいセッション確立交換の最初のメッセージであることを示します。イニシエーターはCID値も入力します。これは、Loginコマンドが交換されるTCP接続を識別します。 iSCSIターゲットがログインコマンドで応答すると、両方のiSCSIデバイスがTSIHを認識し、iSCSIセッション識別子<ISID、TSIH>を認識します。
A single iSCSI session identifier may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session identifiers. Each iSCSI connection (identified by the connection identifier) corresponds to a single TCP connection (identified by the 5-tuple). Each IKE Phase 2 SA is identified by the <Protocol (ESP), destination address, SPI> combination. A Phase 2 SA may protect multiple TCP connections, and corresponds to a single IKE Phase 1 SA.
単一のiSCSIセッション識別子には複数のIKEフェーズ1 SAが関連付けられている場合があり、各IKEフェーズ1 SAは複数のiSCSIセッション識別子に対応している場合があります。各iSCSI接続（接続識別子で識別される）は、単一のTCP接続（5タプルで識別される）に対応します。各IKEフェーズ2 SAは、<プロトコル（ESP）、宛先アドレス、SPI>の組み合わせによって識別されます。フェーズ2 SAは複数のTCP接続を保護する場合があり、単一のIKEフェーズ1 SAに対応します。
Within IKE, each key refresh requires that a new security association be established. In practice there is a time interval during which an old, about-to-expire SA and newly established SA will both be valid. The IPsec implementation will choose which security association to use based on local policy, and iSCSI concerns play no role in this selection process.
IKE内では、キーを更新するたびに、新しいセキュリティアソシエーションを確立する必要があります。実際には、期限切れ間近の古いSAと新しく確立されたSAの両方が有効になる時間間隔があります。 IPsec実装は、ローカルポリシーに基づいて、使用するセキュリティアソシエーションを選択します。iSCSIの懸念は、この選択プロセスでは役割を果たしません。
Mechanisms within iSCSI provide for both graceful and non-graceful teardown of iSCSI Sessions or individual TCP connections within a given session. The iSCSI Logout command is used to effect graceful teardown. This command allows the iSCSI initiator to request that:
iSCSI内のメカニズムは、iSCSIセッションまたは特定のセッション内の個々のTCP接続の正常な破棄と正常でない破棄の両方を提供します。 iSCSI Logoutコマンドは、正常なティアダウンを実行するために使用されます。このコマンドにより、iSCSIイニシエーターは以下を要求できます。
[a] the session be closed
[a] セッションを閉じます
[b] a specific connection within the session be closed
[b] セッション内の特定の接続が閉じられる
[c] a specific connection be marked for recovery
[c] 特定の接続にリカバリのマークを付ける
When the iSCSI implementation wishes to close a session, it uses the appropriate iSCSI commands to accomplish this. After exchanging the appropriate iSCSI control messages for session closure, the iSCSI security implementation will typically initiate a half-close of each TCP connection within the iSCSI session.
iSCSI実装がセッションを閉じる場合、適切なiSCSIコマンドを使用してこれを実行します。適切なiSCSI制御メッセージをセッションクローズに交換した後、iSCSIセキュリティ実装は通常、iSCSIセッション内の各TCP接続のハーフクローズを開始します。
When the iSCSI security implementation wishes to close an individual TCP connection while leaving the parent iSCSI session active, it should half-close the TCP connection. After the expiration of the TIME_WAIT timeout, the TCP connection is closed.
親iSCSIセッションをアクティブにしたまま、iSCSIセキュリティ実装が個々のTCP接続を閉じたい場合は、TCP接続を半分閉じます。 TIME_WAITタイムアウトの期限が切れると、TCP接続が閉じられます。
If a given TCP connection unexpectedly fails, the associated iSCSI connection is torn down. There is no requirement that an IKE Phase 2 delete immediately follow iSCSI connection tear down or Phase 1 deletion. Since an IKE Phase 2 SA may correspond to multiple TCP connections, such a deletion might be inappropriate. Similarly, if the IKE implementation receives a Phase 2 Delete message for a security association corresponding to a TCP connection, this does not necessarily imply that the TCP or iSCSI connection is to be torn down.
特定のTCP接続が予期せず失敗した場合、関連付けられているiSCSI接続が切断されます。 IKEフェーズ2削除がiSCSI接続の切断またはフェーズ1削除の直後に続く必要はありません。 IKEフェーズ2 SAは複数のTCP接続に対応している可能性があるため、このような削除は不適切な場合があります。同様に、IKE実装がTCP接続に対応するセキュリティアソシエーションのフェーズ2削除メッセージを受信した場合、これは必ずしもTCP接続またはiSCSI接続が切断されることを意味するわけではありません。
If a Logout Command/Logout Response sequence marks a connection for removal from the iSCSI session, then after the iSCSI peer has executed an iSCSI teardown process for the connection, the TCP connection will be closed. The iSCSI connection state can then be safely removed.
ログアウトコマンド/ログアウト応答シーケンスがiSCSIセッションからの削除のために接続をマークした場合、iSCSIピアが接続に対してiSCSIティアダウンプロセスを実行した後、TCP接続は閉じられます。その後、iSCSI接続状態を安全に削除できます。
Since an IKE Phase 2 SA may be used by multiple TCP connections, an iSCSI implementation should not depend on receiving the IPsec Phase 2 delete as confirmation that the iSCSI peer has executed an iSCSI teardown process for the connection.
IKEフェーズ2 SAは複数のTCP接続で使用される可能性があるため、iSCSIピアが接続のiSCSIティアダウンプロセスを実行したことの確認として、iSCSI実装はIPsecフェーズ2削除の受信に依存しないようにする必要があります。
Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down the corresponding iSCSI connection if no Logout Command/Logout Receive has been executed on the connection. Rather, it is preferable to leave the iSCSI connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing iSCSI connections up and down.
IPsecアクセラレーションハードウェアは限られた数のアクティブなIKEフェーズ2 SAしか処理できないため、アクティブなフェーズ2 SAの数を最小限に抑える手段として、フェーズ2削除メッセージをアイドルSAに送信できます。 IKEフェーズ2削除メッセージの受信は、ログアウトコマンド/ログアウト受信が接続で実行されていない場合に、対応するiSCSI接続を破棄する理由として解釈してはなりません（MUST NOT）。むしろ、iSCSI接続をアップのままにして、追加のトラフィックが送信される場合は、それを保護するために別のIKEフェーズ2 SAを起動することが望ましいです。これにより、iSCSI接続が継続的にアップおよびダウンする可能性が回避されます。
iSCSI's error detection and recovery assumes that the TCP and IP checksums provide inadequate integrity protection for high speed communications. As described in [CRCTCP], when operating at high speeds, the 16-bit TCP checksum [RFC793] will not necessarily detect all errors, resulting in possible data corruption. iSCSI [RFC3720] therefore incorporates a 32-bit CRC to protect its headers and data.
iSCSIのエラー検出と回復は、TCPとIPのチェックサムが高速通信に不十分な完全性保護を提供すると想定しています。 [CRCTCP]で説明されているように、高速で動作している場合、16ビットTCPチェックサム[RFC793]がすべてのエラーを検出するとは限らず、データが破損する可能性があります。 iSCSI [RFC3720]は、32ビットのCRCを組み込んで、ヘッダーとデータを保護します。
When a CRC check fails (i.e., CRC computed at receiver does not match the received CRC), the iSCSI PDU covered by that CRC is discarded. Since presumably the error was not detected by the TCP checksum, TCP retransmission will not occur and thus cannot assist in recovering from the error. iSCSI contains both data and command retry mechanisms to deal with the resulting situations, including SNACK, the ability to reissue R2T commands, and the retry (X) bit for commands.
CRCチェックが失敗した場合（つまり、レシーバーで計算されたCRCが受信したCRCと一致しない場合）、そのCRCでカバーされているiSCSI PDUは破棄されます。おそらくTCPチェックサムでエラーが検出されなかったため、TCP再送信は発生せず、エラーからの回復を支援できません。 iSCSIには、SNACK、R2Tコマンドを再発行する機能、コマンドの再試行（X）ビットなど、結果として生じる状況に対処するためのデータとコマンドの両方の再試行メカニズムが含まれています。
IPsec offers protection against an attacker attempting to modify packets in transit, as well as unintentional packet modifications caused by network malfunctions or other errors. In general, IPsec authentication transforms afford stronger integrity protection than both the 16-bit TCP checksum and the 32-bit application-layer CRC specified for use with iSCSI. Since IPsec integrity protection occurs below TCP, if an error is discovered, then the packet will be discarded and TCP retransmission will occur, so that no recovery action need be taken at the iSCSI layer.
IPsecは、転送中のパケットを変更しようとする攻撃者、およびネットワークの誤動作やその他のエラーによって引き起こされた意図しないパケット変更に対する保護を提供します。一般に、IPsec認証変換は、iSCSIで使用するために指定された16ビットTCPチェックサムと32ビットアプリケーション層CRCの両方よりも強力な整合性保護を提供します。 IPsec整合性保護はTCPの下で発生するため、エラーが発見された場合、パケットは破棄され、TCP再送信が発生するため、iSCSIレイヤーで回復アクションを実行する必要はありません。
Where IPsec integrity protection is known to be in place end-to-end between iSCSI endpoints (or the portion that requires additional integrity protection), portions of iSCSI can be simplified. For example, mechanisms to recover from CRC check failures are not necessary.
IPsec整合性保護がiSCSIエンドポイント（または追加の整合性保護が必要な部分）の間にエンドツーエンドで配置されていることがわかっている場合、iSCSIの部分を簡略化できます。たとえば、CRCチェックの失敗から回復するメカニズムは必要ありません。
If the iSCSI CRC is negotiated, the recovery logic can be simplified to regard any CRC check failure as fatal (e.g., generate a SCSI CHECK CONDITION on data error, close the corresponding TCP connection on header error) because it will be very rare for errors undetected by IPsec integrity protection to be detected by the iSCSI CRC.
iSCSI CRCがネゴシエートされた場合、CRCチェックの失敗を致命的と見なすように回復ロジックを簡略化できます（たとえば、データエラーでSCSI CHECK CONDITIONを生成し、ヘッダーエラーで対応するTCP接続を閉じます）。 iSCSI CRCによって検出されるIPsec整合性保護によって検出されません。
In some situations where IPsec is employed, the iSCSI CRC will not provide additional protection and can be omitted.
IPsecが採用されている一部の状況では、iSCSI CRCは追加の保護を提供せず、省略できます。
For example, where IPsec processing as well as TCP checksum and iSCSI CRC verification are offloaded within the NIC, each of these checks will be verified prior to transferring data across the bus, so that subsequent errors will not be detected by these mechanisms. As a result, where IPsec processing is offloaded to the NIC, the iSCSI CRC is not necessary and the implementations may wish not to negotiate it.
たとえば、IPsec処理、TCPチェックサム、およびiSCSI CRC検証がNIC内でオフロードされる場合、これらの各チェックは、バスを介してデータを転送する前に検証されるため、これらのメカニズムによって後続のエラーは検出されません。その結果、IPsec処理がNICにオフロードされる場合、iSCSI CRCは不要であり、実装はそれをネゴシエートしないことを望む場合があります。
However, in other circumstances, the TCP checksum and iSCSI CRC will provide additional error coverage because they are computed and checked at a different point in the protocol stack or in devices different from those that implement the IPsec integrity checks. The resulting coverage of additional possible errors may make it desirable to negotiate use of the iSCSI CRC even when IPsec integrity protection is in use. Examples of these situations include where:
ただし、他の状況では、TCPチェックサムとiSCSI CRCは、プロトコルスタック内の別のポイントまたはIPsec整合性チェックを実装するデバイスとは異なるデバイスで計算およびチェックされるため、追加のエラーカバレッジを提供します。結果として生じる可能性のある追加エラーのカバレッジにより、IPsec整合性保護が使用されている場合でも、iSCSI CRCの使用についてネゴシエートすることが望ましい場合があります。これらの状況の例には、以下が含まれます。
[1] IPsec, TCP and iSCSI are implemented purely in software. Here, additional failure modes may be detected by the TCP checksum and/or iSCSI CRC. For example, after the IPsec message integrity check is successfully verified, the segment is copied as part of TCP processing, and a memory error during this process might cause the TCP checksum or iSCSI CRC verification to fail.
[1] IPsec、TCP、iSCSIは純粋にソフトウェアで実装されています。ここでは、TCPチェックサムやiSCSI CRCによって追加の障害モードが検出される場合があります。たとえば、IPsecメッセージの整合性チェックが正常に検証された後、セグメントはTCP処理の一部としてコピーされ、このプロセス中にメモリエラーが発生すると、TCPチェックサムまたはiSCSI CRC検証が失敗する可能性があります。
[2] The implementation is an iSCSI-iSCSI proxy or gateway. Here the iSCSI CRC can be propagated from one iSCSI connection to another. In this case, the iSCSI CRC is useful to protect iSCSI data against memory, bus, or software errors within the proxy or gateway, and requesting it is desirable.
[2] 実装は、iSCSI-iSCSIプロキシまたはゲートウェイです。ここでは、iSCSI CRCをあるiSCSI接続から別のiSCSI接続に伝達できます。この場合、iSCSI CRCは、プロキシーまたはゲートウェイ内のメモリー、バス、またはソフトウェアのエラーからiSCSIデータを保護するのに役立ち、要求することが望ましいです。
[3] IPsec is provided by a device external to the actual iSCSI device. Here the iSCSI header and data CRCs can be kept across the part of the connection that is not protected by IPsec. For instance, the iSCSI connection could traverse an extra bus, interface card, network, interface card, and bus between the iSCSI device and the device providing IPsec. In this case, the iSCSI CRC is desirable, and the iSCSI implementation behind the IPsec device may request it.
[3] IPsecは、実際のiSCSIデバイスの外部にあるデバイスによって提供されます。ここで、iSCSIヘッダーとデータCRCは、IPsecで保護されていない接続部分全体で保持できます。たとえば、iSCSI接続は、iSCSIデバイスとIPsecを提供するデバイスの間の追加のバス、インターフェイスカード、ネットワーク、インターフェイスカード、およびバスを通過できます。この場合、iSCSI CRCが望ましく、IPsecデバイスの背後にあるiSCSI実装がそれを要求する場合があります。
Note that if both ends of the connection are on the same segment, then traffic will be effectively protected by the layer 2 CRC, so that negotiation of the iSCSI CRC is not necessary to protect against NIC and network errors, although it may be desirable for other reasons (e.g., [1] and [2] above).
接続の両端が同じセグメント上にある場合、トラフィックはレイヤー2 CRCによって効果的に保護されるため、NICおよびネットワークエラーから保護するためにiSCSI CRCのネゴシエーションは必要ありませんが、その他の理由（上記の[1]および[2]など）。
iFCP and FCIP are peer-to-peer protocols. iFCP and FCIP sessions may be initiated by either or both peer gateways. Consequently, bi-directional authentication of peer gateways MUST be provided.
iFCPとFCIPはピアツーピアプロトコルです。 iFCPおよびFCIPセッションは、一方または両方のピアゲートウェイによって開始できます。したがって、ピアゲートウェイの双方向認証を提供する必要があります。
iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre Channel frames over IP. Therefore, Fibre Channel, operating system, and user identities are transparent to the iFCP and FCIP protocols.
iFCPおよびFCIPは、IP上のSCSIおよびファイバーチャネルフレームをカプセル化するトランスポートプロトコルです。したがって、ファイバーチャネル、オペレーティングシステム、およびユーザーIDは、iFCPおよびFCIPプロトコルに対して透過的です。
iFCP gateways use Discovery Domain information obtained from the iSNS server to determine whether the initiating Fibre Channel N_PORT should be allowed access to the target N_PORT. N_PORT identities used in the Port Login (PLOGI) process will be considered authenticated provided that they are received over a connection whose security complies with the local security policy.
iFCPゲートウェイは、iSNSサーバーから取得したディスカバリードメイン情報を使用して、開始ファイバーチャネルN_PORTにターゲットN_PORTへのアクセスを許可するかどうかを決定します。ポートログイン（PLOGI）プロセスで使用されるN_PORT IDは、セキュリティがローカルセキュリティポリシーに準拠している接続を介して受信される場合、認証済みと見なされます。
There is no requirement that the identities used in authentication be kept confidential.
認証で使用されるIDを秘密にしておく必要はありません。
A conformant iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized, or may be deferred until the first TCP connection with security requirements is established.
適合iFCPポータルは、ピアiFCPポータルに対して1つ以上のIKEフェーズ1セキュリティアソシエーション（SA）を確立できます。フェーズ1 SAは、iFCPポータルが初期化されるときに確立されるか、セキュリティ要件を備えた最初のTCP接続が確立されるまで延期されます。
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, the successful establishment of an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <SPI, destination IP address, ESP>. These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. Each of the TCP connections protected by an SA is either in the unbound state, or is bound to a specific iFCP session.
IKEフェーズ2 SAは、同じiFCPポータル内の1つ以上のTCP接続を保護します。より具体的には、IKEフェーズ2 SAの確立が成功すると、タプル<SPI、宛先IPアドレス、ESP>によって完全修飾された2つの単方向IPsec SAが作成されます。これらのSAは、基になるTCP接続のセットアッププロセスと、それに続くすべてのTCPトラフィックを保護します。 SAによって保護されている各TCP接続は、非バインド状態であるか、特定のiFCPセッションにバインドされています。
In summary, at any point in time:
要約すると、いつでも：
[1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals [2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs [3] Each IKE Phase-2 SA protects 0..Z TCP connections
[1] ピアiFCPポータル間には0..MのIKEフェーズ1 SAが存在します[2]各IKEフェーズ1 SAには0..NのIKEフェーズ2 SAがあります[3]各IKEフェーズ2 SAは0..Z TCP接続を保護します
The creation of an IKE Phase-2 SA may be triggered by security policy rules retrieved from an iSNS server. Alternately, the creation of an SA may be triggered by policy rules configured through a management interface, reflecting iSNS-resident policy rules. Likewise, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be driven by security policy rules retrieved from the iSNS server, or set through a management interface.
IKEフェーズ2 SAの作成は、iSNSサーバーから取得したセキュリティポリシールールによってトリガーされます。または、SAの作成は、iSNS常駐ポリシールールを反映して、管理インターフェースを介して構成されたポリシールールによってトリガーされます。同様に、完全転送秘密のためのクイックモードでの鍵交換ペイロードの使用は、iSNSサーバーから取得した、または管理インターフェイスを介して設定されたセキュリティポリシールールによって駆動されます。
If an iFCP implementation makes use of unbound TCP connections, and such connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times just like bound connections.
iFCP実装がバインドされていないTCP接続を利用し、そのような接続がセキュリティ要件のあるiFCPポータルに属している場合、バインドされていない接続は常にバインドされた接続と同様にSAによって保護される必要があります。
Upon receiving an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating such connections might in fact be inappropriate and untimely.
IKEフェーズ2削除メッセージを受信すると、保護されたTCP接続を終了したり、関連するIKEフェーズ1 SAを削除したりする必要はありません。 IKEフェーズ2 SAは複数のTCP接続に関連付けられている可能性があるため、そのような接続を終了することは実際には不適切であり、タイミングが合わない場合があります。
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.
アクティブなフェーズ2 SAの数を最小限に抑えるために、TCP接続がしばらくの間データトラフィックを処理しなかったフェーズ2 SAに対して、IKEフェーズ2削除メッセージが送信される場合があります。関連するTCP接続がアイドル状態のときにSAリソースの使用を最小限に抑えるには、新しいデータが接続を介して送信されるまで、新しいSAの作成を延期する必要があります。
FCIP Entities establish tunnels with other FCIP Entities in order to transfer IP encapsulated FC frames. Each tunnel is a separate FCIP Link, and can encapsulate multiple TCP connections. The binding of TCP connections to an FCIP Link is performed using the Fibre Channel World Wide Names (WWNs) of the two FCIP Entities.
FCIPエンティティは、IPカプセル化FCフレームを転送するために、他のFCIPエンティティとのトンネルを確立します。各トンネルは個別のFCIPリンクであり、複数のTCP接続をカプセル化できます。 FCIPリンクへのTCP接続のバインドは、2つのFCIPエンティティのファイバーチャネルワールドワイド名（WWN）を使用して実行されます。
FCIP Entities may have more than one interface and IP address, and it is possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is typically established for each FCIP endpoint IP Address pair. For the purposes of establishing an IKE Phase 1 SA, static IP addresses are typically used for identification.
FCIPエンティティには複数のインターフェイスとIPアドレスがあり、FCIPリンクには、FCIPエンドポイントのIPアドレスが異なる複数のTCP接続を含めることができます。この場合、IKEフェーズ1 SAは通常、FCIPエンドポイントのIPアドレスペアごとに確立されます。 IKEフェーズ1 SAを確立する目的で、静的IPアドレスは通常、識別に使用されます。
Each TCP connection within an FCIP Link corresponds to an IKE Phase 2 (Quick Mode) SA. This is established prior to sending the initial TCP SYN packet and applies to the life of the connection. Phase 2 negotiation is also required for rekeying, in order to protect against replay attacks.
FCIPリンク内の各TCP接続は、IKEフェーズ2（クイックモード）SAに対応しています。これは、最初のTCP SYNパケットを送信する前に確立され、接続の存続期間に適用されます。リプレイ攻撃から保護するために、キー再生成にはフェーズ2ネゴシエーションも必要です。
FCIP implementations MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
FCIP実装は、機密性の使用の管理管理を提供する場合があります。これらの管理インターフェースは、攻撃者が管理インターフェースを攻撃することによってセキュリティプロセスを破壊することを防ぐために、安全な方法で提供されるべきです（SHOULD）。
FCIP Entities do not require any user-level authentication, since all FCIP Entities participate in a machine-level tunnel function. FCIP uses SLP for discovery, but not to distribute security policies.
すべてのFCIPエンティティはマシンレベルのトンネル機能に参加するため、FCIPエンティティはユーザーレベルの認証を必要としません。 FCIPは、検出にSLPを使用しますが、セキュリティポリシーの配布には使用しません。
With respect to block storage protocols, the major differences between the IPsec tunnel mode and transport mode are as follows:
ブロックストレージプロトコルに関して、IPsecトンネルモードとトランスポートモードの主な違いは次のとおりです。
[1] MTU considerations. Tunnel mode introduces an additional IP header into the datagram that reflects itself in a corresponding decrease in the path MTU seen by packets traversing the tunnel. This may result in a decrease in the maximum segment size of TCP connections running over the tunnel.
[1] MTUに関する考慮事項。トンネルモードでは、追加のIPヘッダーがデータグラムに導入されます。これは、トンネルを通過するパケットによって見られるパスMTUの対応する減少に反映されます。これにより、トンネルを介して実行されるTCP接続の最大セグメントサイズが減少する可能性があります。
[2] Address assignment and configuration. Within IPsec tunnel mode, it is necessary for inner and outer source addresses to be configured, and for inner and outer destination addresses to be discovered. Within transport mode it is only necessary to discover a single destination address and configure a single source address. IPsec tunnel mode address usage considerations are discussed in more detail below.
[2] アドレスの割り当てと構成。 IPsecトンネルモード内では、内部および外部の送信元アドレスを設定し、内部および外部の宛先アドレスを検出する必要があります。トランスポートモード内では、単一の宛先アドレスを検出し、単一の送信元アドレスを構成するだけで済みます。 IPsecトンネルモードアドレスの使用に関する考慮事項については、以下で詳しく説明します。
[3] NAT traversal. As noted in [RFC3715], IPsec tunnel mode ESP can traverse NAT in limited circumstances, whereas transport mode ESP cannot traverse NAT. To enable NAT traversal in the general case, the IPsec NAT traversal functionality described in [RFC3715], [UDPIPsec] and [NATIKE] can be implemented. More details are provided in the next section.
[3] NATトラバーサル。 [RFC3715]に記載されているように、IPsecトンネルモードESPは限られた状況でNATを通過できますが、トランスポートモードESPはNATを通過できません。一般的なケースでNATトラバーサルを有効にするために、[RFC3715]、[UDPIPsec]、および[NATIKE]で説明されているIPsec NATトラバーサル機能を実装できます。詳細については、次のセクションで説明します。
[4] Firewall traversal. Where a block storage protocol is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for the block storage protocol. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end-to-end security, so that they can also verify authenticity and integrity of each packet for themselves.
[4] ファイアウォールトラバーサル。ブロックストレージプロトコルが管理ドメインを通過する場合、ファイアウォール管理者は、ファイアウォールにブロックストレージプロトコル用の穴を開けるのではなく、通過する各パケットの整合性と信頼性を検証することを望む場合があります。エンドポイントがエンドツーエンドで通信できるようにしながら、ファイアウォールがトンネルモード接続を終了できるため、IPsecトンネルモードはそのような検証に役立ちます。必要に応じて、エンドポイントはさらに、エンドツーエンドのセキュリティのためにIPsecトランスポートモードを利用できるため、各パケットの信頼性と整合性を自分自身で確認することもできます。
In contrast, carrying out this verification with IPsec transport mode is more complex, since the firewall will need to terminate the IPsec transport mode connection and will need to act as an iSCSI, iFCP or FCIP gateway or TCP proxy, originating a new IPsec transport mode connection from the firewall to the internal endpoint. Such an implementation cannot provide end-to-end authenticity or integrity protection, and an application-layer CRC (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and FCIP) is necessary to protect against errors introduced by the firewall.
対照的に、ファイアウォールはIPsecトランスポートモード接続を終了する必要があり、iSCSI、iFCPまたはFCIPゲートウェイまたはTCPプロキシとして機能し、新しいIPsecトランスポートモードを開始する必要があるため、IPsecトランスポートモードでこの検証を実行するのはより複雑です。ファイアウォールから内部エンドポイントへの接続。このような実装では、エンドツーエンドの認証または整合性保護を提供できません。ファイアウォールによって導入されたエラーから保護するには、アプリケーション層CRC（iSCSI）またはファイバーチャネルフレームCRC（iFCPおよびFCIP）の転送が必要です。
[5] IPsec-application integration. Where IPsec and the application layer protocol are implemented on the same device or host, it is possible to enable tight integration between them. For example, the application layer can request and verify that connections are protected by IPsec, and can obtain attributes of the IPsec security association. While in transport mode implementations the IPsec and application protocol implementations typically reside on the same host, with IPsec tunnel mode they may reside on different hosts. Where IPsec is implemented on an external gateway, integration between the application and IPsec is typically not possible. This limits the ability of the application to control and verify IPsec behavior.
[5] IPsec-アプリケーション統合。 IPsecとアプリケーション層プロトコルが同じデバイスまたはホストに実装されている場合、それらの間の緊密な統合を有効にすることが可能です。たとえば、アプリケーション層は、接続がIPsecによって保護されていることを要求および検証し、IPsecセキュリティアソシエーションの属性を取得できます。トランスポートモードの実装では、IPsecとアプリケーションプロトコルの実装は通常同じホストに存在しますが、IPsecトンネルモードでは、それらは異なるホストに存在する場合があります。 IPsecが外部ゲートウェイに実装されている場合、アプリケーションとIPsec間の統合は通常不可能です。これにより、IPsecの動作を制御および検証するアプリケーションの機能が制限されます。
IPsec tunnels include both inner and outer source as well as destination addresses.
IPsecトンネルには、内部および外部の送信元と宛先アドレスの両方が含まれます。
When used with IP block storage protocols, the inner destination address represents the address of the IP block storage protocol peer (e.g., the ultimate destination for the packet). The inner destination address can be discovered using SLPv2 or iSNS, or can be resolved from an FQDN via DNS, so that obtaining this address is typically not an issue.
IPブロックストレージプロトコルで使用する場合、内部宛先アドレスは、IPブロックストレージプロトコルピアのアドレス（たとえば、パケットの最終的な宛先）を表します。内部宛先アドレスは、SLPv2またはiSNSを使用して検出するか、DNSを介してFQDNから解決できるため、通常、このアドレスの取得は問題になりません。
The outer destination address represents the address of the IPsec security gateway used to reach the peer. Several mechanisms have been proposed for discovering the IPsec security gateway used to reach a particular peer. [RFC2230] discusses the use of KX Resource Records (RRs) for IPsec gateway discovery. However, while KX RRs are supported by many DNS server implementations, they have not yet been widely deployed. Alternatively, DNS SRV [RFC2782] can be used for this purpose. Where DNS is used for gateway location, DNS security mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple Secure Dynamic Update [RFC3007] are advisable.
外部宛先アドレスは、ピアに到達するために使用されるIPsecセキュリティゲートウェイのアドレスを表します。特定のピアに到達するために使用されるIPsecセキュリティゲートウェイを検出するために、いくつかのメカニズムが提案されています。 [RFC2230]では、IPsecゲートウェイの検出にKXリソースレコード（RR）を使用する方法について説明しています。ただし、KX RRは多くのDNSサーバー実装でサポートされていますが、まだ広く展開されていません。あるいは、この目的でDNS SRV [RFC2782]を使用できます。ゲートウェイの場所にDNSが使用されている場合、DNSSEC（[RFC2535]、[RFC2931]）、TSIG [RFC2845]、Simple Secure Dynamic Update [RFC3007]などのDNSセキュリティメカニズムが推奨されます。
When used with IP block storage protocols, the outer source address is configured either statically or dynamically, using mechanisms such as DHCPv4 [RFC2131], DHCPV6 [RFC3315], or stateless address autoconfiguration [RFC2373].
IPブロックストレージプロトコルと共に使用される場合、外部ソースアドレスは、DHCPv4 [RFC2131]、DHCPV6 [RFC3315]、またはステートレスアドレス自動構成[RFC2373]などのメカニズムを使用して、静的または動的に構成されます。
The inner source address SHOULD be included in the Quick Mode ID payload when the peer establishes a tunnel mode SA with the IPsec security gateway. This enables the IPsec security gateway to properly route packets back to the remote peer. The inner source address can be configured via a variety of mechanisms, depending on the scenario. Where the IP block storage peers are located within the same administrative domain, it is typically possible for the inner and outer source addresses to be the same. This will work because the outer source address is presumably assigned from within a prefix assigned to the administrative domain, and is therefore routable within the domain. Assuming that the IPsec security gateway is aware of the inner source address used by the connecting peer and plumbs a host route for it, then packets arriving at the IPsec security gateway destined for the address can be correctly encapsulated and sent down the correct tunnel.
ピアがIPsecセキュリティゲートウェイでトンネルモードSAを確立するときに、内部ソースアドレスをクイックモードIDペイロードに含める必要があります（SHOULD）。これにより、IPsecセキュリティゲートウェイがパケットをリモートピアに適切にルーティングできるようになります。内部送信元アドレスは、シナリオに応じて、さまざまなメカニズムで構成できます。 IPブロックストレージピアが同じ管理ドメイン内にある場合、通常、内部と外部の送信元アドレスが同じになる可能性があります。外部ソースアドレスはおそらく管理ドメインに割り当てられたプレフィックス内から割り当てられ、ドメイン内でルーティング可能であるため、これは機能します。 IPsecセキュリティゲートウェイが接続ピアが使用する内部ソースアドレスを認識し、そのホストルートを組み込むと仮定すると、アドレス宛てのIPsecセキュリティゲートウェイに到着するパケットを正しくカプセル化して、正しいトンネルに送信できます。
Where IP block storage peers are located within different administrative domains, it may be necessary for the inner source address to be assigned by the IPsec security gateway, effectively "joining" the remote host to the LAN attached to the IPsec security gateway. For example, if the remote peer were to use its assigned (outer) source address as the inner source address, then a number of problems might result:
IPブロックストレージピアが異なる管理ドメイン内にある場合、内部ソースアドレスがIPsecセキュリティゲートウェイによって割り当てられ、リモートホストをIPsecセキュリティゲートウェイに接続されたLANに効果的に「結合」する必要がある場合があります。たとえば、リモートピアが割り当てられた（外部）送信元アドレスを内部送信元アドレスとして使用する場合、いくつかの問題が発生する可能性があります。
[1] Intrusion detection systems sniffing the LAN behind the IPsec security gateway would notice source addresses originating outside the administrative domain.
[1] IPsecセキュリティゲートウェイの背後にあるLANをスニッフィングする侵入検知システムは、管理ドメインの外部から発信された送信元アドレスに気づきます。
[2] Reply packets might not reach their destination, since the IPsec security gateway typically does not advertise the default route, but rather only the prefix that it allocates addresses from. Since the remote peer's address does not originate from with a prefix native to the administrative domain, it is likely that routers within the domain would not have a route for it, and would send the packet off to the router advertising the default route (perhaps a border router) instead of to the IPsec security gateway.
[2] IPsecセキュリティゲートウェイは通常、デフォルトルートをアドバタイズせず、アドレスを割り当てるプレフィックスのみをアドバタイズするため、応答パケットは宛先に到達しない可能性があります。リモートピアのアドレスは、管理ドメインに固有のプレフィックスから発信されていないため、ドメイン内のルーターはそのルートを持たず、デフォルトルートをアドバタイズするルーターにパケットを送信する可能性があります（おそらく境界ルーター）の代わりにIPsecセキュリティゲートウェイを使用します。
For these reasons, for inter-domain use, assignment of inner source addresses may be needed. At present this is not a very common scenario; however, if address assignment is provided, then DHCP-based address assignment within IPsec tunnel mode [RFC3456] MUST be supported. Note that this mechanism is not yet widely deployed within IPsec security gateways; existing IPsec tunnel mode servers typically implement this functionality via proprietary extensions to IKE.
これらの理由により、ドメイン間で使用するために、内部送信元アドレスの割り当てが必要になる場合があります。現在、これはあまり一般的なシナリオではありません。ただし、アドレス割り当てが提供されている場合、IPsecトンネルモード[RFC3456]内のDHCPベースのアドレス割り当てをサポートする必要があります。このメカニズムは、まだIPsecセキュリティゲートウェイ内に広く導入されていないことに注意してください。既存のIPsecトンネルモードサーバーは、通常、IKEの独自の拡張機能を介してこの機能を実装しています。
As noted in [RFC3715], tunnel mode ESP can traverse NAT in a limited set of circumstances. For example, if there is only one protocol endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver does not perform source address validation, then tunnel mode ESP may successfully traverse NATs. Since ignoring source address validation introduces new security vulnerabilities, and negotiation of specific selectors is desirable so as to limit the traffic that can be sent down the tunnel, these conditions may not necessarily apply, and tunnel mode NAT traversal will not always be possible.
[RFC3715]に記載されているように、トンネルモードのESPは、限られた状況でNATを通過できます。たとえば、NATの背後にプロトコルエンドポイントが1つしかない場合、「ANY to ANY」セレクターがネゴシエートされ、受信者が送信元アドレスの検証を実行しない場合、トンネルモードESPは正常にNATを通過できます。送信元アドレスの検証を無視すると新しいセキュリティの脆弱性が発生し、トンネルを介して送信できるトラフィックを制限するために特定のセレクターのネゴシエーションが望ましいため、これらの条件が必ずしも適用されるとは限らず、トンネルモードのNATトラバーサルが常に可能とは限りません。
TCP carried within Transport mode ESP cannot traverse NAT, even though ESP itself does not include IP header fields within its message integrity check. This is because the 16-bit TCP checksum is calculated based on a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec ESP message integrity check. As a result, the TCP checksum will be invalidated by a NAT located between the two endpoints.
ESP自体がメッセージの整合性チェックにIPヘッダーフィールドを含まない場合でも、トランスポートモードESP内で伝送されるTCPはNATを通過できません。これは、16ビットTCPチェックサムがIPヘッダーフィールドを含む「疑似ヘッダー」に基づいて計算され、チェックサムがIPsec ESPメッセージの整合性チェックによって保護されるためです。その結果、2つのエンドポイントの間にあるNATによってTCPチェックサムが無効になります。
Since TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, it is not possible to omit checksum verification while remaining standards compliant. In order to enable traversal of NATs existing while remaining in compliance, iSCSI, iFCP or FCIP security implementations can implement IPsec/IKE NAT traversal, as described in [RFC3715], [UDPIPsec], and [NATIKE].
TCPチェックサムの計算と検証はIPv4とIPv6の両方で必須であるため、標準に準拠したままチェックサム検証を省略することはできません。 [RFC3715]、[UDPIPsec]、および[NATIKE]で説明されているように、コンプライアンスを維持しながら既存のNATのトラバーサルを有効にするために、iSCSI、iFCP、またはFCIPセキュリティ実装はIPsec / IKE NATトラバーサルを実装できます。
The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications enable UDP encapsulation of IPsec to be negotiated if a NAT is detected in the path. By determining the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header including the NAT-adjusted address and ports. If this is done prior to calculating the IPsec message integrity check, TCP checksum verification will not fail.
IKE [NATIKE]およびIPsec [UDPIPsec] NATトラバーサル仕様では、NATがパスで検出された場合に、IPsecのUDPカプセル化をネゴシエートできます。 NATのIPアドレスを決定することにより、NAT調整済みのアドレスとポートを含む疑似ヘッダーに基づいてTCPチェックサムを計算できます。 IPsecメッセージの整合性チェックを計算する前にこれが行われた場合、TCPチェックサム検証は失敗しません。
There are situations where it is necessary for IKE to be implemented in firmware. In such situations, it is important to keep the size of the IKE implementation within strict limits. An upper bound on the size of an IKE implementation might be considered to be 800 KB, with 80 KB enabling implementation in a wide range of situations.
IKEをファームウェアに実装する必要がある状況があります。このような状況では、IKE実装のサイズを厳格な制限内に保つことが重要です。 IKE実装のサイズの上限は800 KBと見なされ、80 KBは幅広い状況での実装を可能にします。
As noted in Table 5.3-1 on the next page, IKE implementations currently exist which meet the requirements. Therefore, while removal of seldom used IKE functionality (such as the nonce authentication methods) would reduce complexity, implementations typically will not require this in order to fit within the code size budget.
次のページの表5.3-1に示すように、現在、要件を満たすIKE実装が存在します。したがって、めったに使用されないIKE機能（ノンス認証方式など）を削除すると複雑さが軽減されますが、実装では通常、コードサイズの予算内に収めるためにこれを必要としません。
It is expected that IP block storage implementations will need to operate at high speed. For example, implementations operating at 1 Gbps are currently in design, with 10 Gbps implementations to follow shortly thereafter. At these speeds, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space.
IPブロックストレージの実装は高速で動作する必要があることが予想されます。たとえば、現在1 Gbpsで動作する実装が設計されており、その後すぐに10 Gbpsの実装が続く予定です。これらの速度では、単一のIPsec SAが32ビットIPsecシーケンス番号スペースをすばやく循環できます。
For example, a single SA operating at 1 Gbps line rate and sending 64 octet packets would exhaust the 32-bit sequence number space in 2200 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur in 14.5 hours. At 10 Gbps, exhaustion would occur in 220 seconds or 3.67 minutes. With 1518 octet packets, this would occur within 1.45 hours.
たとえば、1 Gbpsのラインレートで動作し、64オクテットパケットを送信する単一のSAは、32ビットのシーケンス番号スペースを2200秒、つまり37分で使い果たします。 1518オクテットパケットの場合、枯渇は14.5時間で発生します。 10 Gbpsでは、220秒または3.67分で消耗が発生します。 1518オクテットパケットの場合、これは1.45時間以内に発生します。
In the future, it may be desirable for implementations operating at speeds of 1 Gbps or greater to implement IPsec sequence number extension, described in [Seq]. Note that depending on the transform in use, it is possible that rekeying will be required prior to exhaustion of the sequence number space.
将来、[Seq]で説明されているように、1 Gbps以上の速度で動作する実装がIPsecシーケンス番号拡張を実装することが望ましい場合があります。使用している変換によっては、シーケンス番号スペースがなくなる前に鍵の再生成が必要になる場合があることに注意してください。
In CBC-mode ciphers the ciphertext of one block depends on the plaintext of that block as well as the ciphertext of the previous block. This implies that if the ciphertext of two blocks are identical, and the plaintext of the next block is also identical, then the ciphertext of the next block will be identical. Thus, if identical ciphertext blocks can be found with matching subsequent blocks, an attacker can determine the existence of matching plaintext.
CBCモードの暗号では、1つのブロックの暗号文は、そのブロックの平文と前のブロックの暗号文に依存します。これは、2つのブロックの暗号文が同一で、次のブロックの平文も同一である場合、次のブロックの暗号文も同一であることを意味します。したがって、後続のブロックが一致する同じ暗号文ブロックが見つかった場合、攻撃者は一致する平文の存在を判断できます。
Such "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. On average, a ciphertext block of size n bits will be expected to repeat every 2^[n/2] blocks. Although a single "birthday attack" does not provide much information to an attacker, multiple such attacks might provide useful information. To make this unlikely, it is recommended that a rekey occur before 2^[n/2] blocks have been sent on a given SA. Bellare et. al. have formalized this in [DESANALY], showing that the insecurity of CBC mode increases as O(s^2/2^n), where n is the block size in bits, and s is the total number of blocks encrypted. These conclusions do not apply to counter mode.
このような「誕生日の攻撃」は、Bellareらによって検討されました。 al。 [DESANALY]。平均して、サイズnビットの暗号文ブロックは、2 ^ [n / 2]ブロックごとに繰り返されると予想されます。単一の「誕生日の攻撃」は攻撃者に多くの情報を提供しませんが、そのような複数の攻撃は有用な情報を提供する可能性があります。これを起こりにくくするために、所定のSAで2 ^ [n / 2]ブロックが送信される前にキーの再生成を行うことをお勧めします。ベラレ他al。これを[DESANALY]で形式化し、CBCモードの安全性がO（s ^ 2/2 ^ n）として増加することを示しています。ここで、nはビット単位のブロックサイズ、sは暗号化されたブロックの総数です。これらの結論は、カウンターモードには適用されません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code size | |
|Implementation | (octets) | Release |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Linux |
| Pluto | 258KB | FreeSWAN |
|(FreeSWAN) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Racoon | 400KB | NetBSD 1.5 |
| (KAME) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Isakmpd | 283KB | NetBSD 1.5 |
| (Erickson) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| WindRiver | 142KB | PowerPC |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 222KB | PowerPC |
| VPN1700 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 350K | PowerPC |
| VPN3000 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 228KB | MIPS |
| VPN7200 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 5.3-1 - Code Size for IKE implementations
表5.3-1-IKE実装のコードサイズ
The formula below sets a limit on the bytes that can be sent on a CBC SA before a rekey is required:
以下の式は、キーの再生成が必要になる前にCBC SAで送信できるバイト数に制限を設定します。
B = (n/8) * 2^[n/2]
Where:
B = maximum bytes sent on the SA
n = block size in bits
This means that cipher block size as well as key length needs to be considered in the rekey decision. 3DES uses a block size n = 64 bits (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey is required every 27.5 seconds.
つまり、鍵の再決定では、暗号ブロックサイズと鍵の長さを考慮する必要があります。 3DESは、ブロックサイズn = 64ビット（2 ^ 3バイト）を使用します。これは、B =（64/8）*（2 ^ 32）= 2 ^ 35バイトが送信される前にSAの鍵を再設定する必要があることを意味します。 1 Gbpsでは、これは、274.9秒（4.6分）ごとに鍵の再生成が必要になることを意味します。 10 Gbpsでは、27.5秒ごとに鍵の再生成が必要です。
In terms of the sequence number space, for a 3DES encrypted message of 512 = 2^9 bytes (2^6 blocks) this implies that the key has become insecure after about 2^26 messages.
シーケンス番号スペースに関しては、512 = 2 ^ 9バイト（2 ^ 6ブロック）の3DES暗号化メッセージの場合、これは、約2 ^ 26メッセージの後で鍵が安全でなくなったことを意味します。
Since IP block storage implementations may operate at speeds of 1 Gbps or greater, the ability to offer IPsec security services at high speeds is of intense concern. Since support for multiple algorithms multiplies the complexity and expense of hardware design, one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms implementable in hardware at speeds of up to 10 Gbps, as well as being efficient for implementation in software at speeds of 100 Mbps or slower.
IPブロックストレージの実装は1 Gbps以上の速度で動作する可能性があるため、高速でIPsecセキュリティサービスを提供する機能には大きな懸念があります。複数のアルゴリズムのサポートはハードウェア設計の複雑さと費用を増大させるため、変換選択の取り組みの目標の1つは、最大10 Gbpsの速度でハードウェアに実装可能な最小セットの機密性アルゴリズムと認証アルゴリズムを見つけ、効率的であることです。 100 Mbps以下の速度でソフトウェアに実装する場合。
In this specification, we primarily concern ourselves with IPsec transforms that have already been specified, and for which parts are available that can run at 1 Gbps line rate. Where existing algorithms do not gracefully scale to 10 Gbps, we further consider algorithms for which transform specifications are not yet complete, but for which parts are expected to be available for inclusion in products shipping within the next 12 months. As the state of the art advances, the range of feasible algorithms will broaden and additional mandatory-to-implement algorithms may be considered.
この仕様では、主に、すでに指定されているIPsecトランスフォームに関心があり、1 Gbpsのラインレートで実行できるパーツが利用可能です。既存のアルゴリズムが10 Gbpsに適切に拡張されない場合は、変換仕様がまだ完全ではないが、今後12か月以内に出荷される製品に含めることができるパーツが見込まれるアルゴリズムをさらに検討します。最先端の技術が進歩するにつれて、実現可能なアルゴリズムの範囲が広がり、追加の必須から実装までのアルゴリズムが検討される可能性があります。
Section 5 of [RFC2406] states:
[RFC2406]のセクション5には次のように記載されています。
"A compliant ESP implementation MUST support the following mandatory-to-implement algorithms:
「準拠したESP実装は、次の実装必須アルゴリズムをサポートする必要があります。
- DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 - NULL Authentication algorithm - NULL Encryption algorithm"
- CBCモードのDES-MD5を使用したHMAC-SHA-1を使用したHMAC-NULL認証アルゴリズム-NULL暗号化アルゴリズム
The DES algorithm is specified in [FIPS46-3]; implementation guidelines are found in [FIPS74], and security issues are discussed in [DESDIFF],[DESINT], [DESCRACK]. The DES IPsec transform is defined in [RFC2405] and the 3DES in CBC mode IPsec transform is specified in [RFC2451].
DESアルゴリズムは[FIPS46-3]で指定されています。実装ガイドラインは[FIPS74]にあり、セキュリティの問題は[DESDIFF]、[DESINT]、[DESCRACK]で説明されています。 DES IPsecトランスフォームは[RFC2405]で定義されており、CBCモードの3DESのIPsecトランスフォームは[RFC2451]で指定されています。
The MD5 algorithm is specified in [RFC1321]; HMAC is defined in [RFC2104] and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 IPsec transform is specified in [RFC2403]. The HMAC-SHA1 IPsec transform is specified in [RFC2404].
MD5アルゴリズムは[RFC1321]で指定されています; HMACは[RFC2104]で定義されており、MD5のセキュリティ問題は[MD5Attack]で議論されています。 HMAC-MD5 IPsecトランスフォームは[RFC2403]で指定されています。 HMAC-SHA1 IPsecトランスフォームは[RFC2404]で指定されています。
In addition to these existing algorithms, NIST is currently evaluating the following modes [NSPUE2] of AES, defined in [FIPS197]:
これらの既存のアルゴリズムに加えて、NISTは現在、[FIPS197]で定義されているAESの次のモード[NSPUE2]を評価しています。
AES in Electronic Codebook (ECB) confidentiality mode AES in Cipher Block Chaining (CBC) confidentiality mode AES in Cipher Feedback (CFB) confidentiality mode AES in Output Feedback (OFB) confidentiality mode AES in Counter (CTR) confidentiality mode AES CBC-MAC authentication mode
電子コードブック（ECB）機密モードのAES暗号ブロックチェーン（CBC）機密モードのAES暗号フィードバック（CFB）機密モードのAES出力フィードバック（OFB）機密モードのAESカウンター（CTR）機密モードのAES AES CBC-MAC認証モード
When utilizing AES modes, it may be necessary to use larger public keys; the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526].
AESモードを使用する場合、より大きな公開鍵を使用する必要がある場合があります。トレードオフは[KeyLen]で説明されています。 IKEで使用するための追加のMODP Diffie-Hellmanグループについては、[RFC3526]で説明されています。
The Modes [NSPUE2] effort is also considering a number of additional algorithms, including the following:
モード[NSPUE2]の取り組みでは、以下を含む多数の追加アルゴリズムも検討されています。
PMAC
PMAC
To provide authentication, integrity and replay protection, IP block storage security implementations MUST support HMAC-SHA1 [RFC2404] for authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be supported [RFC3566].
認証、整合性、再生保護を提供するために、IPブロックストレージセキュリティ実装は、認証用にHMAC-SHA1 [RFC2404]をサポートする必要があり、XCBC拡張を使用したCBC MACモードのAESをサポートする必要があります[RFC3566]。
HMAC-SHA1 [RFC2404] is to be preferred to HMAC-MD5, due to concerns that have been raised about the security of MD5 [MD5Attack]. HMAC-SHA1 parts are currently available that run at 1 Gbps, the algorithm is implementable in hardware at speeds up to 10 Gbps, and an IPsec transform specification [RFC2404] exists. As a result, it is most practical to utilize HMAC-SHA1 as the authentication algorithm for products shipping in the near future. AES in CBC-MAC authentication mode with XCBC extensions was selected since it avoids adding substantial additional code if AES is already being implemented for encryption; an IPsec transform document is available [RFC3566].
HMAC-SHA1 [RFC2404]は、MD5 [MD5Attack]のセキュリティについて提起されている懸念のため、HMAC-MD5よりも優先されます。現在1 Gbpsで動作するHMAC-SHA1パーツが利用可能で、アルゴリズムは最大10 Gbpsの速度でハードウェアに実装可能であり、IPsec変換仕様[RFC2404]が存在します。その結果、近い将来出荷される製品の認証アルゴリズムとしてHMAC-SHA1を利用することが最も現実的です。 XCBC拡張を使用したCBC-MAC認証モードのAESが選択されました。これは、暗号化のためにAESがすでに実装されている場合に、実質的な追加コードを追加する必要がないためです。 IPsec変換ドキュメントが利用可能です[RFC3566]。
Authentication transforms also exist that are considerably more efficient to implement than HMAC-SHA1, or AES in CBC-MAC authentication mode. UMAC [UMAC],[UMACKR] is more efficient to implement in software and PMAC [PMAC] is more efficient to implement in hardware. PMAC is currently being evaluated as part of the NIST modes effort [NSPUE2] but an IPsec transform does not yet exist; neither does a UMAC transform.
HBC-SHA1、またはCBC-MAC認証モードのAESよりも実装がかなり効率的な認証変換も存在します。 UMAC [UMAC]、[UMACKR]はソフトウェアで実装する方が効率的であり、PMAC [PMAC]はハードウェアで実装する方が効率的です。 PMACは現在、NISTモードの取り組み[NSPUE2]の一部として評価されていますが、IPsecトランスフォームはまだ存在しません。 UMAC変換も行いません。
For confidentiality, the ESP mandatory-to-implement algorithm (DES) is unacceptable. As noted in [DESCRACK], DES is crackable with modest computation resources, and so is inappropriate for use in situations requiring high levels of security.
機密性のために、ESP必須実装アルゴリズム（DES）は受け入れられません。 [DESCRACK]で述べたように、DESは適度な計算リソースでクラック可能であるため、高レベルのセキュリティが必要な状況での使用には不適切です。
To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC mode [RFC2451] MUST be supported and AES in Counter Mode [RFC3686] SHOULD be supported. For use in high speed implementations, 3DES has significant disadvantages. However, a 3DES IPsec transform has been specified and parts are available that can run at 1 Gbps, so implementing 3DES in products is practical for the short term.
iSCSI、iFCP、およびFCIPに機密性を提供するには、CBCモードの[3DES] [RFC2451]をサポートする必要があり、カウンターモードの[AES] [RFC3686]をサポートする必要があります（SHOULD）。高速実装で使用する場合、3DESには重大な欠点があります。ただし、3DES IPsecトランスフォームが指定されており、1 Gbpsで実行できるパーツが利用可能であるため、製品に3DESを実装することは短期的には実用的です。
As described in Appendix B, 3DES software implementations make excessive computational demands at speeds of 100 Mbps or greater, effectively ruling out software-only implementations. In addition, 3DES implementations require rekeying prior to exhaustion of the current 32-bit IPsec sequence number space, and thus would not be able to make use of sequence space extensions if they were available. This means that 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. Thus, 3DES is inconvenient for use at very high speeds, as well as being impractical for implementation in software at slower speeds (100+ Mbps).
付録Bで説明されているように、3DESソフトウェア実装は、100 Mbps以上の速度で過剰な計算を要求し、ソフトウェアのみの実装を事実上排除します。さらに、3DESの実装では、現在の32ビットIPsecシーケンス番号スペースが使い果たされる前にキーの再生成が必要になるため、シーケンススペース拡張が利用可能である場合、それを利用できません。つまり、3DESでは10 Gbps以上の速度で非常に頻繁な鍵の再生成が必要になります。したがって、3DESは非常に高速での使用には不便であり、ソフトウェアでの低速（100+ Mbps）での実装には実用的ではありません。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size or size of other certificate fields (such as the distinguished name and other OIDs) is large enough. Many Network Address Translators (NATs) and firewalls do not handle fragments properly, dropping them on inbound and/or outbound.
証明書認証を使用すると、IKEフラグメンテーションが発生する可能性があります。これは、証明書チェーンが使用されている場合、または他の証明書フィールド（識別名や他のOIDなど）のキーサイズまたはサイズが十分に大きい場合に単一の証明書を交換する場合でも発生する可能性があります。多くのNetwork Address Translator（NAT）とファイアウォールはフラグメントを適切に処理せず、インバウンドまたはアウトバウンド（あるいはその両方）にドロップします。
Routers in the path will also frequently discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an Access List.
また、パス内のルーターは、最初のフラグメントの後でフラグメントを頻繁に破棄します。これは、ルーターには通常、アクセスリストと比較できる完全なIPヘッダーが含まれていないためです。
As a result, where IKE fragmentation occurs, the endpoints will often be unable to establish an IPsec security association. The solution to this problem is to install NAT, firewall or router code load that can properly support fragments. If this cannot be done, then the following alternatives can be considered:
その結果、IKEフラグメンテーションが発生すると、エンドポイントはIPsecセキュリティアソシエーションを確立できなくなります。この問題の解決策は、フラグメントを適切にサポートできるNAT、ファイアウォール、またはルーターのコードロードをインストールすることです。これを実行できない場合は、次の代替策を検討できます。
[1] Obtaining certificates by other means.
[1] 他の方法で証明書を取得する。
[2] Reducing the size of the certificate chain.
[2] 証明書チェーンのサイズを縮小します。
[3] Reducing the size of fields within the certificates. This includes reduction in the key size, the distinguished name or other fields. This should be considered only as a last resort.
[3] 証明書内のフィールドのサイズを小さくする。これには、キーサイズ、識別名、またはその他のフィールドの縮小が含まれます。これは最後の手段としてのみ考慮されるべきです。
Fragmentation can become a concern when prepending IPsec headers to a frame. One mechanism that can be used to reduce this problem is to utilize path MTU discovery. For example, when TCP is used as the transport for iSCSI, iFCP or FCIP then path MTU discovery, described in [RFC1191], [RFC1435], [RFC1981], can be used to enable the TCP endpoints to discover the correct MTU, including effects due to IPsec encapsulation.
IPsecヘッダーをフレームの先頭に追加するときに、フラグメンテーションが問題になる可能性があります。この問題を軽減するために使用できるメカニズムの1つは、パスMTUディスカバリーを利用することです。たとえば、TCPがiSCSI、iFCP、またはFCIPのトランスポートとして使用される場合、[RFC1191]、[RFC1435]、[RFC1981]で説明されているパスMTU検出を使用して、TCPエンドポイントが正しいMTUを検出できるようにすることができます。 IPsecカプセル化による影響。
However, Path MTU discovery fails when appropriate ICMP messages are not received by the host. This occurs in IPsec implementations that drop unauthenticated ICMP packets. This can result in blackholing in naive TCP implementations, as described in [RFC2923]. Appropriate TCP behavior is described in section 2.1 of [RFC2923]:
ただし、適切なICMPメッセージがホストによって受信されない場合、パスMTU検出は失敗します。これは、認証されていないICMPパケットをドロップするIPsec実装で発生します。これは、[RFC2923]で説明されているように、単純なTCP実装でブラックホール化を引き起こす可能性があります。適切なTCPの動作は、[RFC2923]のセクション2.1で説明されています。
"TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed."
「TCPは接続がタイムアウトしていることを認識する必要があります。数回のタイムアウトの後、TCPは小さいパケットの送信を試み、おそらく各パケットのDFフラグをオフにする必要があります。これが成功した場合、妥当な接続のPMTUDをオフにし続けます。その後、再度プローブして、パスが変更されたかどうかを判別する必要があります。」
If an ICMP PMTU is received by an IPsec implementation that processes unauthenticated ICMP packets, this value should be stored in the SA as proposed in [RFC2401], and IPsec should also provide notification of this event to TCP so that the new MTU value can be correctly reflected.
認証されていないICMPパケットを処理するIPsec実装がICMP PMTUを受信した場合、この値は[RFC2401]で提案されているようにSAに保存する必要があり、IPsecはこのイベントの通知をTCPに提供して、新しいMTU値を正しく反映されます。
When a connection is opened which requires security, IP block storage security implementations may wish to check that the connection is protected by IPsec. If security is desired and IPsec protection is removed on a connection, it is reinstated before non-protected IP block storage packets are sent. Since IPsec verifies that each packet arrives on the correct SA, as long as it can be ensured that IPsec protection is in place, then IP block storage implementations can be assured that each received packet was sent by a trusted peer.
セキュリティを必要とする接続が開かれると、IPブロックストレージのセキュリティ実装は、接続がIPsecによって保護されていることを確認したい場合があります。セキュリティが必要であり、接続でIPsec保護が削除された場合、保護されていないIPブロックストレージパケットが送信される前に復元されます。 IPsecは、各パケットが正しいSAに到着することを確認するので、IPsec保護が確実に行われている限り、IPブロックストレージの実装は、受信した各パケットが信頼できるピアによって送信されたことを保証できます。
When used with IP block storage protocols, each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. IP block storage security implementations need not verify that the IP addresses and TCP port values in the packet match the socket information that was used to setup the connection. This check will be performed by IPsec, preventing malicious peers from sending commands on inappropriate Quick Mode SAs.
IPブロックストレージプロトコルで使用する場合、各TCP接続はIKEフェーズ2 SAで保護する必要があります。 1つまたは複数のTCP接続からのトラフィックは、各IPsecフェーズ2 SA内を流れる可能性があります。 IPブロックストレージセキュリティの実装では、パケットのIPアドレスとTCPポート値が、接続のセットアップに使用されたソケット情報と一致することを確認する必要はありません。このチェックはIPsecによって実行され、悪意のあるピアが不適切なクイックモードSAでコマンドを送信するのを防ぎます。
The certificate credentials provided by the iSCSI initiator during the IKE negotiation may be those of the machine or of the iSCSI entity. When machine authentication is used, the machine certificate is typically stored on the iSCSI initiator and target during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard. For iFCP and FCIP, the certificate credentials provided will almost always be those of the device and will be stored on the device.
IKEネゴシエーション中にiSCSIイニシエーターによって提供される証明書の資格情報は、マシンまたはiSCSIエンティティの資格情報である場合があります。マシン認証を使用する場合、マシン証明書は通常、登録プロセス中にiSCSIイニシエーターとターゲットに保存されます。ユーザー証明書を使用する場合、ユーザー証明書はマシンまたはスマートカードに保存できます。 iFCPおよびFCIPの場合、提供される証明書の資格情報はほとんどの場合デバイスの資格情報であり、デバイスに保存されます。
Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate.
マシン証明書の値は、攻撃者が偽装したときに取得できる容易さに反比例するため、マシン証明書の登録プロセスを厳密に制御することをお勧めします。たとえば、マシン証明書を使用してマシンを登録できるのは、管理者のみです。
While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided within iSCSI login (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. Since iFCP and FCIP have no equivalent of iSCSI Login, for these protocols only the machine is authenticated.
スマートカード証明書の保存により、秘密鍵が危険にさらされる可能性は低くなりますが、スマートカードは必ずしもすべての状況で望ましいとは限りません。たとえば、マシン証明書を展開している一部の組織は、承認されていないハードウェアの使用を制限するためにそれらを使用します。ユーザー認証はiSCSIログイン内で提供できるため（前述の弱点に留意）、IPsecでのマシン認証のサポートにより、マシンとユーザーの両方を認証することが可能になります。 iFCPとFCIPにはiSCSIログインに相当するものがないため、これらのプロトコルではマシンのみが認証されます。
In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable.
この二重の保証が重要であると考えられる状況では、マシン証明書がスマートカードに格納されている場合に可能であるように、マシン証明書をあるマシンから別のマシンに移動できるようにすることは望ましくない場合があります。
Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired.
同様に、ユーザー証明書を展開する場合は、ユーザー登録プロセスを厳密に制御することをお勧めします。たとえば、ユーザーのパスワードを使用して証明書（一時的または長期の証明書）を簡単に取得できる場合、その証明書のセキュリティ値はパスワードと同じです。攻撃者が盗んだパスワードからユーザー証明書を取得する能力を制限するために、登録期間を制限できます。その後、パスワードアクセスがオフになります。このようなポリシーにより、未使用のアカウントのパスワードを取得する攻撃者が、登録期間が終了するとユーザー証明書を取得できなくなります。
Use of pre-shared keys in IKE Main Mode is vulnerable to man-in-the-middle attacks when used with dynamically addressed hosts (such as with iSCSI initiators). In Main Mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, where dynamic IP address assignment is typical, it is often not possible to identify the required pre-shared key based on the IP address.
IKEメインモードで事前共有キーを使用すると、動的にアドレス指定されたホスト（iSCSIイニシエーターなど）で使用した場合、中間者攻撃に対して脆弱になります。メインモードでは、識別ペイロードを受信する前にSKEYID_eを使用する必要があります。したがって、事前共有キーの選択は、IPヘッダーに含まれている情報にのみ基づく場合があります。ただし、動的なIPアドレスの割り当てが一般的である場合、IPアドレスに基づいて必要な事前共有キーを特定できないことがよくあります。
Thus when pre-shared key authentication is used in Main Mode along with entities whose address is dynamically assigned, the same pre-shared key is shared by a group and is no longer able to function as an effective shared secret. In this situation, neither the initiator nor Responder identifies itself during IKE Phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle. This vulnerability is typically not of concern where IP addresses are typically statically assigned (such as with iFCP and FCIP), since in this situation individual pre-shared keys are possible within IKE Main Mode.
したがって、アドレスが動的に割り当てられるエンティティと共にメインモードで事前共有キー認証を使用すると、同じ事前共有キーがグループによって共有され、有効な共有シークレットとして機能できなくなります。この状況では、イニシエーターもレスポンダーもIKEフェーズ1中に自分自身を識別しません。両方の当事者が事前共有鍵の知識を持つグループのメンバーであることのみがわかっています。これにより、グループの事前共有キーにアクセスできるすべての人が中間者として機能できます。この脆弱性は通常、IPアドレスが静的に割り当てられている場合（iFCPやFCIPなど）には関係ありません。この状況では、IKEメインモード内で個別の事前共有キーが可能になるためです。
However, where IP addresses are dynamically assigned and Main Mode is used along with pre-shared keys, the Responder is not authenticated unless application-layer mutual authentication is performed (e.g., iSCSI login authentication). This enables an attacker in possession of the group pre-shared key to masquerade as the Responder. In addition to enabling the attacker to present false data, the attacker would also be able to mount a dictionary attack on legacy authentication methods such as CHAP [RFC1994], potentially compromising many passwords at a time. This vulnerability is widely present in existing IPsec implementations.
ただし、IPアドレスが動的に割り当てられ、メインモードが事前共有キーと共に使用される場合、アプリケーションレイヤーの相互認証（iSCSIログイン認証など）が実行されない限り、レスポンダーは認証されません。これにより、グループの事前共有鍵を所持している攻撃者は、レスポンダーになりすますことができます。攻撃者が偽のデータを提示できるようにすることに加えて、攻撃者はCHAP [RFC1994]などのレガシー認証方式に辞書攻撃を仕掛け、一度に多くのパスワードを危険にさらす可能性があります。この脆弱性は、既存のIPsec実装に広く存在しています。
Group pre-shared keys are not required in Aggressive Mode since the identity payload is sent earlier in the exchange, and therefore the pre-shared key can be selected based on the identity. However, when Aggressive Mode is used the user identity is exposed and this is often considered undesirable.
IDペイロードは交換の早い段階で送信されるため、アグレッシブモードではグループ事前共有キーは必要ありません。したがって、事前共有キーはIDに基づいて選択できます。ただし、アグレッシブモードを使用すると、ユーザーIDが公開されるため、これは望ましくないと見なされることがよくあります。
Note that care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned.
アグレッシブモードでも事前共有キーへのIDのマッピングを有効にするには、IKEフェーズ1のIDペイロードの選択に注意する必要があることに注意してください。 ID_IPV4_ADDRまたはID_IPV6_ADDRのIDペイロードが使用され、アドレスが動的に割り当てられる場合、IDをキーにマッピングすることはできないため、グループの事前共有キーは依然として実際に必要です。その結果、ID_IPV4_ADDRおよびID_IPV6_ADDR以外のID（ID_FQDNやID_USER_FQDNなど）は、事前共有キーとアグレッシブモードが使用され、IPアドレスが動的に割り当てられる状況で使用する必要があります。
In addition to IKE authentication, iSCSI implementations utilize their own authentication methods. Currently, work is underway on Fibre Channel security, so that a similar authentication process may eventually also apply to iFCP and FCIP as well.
IKE認証に加えて、iSCSI実装は独自の認証方法を利用します。現在、ファイバーチャネルのセキュリティに関する作業が進行中のため、最終的に同様の認証プロセスがiFCPおよびFCIPにも適用される可能性があります。
While iSCSI provides initial authentication, it does not provide per-packet authentication, integrity or replay protection. This implies that the identity verified in the iSCSI Login is not subsequently verified on reception of each packet.
iSCSIは初期認証を提供しますが、パケットごとの認証、整合性、またはリプレイ保護は提供しません。これは、iSCSIログインで検証されたIDが、その後各パケットの受信時に検証されないことを意味します。
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet.
IPsecでは、IKEでアサートされたIDが認証されると、結果の派生キーを使用して、パケットごとの認証、整合性、およびリプレイ保護が提供されます。その結果、IKE会話で検証されたIDは、各パケットの受信時に検証されます。
Let us assume that the identity claimed in iSCSI Login is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way for the recipient to verify that only the user authenticated via iSCSI Login is using the IPsec SA.
iSCSIログインで要求されたIDがユーザーIDであるのに対し、IKE内で要求されたIDはマシンIDであると仮定します。マシンIDのみがパケットごとに検証されるため、iSCSIログインで認証されたユーザーだけがIPsec SAを使用していることを受信者が検証する方法はありません。
In fact, IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once an IPsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. This is true for both transport mode and tunnel mode SAs.
実際、マシン認証のみをサポートするIPsec実装には、通常、カーネル内のユーザートラフィックを区別する方法がありません。その結果、マシン認証が使用される場合、IPsec SAが開かれると、マルチユーザーマシンの別のユーザーがIPsec SAにトラフィックを送信できる可能性があります。これは、トランスポートモードとトンネルモードのSAの両方に当てはまります。
To limit the potential vulnerability, IP block storage implementations MUST do the following:
潜在的な脆弱性を制限するために、IPブロックストレージの実装は以下を実行する必要があります。
[1] Ensure that socket access is appropriately controlled. On a multi-user operating system, this implies that sockets opened for use by IP block storage protocols MUST be exclusive.
[1] ソケットアクセスが適切に制御されていることを確認します。これは、マルチユーザーオペレーティングシステムでは、IPブロックストレージプロトコルで使用するために開かれたソケットは排他的でなければならないことを意味します。
[2] In the case of iSCSI, implementations MUST also ensure that application layer login credentials (such as iSCSI login credentials) are protected from unauthorized access.
[2] iSCSIの場合、実装では、アプリケーション層のログイン資格情報（iSCSIログイン資格情報など）が不正アクセスから確実に保護されるようにする必要もあります。
If these directives are followed, then a rogue process will not be able to access an IP block storage volume.
これらのディレクティブに従うと、不正なプロセスはIPブロックストレージボリュームにアクセスできなくなります。
While the identity asserted within IKE is verified on a per-packet basis, to avoid interference between users on a given machine, operating system support is required. In order to segregate traffic between users when user authentication is supported, the IPsec endpoints must ensure that only traffic from that particular user is sent or received within the IPsec SA. Enforcement of this restriction is the responsibility of the operating system.
IKE内でアサートされたIDはパケットごとに検証されますが、特定のマシン上のユーザー間の干渉を回避するには、オペレーティングシステムのサポートが必要です。ユーザー認証がサポートされているときにユーザー間のトラフィックを分離するために、IPsecエンドポイントは、特定のユーザーからのトラフィックのみがIPsec SA内で送受信されるようにする必要があります。この制限の実施は、オペレーティングシステムの責任です。
In kernel mode iSCSI drivers there typically is no user context to perform user authentication. In this case the authentication is closer to machine authentication. In most operating systems device permissions would control the ability to read/write to the device prior to mounting. Once the device is mounted, ACLs set by the filesystem control access to the device. An administrator can access the blocks on the device directly (for instance, by sending pass through requests to the port driver directly such as in Windows NT). In the same way, an administrator can open a raw socket and send IPsec protected packets to an iSCSI target. The situation is analogous, and in this respect no new vulnerability is created that didn't previously exist. The Operating system's ACLs need to be effective to protect a device (whether it is a SCSI device or an iSCSI device).
カーネルモードのiSCSIドライバーでは、通常、ユーザー認証を実行するためのユーザーコンテキストはありません。この場合、認証はマシン認証に近くなります。ほとんどのオペレーティングシステムでは、デバイスのアクセス許可によって、マウント前のデバイスの読み取り/書き込み機能が制御されます。デバイスがマウントされると、ファイルシステムによって設定されたACLがデバイスへのアクセスを制御します。管理者は、デバイス上のブロックに直接アクセスできます（たとえば、Windows NTのように、パススルー要求をポートドライバーに直接送信することにより）。同様に、管理者はrawソケットを開き、IPsecで保護されたパケットをiSCSIターゲットに送信できます。状況は類似しており、この点で、以前は存在しなかった新しい脆弱性は作成されません。オペレーティングシステムのACLは、デバイス（SCSIデバイスまたはiSCSIデバイス）を保護するために効果的である必要があります。
IP block storage protocols can use a variety of mechanisms for authorization. Where ID_FQDN is used as the Identity Payload, IP block storage endpoints can be configured with a list of authorized FQDNs. The configuration can occur manually, or automatically via iSNS or the iSCSI MIB, defined in [AuthMIB].
IPブロックストレージプロトコルは、認証にさまざまなメカニズムを使用できます。 ID_FQDNがIDペイロードとして使用される場合、IPブロックストレージエンドポイントは、承認されたFQDNのリストで構成できます。設定は手動で行うことも、[AuthMIB]で定義されたiSNSまたはiSCSI MIBを介して自動的に行うこともできます。
Assuming that IPsec authentication is successful, this list of FQDNs can be examined to determine authorization levels. Where certificate authentication is used, it is possible to configure IP block storage protocol endpoints with trusted roots. The trusted roots used with IP block storage protocols might be different from the trusted roots used for other purposes. If this is the case, then the burden of negotiating use of the proper certificates lies with the IPsec initiator.
IPsec認証が成功した場合、このFQDNのリストを調べて、承認レベルを決定できます。証明書認証を使用する場合、信頼されたルートを持つIPブロックストレージプロトコルエンドポイントを構成することが可能です。 IPブロックストレージプロトコルで使用される信頼されたルートは、他の目的で使用される信頼されたルートとは異なる場合があります。この場合、適切な証明書の使用をネゴシエートする負担は、IPsecイニシエーターにあります。
Note that because IKE does not deal well with certificate chains, and is typically configured with a limited set of trusted roots, it is most appropriate for intra-domain usage.
IKEは証明書チェーンを適切に処理せず、通常は限られた信頼されたルートのセットで構成されているため、ドメイン内での使用に最適です。
Since iSCSI supports Login authentication, it is also possible to use the identities presented within the iSCSI Login for authorization purposes.
iSCSIはログイン認証をサポートしているため、iSCSIログイン内で提示されたIDを承認目的で使用することもできます。
In iFCP, basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains in iSNS yields access control schemas of greater complexity.
iFCPでは、基本的なアクセス制御プロパティは、2つの通信iFCPゲートウェイが1つ以上のiSNSサーバーに知られてからiFCP交換を行うことができるという要件に基づいています。オプションでiSNSの検出ドメインを使用すると、より複雑なアクセス制御スキーマが生成されます。
When utilizing AES modes, it may be necessary to use larger public keys; the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526].
AESモードを使用する場合、より大きな公開鍵を使用する必要がある場合があります。トレードオフは[KeyLen]で説明されています。 IKEで使用するための追加のMODP Diffie-Hellmanグループについては、[RFC3526]で説明されています。
When AES in counter mode is used, it is important to avoid reuse of the counter with the same key, even across all time. Counter mode creates ciphertext by XORing generated key stream with plaintext. It is fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing together the two packets. The implication of this is that it is an error to use IPsec manual keying with counter mode, except when the implementation takes heroic measures to maintain state across sessions. In any case, manual keying MUST NOT be used since it does not provide the necessary rekeying support.
カウンターモードのAESを使用する場合は、常に同じキーでカウンターを再利用しないようにすることが重要です。カウンターモードは、生成されたキーストリームをプレーンテキストでXORすることにより暗号文を作成します。 2つのパケットをXORするだけで、同じカウンター値で暗号化された2つのメッセージカウンターモードからプレーンテキストを復元するのはかなり簡単です。これが意味することは、実装がセッション間で状態を維持するために英雄的な措置をとる場合を除いて、カウンターモードでIPsec手動キーイングを使用することはエラーであることです。いずれの場合も、必要な再キーイングサポートを提供しないため、手動キーイングを使用してはなりません。
Another counter mode issue is it makes forgery of correct packets trivial. Counter mode should therefore never be used without also using data authentication.
もう1つのカウンターモードの問題は、正しいパケットの偽造を簡単にすることです。したがって、データ認証を使用せずにカウンタモードを使用しないでください。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values of the SRP_GROUP key parameter within iSCSI, in accordance with BCP 26, [RFC2434].
このセクションは、BCP 26、[RFC2434]に従って、iSCSI内のSRP_GROUPキーパラメータの値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。
IANA considerations for the iSCSI protocol are described in [RFC3720], Section 13; for the iFCP protocol in [iFCP], Section 12; and for the FCIP protocol in [FCIP], Appendix B.
iSCSIプロトコルに関するIANAの考慮事項は、[RFC3720]、セクション13で説明されています。 [iFCP]のiFCPプロトコルの場合、セクション12。 [FCIP]のFCIPプロトコルについては、付録B。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
以下の用語は、BCP 26で定義された意味でここで使用されています：「名前空間」、「割り当てられた値」、「登録」。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
次のポリシーは、BCP 26で定義された意味でここで使用されます：「私用」、「先着順」、「専門家によるレビュー」、「必要な仕様」、「IETFコンセンサス」、「標準アクション」。
For registration requests where a Designated Expert should be consulted, the responsible IESG Area Director should appoint the Designated Expert.
指定専門家に相談する必要がある登録要求については、担当IESGエリアディレクターが指定専門家を指名する必要があります。
For registration requests requiring Expert Review, the IPS mailing list should be consulted, or if the IPS WG is disbanded, to a mailing list designated by the IESG Area Director.
Expert Reviewを必要とする登録要求の場合、IPSメーリングリストを参照するか、IPS WGが解散されている場合は、IESG Area Directorによって指定されたメーリングリストに問い合わせる必要があります。
This document defines the following SRP_GROUP keys:
このドキュメントでは、次のSRP_GROUPキーを定義しています。
SRP-768, SRP-1024, SRP-1280, SRP-1536, SRP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192
SRP-768、SRP-1024、SRP-1280、SRP-1536、SRP-2048、MODP-3072、MODP-4096、MODP-6144、MODP-8192
New SRP_GROUP keys MUST conform to the iSCSI extension item-label format described in [RFC3720] Section 13.5.4.
新しいSRP_GROUPキーは、[RFC3720]セクション13.5.4で説明されているiSCSI拡張項目ラベル形式に準拠する必要があります。
Registration of new SRP_GROUP keys is by Designated Expert with Specification Required. The request is posted to the IPS WG mailing list or its successor for comment and security review, and MUST include a non-probabalistic proof of primality for the proposed SRP group. After a period of one month as passed, the Designated Expert will either approve or deny the registration request.
新しいSRP_GROUPキーの登録は、指定された専門家による指定が必要です。リクエストはコメントとセキュリティレビューのためにIPS WGメーリングリストまたはその後継者に投稿され、提案されたSRPグループの素数性の確率論的でない証拠を含める必要があります。 1か月が経過した後、指定エキスパートは登録要求を承認または拒否します。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed- Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]マドソン、C。およびR.グレン、「ESPおよびAH内でのHMAC-SHA-1-96の使用」、RFC 2404、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)," RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H。、「The OAKLEY鍵決定プロトコル」、RFC 2412、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。およびM. Day、「Service Location Protocol、バージョン2」、RFC 2608、1999年6月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945] Wu、T。、「SRP認証および鍵交換システム」、RFC 2945、2000年9月。
[RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz ,, B.、Lemon、T.、Perkins、C. and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3456] Patel、B.、Aboba、B.、Kelly、S。およびV. Gupta、「Dynamic Host Configuration Protocol（DHCPv4）Configuration of IPsec Tunnel Mode」、RFC 3456、2003年1月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）のためのより多くのモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use with IPsec", RFC 3566, September 2003.
[RFC3566]フランケルS.およびH.ハーバート、「AES-XCBC-MAC-96アルゴリズムとそのIPsecでの使用」、RFC 3566、2003年9月。
[RFC3643] Weber, R., Rajagopal, M., Trovostino, F., O'Donnel., M, Monia, C.and M. Mehrar, "Fibre Channel (FC) Frame Encapsuation", RFC 3643, December 2003.
[RFC3643] Weber、R.、Rajagopal、M.、Trovostino、F.、O'Donnel。、M、Monia、C。およびM. Mehrar、「Fibre Channel（FC）Frame Encapsuation」、RFC 3643、2003年12月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、Meth、K.、Sapuntzakis、C。Chadalapaka、M。およびE. Zeidner、「Internet Small Computer Systems Interface（iSCSI）」、RFC 3720、2004年4月。
[3DESANSI] American National Standard for Financial Services X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation", American Bankers Association, Washington, D.C., July 29, 1998
[3DESANSI]金融サービスの米国規格X9.52-1998、「トリプルデータ暗号化アルゴリズムの動作モード」、米国銀行協会、ワシントンD.C.、1998年7月29日
[SRPNDSS] Wu, T., "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111
[SRPNDSS] Wu、T。、「The Secure Remote Password Protocol」、Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security、カリフォルニア州サンディエゴ、pp。97-111
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[RFC2230] Atkinson、R。、「DNSのキー交換委任レコード」、RFC 2230、1997年11月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 2373、1998年7月。
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S。、アトキンソン、R。、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403]マドソン、C。およびR.グレン、「ESPおよびAH内でのHMAC-MD5-96の使用」、RFC 2403、1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C。およびN. Doraswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメインネームシステムのセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake、D。およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.
[RFC2931] Eastlake、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、2000年9月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、D。「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Simple Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3347] Krueger, M. and R. Haagens, "Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations", RFC 3347, July 2002.
[RFC3347] Krueger、M。、およびR. Haagens、「インターネット上の小型コンピュータシステムインターフェイスプロトコル（iSCSI）要件および設計上の考慮事項」、RFC 3347、2002年7月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721] Bakke、M.、Hafner、J.、Hufferd、J.、Voruganti、K。、およびM. Krueger、「Internet Small Computer Systems Interface（iSCSI）Naming and Discovery」、RFC 3721、2004年4月。
[AESPERF] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions", http://www.counterpane.com/aes-performance.html
[AESPERF] Schneier、B.、J。Kelsey、D。Whiting、D。Wagner、C。Hall、およびN. Ferguson、「AES Submissionsのパフォーマンス比較」、http：//www.counterpane.com/aes- performance.html
[AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for iSCSI", Work in Progress, September 2002.
[AuthMIB] Bakke、M。他、「iSCSIの管理対象オブジェクトの定義」、Work in Progress、2002年9月。
[CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000.
[CRCTCP] Stone J.、Partridge、C。、「CRCとTCPチェックサムが一致しない場合」、ACM Sigcomm、2000年9月。
[DESANALY] Bellare, Desai, Jokippi, Rogaway, "A Concrete
Treatment of Symmetric Encryption: Analysis of the DES
Modes of Operation", 1997, http://www-
cse.ucsd.edu/users/mihir/papers/sym-enc.html
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
[DESCRACK] Cracking DES、O'Reilly＆Associates、セバスタポル、CA 2000。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.
[DESDIFF] Biham、E.、Shamir、A.、 "Differential Cryptanalysis of DES-like cryptosystems"、Journal of Cryptology Vol 4、Jan 1991。
[DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995
[DESINT] Bellovin、S.、「強力な整合性なしで使用した場合のDES-CBCの問題」、第32回IETFの議事録、マサチューセッツ州ダンバーズ、1995年4月
[FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", Work in Progress, August 2002.
[FCIP] Rajagopal、M。、他、「TCP / IPを介したファイバーチャネル（FCIP）」、Work in Progress、2002年8月。
[FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLPv2", Work in Progress, September 2002.
[FCIPSLP] Petersen、D。、「Finding FCIP Entities Using SLPv2」、Work in Progress、2002年9月。
[FIPS46-3] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 25, 1999.
[FIPS46-3]米国DoC / NIST、「データ暗号化標準（DES）」、FIPS 46-3、1999年10月25日。
[FIPS74] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data encryption standard", FIPS 74, Apr 1981.
[FIPS74] U.S. DoC / NIST、「nbsデータ暗号化標準の実装と使用に関するガイドライン」、FIPS 74、1981年4月。
[FIPS197] U.S. DoC/NIST, "Advanced Encryption Standard (AES)",
FIPS 197, November 2001,
http://csrc.nist.gov/CryptoToolkit/aes
[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress, August 2002.
[iFCP]モニア、C。他、「iFCP-インターネットファイバーチャネルストレージネットワークのプロトコル」、進行中の作業、2002年8月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「IPsecネットワークアドレス変換（NAT）互換性要件」、RFC 3715、2004年3月。
[iSCSISLP] Bakke, M., "Finding iSCSI targets and Name Servers Using SLP", Work in Progress, March 2002.
[iSCSISLP] Bakke、M。、「Finding iSCSI Targets and Name Servers Using SLP」、Work in Progress、2002年3月。
[iSNS] Gibbons, K., et al., "iSNS Internet Storage Name Service", Work in Progress, August 2002.
[iSNS] Gibbons、K.、et al。、 "iSNS Internet Storage Name Service"、Work in Progress、2002年8月。
[KeyLen] Orman, H., Hoffman, P., "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", Work in Progress, December 2001.
[KeyLen] Orman、H.、Hoffman、P。、「対称鍵の交換に使用される公開鍵の強さの決定」、進行中の作業、2001年12月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996
[MD5Attack] Dobbertin、H.、「最近の攻撃後のMD5のステータス」、CryptoBytes Vol.2 No.2、1996年夏
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002.
[NATIKE] Kivinen、T.、et al。、 "Negotiation of NAT-Traversal in the IKE"、Work in Progress、2002年6月。
[NSPUE2] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-38A, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001.
[NSPUE2]「ブロック暗号動作モードの推奨事項」、国立標準技術研究所（NIST）特別刊行物800-38A、CODEN：NSPUE2、米国政府印刷局、ワシントンDC、2001年7月。
[PENTPERF] A. Bosselaers, "Performance of Pentium
implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[PMAC] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a
parallelizable message authentication code",
http://csrc.nist.gov/encryption/modes/proposedmodes/
pmac/pmac-spec.pdf
[Seq] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, July 2002.
[Seq]ケントS。、「IPカプセル化セキュリティペイロード（ESP）」、進行中の作業、2002年7月。
[SRPDIST] Wu, T., "SRP Distribution", http://www-cs-
students.stanford.edu/~tjw/srp/download.html
[UDPIPsec] Huttunen, A., et. al., "UDP Encapsulation of IPsec Packets", Work in Progress, June 2002.
[UDPIPsec] Huttunen、A。、他その他、「IPsecパケットのUDPカプセル化」、Work in Progress、2002年6月。
[UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T.,
Rogaway, P., "UMAC: Fast and provably secure message
authentication", Advances in Cryptology - CRYPTO '99,
LNCS vol. 1666, pp. 216-233. Full version available
from http://www.cs.ucdavis.edu/~rogaway/umac
[UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A.,
Krawczyk, H., Rogaway, P., "UMAC: Message
Authentication Code using Universal Hashing", Work in
Progress, October 2000. Also available
at:http://www.cs.ucdavis.edu/~rogaway/umac/draft-
krovetz-umac-01.txt
[UMACPERF] Rogaway, P., "UMAC Performance",
http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
Thanks to Steve Bellovin of AT&T Research, William Dixon of V6 Security, David Black of EMC, Joseph Tardo and Uri Elzur of Broadcom, Julo Satran, Ted Ts'o, Ofer Biran, and Charles Kunzinger of IBM, Allison Mankin of ISI, Mark Bakke and Steve Senum of Cisco, Erik Guttman of Sun Microsystems and Howard Herbert of Intel for useful discussions of this problem space.
AT＆T ResearchのSteve Bellovin、V6 SecurityのWilliam Dixon、EMCのDavid Black、BroadcomのJoseph TardoとUri Elzur、Julo Satran、Ted Ts'o、Ofer Biran、IBMのCharles Kunzinger、ISIのAllison Mankin、Markに感謝します。この問題空間についての有益な議論については、CiscoのBakkeとSteve Senum、Sun MicrosystemsのErik Guttman、IntelのHoward Herbert氏。
Appendix A - Well Known Groups for Use with SRP
付録A-SRPで使用する既知のグループ
Modulus (N) and generator (g) values for various modulus lengths are given below. The values below are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [SRPDIST], and subsequently rigorously verified to be prime. Implementations supporting SRP authentication MUST support groups up to 1536 bits, with 1536 bits being the default.
さまざまな係数の長さの係数（N）とジェネレーター（g）の値を以下に示します。以下の値は、スタンフォードSRPディストリビューション[SRPDIST]のためにトムウーとユージーンジョンが開発したソフトウェアから取得され、厳密に検証されて素数であることが確認されています。 SRP認証をサポートする実装は、最大1536ビットのグループをサポートする必要があります（デフォルトは1536ビット）。
iSCSI Key="SRP-768" [768 bits] Modulus (base 16) = B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator = 2
iSCSIキー= "SRP-768" [768ビット]モジュラス（ベース16）= B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE6ABE6C96AB3CADAB3CADAB3C7B3C7B3C7B3C7C96B3C0C0d0e6E6C7C96B3E6C6C7C6C9C6E6C6C8C8C8C8C8C4C4C4B29B29B29C9529B29C28B29B29C95C28C28C28C28C28C65B3C98B23B9859B98B23B97B3135位
iSCSI Key="SRP-1024" [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2
iSCSIのキー= "SRP-1024" [1024ビット]弾性率（ベース16）= EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3ジェネレータ= 2
iSCSI Key="SRP-1280" [1280 bits] Modulus (base 16) = D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator = 2
iSCSIのキー= "SRP-1280" [1280ビット]弾性率（ベース16）= D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605Bジェネレータ= 2
iSCSI Key="SRP-1536" [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2 iSCSI Key="SRP-2048" [2048 bits] Modulus (base 16) = AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 Generator = 2
iSCSIのキー= "SRP-1536" [1536ビット]弾性率（ベース16）= 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BBジェネレータ= 2のiSCSIキー= "SRP-2048" [2048ビット]弾性率（ベース16）= AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B6 5E372FCD68EF20FA7111F9E4AFF73ジェネレーター= 2
In addition to these groups, the following groups MAY be supported, each of which has also been rigorously proven to be prime:
これらのグループに加えて、次のグループがサポートされる場合があります。これらのグループのそれぞれも、素数であることが厳密に証明されています。
[1] iSCSI Key="MODP-3072": the 3072-bit [RFC3526] group, generator: 5
[1] iSCSI Key = "MODP-3072"：3072ビット[RFC3526]グループ、ジェネレーター：5
[2] iSCSI Key="MODP-4096": the 4096-bit [RFC3526] group, generator: 5
[2] iSCSI Key = "MODP-4096"：4096ビット[RFC3526]グループ、ジェネレーター：5
[3] iSCSI Key="MODP-6144": the 6144-bit [RFC3526] group, generator: 5
[3] iSCSI Key = "MODP-6144"：6144ビット[RFC3526]グループ、ジェネレーター：5
[4] iSCSI Key="MODP-8192": the 8192-bit [RFC3526] group, generator: 19
[4] iSCSI Key = "MODP-8192"：8192ビット[RFC3526]グループ、ジェネレーター：19
Appendix B - Software Performance of IPsec Transforms
付録B-IPsecトランスフォームのソフトウェアパフォーマンス
This Appendix provides data on the performance of IPsec encryption and authentication transforms in software. Since the performance of IPsec transforms is heavily implementation dependent, the data presented here may not be representative of performance in a given situation, and are presented solely for purposes of comparison. Other performance data is available in [AESPERF], [PENTPERF] and [UMACPERF].
この付録では、ソフトウェアでのIPsec暗号化および認証変換のパフォーマンスに関するデータを提供します。 IPsecトランスフォームのパフォーマンスは実装に大きく依存するため、ここに示すデータは、特定の状況でのパフォーマンスを表すものではない可能性があり、比較の目的でのみ提示されています。その他のパフォーマンスデータは、[AESPERF]、[PENTPERF]、および[UMACPERF]で利用できます。
Table B-1 presents the cycles/byte required by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet sizes, implemented in software.
表B-1に、ソフトウェアで実装された、さまざまなパケットサイズでのAES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5、およびHMAC-SHA1アルゴリズムに必要なサイクル/バイトを示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at various packet sizes.
表B-1：AES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5、およびHMAC-SHA1認証アルゴリズムがさまざまなパケットサイズで消費するサイクル/バイト。
Source: Jesse Walker, Intel Table B-2 presents the cycles/second required by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in software, assuming a 1500 byte packet.
出典：Jesse Walker、Intel表B-2は、AES-PMAC、AES-CBC-MAC、AES-UMAC、HMAC-MD5、およびHMAC-SHA1アルゴリズムに必要なサイクル/秒を示し、ソフトウェアで実装され、1500バイトを想定していますパケット。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B |
| (8 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B |
| (20 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B |
| (8 octets) | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
表B-2：100 Mbps、1 Gbps、および10 Gbpsのラインレート（1500バイトパケット）でのHMAC-SHA1、HMAC-MD5、AES-CBC-MACおよびAES-PMAC認証アルゴリズムのソフトウェアパフォーマンス。
Source: Jesse Walker, Intel
出典：Jesse Walker、Intel
At speeds of 100 Mbps, AES-UMAC is implementable with only a modest processor, and the other algorithms are implementable, assuming that a single high-speed processor can be dedicated to the task. At 1 Gbps, only AES-UMAC is implementable on a single high-speed processor; multiple high speed processors (1+ Ghz) will be required for the other algorithms. At 10 Gbps, only AES-UMAC is implementable even with multiple high speed processors; the other algorithms will require a prodigious number of cycles/second. Thus at 10 Gbps, hardware acceleration will be required for all algorithms with the possible exception of AES-UMAC.
100 Mbpsの速度では、AES-UMACは適度なプロセッサのみで実装でき、他のアルゴリズムは単一の高速プロセッサをタスク専用にできると想定して実装できます。 1 Gbpsでは、AES-UMACのみが単一の高速プロセッサに実装可能です。他のアルゴリズムには、複数の高速プロセッサ（1 GHz以上）が必要です。 10 Gbpsでは、複数の高速プロセッサでもAES-UMACのみが実装可能です。他のアルゴリズムは、驚異的な数のサイクル/秒を必要とします。したがって、10 Gbpsでは、AES-UMACを除いて、すべてのアルゴリズムでハードウェアアクセラレーションが必要になります。
Table B-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, for various packet sizes.
表B-3は、さまざまなパケットサイズに対して、ソフトウェアで実装されたAES-CBC、AES-CTRおよび3DES-CBC暗号化アルゴリズム（MACなし）で必要なサイクル/バイトを示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data size | AES-CBC | AES-CTR | 3DES-CBC |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 156.09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 31.22 | 28.62 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 31.22 | 27.75 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 28.62 | 27.32 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 29.14 | 28.1 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 28.62 | 27.75 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 28.99 | 27.5 | 149.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 28.62 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 28.33 | 27.75 | 147.72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 28.62 | 27.06 | 147.77 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 28.18 | 27.32 | 147.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 28.25 | 27.5 | 147.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 27.97 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 28.33 | 27.46 | 147.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 28.1 | 27.58 | 146.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 27.91 | 27.43 | 147.34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 27.97 | 27.53 | 147.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC
encryption algorithms at various packet sizes, implemented in
software.
Source: Jesse Walker, Intel
出典：Jesse Walker、Intel
Table B-4 presents the cycles/second required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet).
表B-4は、ソフトウェアに実装されたAES-CBC、AES-CTRおよび3DES-CBC暗号化アルゴリズム（MACなし）に必要なサイクル/秒を100 Mbps、1 Gbps、および10 Gbpsのラインレートで示します（1500と仮定）バイトパケット）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-4: Software performance of the AES-CBC, AES-CTR, and 3DES encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
表B-4：100 Mbps、1 Gbps、および10 Gbpsのラインレート（1500バイトパケット）でのAES-CBC、AES-CTR、および3DES暗号化アルゴリズムのソフトウェアパフォーマンス。
Source: Jesse Walker, Intel At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a high-speed processor, while 3DES would require multiple high speed processors. At speeds of 1 Gbps, multiple high speed processors are required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, and 10 Gbps for all algorithms, implementation in software is infeasible, and hardware acceleration is required.
出典：Jesse Walker、Intel 100 Mbpsの速度、AES-CBCおよびAES-CTRモードは高速プロセッサで実装可能ですが、3DESには複数の高速プロセッサが必要です。 1 Gbpsの速度では、AES-CBCおよびAES-CTRモードには複数の高速プロセッサが必要です。 3DESで1+ Gbps、すべてのアルゴリズムで10 Gbpsの速度では、ソフトウェアでの実装は実行不可能であり、ハードウェアアクセラレーションが必要です。
Table B-5 presents the cycles/byte required for combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software.
表B-5は、暗号化/認証アルゴリズムの組み合わせに必要なサイクル/バイトを示しています。ソフトウェアで実装された、さまざまなパケットサイズでのAES CBC + CBCMAC、AES CTR + CBCMAC、AES CTR + UMAC、およびAES-OCB。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 119.67 | 52.03 | 52.03 | 57.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 70.24 | 57.23 | 39.02 | 44.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 58.97 | 55.5 | 36.42 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 57.23 | 55.93 | 35.12 | 40.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 57.23 | 55.15 | 33.3 | 38.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 57.23 | 55.5 | 32.95 | 37.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 58.72 | 55 | 32.71 | 37.17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 58.54 | 55.28 | 32.52 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 57.81 | 55.5 | 31.8 | 37 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 57.75 | 55.15 | 31.74 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 57.67 | 55.5 | 31.65 | 35.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 57.61 | 55.75 | 31.22 | 35.68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 57.56 | 55.61 | 31.22 | 35.45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 57.52 | 55.21 | 31.22 | 35.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 57.75 | 55.15 | 31.22 | 36.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 57.47 | 55.34 | 30.75 | 35.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 57.72 | 55.5 | 30.86 | 35.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-5: Cycles/byte of combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software.
表B-5：暗号化/認証アルゴリズムを組み合わせたサイクル/バイト：AES CBC + CBCMAC、AES CTR + CBCMAC、AES CTR + UMAC、およびソフトウェアに実装されたさまざまなパケットサイズのAES-OCB。
Table B-6 presents the cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 byte packets.
表B-6は、100 Mbps、1 Gbps、10 Gbpsのラインレートで動作するAES CBC + CBCMAC、AES CTR + CBCMAC、AES CTR + UMAC、およびAES-OCB暗号化および認証アルゴリズムに必要なサイクル/秒を示しています。 1500バイトのパケット。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
| CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| | | | | |
| AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table B-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 octet packets.
表B-6：100 Mbps、1 Gbpsおよび10 Gbpsのラインレートで動作する、AES CBC + CBCMAC、AES CTR + CBCMAC、AES CTR + UMAC、およびAES-OCB暗号化および認証アルゴリズムに必要なサイクル/秒（想定） 1500オクテットパケット。
Source: Jesse Walker, Intel
出典：Jesse Walker、Intel
At speeds of 100 Mbps, the algorithms are implementable on a high speed processor. At speeds of 1 Gbps, multiple high speed processors are required, and none of the algorithms are implementable in software at 10 Gbps line rate.
100 Mbpsの速度では、アルゴリズムは高速プロセッサに実装できます。 1 Gbpsの速度では、複数の高速プロセッサが必要であり、10 Gbpsのラインレートでソフトウェアに実装できるアルゴリズムはありません。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン州98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Joshua Tseng McDATA Corporation 3850 North First Street San Jose, CA 95134-1702
Joshua Tseng McDATA Corporation 3850 North First Street San Jose、CA 95134-1702
Phone: +1 650 207 8012
EMail: joshtseng@yahoo.com
Jesse Walker Intel Corporation 2211 NE 25th Avenue Hillboro, OR 97124
Jesse Walker Intel Corporation 2211 NE 25th Avenue Hillsboro、OR 97124
Phone: +1 503 712 1849
Fax: +1 503 264 4843
EMail: jesse.walker@intel.com
Venkat Rangan Brocade Communications Systems Inc. 1745 Technology Drive, San Jose, CA 95110
Venkat Rangan Brocade Communications Systems Inc. 1745 Technology Drive、San Jose、CA 95110
Phone: +1 408 333 7318
Fax: +1 408 333 7099
EMail: vrangan@brocade.com
Franco Travostino Director, Content Internetworking Lab Nortel Networks 3 Federal Street Billerica, MA 01821
Franco TravostinoコンテンツインターネットワーキングラボディレクターNortel Networks 3 Federal Street Billerica、MA 01821
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright（C）The Internet Society（2004）。このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われた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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。