RFC3723 日本語訳
3723 Securing Block Storage Protocols over IP. B. Aboba, J. Tseng, J.Walker, V. Rangan, F. Travostino. April 2004. (Format: TXT=171673 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3723年のマイクロソフトカテゴリ: 標準化過程J.ツェンMcDATA社のJ.ウォーカーインテルV.Ranganは2004年4月に通信網株式会社F.Travostinoノーテルネットワークを紋織りにします。
Securing Block Storage Protocols over IP
IPの上でブロックストレージがプロトコルであると機密保護します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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(インターネットプロトコルSmallコンピュータSystem Interface)、iFCP(インターネットFibre Channel Storage Networking)、およびFCIP(TCP/IPの上の繊維Channel)のために開発されます、iSNS(インターネットStorage Name Server)とSLPv2(サービスLocationプロトコル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
1. 序論… 3 1.1iSCSI概要… 3 1.2iFCP概要… 4 1.3. FCIP概要… 4 1.4. IPsec概要… 4 1.5. 用語… 6 1.6. 要件言語… 7
Aboba, et al. Standards Track [Page 1] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[1ページ]RFC3723
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
2. ストレージプロトコルセキュリティを妨げてください… 7 2.1. セキュリティ要件… 7 2.2. リソース規制… 10 2.3. セキュリティは議定書を作ります… 12 2.4iSCSI認証… 16 2.5. SLPv2セキュリティ… 18 2.6iSNSセキュリティ… 24 3iSCSIセキュリティInter-運転可能性Guidelines… 28 3.1iSCSI安全保障問題… 28 3.2のiSCSIとIPsec相互作用… 29 3.3. 新しいiSCSIセッションを開始します… 30 3.4. 優雅なiSCSI分解… 31 3.5. 非優雅なiSCSI分解… 31 3.6. 応用層CRC… 32 4iFCPとFCIP安全保障問題… 34 4.1iFCPとFCIP認証要件… 34 IPsecとIKEとの4.2iFCP相互作用… 34 4.3. IPsecとIKEとのFCIP相互作用… 35 5. セキュリティ問題… 36 5.1. トンネル・モードに対してモードを輸送してください… 36 5.2. NAT縦断… 39 5.3. IKE問題… 40 5.4. 問題をRekeyingします… 40 5.5. 問題を変えてください… 43 5.6. 断片化問題… 45 5.7. セキュリティチェック… 46 5.8. 認証問題… 47 5.9. カウンタモードにおけるAESの使用… 51 6. IANA問題… 51 6.1. 用語の定義… 52 6.2. お勧めの登録方針… 52 7. 標準の参照… 52 8. 有益な参照… 54 9. 承認… 58 付録A--SRPとの使用のためのよく知られているグループ… 59 付録B--IPsecのソフトウェア・パフォーマンスは変形します… 61 B.1。 認証は変形します… 61 B.2。 暗号化と認証は変形します… 64人の作者のアドレス… 69 完全な著作権宣言文… 70
Aboba, et al. Standards Track [Page 2] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[2ページ]RFC3723
1. Introduction
1. 序論
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).
この仕様はIPsecプロトコル群のIPネットワークの上にブロックストレージプロトコルを保護する使用について議論します(iSCSI、iFCP、およびFCIPを含んでいて)、ストレージ発見プロトコル(iSNSとSLPv2)と同様に。
1.1. iSCSI Overview
1.1. iSCSI概要
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に発行するかもしれません、同じ接続の上で。(目標は各コマンドのための状態応答を返します)。 単独結合はコマンド/ステータスメッセージとデータ転送、そして/または、任意のコマンドパラメタの両方に使用されます。 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 PDUsが運ばれるiSCSI Sessionと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
iSCSIログインがiSCSI終点の互いの認証とセッションパラメタの交渉を含んでいるかもしれない間、iSCSIはそれ自身の1パケットあたりの認証、保全、秘密性または反復操作による保護メカニズムを定義しません。そしてむしろ、1パケットあたりのデータの機密性を提供するためにIPsecプロトコル群を当てにする。
Aboba, et al. Standards Track [Page 3] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[3ページ]RFC3723
integrity and authentication services, with IKE as the key management protocol. iSCSI uses TCP to provide congestion control, error detection and error recovery.
保全と認証サービス、キーとしてのIKEと共に、管理は議定書を作ります。iSCSIは、輻輳制御、誤り検出、およびエラー回復を提供するのにTCPを使用します。
1.2. iFCP Overview
1.2. iFCP概要
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はゲートウェー間プロトコルです。(ゲートウェー間プロトコルはFibre Channelデバイスへの輸送サービスをTCP/IPネットワークの上に提供します)。iFCPはIPネットワークの上にワイヤ速度で既存のFibre Channelデバイスのインタコネクトとネットワークを許容します。iFCP実装は、IP技術を完全に利用することによって耐障害性とスケーラビリティを改良するために骨組みのサービスを見習います。 それぞれのTCP接続は、ストレージがユニークなFibre Channel N_PORTsの間のトラフィックであるとサポートするのに使用されます。
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には、ネイティブの、そして、バンドのセキュリティー対策がありません。 むしろ、それは、かぎ管理プロトコルとしてデータの機密性、認証サービス、およびIKEを提供するためにIPsecプロトコル群を当てにされます。iFCPは、輻輳制御、誤り検出、およびエラー回復を提供するのにTCPを使用します。
1.3. FCIP Overview
1.3. FCIP概要
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カプセル化プロトコルです。 現在の仕様仕事はFibre ChannelスイッチのインタコネクトのためにTCP/IPネットワークの上でこれを意図しますが、プロトコルは本来接続FCスイッチに制限されません。 FCIPはどんな骨組みのサービスの妨害もエミュレーションもかかわらないという点においてiFCPと異なっています。 1つ以上のTCP接続がFCIP Linkに縛られます。(FCIP Linkは、組のFibre Channel実体の間のInter-スイッチリンクス(ISLs)がわかるのに使用されます)。 FCIP Frame Encapsulationは[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には、ネイティブの、そして、バンドのセキュリティー対策がありません。 むしろ、それは、かぎ管理プロトコルとしてデータの機密性、認証サービス、およびIKEを提供するためにIPsecプロトコル群を当てにされます。 FCIPは、輻輳制御、誤り検出、およびエラー回復を提供するのにTCPを使用します。
1.4. IPsec Overview
1.4. IPsec概要
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 Security Architecture[RFC2401]の中で指定されます、IKE[RFC2409][RFC2412]、IPsec Authentication Header(AH)[RFC2402]とIPsec Encapsulating Security有効搭載量(超能力)[RFC2406]ドキュメント。 AHと超能力はIPトラフィックを保護するのに使用されますが、IKEはかぎ管理プロトコルです。
Aboba, et al. Standards Track [Page 4] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[4ページ]RFC3723
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は3-tupleによって唯一特定された一方向セキュリティ協会です: セキュリティParameter Index(SPI)、(超能力)と目的地IPについて議定書の中で述べてください。 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]、およびInterpretation(DOI)のIP Security Domain[RFC2407]に基づく二相交渉プロトコルです。 IKEは二相を持って、以下の機能を達成します:
[1] Protected cipher suite and options negotiation - using keyed
MACs and encryption and anti-replay mechanisms
[1]の保護された暗号スイートとオプション交渉--合わせられたMACsと暗号化と反再生メカニズムを使用すること。
[2] Master key generation - such as via MODP Diffie-Hellman
calculations
[2]MODPディフィー-ヘルマンの計算を通したなどマスターキー世代
[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 Phase1で達成されますが、項目4はIKE Phase2で扱われます。
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 Phase2交渉は、両方の本国行きの、そして、外国行きのIPsec SAを証明するために実行されます。 IPsec SAによって保護されるべきトラフィックはIKE創始者によって提案されて、IKE Responderによって受け入れられたセレクタで決定します。 IPsec交通機関で、IPsec SAセレクタは、5-tupleと定義された「フィルタ」かトラフィッククラシファイアであるかもしれません: <ソースIPアドレス、Destination IPアドレスはプロトコル(UDP/SCTP/TCP)、Sourceポート、Destinationポート>を輸送します。 IKE Phase-2 SAのうまくいっている設立はtuple<プロトコル(超能力/AH)によって完全に資格があった2uni方向のIPsec SAsの作成をもたらします、送付先アドレス、SPI>。
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.
マスターキーから通常MODPディフィー-ヘルマンの計算で各IPsec SAのためのセッションキーを得ます。 既存のIPsec SA組のRekeyingは2新しいIPsec SAsを作成することによって、達成されます、彼らをアクティブにして、次に、任意により古いIPsec SA組を削除して。 通常、新しい外国行きのSAはすぐに使用されます、そして、古い本国行きのSAは何らかの局所的に定義された回、恐らく30秒または1分間パケットを受けるためにアクティブな状態で残されます。
Aboba, et al. Standards Track [Page 5] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[5ページ]RFC3723
1.5. Terminology
1.5. 用語
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.
繊維Channel Fibre Channel(FC)がStorage Area Networks(SANs)を実装するのに主として使用されるギガビット速度ネットワーク・テクノロジーである、また、それは使用されるかもしれませんが、また、他のフレームを輸送するのはタイプされます、IPを含んでいて。 FCはT11専門委員会におけるInformational Technology Standards(ANSI-INCITS)のためのInterNational Committeeの情報システムのために米国標準規格の下で標準化されます。
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.
IP(FCIP)の上のFCIP Fibre Channelは、ただ一つのFibre Channel骨組みで統一されたSANを形成するためにIP Networksの上でFibre Channel島とインタコネクトするためのプロトコルです。 IP Networkへの主要なFCIPインタフェースポイントはFCIP Entityです。 FCIP Linkは1組のFCIP Entitiesの間に存在する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 Host Bus Adapter(HBA)は対向機器へのSCSIインタフェースへの総称です。 TCP/IPネットワーク・インターフェースにおいて、それはNetwork Interface Cardという用語におよそ類似しています(NIC)、ほとんどのNICsがTCP、UDP、またはIPを実装しませんが、一般に、HBAsには車載SCSI実装があるのを除いて。
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ネットワークの上でFibre Channelデバイスに対する骨組みのサービスをFibre Channelに供給します)。
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ブロックストレージプロトコルWhere、「IPブロックストレージプロトコル」がiSCSI、iFCP、およびFCIPを含んでいて、IPをひくすべてのブロックストレージプロトコルに適用する用語。
iSCSI
iSCSI is a client-server protocol in which clients (initiators)
open connections to servers (targets).
iSCSI iSCSIはクライアント(創始者)がサーバ(目標)に接続を開くクライアント/サーバプロトコルです。
Aboba, et al. Standards Track [Page 6] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[6ページ]RFC3723
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.
インターネットStorage Name Server(iSNS)プロトコルがiSCSIとFibre Channel(FCP)記憶装置iSNSアプリケーションの発見と管理に提供する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創始者はiSCSI目標で実行のためのコマンドをSCSIに発行します。
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創始者によって発行された各コマンドのために状態応答を返します、同じ接続の上で。
1.6. Requirements Language
1.6. 要件言語
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].
このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHALL"、「」、“SHOULD"、「」、[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.
iFCP[iFCP]とFCIP[FCIP]標準化過程は、セキュリティ要件が本書では既にiSCSI[RFC3720]に組み入れられますが、それらが便宜のためにここで再生すると記録します。 食い違いの場合、個々のプロトコル標準化過程ドキュメントは優先します。
2. Block Storage Protocol Security
2. ブロックストレージプロトコルセキュリティ
2.1. Security Requirements
2.1. セキュリティ要件
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 Blockストレージプロトコルは、IPネットワークの上にSCSIコマンドを伝えるのに使用されます。 したがって、コントロールとこれらのIPブロックストレージプロトコルのデータ・パケットの両方が、攻撃するために被害を受け易いです。 攻撃に関する例は:
Aboba, et al. Standards Track [Page 7] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[7ページ]RFC3723
[1] An adversary may attempt to acquire confidential data and
identities by snooping data packets.
[1] 敵は、データ・パケットについて詮索することによって秘密のデータとアイデンティティを取得するのを試みるかもしれません。
[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 Loginなどのアプリケーション層の認証交渉の分裂を含んでいます。
[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デバイスが全体のFibre Channel島への最後の砦であるので、うまくいくなら、上の攻撃はデバイスの後ろのすべてのFibre Channelホストのセキュリティに感染するかもしれません。
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ブロックストレージセキュリティプロトコルは1パケットあたり1個のベースで秘密性、データ発生源認証、保全、および反復操作による保護をサポートしなければなりません。 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).
コミュニケーション終点の双方向の認証を提供しなければなりません。 認証に使用されるアイデンティティが秘密にされるという(例えば、受け身の立ち聞きする者から)要件が全くありません。
Aboba, et al. Standards Track [Page 8] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[8ページ]RFC3723
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オーバーヘッドとハードウェアの有用性は今日、1Gbpsで実装を排除してはいけません。 10Gbpsの実装の実行可能性は、非常に望ましいのですが、このとき、明白でないかもしれません。 これらの性能レベルは、スループットに集めるのに申し込んで、IPブロックストレージ終点の間で使用されるすべてのTCP接続を含んでいます。 IPブロックストレージコミュニケーションは複数のTCP接続に通常かかわります。 Appendix 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.
デバイスが企業網、IPアドレスの中で配布されるiFCPかFCIPがいつになるかは、ほとんどのルータに関してそうであるように静的に通常割り当てられて、切り替わります。 その結果、[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 Loginの中で交渉された認証アルゴリズムに影響を及ぼすでしょう、セキュリティー・サービス(秘密性、データ発生源認証(保全)は保護を再演する)とIPsecがiSCSIや、iFCPやFCIPなどのIPブロックストレージプロトコルを保護するのに使用されるとき交渉された変換と同様に。
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 Linkの粒状でセキュリティがメカニズムであると可能にして、無効にするのを許容するかもしれません。 iFCPに関しては、粒状はiFCP Portalに対応しています。 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の粒状で交渉されることに注意してください、それらと異なったセキュリティー・サービスをセットに要求するIPブロックストレージ接続がIPsec SAsが新しいIPsec SAを交渉するために必要とする存在と交渉したように。
Aboba, et al. Standards Track [Page 9] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[9ページ]RFC3723
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].
また、別々のIPsec SAsもサービスの質問題がIPブロックストレージ接続の異なった取り扱いを決めるところで賢明です。 同じ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とFibre Channelは現在少ししかセキュリティー対策の方法で含まないで、彼らのセキュリティの特性のためにそれに取り付けられたコミュニケーション媒体とシステム/デバイスの物理的なセキュリティ、管理安全保護、および正しい構成を当てにします。
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ネットワークに、ネットワークとすべての物理的なセキュリティ、管理安全保護、および正しい構成がノードを添付した(テスト研究室の肉体的に孤立しているネットワークは例外であるかもしれない)と仮定するのは不適当です。 したがって、認証SHOULD、IPブロックストレージプロトコル(例えば、iSCSI SHOULDはバンドにおける認証機構かIKEによって提供された認証の1つを使用する)で、接続が初めは意図している対応者と共に開かれたという最小量の保証を提供するのに使用されてください。
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サーバとそのクライアントとのコミュニケーションを保証するためにメカニズムを定義します。
2.2. Resource Constraints
2.2. リソース規制
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
iSCSIは、汎用のオペレーティングシステムを動かす大きいサーバから埋め込まれたホストバスアダプター(HBAs)まで及びながら、さまざまなシステムの上で実装されるでしょう。 一般に、ホストバスアダプターは最も強制的なiSCSI実装環境です、HBAがいくつかの場合、それが取り付けられるシステムに関するリソースを利用するかもしれませんが(例えば、認証計算が接続に必要です。
Aboba, et al. Standards Track [Page 10] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[10ページ]RFC3723
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実装に利用可能であるべきです。以下のガイドラインは機能性を合わせて、「再-合わせ」る認証が利用すると合理的に予想できる大体のレベルに関するリソースを示します:
- 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).
- 一般に、わずかな語長がある低いパワープロセッサは使用されません、パワーが通常抑制要素でないので、HBAsの可能な例外で。(HBAsはそれらが挿入されるシステムのコンピュータのリソースを利用できます)。 コンピュータの馬力は、接続設定のための認証と主要な派生の一部として十分な量の羃法を実行するために利用可能であるべきです。 同じくらいは「再-合わせ」るのに関して本当です、「再-合わせ」るために羃法を避ける能力が望ましいかもしれませんが(しかし、絶対条件ではありません)。
- 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、そして/または、フラッシュリソースは、埋め込まれた実装で抑制される傾向があります。 80-100 8-10 コードのMBと認証、合わせる、および「再-合わせ」るデータは明確に過度です、そして、800-1000 他の代替手段が全くなければ、KBは望ましいのですが、許容できるより明確に大きいです、そして、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ダースが大きいテープ装置であるので。
Aboba, et al. Standards Track [Page 11] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[11ページ]RFC3723
2.3. Security Protocol
2.3. セキュリティプロトコル
2.3.1. Transforms
2.3.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ブロック、ストレージのセキュリティ対応することの実装はコントロールパケットとデータ・パケットの両方にセキュリティを提供するために、超能力[RFC2406]をIPsecにサポートしなければなりません、IPsecの反復操作による保護メカニズムと同様に。 超能力が利用されているとき、1パケットあたりのデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
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.
超能力を秘密性に提供してください、超能力。[RFC3686]、SHOULDの説明されるとしてのモード[RFC2451][3DESANSI]をサポートしなければならないCBCの3DES、およびCounterモードによるAESと共に、サポートされてください。 XCBC拡張子[RFC3566]SHOULDがあるCBC MACモードで超能力、[RFC2404]をサポートしなければならないHMAC-SHA1、およびAESをデータ発生源認証と保全に提供するには、サポートされてください。 DES、CBCモードSHOULD NOTで、固有の弱点のため使用されてください。 認証のためにNULL暗号化がある超能力をサポートしなければなりません。
2.3.2. IPsec Modes
2.3.2. IPsecモード
Conformant IP block storage protocol implementations MUST support ESP [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport mode.
Conformant IPブロックストレージプロトコル実装は、トンネルモードで超能力[RFC2406]をサポートしなければならなくて、超能力で交通機関でIPsecを実装するかもしれません。
2.3.3. IKE
2.3.3. イケ
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.
Conformant IPブロックストレージセキュリティ実装は、IKEが同輩認証のための[RFC2409]と、セキュリティ協会の交渉と、かぎ管理であるとサポートしなければなりません、IPsec DOI[RFC2407]を使用して。 サポートを「再-合わせ」ながら金策しないので、手動の合わせることを使用してはいけません。 Conformant IPブロックストレージセキュリティ実装は、あらかじめ共有されたキーを使用するのを同輩認証にサポートして、デジタル署名を使用する証明書ベースの同輩認証を5月のサポートにサポートしなければなりません。 公開鍵暗号化メソッドを使用する同輩認証がIKEのセクション5.2と5.3で[RFC2409]SHOULD NOTについて概説しました。使用されます。
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.
Conformant IPブロックストレージセキュリティ実装はIKE Main ModeとSHOULDサポートAggressive Modeをサポートしなければなりません。 同輩のどちらかであるときに、あらかじめ共有された主要な認証SHOULD NOTが使用されているIKE Main Modeはダイナミックに割り当てられたIPアドレスを使用します。 あらかじめ共有された主要な認証があるMain Modeは多くの場合優れた警備体制を提供しますが、ダイナミックに割り当てられたアドレスがグループの武力行使した使用である状況はキーをあらかじめ共有しました。(それは、介入者攻撃に被害を受け易いです)。
Aboba, et al. Standards Track [Page 12] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[12ページ]RFC3723
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 Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 すべての場合では、適当に局所的に保存された秘密の情報(あらかじめ共有されたキー、またはデジタル署名のための秘密鍵)へのアクセスを制限しなければなりません、秘密の情報の感染が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を達成するために、交渉者SHOULDは認証局(または、当局)を指定するローカルの方針によると、信じられるIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。
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 Phase1の中では、IDiiとIDirペイロードの中の使用のために、conformant IPブロックストレージセキュリティ実装は、__ID IPV4_ADDR、ID IPV6_ADDR(プロトコル・スタックがIPv6をサポートするなら)とID_FQDN Identityが有効搭載量であるとサポートしなければなりません。iSCSIセキュリティ実装SHOULDは、ID_USER_がFQDN Identity有効搭載量であるとサポートします。 他のIPブロックストレージプロトコル(iFCP、FCIP)SHOULD NOTはID_USER_FQDN Identity有効搭載量を使用します。 アイデンティティ、_ID IPV4_ADDRと_ID IPV6_ADDR(_ID FQDNか_ID USER_FQDNなどの)SHOULDを除いて、Aggressiveモードがあらかじめ共有されたキーと共に利用されて、IPアドレスがダイナミックに割り当てられる状況で、使われてください。 IP Subnetであり、_IP Address Range、ID DER_ASN1__DN、ID DER_ASN1_GNはSHOULD NOTをフォーマットします。IPブロックストレージプロトコルセキュリティには、使用されてください。 ID_KEY_ID Identity有効搭載量を使用してはいけません。 [RFC2407]で説明されるPhase1の中では、500をゼロに合わせるか、またはUDP移植するようにIDポートとプロトコル分野を設定しなければなりません。 また、[RFC2407]に述べられるように:
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ブロックストレージプロトコル実装によって使用されるPhase2クィックMode交換は明らかに、Identity有効搭載量野原(IDciとIDcr)を運ばなければなりません。 それぞれのPhase2IDciとIDcr有効搭載量SHOULDはただ一つのIPアドレス(__ID IPV4_ADDR、ID IPV6_ADDR)とIP SubnetかIP Address RangeがフォーマットするSHOULD NOT使用を運びます。 他のIDペイロード形式を使用してはいけません。
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
IPsec加速ハードウェアが2SAs、Phase2が削除するアクティブなIKE Phaseの限られた数を扱うことができるだけであるかもしれないので、使用されていないSAsのためにメッセージを送るかもしれません、アクティブなPhase2SAsの数を最小限に保つ手段として。 IKE Phase2の領収書が削除する、IPを取りこわす理由としてメッセージを解釈してはいけません。
Aboba, et al. Standards Track [Page 13] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[13ページ]RFC3723
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.
ストレージ接続を妨げてください。 むしろ、接続が上げる休暇、それを保護するために別のIKE Phase2SAを持って来るためにそれで追加トラフィックを送るなら、望ましいです。 これは絶えず上下に接続を連れて来る可能性を避けます。
2.3.4. Security Policy Configuration
2.3.4. 安全保障政策構成
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]がサポートされると、この変換組み合わせは通常好まれるでしょう、セカンダリ申し出としての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グループを提供するなら、それと共に少なくとも2048ビットのDHグループを提供するのはお勧めです、[KeyLen]に述べられるように。 完全な前進の秘密保持がクィックModeで必要であるなら、QM PFS DHグループがIKE Phase1DHが分類するのと同じであることは、お勧めです。 相互運用性のために機会を高めて、これは組み合わせの総数を減少させます。
[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交渉が失敗することを引き起こすよりむしろ、Responderが提供された寿命が最大であるとみなして、それを受け入れるのは、お勧めです。 キーは、生涯満了についてもう片方の同輩に知らせるのに次に、より少ない値を生涯に使用して、Lifetime Notifyを利用できます。
Aboba, et al. Standards Track [Page 14] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[14ページ]RFC3723
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かcleartextサポート。 必要である同輩構成の最小の断片はIPブロックストレージ終点がIPsecかcleartextを必要とするかどうかということです。 長いタイムアウトの危険を冒さないで、これは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] Forward Secrecy(PFS)サポートを完成させてください。 同輩がPFSを許すかどうかを知るのは役立っています、創始者がそれを許容しないResponderにPFSを提案するならIKE Phase2クィックModeが失敗できるので。
[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.
主なModeとAggressive Modeがサポートする[7]。 モードがそれを許さない同輩に提案されるならIKE交渉が失敗できるので、同輩がどのモードを許すかを知るのは役立っています、一度で許容モードを交渉できるように。
Aboba, et al. Standards Track [Page 15] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[15ページ]RFC3723
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.
IPsec安全保障政策を分配するのにiSNSかSLPv2を使用できて、IPブロックストレージプロトコルによる使用のための設定情報、プロトコルが'弱いリンク'を構成するだろうというこれらの発見が使用されたので、それらは少なくともプロトコルと同様に構成するセキュリティを保証しませんでした。 以来、iSNSであるときに、主要な脆弱性は、パケット変更と再生であるかSLPv2は安全保障政策か設定情報を分配するのに使用されます、最小限で-、発見プロトコルを保護するのにパケットデータ発生源認証、保全、および反復操作による保護を使用しなければなりません。
2.4. iSCSI Authentication
2.4. iSCSI認証
2.4.1. CHAP
2.4.1. やつ
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秘密をサポートしなければなりません、そのような秘密を生成して、外部の世代ソースからそれらを受け入れる手段を含んでいて。 実装は無作為の世代以外の秘密の世代(または、拡張)手段を提供してはいけません。
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.
秘密が96ビットより小さい状態でCHAPが使用されるなら、接続を保護するのに、IPsec暗号化([RFC3720]セクション8.3.2における実装要件に従って)を使用しなければなりません。 そのうえこの場合グループのあらかじめ共有されたキーSHOULD NOTが使用されているIKE認証。 秘密が、より小さい状態でCHAPがその時96ビット使用されるとき、IPsec暗号化が接続を保護するのに使用されていることを確かめることができないなら、対応する実装はiSCSIログインを続行してはいけません。
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.
創始者はResponderによって双方向の認証のもう片方の方向に送られたCHAP挑戦を再利用してはいけません。 起こるなら、応答者は、この状態がないかどうかチェックして、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
同じCHAPの秘密のSHOULD NOTが複数の創始者か複数の目標の認証のために構成されて、これがそれらのどれかを可能にするとき、それら、および妥協についていかなる他の1つもまねるために、彼らのひとりは、攻撃者がそれらのどれかをまねるのを可能にします。 iSCSI実装が異なった同輩による同じCHAP秘密の使用がないかどうかこのチェックがいつ可能であるかをチェックして、これがいつ検出されるかをユーザ、そして/または、管理者に警告する穏当な処置を取るのは、お勧めです。 ただ一つのCHAP秘密は個人の認証に使用されるかもしれません。
Aboba, et al. Standards Track [Page 16] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[16ページ]RFC3723
initiator to multiple targets. Likewise, a single CHAP secret MAY be used for authentication of an individual target to multiple initiators.
マルチターゲットへの創始者。 同様に、ただ一つのCHAP秘密は個々の目標の認証に複数の創始者に使用されるかもしれません。
A Responder MUST NOT send its CHAP response if the initiator has not successfully authenticated. For example, the following exchange:
創始者が首尾よく認証されていた状態で送らないなら、ResponderはCHAP応答を送ってはいけません。 例えば、以下は以下を交換します。
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>
I>Rやつは<A1、A2と等しいです…>R>Iやつ=<A1>やつ_Cは<I>I>Rやつ=<N>やつ_C=<C><C>やつ_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)、私、C、およびRが対応するそうである、[RFC1994)で定義されるName、Algorithms、Identifier、Challenge、およびResponse
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が全くありません)Responder(目標)をもたらさなければなりません。
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秘密も構成してはいけません、そして、目標認証に使用されるどんなCHAP秘密もどんな創始者の認証のためにも構成されてはいけません。 iSCSI接続の片端によって受けられたCHAP応答が受信終点が同じCHAP挑戦のために生成したCHAP応答と同じであるなら、応答で、認証失敗として扱われて、接続は閉じなければなりません(これは、同じCHAP秘密が両方の方向への認証に使用されないのを確実にします)。 また、iSCSI実装が創始者と目標の両方として機能できるなら、これらの2つの役割のために異なったCHAP秘密とアイデンティティを構成しなければなりません。 ↓これは上記の要件によって防がれた攻撃に関する例です:
Rogue wants to impersonate Storage to Alice, and knows that a
single secret is used for both directions of Storage-Alice
authentication.
悪党は、アリスにStorageをまねたくて、ただ一つの秘密がStorage-アリス認証の両方の方向に使用されるのを知っています。
Rogue convinces Alice to open two connections to Rogue, and
Rogue identifies itself as Storage on both connections.
悪党は、2つの接続をRogueに開くようにアリスを説得します、そして、Rogueは両方の接続のときにそれ自体がStorageであると認識します。
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.
悪党は、接続2のときにアリスへの初期の挑戦として接続1のときにCHAP挑戦を発行して、アリスが応じるのを待っていて、次に、アリスの挑戦を反映します。
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.
アリスが反射がないかどうか接続の向こう側にチェックしないなら、接続2のアリスの応答は、Rogueが接続1のときにStorageをまねるのを可能にします、Rogueがアリス-ストレージCHAP秘密を知りませんが。
Aboba, et al. Standards Track [Page 17] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[17ページ]RFC3723
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クライアントとして作動する目標が創始者Responseについて確かめることができる間、それは創始者挑戦に応じないことができるでしょう。
2.4.2. SRP
2.4.2. SRP
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がジェネレータgがGF(n)[SRPNDSS]の原始根であるソフィーGermanの主要(またqも主要であるところでフォームN=2q+1について)になるのに必要です。
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のよく知られるグループはAppendix Aに含まれています、そして、追加グループはともに記名されて、IANA. iSCSI実装がこれらのよく知られるグループの1つを使用しなければならないということであるかもしれません。 創始者と目標でAppendix Aで1536ビット(すなわち、SRP-768、SRP-1024、SRP-1280、SRP-1536)まで指定されたすべてのグループをサポートしなければなりません。 相互運用性を保証するために、目標は提案されたグループの1つとしていつも"SRP-1536"を提供しなければなりません。
2.5. SLPv2 Security
2.5. SLPv2セキュリティ
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が配布されるとき、UA要求、そして/または、応答と同様にSA広告は以下の軍事的脅威を受けることがあります:
[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] 攻撃者は、本当の同輩のふりをするか、またはサービス不能攻撃に着手するためにUA要求へのSA広告か応答を載せるか、または変更できました。
[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を偽造することができました。 これで、UAsとSAsは凶暴なDAsを使用するかもしれません。
Aboba, et al. Standards Track [Page 18] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[18ページ]RFC3723
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では、機密保護モデルSAsはサインデータに任せられます。
[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 Advertisementsを見分けることができなければなりません。 これで、UAは間違ったデータを返しますが、どんなデータも全く返さない凶暴なDAsを避けることができます。 UAsは、サービスのときに質問に答えて、データを転送しますが、それを溯源するために必ずSLPv2機密保護モデルで転送するというわけではないようにDAsが保存すると信じます。
[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が使用されているなら、SAsはDAsを信じなければならないかもしれません。 この場合、SAsは、1DAだけとともに記名して、この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から可能にするかのように攻撃者が「ゼロは結果として生じること」のSrvRplyかAttrRplyをUAsに送ることによってサービス不能攻撃を仕掛けるのを可能にします。
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のベースの発見メカニズムがないときでさえ可能です。
2.5.1. SLPv2 Security Protocol
2.5.1. 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は、Userエージェント(UAs)とServiceエージェント(SAs)がSrvRqst、SrvRply、およびDAAdvertをサポートするのを必要とします。 SAsはさらに、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.
ディレクトリエージェント(DA)がないのが存在しているところでは、SrvRqstはマルチキャストですが、ユニキャストUDPを通してSrvRplyを送ります。 また、DAAdvertsはマルチキャストです。 しかしながら、UDPユニキャストで他のすべてのSLPv2メッセージを送ります。
Aboba, et al. Standards Track [Page 19] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[19ページ]RFC3723
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セキュリティがSHOULDであるとサポートするiSCSIとFCIP実装はメッセージがIPsecを使用するユニキャストで非ヌル変換がある超能力を送ったSLPv2を保護します。 [RFC2608]で説明されたSLPv2認証ブロック(デジタル署名を運ぶ)は使用するかもしれません、また、使用されて、ユニキャストとマルチキャストメッセージを認証してください。
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メカニズムがアイデンティティを確立するのを可能にするかもしれません。 さらに、その後のユーザレベル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 Entitiesは、また、同輩のIKEのアイデンティティがいったん確立されると、FCIP Short Frameで運ばれたFCIP Entity Nameが認証された同輩としてそれとなく認められると仮定します。 IKEのアイデンティティとFCIP Entity Nameとのどんなそのような協会も行政上設立されます。
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).
デジタル署名がIKEで認証を達成するのに使用されるとき、SLPv2がIKEであると機密保護することにおける使用のために、交渉者SHOULDは認証局(または、当局)を指定するローカルの方針によると、信じられるIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。 SLPv2 DAsのかぎ管理が、プロトコルサービス実装と同様にSAsとUAsと共に調整される必要があるなら、証明書のベースのかぎ管理を使用するかもしれません、共有された根のCertificate Authority(カリフォルニア)と共に。
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.
IPsecを利用する理由の1つは、SLPv2セキュリティがそれであるので、IPsecのためにSLPv2より証明書が配布されそうでしょう。 これで、SLPv2セキュリティを簡素化して、それがinteroperablyにより重要に実装されて、使用されるのは、よりありそうになります。 その結果、追加取り組みは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操作を実行するのに権限を与えられるのを必ず含意するというわけではありません。 SLPv2を固定するのにIPsecを使用するとき、UAs、SAs、およびDAsによる使用に、適切な証明書を見分けるのは望ましいかもしれません。 例えば、UAはIKE証明書方針にどんな証明書の従うことを使用できるかもしれませんが、SAによって使用された証明書は、それがサービス広告の正統の源であることを示すかもしれません。 同様に、DA証明書は、それが有効なDAであることを示すかもしれません。 SAsとDAsは使用に、有効な証明書を発行するのに特別なCAsを使用することによって、これを達成できます。 あるいはまた、SAとDA承認を使うことができます。
Aboba, et al. Standards Track [Page 20] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[20ページ]RFC3723
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の認可された証明書をSAsとDAsに発行して、配布するための方針が彼らを正統のSAsとDAsに制限するだけであると仮定してください。 この場合、IPsecは以下のセキュリティをSLPv2に供給するのに使用されます:
[a] SLPv2 messages sent via unicast are IPsec protected, using ESP
with a non-null transform.
[a] ユニキャストで送られたSLPv2メッセージは非ヌル変換がある超能力を使用して、保護された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メッセージはUAsへのユニキャストです。 SAが証明書を使用したと仮定するのがSLPv2サービス広告のためにIKE Phaseを設立する際に1SAを認可したか、または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メッセージはDAsへのユニキャストです。 SAが証明書を使用したと仮定するのがSLPv2サービス広告のためにIKE Phaseを設立する際に1SAを認可して、それにSLPv2認証ブロックが全くなくても、DAはde/登録を受け入れることができます。 サービス広告を送る前に、通常、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は、ユニキャストでDAsに連絡するのを試みるでしょう。 DAが証明書を使用したと仮定するのがSLPv2 DAAdvertsのためにIKE Phaseを設立する際に1SAを認可して、それにSLPv2認証ブロックが全くなくても、UAはDAAdvertを受け入れることができます。
[e] SAs can accept DAAdverts as described in [d].
[e] SAsは[d]で説明されるようにDAAdvertsを受け入れることができます。
2.5.2. Confidentiality of Service Information
2.5.2. サービス情報の秘密性
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 Entity Nameは攻撃者がEntityの特性に関する潜在的に有用性のある情報を学ぶことができるWWNを明らかにするかもしれません。
Aboba, et al. Standards Track [Page 21] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[21ページ]RFC3723
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機密保護モデルは、サービス情報が公共であると仮定して、したがって、秘密性に備えません。 しかしながら、記憶装置がかなりの価値のミッションクリティカルなインフラストラクチャを表すので、iSCSIとSLPv2がSHOULDが暗号化して、認証するセキュリティと保全であるとサポートするFCIPセキュリティ実装がユニキャストSLPv2メッセージを保護します。
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によって保護されて、秘密性が提供されると仮定する場合、公開の危険をすなわち、マルチキャスト、SrvRqstを通して送られたSLPv2メッセージと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が使用中であり、また、ことによると、ディレクトリサービスも存在しているのを知っているのを可能にするだけです。 この情報は非常に貴重であると考えられません。
2.5.3. SLPv2 Security Implications
2.5.3. 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.
セキュリティー属性の定義で、IPブロックストレージ実体のためにセキュリティー設定の情報を分配するのにSLPv2を使用するのは可能です。 セキュリティー設定が他の手段で決定できるなら、安全保障政策のSLPv2分配は必要ではありません、手動の構成やIPsec安全保障政策分配のように。 実体が他のメカニズムで既にセキュリティ設定を得たなら、それはSLPv2を通して安全保障政策を要求してはいけません。
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.
SLPv2がIPブロックストレージプロトコルを使用のための安全保障政策情報に提供するのに使用されるところでは、本書では説明されるIPsecはSLPv2を保護しなければなりません。 SLPv2が安全保障政策情報を分配するのに使用されないところでは、実装は、本書では説明されるようにSLPv2がセキュリティであると実装するかもしれません。
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 Loginの場合における)で認証に失敗する発見された終点に絶えず接触するのを避けることができます。 否定的キャッシュはIPsec実装、しかし、むしろIPブロックストレージプロトコル実装の中で維持される必要はありません。
Aboba, et al. Standards Track [Page 22] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[22ページ]RFC3723
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を保護するのに一次機構として使用されるよう提案するので、UAsは、DAsが正確にSAsからのデータをリレーすると信じなければなりません。 これは[RFC2608]で説明されたSLPv2機密保護モデルへの変化です。 しかしながら、[RFC2608]で定義されるSLPv2認証は「結果応答がありません」を認証する方法を提供しません、サービス不能攻撃に被害を受け易い退出SLPv2。 UAで正統のDAAdvertを発行するDAに対応するソースアドレスから送られた「ゼロは結果として生じること」のSrvRplyかAttrRplyをそれに送ることによって、そのような攻撃を行うことができます。
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を保護するのに超能力を伴うIPsecと非ヌルがいつ変形するか使用します、また、ユニキャスト要求と回答を認証できるだけではなく、秘密性を提供できます。 これは回答と同様にDAsとSAsにユニキャスト要求を含めます。 また、マルチキャストSA発見を使用することで活発にSAsを発見して、そして、ユニキャスト要求を発見されたSAsに送るのも可能です。
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ブロックストレージプロトコルによる使用において、IPsecのセキュリティの使用が[RFC2608]で定義されたSLPv2機密保護モデルより適切であると信じられています。
Using IPsec to secure SLPv2 has performance implications. Security associations established between:
SLPv2を固定するのにIPsecを使用するのにおいて、性能意味があります。 以下の間に設立されたセキュリティ協会
- UAs and SAs may be reused (the client on the UA host will use the
service on the SA host).
- UAsとSAsは再利用されるかもしれません(UAホストの上のクライアントはSAホストの上でサービスを利用するでしょう)。
- SAs and DAs may be reused (the SAs will reregister services)
- SAsとDAsは再利用されるかもしれません。(意志の「再-レジスタ」が調整するSAs)
- UAs and DAs will probably not be reused (many idle security
associations are likely to result, and build up on the DA).
- UAsとDAsはたぶん再利用されないでしょう(多くの活動していないセキュリティ協会が、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
[1] アイデンティティでSAsを構成するか、有効なDAsと、IPブロックストレージの広告を出すことができるSAsのアイデンティティでDAsを構成する証明書の特性
Aboba, et al. Standards Track [Page 23] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[23ページ]RFC3723
services. The DAs are then trusted to enforce policies on
service registration. This approach involves manual
configuration, but avoids certificate customization for SLPv2.
サービス。 そして、DAsが方針にサービス登録に押しつけると信じられます。 このアプローチは、手動の構成にかかわりますが、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によって認可されたカリフォルニアによって署名されることができたか、証明書の中に明白なSLPv2承認を含むかもしれません。 そして、IPsecセキュリティ協会がSLPv2実体の間に設立された後に、SLPv2実装は実体が実行されている操作のために認可されるかどうか決定するのに交渉に使用される証明書を検索できます。 このアプローチは、SLPv2との使用のために、より少ない構成を必要としますが、何らかの証明書改造を必要とします。
2.6. iSNS Security
2.6. iSNSセキュリティ
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を使用するのに必要ですが。 さらに、iSCSIとiFCPデバイスに安全保障政策と承認情報を保存して、分配するのにiSNSを使用できます。 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のためにIPsec保護を弱めるか、またはiFCPトラフィックで関係を樹立するようiSCSIとiFCPデバイスに指示して。
[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サーバのふりをすることができます。 これは凶暴なiSNSサーバを使用するのにiSCSIとiFCPデバイスをごまかすかもしれません。
[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] 攻撃者は、iSCSIとiFCPデバイスの周りでiSNSプロトコルメッセージについて詮索することによって、知識を得ることができます。 そのような情報は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のある機能であるときに、REQUIREDが使用されています。
Aboba, et al. Standards Track [Page 24] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[24ページ]RFC3723
[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実体のアイデンティティが秘密にされるという要件が全くありません。 明確に、iSNSサーバのアイデンティティと位置は秘密にされる必要はありません。
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が単に放送するので使用される認証ブロックかマルチキャストメッセージと、SHOULD NOTがユニキャスト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 Loginの場合における)で認証に失敗する発見された終点に絶えず接触するのを避けることができます。 否定的キャッシュはIPsec実装、しかし、むしろIPブロックストレージプロトコル実装の中で維持される必要はありません。
2.6.1. Use of iSNS to Discover Security Configuration of Peer Devices
2.6.1. 同輩デバイスのセキュリティ設定を発見するiSNSの使用
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.
実際には、構成のこれらの変化は互いにコミュニケートできないデバイスをもたらすことができます。 例えば、いつも安全なコミュニケーションを開始するために構成されるデバイスはどちらもしっかりと開始して、反応させないデバイスとコミュニケートすることにおける苦境に陥るでしょう。
Aboba, et al. Standards Track [Page 25] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[25ページ]RFC3723
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、Main Mode、Aggressive Mode、PFS、Preによって共有されたKey、および証明書の非使用を含んでいます。
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サーバに相談することによってこれを知ることができると、それはそのデバイスがある1SAが連結するIKE Phaseを開始するのを試みる時間とリソースを浪費する必要はないでしょう。
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サーバから学習されるべきである最小の情報は、IKEと各iFCPかiSCSI同輩デバイス・インタフェースのそばのIPsecの使用か非使用です。 この情報は、同輩デバイスのそれぞれのPortalのSecurity Bitmap分野でコード化されて、同輩デバイスの1インタフェースあたり1個のベースで適切です。IPsec/超能力認証で同輩デバイスに関するセキュリティ設定データを取得するiSNS質問を保護しなければなりません。
2.6.2. Use of iSNS to Distribute iSCSI and iFCP Security Policies
2.6.2. iSCSIを分配するiSNSとiFCP安全保障政策の使用
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.
IPsecの使用でいったんiSNSクライアントとiSNSサーバとのコミュニケーションを保証すると、iSNSクライアントには、セキュリティー設定がコミュニケーションにiSCSI、そして/または、iFCPプロトコルで必要であると発見する能力があります。 iSNSの安全保障政策の分配の使用は手動のデバイス構成の負担を減少させて、両立しない安全保障政策のためコミュニケーション失敗の確率を減少させる可能性を提供します。 iSNSが安全保障政策を分配するのに使用されるなら、すべてのiSNSプロトコルメッセージを保護するのに当時のIPsec認証、データ保全、および秘密性を使用しなければなりません。
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.
iSNSサーバでそれぞれのiFCP、そして/または、iSCSIデバイスの完全なIKE/IPsec構成を保存できます、クライアントデバイスの間のIKE Phase1とPhase2つの交渉に使用される方針を含んでいて。 IKEペイロード形式はiSCSIかiFCPトラフィックを保護するのに使用するのが適切であるIPsec方針を交渉するときiSCSIかiFCPデバイスが使用する一連の1つ以上の提案を含んでいます。
Aboba, et al. Standards Track [Page 26] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[26ページ]RFC3723
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.
安全保障政策のiSNS分配はセキュリティー設定であるなら必要でないというメモが手動の構成かIPsec安全保障政策分配などの他の手段で決定できます。 実体が他のメカニズムで既にセキュリティ設定を得たなら、それはiSNSを通して安全保障政策を要求してはいけません。
For further details on how to store and retrieve IKE policy proposals in the iSNS server, see [iSNS].
iSNSサーバにおけるIKE政策提議を保存して、さらに詳しい明細についてはどう検索するかに関して、[iSNS]を見てください。
2.6.3. iSNS Interaction with IKE and IPsec
2.6.3. IKEとIPsecとの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サーバとの少なくとも1Phase1と1のPhase2セキュリティ協会を維持します。iSNSクライアントとiSNSサーバの間のすべてのiSNSプロトコルメッセージはフェーズ-2セキュリティ協会によって保護されることです。
2.6.4. iSNS Server Implementation Requirements
2.6.4. iSNSサーバ実装要件
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のメカニズムであるとサポートしなければなりません。 トンネルモードにおける超能力を実装しなければなりません、そして、交通機関における超能力を伴うIPsecは実装されるかもしれません。
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.
データ発生源認証と保全に超能力、HMAC- SHA1 MUSTを提供するために、サポートされてください、そして、XCBC拡張子[RFC3566]SHOULDがサポートされているCBC MACモードによるAES。 秘密性は実装されます、3DES。いつ、[RFC3686]、SHOULDの説明されるとしてのモードをサポートしなければならないCBC、およびCounterモードによるAESでは、サポートされてくださいか。 DES、CBCモードSHOULD NOTで、固有の弱点のため使用されてください。 秘密性は必要ではありませんが、データ発生源認証と保全が可能にされるなら、NULL Encryptionがある超能力を使用しなければなりません。
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.
Conformant iSNS実装は認証、セキュリティ協会の交渉、およびかぎ管理のためにIKEをサポートしなければなりません、[RFC2407]で説明されたIPsec DOIを使用して。 IPブロックストレージプロトコルが高いボリュームにおけるデータを送ると予想されて、その結果、rekeyを必要とすることができます。 以来、手動の合わせることはサポートを「再-合わせ」ながら、提供されないで、使用はIPブロックストレージプロトコルで禁止されています。 iSNSは高いデータ量を発信させて、したがって、rekeyは発信させませんが、主要な関心事、マニュアルはSHOULD NOTを合わせていません。使用されます。 サポートを合わせる動力が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.
Conformant iSNSセキュリティ実装は、あらかじめ共有されたキーを使用して、認証をサポートしなければならなくて、デジタル署名を使用して、証明書ベースの同輩認証をサポートするかもしれません。 公開鍵暗号化メソッドを使用する同輩認証が[RFC2409]にセクション5.2と5.3SHOULD NOTについて概説しました。使用されます。
Aboba, et al. Standards Track [Page 27] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[27ページ]RFC3723
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.
Conformant iSNS実装はIKE Main ModeとSHOULDサポートAggressive Modeをサポートしなければなりません。 同輩のどちらかであるときに、あらかじめ共有された主要な認証SHOULD NOTが使用されているIKE Main Modeはダイナミックに割り当てられたIPアドレスを使用します。 あらかじめ共有された主要な認証があるMain Modeは多くの場合優れた警備体制を提供しますが、ダイナミックに割り当てられたアドレスがグループの武力行使した使用である状況はキーをあらかじめ共有しました。(それは、介入者攻撃に被害を受け易いです)。
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 Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 すべての場合では、適当に局所的に保存された秘密の情報(デジタル署名のためにキーか秘密鍵をあらかじめ共有する)へのアクセスを制限しなければなりません、秘密の情報の感染が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を達成するために、交渉者SHOULDは認証局(または、当局)を指定するローカルの方針によると、信じられるIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。
3. iSCSI Security Interoperability Guidelines
3. iSCSIセキュリティ相互運用性ガイドライン
The following guidelines are established to meet iSCSI security requirements using IPsec in practical situations.
以下のガイドラインは、実用的な状況でIPsecを使用することでiSCSIセキュリティ必要条件を満たすために確立されます。
3.1. iSCSI Security Issues
3.1. 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 Loginに備えます。 と対照的に、この認証が論理的にそうである、iSCSI創始者とiSCSI目標、(TCP/IPコミュニケーション終点) 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
iSCSIプロトコルとiSCSI Login認証は認証が接続創作でiSCSI創始者と目標の間の互いの認証を供給するiSCSI. iSCSI Loginのためのセキュリティ必要条件を満たしません; しかし、パケット基礎あたりのaにおけるコントロールとデータ通信量を保護して、iSCSI接続を攻撃iSCSI Login認証に被害を受け易い状態でお自体と、互いに目標に創始者を認証できますが、1パケットあたりの認証、保全、秘密性または反復操作による保護が提供されますか? コネ
Aboba, et al. Standards Track [Page 28] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[28ページ]RFC3723
addition, iSCSI Login authentication does not provide for a protected ciphersuite negotiation. Therefore, iSCSI Login provides a weak security solution.
追加、iSCSI Login認証は保護されたciphersuite交渉に備えません。 したがって、iSCSI Loginは弱いセキュリティ解決法を提供します。
3.2. iSCSI and IPsec Interaction
3.2. iSCSIとIPsec相互作用
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-tupleによって特定されます、<ISID、TSIH>。 ユニークなConnection Identification、CIDは与えられたセッション以内の各接続に割り当てられます。 TCP接続は5-tuple<Source IPアドレス、Destination IPアドレス、プロトコル(TCP)、Source Port、Destination Port>によって特定されます。 IPsec Phase2SAは3-tuple<プロトコル(超能力)、送付先アドレス、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セッションと接続情報はTCPの上で輸送されたiSCSI Login Commandsの中で運ばれます。 iSCSI創始者には複数のインタフェースがあるかもしれないので、iSCSIセッション以内のiSCSI接続は異なったIPアドレスから開始されるかもしれません。 同様に、複数のiSCSI目標がただ一つのIPアドレスの後ろに存在するかもしれません、与えられた<の間には、ソースIPアドレスが複数のiSCSIセッションにあることができるように、目的地IPアドレス>組。
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セッションで使用されるものからばらばらになることであるに違いありません、目標>組。 したがって、1つの唯一無二のiSCSIセッションにTCP接続を関連づけることができます。
The relationship between iSCSI sessions, TCP connections and IKE Phase 1 and Phase 2 SAs is as follows:
iSCSIセッションと、TCP接続とIKE Phase1とPhase2SAsとの関係は以下の通りです:
[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創始者か目標が、1つ以上のインタフェースを持っていて、したがって、複数のIPアドレスを持っているかもしれません。 また、複数のiSCSI創始者と目標はただ一つのIPアドレスの後ろにいるかもしれません。 その結果、iSCSI Sessionは複数のIKE Phase1Security Associationsに対応するかもしれません、独身のIKE Phase1セキュリティ協会が<創始者IPアドレスのために通常存在するでしょうが、目標IPアドレス>tuple。
[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 Sessionの中のそれぞれのTCP接続はIKE Phase2SAによって保護されます。 セレクタは、そのTCP接続に特定であるかもしれないか、または複数の接続をカバーするかもしれません。 それぞれのIKE Phase2SAが複数のTCP接続を保護しているかもしれない間、それぞれのTCP接続は1IKE Phaseだけの2SAの下で輸送されます。
Aboba, et al. Standards Track [Page 29] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[29ページ]RFC3723
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 Loginメッセージの中に含まれています。 これはIKE Phaseの1SAと、対応するiSCSIセッションと、TCP接続の間の結合と、IKE Phase2SAとiSCSI接続IDの間の結合を含んでいます。
3.3. Initiating a New iSCSI Session
3.3. 新しいiSCSIセッションを開始します。
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 Sessionを作成するために、1SAはIKE Phaseであるなら既に存在していなくて、次に、それはiSCSIがセキュリティであると実装する創始者によって設立されます。 iSCSIセッション中に確立されたその後のiSCSI接続は通常ことになるでしょうIKE Phase2によって保護されて、SAsがそのIKE Phaseから1SAを引き出しました、また、追加IKE Phase1SAsを持って来ることができますが。
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 Loginコマンドを送る前に創始者と目標実装は首尾よくIKE Phase1とPhase2つの交渉を終了します。 正しい方針(例えば、iSCSIのよく知られるTCPポート3260に運命づけられたすべてのトラフィックに非ヌル変換がある超能力を使用する)によって構成されたIPsec実装は自動的にこれを扱うでしょう。
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がLogin Commandとの回答を狙うとき、両方の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 Phase1SAs、および各IKE Phaseがあるかもしれません。1SAが複数のiSCSIセッション識別子に対応するかもしれません。 それぞれのiSCSI接続(接続識別子で、特定される)は単独のTCP接続(5-tupleによって特定される)に文通しています。 それぞれのIKE Phase2SAは<プロトコル(超能力)、送付先アドレス、SPI>組み合わせで特定されます。 Phase2SAは複数のTCP接続を保護するかもしれなくて、独身のIKE Phase1SAに対応しています。
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に基づいて関心を使用するどのセキュリティ協会がこの選択プロセスにおける役割を全く果たさないかを選ぶでしょう。
Aboba, et al. Standards Track [Page 30] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[30ページ]RFC3723
3.4. Graceful iSCSI Teardown
3.4. 優雅な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セッションをアクティブな状態でおく間に個々のTCP接続を終えるというiSCSIセキュリティ実装願望であるときに、それはTCP接続を半分終えるべきです。 タイム誌_WAITタイムアウトの満了の後に、TCP接続は閉じられます。
3.5. Non-graceful iSCSI Teardown
3.5. 非優雅なiSCSI分解
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 Phase2がすぐに下に尾行iSCSI接続裂け目かPhase1削除を削除するという要件が全くありません。 IKE Phase2SAが複数のTCP接続に文通するかもしれないので、そのような削除は不適当であるかもしれません。 同様に、IKE実装がTCP接続において、対応するセキュリティ協会へのPhase2Deleteメッセージを受け取るなら、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.
Logout Command/がログアウトするなら、Response系列は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 Phase2SAが複数のTCP接続によって使用されるとき、iSCSI同輩が持っている確認が接続のためにiSCSI分解プロセスを実行したので、iSCSI実装はIPsec Phase2が削除する受信であることによるべきではありません。
Aboba, et al. Standards Track [Page 31] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[31ページ]RFC3723
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加速ハードウェアが2SAs、Phase2が削除するアクティブなIKE Phaseの限られた数を扱うことができるだけであるかもしれないので、使用されていないSAsのためにメッセージを送るかもしれません、アクティブなPhase2SAsの数を最小限に保つ手段として。 IKE Phase2の領収書はメッセージを削除します。どんなLogout Commandも/ログアウトしないなら対応するiSCSI接続を取りこわして、Receiveが接続のときに実行されたので、理由として解釈されてはいけません。 むしろ、iSCSI接続が上げる休暇、それを保護するために別のIKE Phase2SAを持って来るためにそれで追加トラフィックを送るなら、望ましいです。 これは絶えずiSCSI接続を上下に連れて来る可能性を避けます。
3.6. Application-Layer CRC
3.6. 応用層CRC
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 retransmissionは、起こらないで、その結果、誤りから克服するのを助けることができません。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チェックサムとCRCの32ビットの応用層の両方より強い保全保護を提供します。 IPsec保全保護がTCPの下に起こるので、誤りが発見されると、パケットは捨てられるでしょう、そして、TCP retransmissionは起こるでしょう、iSCSI層で回復行動を全く取る必要はないように。
3.6.1. Simplification of Recovery Logic
3.6.1. 回復論理の簡素化
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.
iSCSI終点(または、追加保全保護を必要とする部分)の間には、IPsec保全保護が適所に終わるために終わった状態であるのが知られているところでは、iSCSIの一部を簡素化できます。 例えば、CRCチェックの故障から回収するメカニズムは必要ではありません。
Aboba, et al. Standards Track [Page 32] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[32ページ]RFC3723
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が交渉されるなら、iSCSI CRCによって検出されるのがIPsec保全保護で非検出された誤りに非常にまれになるのでどんなCRCチェックの故障も致命的であると(例えば、ヘッダー誤りのときに近くのデータ誤りのSCSI CHECK CONDITIONに対応するTCP接続を生成します)みなすために回復論理を簡素化できます。
3.6.2. Omission of iSCSI CRC
3.6.2. iSCSI CRCの省略
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.
例えば、バスの向こう側にデータを移す前にTCPチェックサムと同様にIPsec処理と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:
しかしながら、それらがプロトコル・スタックかIPsec保全がチェックであると実装するものと異なったデバイスで異なったポイントで計算されて、チェックされるので、他の事情に、TCPチェックサムとiSCSI CRCは追加誤り適用範囲を提供するでしょう。 追加可能な誤りの結果として起こる適用範囲で、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プロキシかゲートウェイです。 ここに、1つのiSCSI接続から別の接続までiSCSI CRCを伝播できます。 この場合、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
[3] 実際のiSCSIデバイスへの外部のデバイスはIPsecを提供します。 ここに、IPsecによって保護されない接続の部分の向こう側にiSCSIヘッダーとデータCRCsを保つことができます。 例えば、iSCSI接続は臨時バス、インタフェースカード、ネットワーク、インタフェースカード、およびバスを横断できました。
Aboba, et al. Standards Track [Page 33] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[33ページ]RFC3723
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.
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).
接続の両端が同じセグメントにあると事実上、トラフィックが2CRC層によって保護されることに注意してください、iSCSI CRCの交渉はNICとネットワーク誤りから守るのに必要でないように、それは他の理由(上の例えば、[1]と[2])で望ましいかもしれませんが。
4. iFCP and FCIP Security Issues
4. iFCPとFCIP安全保障問題
4.1. iFCP and FCIP Authentication Requirements
4.1. iFCPとFCIP認証要件
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とFibre Channelがフレームであるとカプセル化するトランスポート・プロトコルです。 したがって、Fibre Channel、オペレーティングシステム、およびユーザアイデンティティは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ゲートウェイはFibre Channel N_PORTがそうするべきである開始が目標N_PORTへの許容アクセスであるか否かに関係なく、決定するiSNSサーバから得られたディスカバリーDomain情報を使用します。 セキュリティがローカルの安全保障政策に従う接続の上にそれらを受け取ると、認証されているとPort Login(PLOGI)プロセスで使用されるN_PORTのアイデンティティを考えるでしょう。
There is no requirement that the identities used in authentication be kept confidential.
認証に使用されるアイデンティティが秘密にされるという要件が全くありません。
4.2. iFCP Interaction with IPsec and IKE
4.2. IPsecとIKEとのiFCP相互作用
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.
conformant iFCP Portalは1IKE Phase-1 Security Associations(SAs)を同輩iFCP Portalに設立できます。 iFCP Portalが初期化されるか、またはセキュリティ要件との最初のTCP関係が確立されるまで延期されるとき、Phase-1 SAは確立しているかもしれません。
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 Phase-2 SAは同じiFCP Portalの中の1つ以上のTCP接続を保護します。 より明確に、IKE Phase-2 SAのうまくいっている設立は完全にtuple<SPIによって資格があった2uni方向のIPsec SAsの作成をもたらします、送付先IPアドレス、超能力>。 これらのSAsは基本的なTCP接続と彼らのすべてのその後のTCPトラフィックのセットアッププロセスを保護します。 SAによって保護されたTCP接続各人は、どちらか無限の状態にいるか、または特定のiFCPセッションまで縛られます。
Aboba, et al. Standards Track [Page 34] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[34ページ]RFC3723
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] 0は存在しています。各IKE Phase-1 SAsが0に持っている同輩iFCP入り口[2]の間のM IKE Phase-1 SAs各IKE Phase-2 SAが0に保護するN IKE Phase-2 SAs[3]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 Phase-2 SAの作成はiSNSサーバから検索された安全保障政策規則で引き起こされるかもしれません。交互に、SAの作成は管理インタフェースを通して構成された政策ルールで引き起こされるかもしれません、iSNS-居住者政策ルールを反映して。 同様に、クィックModeにおける、完全な前進の秘密保持のKey Exchangeペイロード利用は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 Portalに属すなら、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 Phase-2を受けたら、メッセージを削除するか、保護されたTCP接続を終えるという要件が全くないか、または関連IKE Phase-1 SAを削除してください。 IKE Phase-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.
アクティブなPhase-2 SAs、IKE Phase-2の数を最小にするために、メッセージを削除してください。TCP接続がしばらくデータ通信量を扱っていないPhase-2 SAsのために送ってもよいです。 関連TCP接続が無駄である間、SAリソースの使用を最小にするために、新しいSAの作成は接続の上に送るまで新しいデータがことである延期されるべきです。
4.3. FCIP Interaction with IPsec and IKE
4.3. IPsecとIKEとのFCIP相互作用
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 Entitiesは、FCフレームであるとカプセル化されたIPを移すために他のFCIP Entitiesがあるトンネルを確立します。 各トンネルは、別々のFCIP Linkであり、複数のTCP接続をカプセル化することができます。 FCIP LinkとのTCP接続の結合は、2FCIP EntitiesのFibre Channel World Wide Names(WWNs)を使用することで実行されます。
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 Entitiesには複数のTCP接続を含むFCIP Linkに、可能なFCIP終点が1つのインタフェース、IPアドレス、およびそれよりあるかもしれません。IP Addressesは異なっています。 この場合、IKE Phase1SAはそれぞれのFCIP終点IP Address組のために通常設立されます。 IKE Phase1SAを設立する目的において、静的IPアドレスは識別に通常使用されます。
Aboba, et al. Standards Track [Page 35] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[35ページ]RFC3723
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 Linkの中のそれぞれのTCP接続はIKE Phase2(迅速なMode)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実装はConfidentiality用法の行政運営を提供するかもしれません。 これらの経営者側は提供されたコネが安全な方法であったなら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 Entitiesがマシンレベルトンネル機能に参加するので、FCIP Entitiesは少しのユーザレベル認証も必要としません。 しかし、FCIPは、安全保障政策を分配しないように発見のためのSLPを使用します。
5. Security Considerations
5. セキュリティ問題
5.1. Transport Mode Versus Tunnel Mode
5.1. 交通機関対トンネル・モード
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問題。 トンネルモードはトンネルを横断するパケットによって見られた経路MTUの対応する減少にそれ自体を反映するデータグラムを追加IPヘッダーに紹介します。 これはトンネル中を走らせている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トンネルモード超能力缶の横断NAT)がモードを輸送することに注意するので、超能力はNATを横断できません。 一般的な場合におけるNAT縦断を可能にするために、[RFC3715]、[UDPIPsec]、および[NATIKE]で説明されたIPsec NAT縦断の機能性は実装することができます。 次のセクションにその他の詳細を提供します。
Aboba, et al. Standards Track [Page 36] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[36ページ]RFC3723
[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交通機関があるこの検証を行うのは、より複雑です、ファイアウォールが、IPsec交通機関接続を終えるのが必要であり、iSCSI、iFCP、FCIPゲートウェイまたはTCPプロキシとして務める必要があるので、ファイアウォールから内部の終点までの新しいIPsec交通機関接続を溯源して。 そのような実装が(iSCSI)の終わりまでの終わりの信憑性か保全保護と、CRC応用層を提供できませんか、またはFibre Channelフレーム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の振舞いを制御して、確かめる能力を制限します。
5.1.1. IPsec Tunnel Mode Addressing Considerations
5.1.1. 問題を扱う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から決議できます、通常、このアドレスを得るのが、問題でないように。
Aboba, et al. Standards Track [Page 37] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[37ページ]RFC3723
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]はKX Resource Records(RRs)のIPsecゲートウェイ発見の使用について議論します。 しかしながら、KX RRsが多くのDNSサーバ実装によってサポートされている間、それらはまだ広く配布されていません。 あるいはまた、このために、DNS SRV[RFC2782]を使用できます。 DNSがゲートウェイ位置に使用されるところでは、DNSSEC[RFC2535]や、[RFC2931)や、TSIG[RFC2845]や、Simple Secureダイナミック・アップデート[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を設立すると、内側のソースはクィックMode 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
[2] 回答パケットは目的地に到着しないかもしれません、IPsecセキュリティゲートウェイは通常デフォルトルートの広告を出すのではなく、むしろそれがアドレスを割り当てる接頭語だけの広告を出すので。 アドレスがaで発しないリモート同輩のもの以来
Aboba, et al. Standards Track [Page 38] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[38ページ]RFC3723
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.
管理ドメイン固有の接頭語、ドメインの中のルータはそれのためにルートを持たないで、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への独占拡大でこの機能性を通常実装します。
5.2. NAT Traversal
5.2. NAT縦断
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.
超能力が限られたセットの事情のNATを横断できることに[RFC3715]、トンネルモードで注意するので。 例えば、NATの後ろに1つのプロトコル終点しかなくて、また「いずれかへのいずれか」セレクタが交渉されて、受信機がソースアドレス合法化を実行しないなら、超能力が首尾よくそうするかもしれないトンネルモードはNATsを横断します。 ソースアドレス合法化を無視すると新しいセキュリティの脆弱性が導入されて、特定のセレクタの交渉がトンネルの下側に送ることができるトラフィックを制限するために望ましいので、これらの状態は必ず適用されるかもしれないというわけではありません、そして、トンネルモード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.
TCPはTransportモードの中で運びました。超能力はNATを横断できません、超能力自体がメッセージの保全の中のヘッダーフィールドがチェックするIPを含んでいませんが。 これは16ビットのTCPチェックサムがIPヘッダーフィールドを含んでいる「疑似ヘッダー」に基づいて計算されて、チェックサムがIPsec超能力メッセージの保全チェックで保護されるからです。 その結果、TCPチェックサムは2つの終点の間に位置するNATによって無効にされるでしょう。
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の両方で義務的であるので、規格対応することのままで残っている間のチェックサム検証を省略するのは可能ではありません。 承諾に残っている間に存在するNATsの縦断を可能にするために、iSCSI、iFCPまたはFCIPセキュリティ実装が、IPsec/IKE NATが縦断であると実装することができます、[RFC3715]、[UDPIPsec]、および[NATIKE]で説明されるように。
Aboba, et al. Standards Track [Page 39] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[39ページ]RFC3723
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.
NATが経路に検出されるなら、イケ[NATIKE]とIPsec[UDPIPsec]NAT縦断仕様は、IPsecのUDPカプセル化が交渉されるのを可能にします。 NATのIPアドレスを決定することによって、NATで調整されたアドレスとポートを含んでいて、疑似ヘッダーに基づいてTCPチェックサムについて計算できます。 IPsecメッセージの保全チェックについて計算する前にこれをすると、TCPチェックサム検証は失敗しないでしょう。
5.3. IKE Issues
5.3. IKE問題
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実装のサイズに関する上限は800KBであると考えられるかもしれません、80KBがさまざまな状況における実装を可能にしていて。
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.
次のページのTable5.3-1に述べられるように、条件を満たすIKE実装は現在、存在します。 したがって、めったに使用されなかったIKEの機能性(一回だけの認証方法などの)の取り外しが複雑さを減少させているだろうという間、実装は、コードサイズ予算の中で合うようにこれを通常必要としないでしょう。
5.4. Rekeying Issues
5.4. 問題をRekeyingします。
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ブロックストレージ実装が、高速で作動する必要であると予想されます。 例えば、現在、デザインには1Gbpsで作動する実装がその後まもなく続く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時間後に起こるでしょう。 10Gbpsでは、疲労困憊は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.
将来、IPsecが[Seq]で説明された一連番号拡大であると実装するのは、1Gbpsの速度で作動する実装に望ましいか、または、よりすばらしいかもしれません。 使用中の変換によって、「再-合わせ」ることが一連番号スペースの疲労困憊の前に必要であるのが、可能であることに注意してください。
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,
CBC-モード暗号では、1ブロックの暗号文は前のブロックの暗号文と同様にそのブロックの平文によります。 これは、ブロックが2の暗号文であるなら同じであることを含意します、そして、また、次のブロックの平文も同じです。
Aboba, et al. Standards Track [Page 40] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[40ページ]RFC3723
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.
その時、次のブロックの暗号文は同じになるでしょう。 したがって、合っているその後のブロックで同じ暗号文ブロックを見つけることができるなら、攻撃者は合っている平文の存在を決定できます。
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 etアルコネ[DESANALY]によって調べられました。 平均的に、nビットのサイズの暗号文ブロックが2つの^[n/2]ブロック毎を繰り返すと予想されるでしょう。 単一の「誕生日の攻撃」は多くの情報を攻撃者に提供しませんが、そのようなものが攻撃する倍数は役に立つ情報を提供するかもしれません。 これをありそうもなくするように、2^[n/2]ブロックを与えられたSAに送る前にrekeyが現れるのは、お勧めです。 Bellare etアルnがビット、およびsのブロック・サイズであるO(s^2/2^n)が暗号化されたブロックの総数であるのにCBCモードの不安定が増加するのを示して、[DESANALY]でこれを正式にしました。 これらの結論は、モードを打ち返すのに当てはまりません。
Aboba, et al. Standards Track [Page 41] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[41ページ]RFC3723
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | コードサイズ| | |実装| (八重奏) | リリース| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | リナックス| | 冥王星| 258KB| FreeSWAN| |(FreeSWAN) | | x86| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | アライグマ| 400KB| 386BSD派生のOS1.5| | (ケイム) | | x86| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Isakmpd| 283KB| 386BSD派生のOS1.5| | (エリクソン) | | x86| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | WindRiver| 142KB| パワーPC| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | シスコ| 222KB| パワーPC| | VPN1700| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | シスコ| 350 K| パワーPC| | VPN3000| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | シスコ| 228KB| MIPS| | VPN7200| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 5.3-1 - Code Size for IKE implementations
テーブル5.3-1--IKE実装のためのコードSize
The formula below sets a limit on the bytes that can be sent on a CBC SA before a rekey is required:
以下の公式はrekeyが必要である前にCBC SAに送ることができるバイトにおける限界を設定します:
B = (n/8) * 2^[n/2]
Where:
B = maximum bytes sent on the SA
n = block size in bits
Bが(n/8)*2^と等しい、[n/2]どこ: 最大のB=バイトは、SA nがビットのブロック・サイズと等しいのを転送しました。
Aboba, et al. Standards Track [Page 42] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[42ページ]RFC3723
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.
これは、キー長と同様に暗号ブロック・サイズが、rekey決定で考えられる必要を意味します。 3DESは64ブロック・サイズn=ビット(2^3バイト)を使用します。 これは、B=(64/8)*(2^32)が35バイトが送られる2^と等しい前にSAを「再-合わせ」なければならないのを含意します。 1Gbpsでは、これは、rekeyが274.9秒(4.6分)毎に必要であることを含意します。 10Gbpsでは、rekeyが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メッセージの後に不安定になったのを含意します。
5.5. Transform Issues
5.5. 問題を変えてください。
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ブロックストレージ実装が1Gbpsの速度で作動するかもしれないので、高速でセキュリティー・サービスをIPsecに提供する能力は激しい関心のものです。 複数のアルゴリズムのサポートがハードウェアデザインの複雑さと費用を掛けるので、変換選択取り組みの目標の1つは1人の極小集合の秘密性と認証アルゴリズムがハードウェアで100Mbpsの速度でソフトウェアの実装に効率的であるか、または、より遅いことと同様に最大10Gbpsの速度で実装可能であることがわかることです。
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.
この仕様では、それは1つのGbpsライン料率で稼働できます。(それに私たちは既に指定されたIPsec変換で主として自分達に関係があって、部分は利用可能です)。 既存のアルゴリズムが優雅に10Gbpsに比例しないところでは、私たちは、変換仕様がまだ完全ではありませんが、部品が予想されるアルゴリズムが12カ月以内に出荷しながら製品の中に包含に利用可能であるとさらに考えます。 到達技術水準が進むのに従って、可能なアルゴリズムの範囲は広くなるでしょう、そして、追加実装するために義務的なアルゴリズムは考えられるかもしれません。
Section 5 of [RFC2406] states:
[RFC2406]州のセクション5:
"A compliant ESP implementation MUST support the following
mandatory-to-implement algorithms:
「対応する超能力実装は、↓これが実装するために義務的なアルゴリズムであるとサポートしなければなりません」
- 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 Authenticationアルゴリズム--NULL Encryptionアルゴリズム」
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]で定義されます、そして、IPsecが変えるCBCモードによる3DESは[RFC2451]で指定されます。
Aboba, et al. Standards Track [Page 43] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[43ページ]RFC3723
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]で定義されます、そして、[MD5Attack]でMD5の安全保障問題について議論します。 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
Counter(CTR)秘密性モードAES CBC-MAC認証モードによるOutput Feedback(OFB)秘密性モードAESによるCipher Feedback(CFB)秘密性モードAESによるCipher Block Chaining(CBC)秘密性モードAESによるElectronic Codebook(ECB)秘密性モードAESによるAES
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ディフィー-ヘルマングループは[RFC3526]で説明されます。
The Modes [NSPUE2] effort is also considering a number of additional algorithms, including the following:
また、Modes[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].
認証、保全、および反復操作による保護を提供するために、XCBC拡大SHOULDが[RFC3566]であるとサポートされている状態で、IPブロックストレージセキュリティ実装は認証、およびAESのために、CBC MACモードでHMAC-SHA1[RFC2404]をサポートしなければなりません。
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]はHMAC-MD5より好まれることになっています、MD5[MD5Attack]のセキュリティに関して高められた関心のため。 HMAC- SHA1部分は現在、利用可能です。1Gbpsでのその走行、アルゴリズムは最大10の速度Gbpsのハードウェアで実装可能です、そして、IPsec変換仕様[RFC2404]は存在しています。 その結果、近い将来出荷される製品のための認証アルゴリズムとしてHMAC-SHA1を利用するのは最も実用的です。 AESが暗号化のために既に実装されているならかなりの追加コードを加えるのを避けるので、XCBC拡張子があるCBC-MAC認証モードによる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.
また、HMAC-SHA1、またはAESよりかなりCBC-MAC認証モードで道具に効率的な認証変換は存在しています。 UMAC[UMAC]、[UMACKR]はソフトウェアで実装するために、より効率的です、そして、PMAC[PMAC]は、ハードウェアで実装するために、より効率的です。 PMACは現在、NISTモード取り組み[NSPUE2]の一部として評価されていますが、IPsec変換はまだ存在していません。 どちらも、UMACは変形しません。
Aboba, et al. Standards Track [Page 44] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[44ページ]RFC3723
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.
秘密性に関しては、超能力の実装するために義務的なアルゴリズム(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のための秘密性、モード[RFC2451]をサポートしなければならないCBCの3DES、およびAESをCounter Mode[RFC3686]SHOULDに供給するには、サポートされてください。 高速実装における使用のために、3DESには、重要な損失があります。 しかしながら、3DES IPsec変換は指定されました、そして、部品による製品の中の利用可能な1Gbpsで稼働できるのでそんなに実装している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).
Appendix Bで説明されるように、3DESソフトウェア実行は100Mbpsの速度で過度のコンピュータの要求をします、事実上、ソフトウェアだけ実装を除外して。 さらに、3DES実装は、現在の32ビットのIPsec一連番号スペースの疲労困憊の前に「再-合わせ」るのが必要であり、その結果、それらが利用可能であるなら、系列宇宙拡大を利用できないでしょうに。 これは、3DESが10Gbpsの速度においてより速く非常に頻繁な「再-合わせ」ることを必要とすることを意味します。 したがって、より遅い速度(100+Mbps)でソフトウェアの実装に非実用的であることと同様に非常に高い速度での使用に、3DESは不便です。
5.6. Fragmentation Issues
5.6. 断片化問題
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断片化は遭遇できます。 証明書チェーンが使用されているか、またはただ一つの証明書を交換さえするとき、他の証明書分野(分類名や他のOIDsなどの)の主要なサイズかサイズが十分大きいなら、これは起こることができます。 本国行きである、そして/または、外国行きでそれらを下げて、多くのNetwork Address Translators(NATs)とファイアウォールは適切に断片を扱いません。
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.
また、経路のルータは初期のものの後に頻繁に断片を捨てるでしょう、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] 証明書のサイズを減少させて、鎖を作ってください。
Aboba, et al. Standards Track [Page 45] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[45ページ]RFC3723
[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.
フレームへのprepending IPsecヘッダーであるときに、断片化は関心になることができます。 この問題を減少させるのに使用できる1つのメカニズムは経路MTU探索を利用することです。 iSCSIのための輸送、iFCPまたはFCIPの当時の経路MTU探索が[RFC1191]で説明したようにTCPが使用されているとき、例えば、TCP終点が正しいMTUを発見するのを可能にするのに、[RFC1435][RFC1981]を使用できます、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メッセージがホストによって受け取られないとき、Path MTU発見は失敗します。 これはunauthenticated ICMPパケットを下げるIPsec実装で起こります。 これは[RFC2923]で説明されるようにナイーブなTCP実装におけるblackholingをもたらすことができます。 適切な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は、接続が外で調節しているのに気付くはずです。」 数回のタイムアウトの後に、各パケットのために恐らくDF旗をオフにして、TCPは、より小さいパケットを送るのを試みるはずです。 「これが成功するなら、接続のためにそれが経路が変化したかどうか決定しようとするために再び調べられるべきであるいつかの適正な期間の間、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.
unauthenticated ICMPパケットを処理するIPsec実装でICMP PMTUを受け取るなら、[RFC2401]で提案されるようにSAにこの値を保存するべきです、そして、また、IPsecは正しく新しいMTU値を反映できるようにこのイベントの通知をTCPに供給するはずです。
5.7. Security Checks
5.7. セキュリティチェック
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
IPブロックストレージプロトコルと共に使用されると、IKE Phase2SAはそれぞれのTCP接続を保護しなければなりません。 1からのトラフィックか1つ以上のTCP接続がそれぞれのIPsec Phase2SAの中を流れるかもしれません。 実装が必要とするIPブロックストレージセキュリティは、パケットのIPアドレスとTCPポート値がソケットに合っていることを確かめません。
Aboba, et al. Standards Track [Page 46] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[46ページ]RFC3723
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.
接続をセットアップするのに使用された情報。 悪意がある同輩が不適当なクィックMode SAsにコマンドを送るのを防いで、このチェックはIPsecによって実行されるでしょう。
5.8. Authentication Issues
5.8. 認証問題
5.8.1. Machine Versus User Certificates
5.8.1. マシン対ユーザー証明書
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.
マシン証明書の値が逆に攻撃者が偽って1つを得ることができる容易さに変化しているので、マシン証明書登録プロセスが厳密に制御されるのは、賢明です。 例えば、管理者だけには、マシン証明書でマシンを登録する能力があるかもしれません。
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 Loginの同等物が全くないので、これらのプロトコルだけにおいて、マシンは認証されます。
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.
マシン証明書がスマートカードに保存されたなら可能であるようにマシン証明書の1台のマシンから別のマシンまでの動きを可能にして、この二元的な保証が貴重であると考えられる事情では、望ましくないかもしれません。
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
ユーザー証明書が配布されるとき、同様に、ユーザ登録プロセスが厳密に制御されるのは、賢明です。 例えば、証明書(一時的な期間か、より長い期間1)を入手するのに容易にユーザパスワードを使用できるなら、その証明書には、パスワードが値でないことのようなどんなセキュリティ値もありません。 攻撃者が盗まれたパスワード、受講期間からユーザー証明書を入手する能力を制限するのは限ることができます、パスワードアクセスがどれになったかの後に
Aboba, et al. Standards Track [Page 47] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[47ページ]RFC3723
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.
興味を失いました。 そのような方針によって、受講期間がいったん期限が切れると、未使用のアカウントに関するパスワードを得る攻撃者はユーザー証明書を入手できないでしょう。
5.8.2. Pre-Shared Keys
5.8.2. あらかじめ共有されたキー
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 Main Modeにおけるあらかじめ共有されたキーの使用が被害を受け易い、-、-ダイナミックに扱われたホスト(iSCSI創始者などの)と共に使用されると、中央は攻撃されます。 Main Modeでは、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.
したがって、あらかじめ共有された主要な認証がアドレスがダイナミックに割り当てられる実体に伴うMain Modeで使用されるとき、同じあらかじめ共有されたキーは、グループによって共有されて、もう有効な共有秘密キーとして機能できません。 この状況で、IKE Phase1の間、創始者もResponderもそれ自体を特定しません。 双方があらかじめ共有されたキーに関する知識があるグループのメンバーであることが知られているだけです。 これは中央の男性として作動するあらかじめ共有されたキーをグループへのアクセスのだれにも可能にします。 この脆弱性はIPアドレスが静的に通常割り当てられる(iFCPやFCIPなどの)ところで通常重要ではありません、この状況で、個々のあらかじめ共有されたキーがIKE Main Modeの中で可能であるので。
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アドレスがダイナミックに割り当てられて、Main Modeがあらかじめ共有されたキーと共に使用されるところでは、応用層の互いの認証が実行されない場合(例えば、iSCSIログイン認証)、Responderは認証されません。 これは、主要な状態であらかじめ共有されたグループの所有物の攻撃者がResponderのふりをするのを可能にします。 また、攻撃者が誤ったデータを提示するのを可能にすることに加えて、攻撃者は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.
グループのあらかじめ共有されたキーは、交換で、より早くアイデンティティペイロードを送って、したがって、アイデンティティに基づいてあらかじめ共有されたキーを選択できるので、Aggressive Modeで必要ではありません。 しかしながら、Aggressive Modeが使用されているとき、ユーザアイデンティティは暴露されます、そして、これは望ましくないとしばしば考えられます。
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,
注意が、Aggressive Modeがあってもあらかじめ共有されたキーへのアイデンティティに関するマッピングを可能にするためにIKE Phase1Identity有効搭載量選択で取られる必要に注意してください。 ID_IPV4_ADDRかID_IPV6_ADDR Identity有効搭載量がどこで使用されているか、そして、アドレスはダイナミックに割り当てられます。
Aboba, et al. Standards Track [Page 48] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[48ページ]RFC3723
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.
キーへのアイデンティティのマッピングが可能でないので、それでも、グループのあらかじめ共有されたキーは実用的な必要性です。 aは結果として生じます、アイデンティティ。_ID IPV4_ADDRと_ID IPV6_ADDR(_ID FQDNか_ID USER_FQDNなどの)SHOULDを除いて、Aggressiveモードがあらかじめ共有されたキーと共に利用されて、IPアドレスがダイナミックに割り当てられる状況で、使われてください。
5.8.3. IKE and Application-Layer Authentication
5.8.3. IKEと応用層認証
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実装はそれら自身の認証方法を利用します。 現在、仕事はFibre Channelセキュリティで進行中です、また、結局また、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が初期の認証を提供している間、それは1パケットあたりの認証、保全または反復操作による保護を提供しません。 これは、iSCSI Loginで確かめられたアイデンティティが次にそれぞれのパケットのレセプションで確かめられないのを含意します。
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.
IKEで断言されたアイデンティティが認証されるとき、IPsecと共に、結果として起こる派生しているキーは、1パケットあたりの認証、保全、および反復操作による保護を提供するのに使用されます。 その結果、IKEの会話で確かめられたアイデンティティは次に、それぞれのパケットのレセプションで確かめられます。
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 Loginで要求されたアイデンティティがユーザアイデンティティであると仮定しましょう、IKEの中で要求されたアイデンティティはマシンのアイデンティティですが。 以来マシンのアイデンティティだけがaで確かめられる、-、パケット基礎、受取人が、iSCSI Loginを通して認証されたユーザだけが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の下側にトラフィックを送ることができるかもしれません。 交通機関とトンネルモードSAsの両方に、これは本当です。
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ログイン資格証明書などの)が不正アクセスから保護されるのを確実にしなければなりません。
Aboba, et al. Standards Track [Page 49] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[49ページ]RFC3723
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の中で断言されたアイデンティティは与えられたマシンの上でユーザの間の干渉を避けるために1パケットあたり1個のベースで確かめられますが、オペレーティングシステムサポートが必要です。 ユーザー認証がサポートされるとき、ユーザの間にトラフィックを隔離するために、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ドライバーには、ユーザー認証を実行するために、通常、ユーザ文脈は全くありません。 この場合、認証を機械加工するために、認証は、より近くにあります。 大部分では、オペレーティングシステムデバイス許容は取り付けの前にデバイスに読み込むか、または書く能力を制御するでしょう。 デバイスがいったん取り付けられると、ACLsはデバイスへのファイルシステムコントロールアクセスでセットします。 管理者は直接デバイスの上のブロックにアクセスできます(例えば、発信することによって、直接Windows NTなどのポートドライバーに要求を通り抜けてください)。 同様に、管理者は、生のソケットを開けて、iSCSI目標への保護されたパケットをIPsecに送ることができます。 状況は類似しています、そして、この点で以前に存在しなかったどんな新しい脆弱性も作成されません。 OperatingシステムのACLsは、デバイスを保護するのに有効である必要があります(それがSCSIデバイスかiSCSIデバイスであることにかかわらず)。
5.8.4. IP Block Storage Authorization
5.8.4. IPブロックストレージ承認
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がIdentity有効搭載量として使用されるところでは、認可されたFQDNsのリストはIPブロックストレージ終点を構成できます。 構成は[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認証がうまくいっていると仮定する場合、承認レベルを決定するためにFQDNsのこのリストを調べることができます。 証明書認証が使用されているところでは、信じられたルーツで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が証明書チェーンとよく取り引きしないで、限られたセットの信じられたルーツによって通常構成されるのでイントラドメイン用法に、それが最も適切であることに注意してください。
Aboba, et al. Standards Track [Page 50] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[50ページ]RFC3723
Since iSCSI supports Login authentication, it is also possible to use the identities presented within the iSCSI Login for authorization purposes.
iSCSIが、Loginが認証であるとサポートするので、また、承認目的のためにiSCSI Loginの中に提示されたアイデンティティを使用するのも可能です。
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、特性が要件から食い止める交信している2iFCP門がある基本的なアクセスコントロールでは、以前1つ以上のiSNSサーバに知られていて、それらはiFCP交換に従事できます。 iSNSにおける発見ドメインの任意の使用は、より大きい複雑さのアクセスコントロールschemasをもたらします。
5.9. Use of AES in Counter Mode
5.9. カウンタモードにおけるAESの使用
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ディフィー-ヘルマングループは[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が使用されているとき、同じキーによるカウンタの再利用を避けるのは重要です、すべての時間の向こう側にさえ。 カウンタモードは平文がある主要なストリームであると生成されたXORingで暗号文を作成します。 平文を2から取り戻すために、かなりたやすく、カウンタモードが同じカウンタの下で暗号化したメッセージが単に一緒にXORingで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.
別のカウンタモード問題は正しいパケットの偽造を些細にするということです。 したがって、また、データ認証を使用しないで、カウンタモードは決して使用されるべきではありません。
6. IANA Considerations
6. IANA問題
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].
このセクションはiSCSIの中でSRP_GROUPの主要なパラメタの値の登録に関してインターネットAssigned民数記Authority(IANA)に指導を供給します、BCP26によると、[RFC2434。]
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で議定書を作ってください。 Appendix B、そして、FCIPに関して、[FCIP]で議定書を作ってください。
Aboba, et al. Standards Track [Page 51] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[51ページ]RFC3723
6.1. Definition of Terms
6.1. 用語の定義
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
次の用語はBCP26で定義される意味と共にここで使用されます: 「名前スペース」、「割り当てられた値」、「登録。」
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".
以下の方針はBCP26で定義される意味と共にここで使用されます: 「私用」、「先着順」、「専門のレビュー」、「仕様が必要である」「IETFコンセンサス」、「規格動作。」
6.2. Recommended Registration Policies
6.2. お勧めの登録方針
For registration requests where a Designated Expert should be consulted, the responsible IESG Area Director should appoint the Designated Expert.
Designated Expertが相談されるべきである登録要求のために、責任があるIESG AreaディレクターはDesignated Expertを任命するべきです。
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ディレクターによって指定されたメーリングリストに解散されるかどうかをそうされます。
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、MODP4096、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キーの登録がSpecification Requiredと共にDesignated Expertであります。 要求は、コメントと安全レビューのためにIPS WGメーリングリストかその後継者に掲示されて、提案されたSRPグループのためにprimalityの非probabalistic証拠を含まなければなりません。 通るとしての1カ月の期間の後に、Designated Expertは登録要求を承認するか、または否定するでしょう。
7. Normative References
7. 引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path
MTU Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
Aboba, et al. Standards Track [Page 52] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[52ページ]RFC3723
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed- Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation of ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPの解釈のインターネットIPセキュリティー領域」、RFC2407、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、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、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC2608]Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
Aboba, et al. Standards Track [Page 53] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[53ページ]RFC3723
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945, September 2000.
[RFC2945] ウーと、T.と、「SRP認証と主要な交換システム」、RFC2945、9月2000日
[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.(エド))はバウンドしています、J.、フォルツとB.とレモンとT.とパーキンスとC.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、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] パテル、B.、Aboba、B.、ケリー、S.、および「IPsecトンネル・モードのDynamic Host Configuration Protocol(DHCPv4)構成」、RFC3456(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、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、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とのその使用」、RFC3566、9月2003日
[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]ウェーバー、R.、Rajagopal、M.、Trovostino、F.(O'Donnel)、M、Monia、C.、およびM.Mehrar、「繊維チャンネル(FC)はEncapsuationを縁どっています」、RFC3643、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が、セキュリティが有効搭載量(超能力)であるとカプセル化しているエー・イー・エス(AES)カウンタモードを使用します」、RFC3686、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.、メタンフェタミン、K.、Sapuntzakis、C.Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、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
金融サービスX9.52-1998のための[3DESANSI]米国標準規格、「三重のデータ暗号化アルゴリズム運転モード」、アメリカ銀行家協会、1998年7月29日のワシントンDC
[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] ウー、T.、Networkの上の1998インターネット協会SymposiumのProceedingsの「安全なリモートパスワードプロトコル」、およびDistributed Systems Security、サンディエゴ(カリフォルニア)のページ 97-111
8. Informative References
8. 有益な参照
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
Aboba, et al. Standards Track [Page 54] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[54ページ]RFC3723
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
DNS", RFC 2230, November 1997.
[RFC2230] アトキンソン、R.、「DNSに、主要な交換委譲記録」、RFC2230、1997年11月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC2402] Kent, S., Atkinson, R., "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケント、S.、アトキンソン、R.、「IP認証ヘッダー」、RFC2402、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.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] マドソンとC.とN.Doraswamy、「明白なIVがある超能力DES-CBC暗号アルゴリズム」、RFC2405、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、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 SRV)の位置を指定するためのDNS RR」、RFC2782、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.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン(「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865]RigneyとC.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
D.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 2000年9月の[RFC2931]イーストレーク。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983] 黒、D.が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[RFC3007] Wellington, B., "Simple Secure Domain Name System
(DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007] ウェリントン、B.、「簡単な安全なドメインネームシステム(DNS)ダイナミック・アップデート」、RFC3007、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] クルーガー、M.、およびR.Haagens、「小さいコンピュータシステムズInterfaceはインターネット(iSCSI)の要件とDesign Considerationsの上で議定書を作ります」、RFC3347、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] バッキー、M.、ハーフナー、J.、Hufferd、J.、Voruganti、K.、およびM.クルーガー、「インターネットの小さいコンピュータ・システムは(iSCSI)命名と発見を連結します」、RFC3721、2004年4月。
Aboba, et al. Standards Track [Page 55] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[55ページ]RFC3723
[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]シュナイアーとB.とJ.ケルシーとD.ホワイティングとD.ワグナー、C.HallとN.ファーガソン、「AES差出のパフォーマンス比較」 http://www.counterpane.com/aes- performance.html
[AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for
iSCSI", Work in Progress, September 2002.
[AuthMIB] バッキー、M.、他、「iSCSIのための管理オブジェクトの定義」、Progress、2002年9月のWork。
[CRCTCP] Stone J., Partridge, C., "When the CRC and TCP
checksum disagree", ACM Sigcomm, Sept. 2000.
[CRCTCP] C. ストーンJ.、Partridge、ACM Sigcomm、「CRCとTCPチェックサムは意見を異にする」ときの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
[DESANALY] Bellare、デセイ、Jokippi、Rogaway、「Aは左右対称の暗号化の処理が具体的です」。 「OperationのDES Modesの分析」、1997、 http://www- cse.ucsd.edu/ユーザ/mihir/書類/sym-enc.html
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA
2000.
[DESCRACK]分解DES、オライリー、および仲間、Sebastapol、カリフォルニア2000。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of
DES-like cryptosystems", Journal of Cryptology Vol 4,
Jan 1991.
[DESDIFF] Biham、E.、シャミル、A.、「DESのような暗号系の特異なCryptanalysis」、Cryptology Vol4、1991年1月のJournal。
[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と共に発行する、」、第32IETF、ダンバース(MA)、1995年4月の議事
[FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP
(FCIP)", Work in Progress, August 2002.
[FCIP] Rajagopal、M.、他、「TCP/IP(FCIP)の上の繊維チャンネル」、Progress、2002年8月のWork。
[FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLPv2",
Work in Progress, September 2002.
[FCIPSLP]ピーターセン、「SLPv2"を使用するFCIP実体、処理中の作業に2002年9月を見つける」D.。
[FIPS46-3] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS
46-3, October 25, 1999.
[FIPS46-3]米国DoC/NIST、「データ暗号化標準(デス)」、FIPS46-3、1999年10月25日。
[FIPS74] U.S. DoC/NIST, "Guidelines for implementing and using
the nbs data encryption standard", FIPS 74, Apr 1981.
[FIPS74]米国DoC/NIST、「nbsデータ暗号化標準を実装して、使用するためのガイドライン」、FIPS74、1981年4月。
[FIPS197] U.S. DoC/NIST, "Advanced Encryption Standard (AES)",
FIPS 197, November 2001,
http://csrc.nist.gov/CryptoToolkit/aes
[FIPS197]米国DoC/NIST、「エー・イー・エス(AES)」、FIPS197、2001年11月、 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]Monia、C.、他、「iFCP--Aはインターネット繊維河道貯留ネットワークのために議定書を作る」、Progress、8月2002日のWork
Aboba, et al. Standards Track [Page 56] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[56ページ]RFC3723
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address
Translation (NAT) Compatibility Requirements", RFC
3715, March 2004.
[RFC3715] AbobaとB.とW.ディクソン、「IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件」、RFC3715、2004年3月。
[iSCSISLP] Bakke, M., "Finding iSCSI targets and Name Servers
Using SLP", Work in Progress, March 2002.
M. [iSCSISLP]バッキー、Progress、2002年3月の「iSCSI目標とName Servers Using SLPを見つける」Work。
[iSNS] Gibbons, K., et al., "iSNS Internet Storage Name
Service", Work in Progress, August 2002.
[iSNS]テナガザル、K.他、「iSNSインターネットストレージ名前サービス」、Progress、2002年8月のWork。
[KeyLen] Orman, H., Hoffman, P., "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", Work
in Progress, December 2001.
[KeyLen]Orman(H.、ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」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.2No.2、1996年夏
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in
the IKE", Work in Progress, June 2002.
[NATIKE] Kivinen、T.、他、「IKEでのNAT縦断の交渉」、Progress、2002年6月のWork。
[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、コードン: NSPUE2、米国政府印刷局ワシントン(DC)2001年7月。
[PENTPERF] A. Bosselaers, "Performance of Pentium
implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[PENTPERF]A.Bosselaers、「Pentium実装のパフォーマンス」、 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
J.、[PMAC]Rogaway(P.)が黒くする、「PMAC:」 「parallelizableメッセージ確認コードのためのNISTへの提案」、 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」が進歩、2002年7月に働いています。
[SRPDIST] Wu, T., "SRP Distribution", http://www-cs-
students.stanford.edu/~tjw/srp/download.html
[SRPDIST] ウー、T.、「SRP分配」、 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] et Huttunen、A.、アル、「IPsecパケットのUDPカプセル化」、Progress、6月2002日のWork
[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
[UMAC]黒、J.、ハレビ、S.、Krawczyk、H.、Krovetz、T.、Rogaway、P.、「UMAC:」 「通報認証を速さに、そして証明可能に保証してください」、CryptologyのAdvances--CRYPTO'99、LNCS vol.1666、ページ、' 216-233. http://www.cs.ucdavis.edu/~rogaway/umac から利用可能な完全版
Aboba, et al. Standards Track [Page 57] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[57ページ]RFC3723
[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
[UMACKR]Krovetz、T.、黒、J.、ハレビ、S.、Hevia、A.、Krawczyk、H.、Rogaway、P.、「UMAC:」 「通報認証コードは普遍的な論じ尽くすことを使用し」て、進歩、2000年10月に働いてください。 また、: 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
[UMACPERF] Rogaway、P.、「UMACパフォーマンス」、 http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
9. Acknowledgments
9. 承認
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のスティーブBellovin、V6 Securityのウィリアム・ディクソン、EMC、ジョゼフTardoのデヴィッドBlack、BroadcomとJulo SatranとテッドTs'oとオフェルBiranとIBMのチャールズKunzingerとISIのアリソン・マンキンとマーク・バッキーとシスコのスティーブSenum、サン・マイクロシステムズのエリックGuttmanのユリElzur、およびインテルのハワード・ハーバートをありがとうございます。
Aboba, et al. Standards Track [Page 58] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[58ページ]RFC3723
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]のためにトム・ウーとユージンJhongによって開発されて、次に主要になるようにきびしく確かめられたソフトウェアから抜粋されます。 SRPが認証であるとサポートする実装はデフォルトである1536ビットの1536ビットまでのサポートグループがそうしなければなりません。
iSCSI Key="SRP-768" [768 bits] Modulus (base 16) = B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator = 2
iSCSI Key="SRP-768"[768ビット]係数(ベース16)はB344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator=2と等しいです。
iSCSI Key="SRP-1024" [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2
iSCSI Key="SRP-1024" [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2
iSCSI Key="SRP-1280" [1280 bits] Modulus (base 16) = D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator = 2
iSCSI Key="SRP-1280"[1280ビット]係数(ベース16)はD77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator=2と等しいです。
iSCSI Key="SRP-1536" [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2
iSCSI Key="SRP-1536" [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2
Aboba, et al. Standards Track [Page 59] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[59ページ]RFC3723
iSCSI Key="SRP-2048" [2048 bits] Modulus (base 16) = AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 Generator = 2
CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73ジェネレータ=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主要な="MODP-3072": 3072ビット[RFC3526]のグループ、ジェネレータ: 5
[2] iSCSI Key="MODP-4096": the 4096-bit [RFC3526] group, generator:
5
[2] iSCSI主要な="MODP-4096": 4096ビット[RFC3526]のグループ、ジェネレータ: 5
[3] iSCSI Key="MODP-6144": the 6144-bit [RFC3526] group, generator:
5
[3] iSCSI主要な="MODP-6144": 6144ビット[RFC3526]のグループ、ジェネレータ: 5
[4] iSCSI Key="MODP-8192": the 8192-bit [RFC3526] group, generator:
19
[4] iSCSI主要な="MODP-8192": 8192ビット[RFC3526]のグループ、ジェネレータ: 19
Aboba, et al. Standards Track [Page 60] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[60ページ]RFC3723
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].
このAppendixはIPsec暗号化の性能に関するデータを提供します、そして、認証はソフトウェアで変形します。 IPsec変換の性能がずっしりと実装に依存しているので、ここに提示されたデータは、与えられた状況における性能を代表しないかもしれなくて、唯一比較の目的のために提示されます。 他の性能データは[AESPERF]、[PENTPERF]、および[UMACPERF]で利用可能です。
B.1. Authentication Transforms
B.1。 認証は変形します。
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.
様々なパケットサイズにおけるAES-PMACによって必要とされたサイクル/バイト、AES- CBC-Mac、AES-UMAC、HMAC-MD5、およびHMAC-SHA1アルゴリズムがソフトウェアで実装したB-1プレゼントを見送ってください。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | データ| AES| AES-CBC| AES| HMAC| HMAC| | サイズ| 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Standards Track [Page 61] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[61ページ]RFC3723
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | データ| AES| AES-CBC| AES| HMAC| HMAC| | サイズ| 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
ソース: ジェシー・ウォーカー、インテル
Aboba, et al. Standards Track [Page 62] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[62ページ]RFC3723
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.
テーブルB-2は、1500年のバイトのパケットを仮定しながら、ソフトウェアで実装されたAES-PMAC、AES- CBC-Mac、AES-UMAC、HMAC-MD5、およびHMAC-SHA1アルゴリズムによって必要とされたサイクル/秒を提示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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) | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | サイクルズ/| サイクルズ/秒| サイクルズ/秒| サイクルズ/秒| | 変換| 八重奏| @ | @ | @ | | | (ソフトウェア) | 100 Mbps| 1 Gbps| 10 Gbps| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-UMAC| 3.5 | 43,750,000 | 437,500,000 | 4.375 B| | (8つの八重奏) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | HMAC-SHA1| 22.87 | 285,875,000 | 2.8588 B| 28.588 B| | (20の八重奏) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | 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つの八重奏) | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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をテーブルの上に置いてください: HMAC-SHA1のソフトウェア・パフォーマンス、HMAC-MD5とAES-CBC- MACと100Mbps、1Gbps、および10GbpsのAES-PMAC認証アルゴリズムはレート(1500年のバイトのパケット)を裏打ちします。
Source: 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.
100Mbpsの速度では、AES-UMACは穏やかなプロセッサだけで実装可能です、そして、他のアルゴリズムは実装可能です、単一の高速演算処理装置をタスクに捧げることができると仮定して。 1Gbpsでは、AES-UMACだけが単一の高速演算処理装置で実装可能です。 複数の高速演算処理装置(1+Ghz)が他のアルゴリズムに必要でしょう。10Gbpsでは、AES-UMACだけが複数の高速演算処理装置があっても実装可能です。 他のアルゴリズムは莫大な数のサイクル/秒を必要とするでしょう。 したがって、10Gbpsでは、ハードウェア加速がすべてのアルゴリズムにAES-UMACの可能な例外で必要でしょう。
Aboba, et al. Standards Track [Page 63] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[63ページ]RFC3723
B.2. Encryption and Authentication Transforms
B.2。 暗号化と認証は変形します。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | データサイズ| 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Standards Track [Page 64] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[64ページ]RFC3723
Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms at various packet sizes, implemented in software.
B-3をテーブルの上に置いてください: ソフトウェアで実装された様々なパケットサイズでAES-CBC、AES-CTR、および3DES-CBC暗号化アルゴリズムで消費されたサイクルズ/バイト。
Source: 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は100Mbps、1Gbps、および10のGbpsライン料率でソフトウェアで実装されたAES-CBC、AES-CTR、および3DES-CBC暗号化アルゴリズム(MACがない)によって必要とされたサイクル/秒を提示します(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 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | サイクルズ/| サイクルズ/秒| サイクルズ/秒| サイクルズ/秒| | 変換| 八重奏| @ | @ | @ | | | (ソフトウェア) | 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をテーブルの上に置いてください: AES-CBCのソフトウェア・パフォーマンス、AES-CTR、100Mbpsの3DES暗号化アルゴリズム、1Gbps、および10Gbpsがレート(1500年のバイトのパケット)を裏打ちします。
Source: Jesse Walker, Intel
ソース: ジェシー・ウォーカー、インテル
Aboba, et al. Standards Track [Page 65] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[65ページ]RFC3723
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.
100Mbpsの速度では、AES-CBCとAES-CTRモードは高速演算処理装置で実装可能です、3DESが複数の高速演算処理装置を必要とするでしょうが。 1Gbpsの速度では、複数の高速演算処理装置がAES-CBCとAES-CTRモードに必要です。 3DESのための1+Gbps、およびすべてのアルゴリズムのための10Gbpsの速度では、ソフトウェアの実装は実行不可能です、そして、ハードウェア加速が必要です。
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| | | データサイズ| 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Standards Track [Page 66] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[66ページ]RFC3723
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AES| AES| AES| | | データサイズ| 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。
Aboba, et al. Standards Track [Page 67] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[67ページ]RFC3723
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はAES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC、およびAES-OCB暗号化に必要であるサイクル/秒と100Mbpsのライン料率で作動する認証アルゴリズムを提示します、1Gbpsと10Gbps、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 | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | サイクルズ/| サイクルズ/秒| サイクルズ/秒| サイクルズ/秒| | 変換| 八重奏| @ | @ | @ | | | (ソフトウェア) | 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をテーブルの上に置いてください: サイクルズ/秒がAES CBC+CBCMAC、AES CTR+CBCMAC、AES CTR+UMAC、AES-OCB暗号化、および認証アルゴリズムに必要です、100Mbpsのライン料率で作動して、1Gbpsと10Gbps、1500の八重奏パケットを仮定して。
Source: 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.
100Mbpsの速度では、アルゴリズムは高速演算処理装置で実装可能です。 1Gbpsの速度では、複数の高速演算処理装置が必要です、そして、アルゴリズムのいずれもソフトウェアで10Gbpsライン料率で実装可能ではありません。
Aboba, et al. Standards Track [Page 68] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[68ページ]RFC3723
Authors' Addresses
作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 425 706、6605Fax: +1 7329年の425 936メール: bernarda@microsoft.com
Joshua Tseng McDATA Corporation 3850 North First Street San Jose, CA 95134-1702
北の最初の通りサンノゼ、ジャシュアツェンMcDATA社3850のカリフォルニア95134-1702
Phone: +1 650 207 8012 EMail: joshtseng@yahoo.com
以下に電話をしてください。 +1 8012年の650 207メール: joshtseng@yahoo.com
Jesse Walker Intel Corporation 2211 NE 25th Avenue Hillboro, OR 97124
第25ジェシーウォーカーインテル社2211NeアベニューHillboro、または97124
Phone: +1 503 712 1849 Fax: +1 503 264 4843 EMail: jesse.walker@intel.com
以下に電話をしてください。 +1 503 712、1849Fax: +1 4843年の503 264メール: jesse.walker@intel.com
Venkat Rangan Brocade Communications Systems Inc. 1745 Technology Drive, San Jose, CA 95110
サンノゼ、カリフォルニア 株式会社1745技術ドライブ、ヴェンカトRangan錦の通信網95110
Phone: +1 408 333 7318 Fax: +1 408 333 7099 EMail: vrangan@brocade.com
以下に電話をしてください。 +1 408 333、7318Fax: +1 7099年の408 333メール: vrangan@brocade.com
Franco Travostino Director, Content Internetworking Lab Nortel Networks 3 Federal Street Billerica, MA 01821
フランコTravostinoディレクター、ビルリカ、満足しているインターネットワーキング研究室ノーテルネットワーク3の連邦政府の通りMA 01821
Phone: +1 978 288 7708 EMail: travos@nortelnetworks.com
以下に電話をしてください。 +1 7708年の978 288メール: travos@nortelnetworks.com
Aboba, et al. Standards Track [Page 69] RFC 3723 Securing Block Storage Protocols over IP April 2004
Aboba、他 2004年4月にIPの上でブロックストレージがプロトコルであると機密保護する標準化過程[69ページ]RFC3723
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)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboba, et al. Standards Track [Page 70]
Aboba、他 標準化過程[70ページ]
一覧
スポンサーリンク
