Network Working Group P. Sarkar
Request for Comments: 4173 IBM
Category: Standards Track D. Missimer
Hewlett-Packard Company
C. Sapuntzakis
Stanford University
September 2005
Bootstrapping Clients using
the Internet Small Computer System Interface (iSCSI) Protocol
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.
インターネット小型コンピュータシステムインタフェース（iSCSIは）TCPの上で動作小型コンピュータシステムインタフェース（SCSI）のために提案されているトランスポートプロトコルです。このメモは、iSCSIプロトコルを使用して自分自身をブートストラップするようにクライアントを有効にするための標準的なメカニズムを説明しています。この規格の目的は、iSCSIブートサーバーとのiSCSIセッションを開くための情報を得るために、iSCSIブートクライアントを有効にすることです。
The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. SCSI can be characterized as a request/response messaging protocol with a standard architecture and componentized command sets for different device classes.
小型コンピュータシステムインタフェース（SCSI）は、I / Oデバイス、特にストレージデバイスと通信するためのプロトコルの人気のファミリーです。 SCSIは、異なるデバイスクラスのための標準的なアーキテクチャおよびコンポーネント化コマンドセットとの要求/応答メッセージングプロトコルとして特徴付けることができます。
iSCSI is a proposed transport protocol for SCSI that operates on top of TCP. The role of iSCSI is necessitated by the evolution of the system interconnect from a shared bus to a switched network. IP networks meet the architectural and performance requirements of transporting SCSI, paving the way for the iSCSI protocol.
iSCSIはTCPの上で動作SCSIのための提案のトランスポートプロトコルです。 iSCSIのの役割は、スイッチドネットワークへの共有バスからシステム相互接続の進化により必要とされます。 IPネットワークは、iSCSIプロトコルのための道を開く、SCSI輸送の建築とパフォーマンスの要件を満たしています。
Many diskless clients sometimes bootstrap off remote SCSI devices. Such diskless entities are lightweight, space efficient, and power-conserving and are increasingly popular in various environments.
多くのディスクレスのクライアントは、時々、リモートのSCSIデバイスをオフにブートストラップ。このようなディスクレスエンティティは、軽量、省スペース、および電力節約され、様々な環境でますます人気があります。
This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. It is possible that all the information is not available at the very outset, so the memo describes steps to obtain the information required to bootstrap clients off an iSCSI boot server.
このメモは、iSCSIプロトコルを使用して自分自身をブートストラップするようにクライアントを有効にするための標準的なメカニズムを説明しています。この規格の目的は、iSCSIブートサーバーとのiSCSIセッションを開くための情報を得るために、iSCSIブートクライアントを有効にすることです。すべての情報が非常に冒頭で利用できないので、メモはiSCSIブートサーバーからクライアントをブートストラップするために必要な情報を取得する手順を説明している可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Bradner97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [Bradner97]に記載されているように解釈されます。
1. There must be no restriction of network topology between the iSCSI boot client and the boot server other than that in effect for establishing the iSCSI session. Consequently, it is possible for an iSCSI boot client to boot from an iSCSI boot server behind gateways or firewalls as long as it is possible to establish an iSCSI session between the client and the server.
1. iSCSIブートクライアントおよびiSCSIセッションを確立するための効果よりも、他のブート・サーバ間のネットワークトポロジーの制限があってはいけません。 iSCSIブートクライアントがいる限り、クライアントとサーバ間のiSCSIセッションを確立することが可能であるとして、ゲートウェイまたはファイアウォールの背後にあるiSCSIブートサーバーからブートするために結果的に、それが可能です。
2. The following represent the minimum information required for an iSCSI boot client to contact an iSCSI boot server: (a) the client's IP address (IPv6 or IPv4); (b) the server's iSCSI Target Name; and (c) mandatory iSCSI initiator capability.
2. iSCSIブートサーバーに接続するためにiSCSIブートクライアントに必要な最低限の情報を表し、以下：（a）は、クライアントのIPアドレス（IPv4またはIPv6）。 （b）は、サーバーのiSCSIターゲット名。及び（C）の必須iSCSIイニシエータ機能。
The above assume that the default LUN for the boot process is 0 and that the default port for the iSCSI boot server is the well-known iSCSI port [Satran02]. However, both may be overridden at the time of configuration.
上記は、ブート・プロセスのデフォルトのLUNが0であると仮定し、iSCSIブートサーバのデフォルトのポートことはよく知られているiSCSIポート[Satran02]です。しかし、両方は、構成時に上書きされてもよいです。
Additional information may be required at each stage of the boot process.
追加情報は、ブートプロセスの各段階で必要になることがあります。
3. It is possible for the iSCSI boot client to have none of the above information or capability on starting.
iSCSIブートクライアントが起動に関する上記の情報や機能を全く持たないようにするために3。それは可能です。
4. The client should be able to complete boot without user intervention (for boots that occur during an unattended power-up). However, there should be a mechanism for the user to input values so as to bypass stages of the boot protocol.
4.クライアントは（無人パワーアップ時に発生するブーツのための）ユーザーの介入なしでブートを完了することができるはずです。ブート・プロトコルの段階をバイパスするようにしかし、入力値のユーザのためのメカニズムが存在すべきです。
5. Additional protocol software (for example, BOOTP or DHCP) may be necessary if the minimum information required for an iSCSI session is not provided.
iSCSIセッションのために必要な最低限の情報が提供されない場合5.追加のプロトコル・ソフトウェア（例えば、BOOTPまたはDHCP）が必要であってもよいです。
The Reverse Address Resolution Protocol (RARP) [Finlayson84] through the extensions defined in the Dynamic RARP (DRARP) [Brownell96] explicitly addresses the problem of network address discovery, and includes an automatic IP address assignment mechanism. The Trivial File Transfer Protocol (TFTP) [Sollins81] provides for transport of a boot image from a boot server. BOOTP [Croft85, Reynolds93, Wimer93] is a transport mechanism for a collection of configuration information. BOOTP is also extensible, and official extensions have been defined for several configuration parameters. DHCPv4 [Droms97, Droms93] and DHCPv6 [Droms02] are standards by which hosts are to be dynamically configured in an IP network. The Service Location Protocol (SLP) provides for location of higher-level services [Guttman99].
ダイナミックなRARP（DRARP）で定義された拡張による逆アドレス解決プロトコル（RARP）[Finlayson84]は[Brownell96]明示的にネットワークアドレス発見の問題に対処し、自動IPアドレス割り当て機構を含みます。トリビアルファイル転送プロトコル（TFTP）Sollins81]は、ブートサーバからブート・イメージの輸送を提供します。 BOOTP [Croft85、Reynolds93、Wimer93]構成情報の収集のためのトランスポート機構です。 BOOTPも拡張可能であり、そして公式の拡張機能には、いくつかの設定パラメータのために定義されています。 DHCPv4 [Droms97、Droms93]とDHCPv6は[Droms02】ホストが動的IPネットワークで構成すべきことによって規格です。サービスロケーションプロトコル（SLP）は、より高いレベルのサービス[Guttman99]の場所を提供します。
Some iSCSI boot clients may lack the resources to boot up with the mandatory iSCSI initiator capability. Such boot clients may choose to obtain iSCSI initiator software from a boot server. Currently, many established protocols allow such a service in order to enable clients to load software images. For example, BOOTP and DHCP servers have the capability to provide the locations of servers that can serve software images on requests from boot clients.
一部のiSCSIブートクライアントには必須のiSCSIイニシエータ機能を起動するためのリソースが不足していることがあります。このようなブートクライアントはブートサーバーからiSCSIイニシエータソフトウェアを入手することもできます。現在、多くの確立されたプロトコルは、ソフトウェアイメージをロードするために、クライアントを有効にするために、このようなサービスを可能にします。たとえば、BOOTPおよびDHCPサーバは、ブートクライアントからの要求にソフトウェアイメージを提供することができ、サーバの場所を提供する能力を有しています。
Note that this document does not recommend any of the above protocols, and the final decision of which boot protocol is to be used to load iSCSI initiator software is left to the discretion of the implementor.
この文書は、上記のプロトコルのいずれかをお勧めしていませんし、ブートプロトコルは、iSCSIイニシエータソフトウェアをロードするために使用されるべきで、最終的な決定は、実装者の裁量に任されていることに注意してください。
In order to use an iSCSI boot server, the following pieces of information are required for an ISCSI boot client.
iSCSIブートサーバーを使用するためには、以下の情報は、iSCSIブートクライアントのために必要とされます。
- The IP address of the iSCSI boot client (IPv4 or IPv6)
- iSCSIブートクライアントのIPアドレス（IPv4またはIPv6）
- The IP transport endpoint for the iSCSI Target Port for the iSCSI boot server. If the transport is TCP, for example, this has to resolve to an IP address and a TCP port number. TCP is currently the only transport approved for iSCSI.
- iSCSIブートサーバーのiSCSIターゲットポートのためのIPトランスポートエンドポイント。トランスポートがTCPである場合、例えば、これは、IPアドレスとTCPポート番号に解決しなければなりません。 TCPは現在、iSCSIに承認された唯一の輸送です。
- The eight-byte LUN structure identifying the Logical Unit within the iSCSI boot server.
- iSCSIブートサーバー内の論理ユニットを特定する8バイトのLUN構造。
At boot time, all or none of this information may be stored in the iSCSI boot client. This section describes techniques for obtaining the required information via the DHCP stage. Otherwise, if the iSCSI boot client has all the information, the boot client may proceed directly to the Boot stage.
ブート時には、この情報のすべてまたはnoneは、iSCSIブートクライアントに保存することができます。このセクションでは、DHCPの段階を経て、必要な情報を取得するための手法について説明します。 iSCSIブートクライアントは、すべての情報を持っている場合はそうでない場合は、ブートクライアントはブート段階に直接進むことができます。
An iSCSI boot client that does not know its IP address at power-on may acquire it via BOOTP or DHCP (v4 or v6), or via IPv6 address autoconfiguration. Please note that DHCP settings (such as the RA settings in DHCPv6) may prohibit the use of DHCP in distributing iSCSI boot information; in this case, the DHCP stage cannot be used.
電源投入時にそのIPアドレスを知らないiSCSIブートクライアントがBOOTPまたはDHCP（V4またはV6）、またはIPv6アドレスの自動構成経由経由で取得することができます。 iSCSIブート情報を配布するにはDHCPの使用を禁止することができる（たとえば、DHCPv6の中にRAの設定など）がDHCPの設定に注意してください。この場合には、DHCPステージが使用することはできません。
Unless specified otherwise here, BOOTP or DHCP fields such as the client ID and gateway information are used in an identical way as applications other than iSCSI.
そうでない場合は、ここで指定しない限り、このようなクライアントIDおよびゲートウェイ情報などのBOOTPまたはDHCPフィールドは、iSCSI以外のアプリケーションとして同じ方法で使用されています。
A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach its boot device. This is done using the variable-length option named Root Path [Alexander93, Reynolds93]. The use of the option field is reserved for iSCSI boot use by prefacing the string with "iscsi:". The Root Path option is not currently defined for DHCPv6; if the option is defined for DHCPv6 in the future, the use of the option as defined for iSCSI boot will apply.
BOOTPまたはDHCPサーバ（V4またはV6）そのブートデバイスに到達するためにどのようにiSCSIクライアントに指示することができます。これは、ルートパス[Alexander93、Reynolds93]という名前の変数の長さのオプションを使用して行われます。 「iSCSIの：」オプションフィールドの使用はして文字列を巻頭でiSCSIブート用に予約されています。ルートパスオプションは、現在のDHCPv6のために定義されていません。オプションは将来、DHCPv6のために定義されている場合、iSCSIブート用に定義されているオプションの使用が適用されます。
The option field consists of an UTF-8 [Yergeau98] string. The string has the following composition:
オプションフィールドには、UTF-8 [Yergeau98]文字列で構成されています。文字列は、以下の組成を有します：
"iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname>
"iSCSIの：" <サーバー名> "：" <プロトコル> "：" <ポート> "：" <LUN> "：" <ターゲット名>
The fields "servername", "port", "protocol", and "LUN" are OPTIONAL and should be left blank if there are no corresponding values. The "targetname" field is not optional and MUST be provided.
フィールド「サーバ名」、「ポート」、「プロトコル」、および「LUN」はオプションであり、該当する値がない場合は空白のままにすべきです。 「ターゲット名」フィールドはオプションではなく、提供されなければなりません。
The "servername" is the name of iSCSI server and contains either a valid domain name, a literal IPv4 address, or a literal IPv6 address. The servername must follow the specifications outlined in Section 3.2.2 of the URI Specification [Lee98] [Hinden99]. The characters allowed must also conform to Section 2.2 of the same specification. Servername compression MUST NOT be used in this field.
「サーバー名は、」iSCSIのサーバーの名前であり、有効なドメイン名、リテラルIPv4アドレス、またはリテラルIPv6アドレスのいずれかが含まれています。サーバー名は、URI仕様[Lee98] [Hinden99]のセクション3.2.2で示した仕様に従わなければなりません。使用できる文字は、同じ仕様のセクション2.2に準拠する必要があります。サーバー名の圧縮はこの分野で使用してはいけません。
The "protocol" field is the decimal representation of the IANA-approved string for the transport protocol to be used for iSCSI. If the protocol field is left bank, the default value is assumed to be
「プロトコル」フィールドには、iSCSIに使用するトランスポートプロトコルのためのIANAが承認した文字列の10進表現です。プロトコルフィールドが銀行を去っている場合は、デフォルト値があると想定されます
"6" for TCP. The transport protocol MUST have been approved for use in iSCSI; currently, the only approved protocol is TCP.
TCPのための "6"。トランスポートプロトコルは、iSCSIでの使用が承認されている必要があります。現在、唯一承認されたプロトコルがTCPです。
The "port" is the decimal representation of the port on which the iSCSI boot server is listening. If not specified, the port defaults to the well-known iSCSI port [Satran02].
「ポート」のiSCSIブートサーバーがリッスンしているポートの10進表現です。よく知られたiSCSIポート[Satran02]に、ポートのデフォルト値を指定しない場合。
The "LUN" field is a hexadecimal representation of the LU number. If the LUN field is blank, then LUN 0 is assumed. If the LUN field is not blank, the representation MUST be divided into four groups of four hexadecimal digits, separated by "-". Digits above 9 may be either lower or upper case. An example of such a representation would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three leading zero ("0") digits MAY be omitted in any group of hexadecimal digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent to 6734-0009-156f-0127. Furthermore, trailing groups containing only the "0" digit MAY be omitted along with the preceding "-". So, the "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. Other concise representations of the LUN field MUST NOT be used.
「LUN」フィールドは、LU番号の16進表現です。 LUNフィールドが空白の場合、LUN 0が想定されます。 「 - 」LUNフィールドが空白でない場合、表示はで区切られた4桁の16進数の4つのグループに分けなければなりません。 9上記の数字は、ケース下部または上部のいずれであってもよいです。そのような表現の例は4752-3A4F-6b7e-2F99であろう。簡潔にするために、最大で3先行ゼロ（「0」）の数字は、16進数の任意のグループでは省略されてもよいです。このように、 "LUN" 表現6734-9-156f-127は6734-0009-156f-0127と同等です。 「 - 」また、唯一の「0」の数字を含む後続群は、先行すると共に省略されるかもしれません。だから、「LUN」の表現4186から9は、4186-0009-0000-0000と同等です。 LUNフィールドの他の簡潔な表現を使用してはいけません。
Note that SCSI targets are allowed to present different LU numberings for different SCSI initiators, so to our knowledge nothing precludes a SCSI target from exporting several different LUs to several different SCSI initiators as their respective LUN 0s.
我々の知識の何がそれぞれのLUN 0として、いくつかの異なるSCSIイニシエータに複数の異なるLUをエクスポートするからSCSIターゲットを排除しないにように、SCSIターゲットは、異なるSCSIイニシエータに異なるLUの番号付けを提示するために許可されていることに注意してください。
The "targetname" field is an iSCSI Name that is defined by the iSCSI standard [Satran02] to uniquely identify an iSCSI target. The approved characters in the targetname field are stated in the iSCSI String Profile document[Bakke04].
「ターゲット名」フィールドは、一意のiSCSIターゲットを識別するためのiSCSI標準[Satran02]によって定義されるiSCSI名です。 [ターゲットフィールドで承認された文字は、iSCSIの文字列のプロフィール文書[Bakke04]に記載されています。
If the "servername" field is provided by BOOTP or DHCP, then that field is used in conjunction with other associated fields to contact the boot server in the Boot stage (Section 7). However, if the "servername" field is not provided, then the "targetname" field is then used in the Discovery Service stage in conjunction with other associated fields (Section 6).
「サーバー名」フィールドがBOOTPまたはDHCPによって提供されている場合、そのフィールドは、ブート段階（第7節）でブートサーバーに接続するために、他の関連する分野に関連して使用されます。 「サーバ名」フィールドが設けられていない場合は、次に「ターゲット名」フィールドは、他の関連するフィールド（第6）に関連してディスカバリサービス段階で使用されています。
This stage is required if the BOOTP or DHCP server (v4 or v6) is unaware of any iSCSI boot servers or if the BOOTP or DHCP server is unable to provide the minimum information required to connect to the iSCSI boot server, other than the targetname.
BOOTPまたはDHCPサーバ（V4またはV6）は、任意のiSCSIブートサーバーを認識していない場合、またはBOOTPまたはDHCPサーバがターゲット名以外のiSCSIブートサーバーに接続するために必要な最小限の情報を提供することができない場合は、この段階が必要です。
The Discovery Service may be based on the SLP protocol [Guttman99, Bakke02] and is an instantiation of the SLP Service or Directory Agent. Alternatively, the Discovery Service may be based on the iSNS protocol [Tseng03] and is an instantiation of the iSNS Server.
ディスカバリサービスは、SLPプロトコル[Guttman99、Bakke02]に基づいており、SLPサービスまたはディレクトリエージェントのインスタンスであることができます。代替的に、ディスカバリサービスは、iSNSプロトコル[Tseng03]に基づいており、iSNSサーバのインスタンスであることができます。
The iSCSI boot client may have obtained the targetname of the iSCSI boot server in the DHCP stage (Section 5). In that case, the iSCSI boot client queries the SLP Discovery Service using query string 1 of the iSCSI Target Concrete Service Type Template, as specified in Section 6.2 of the iSCSI SLP interaction document [Bakke02], to resolve the targetname to an IP address and port number. Alternatively, the iSCSI boot client may query the iSNS Discovery Service with a Device Attribute Query with the targetname as the query parameter [Tseng03]. Once this is obtained, the iSCSI boot client proceeds to the Boot stage (Section 7).
iSCSIブートクライアントには、DHCPの段階（第5節）でのiSCSIブートサーバーのターゲット名を取得している場合があります。その場合には、iSCSIブートクライアントは、iSCSI SLP相互作用ドキュメントのセクション6.2で指定されたIPアドレスにターゲット名を解決するために、[Bakke02]、iSCSIターゲットコンクリートサービスタイプテンプレートのクエリ文字列1を使用してSLPディスカバリサービスを照会し、ポート番号。また、iSCSIブートクライアントには、クエリパラメータ[Tseng03]としてターゲット名とクエリの属性のデバイスとiSNSのディスカバリサービスに照会することができます。これが取得されると、iSCSIブートクライアントはブート段階（第7節）に移行します。
It is possible that the port number obtained from the Discovery Service may conflict with the one obtained from the DHCP stage. In such a case, the implementor has the option to try both port numbers in the Boot stage.
ディスカバリサービスから取得したポート番号はDHCP段階から得られたものと競合する可能性があります。そのような場合には、実装者は、ブート段階で両方のポート番号を試すためのオプションを持っています。
If the iSCSI boot client does not have any targetname information, the iSCSI boot client may then query the SLP Discovery Service with query string 4 of the iSCSI Target Concrete Service Type Template, as specified in Section 6.2 of the iSCSI SLP interaction document [Bakke02]. In response to this query, the SLP Discovery Service provides the boot client with a list of iSCSI boot servers the boot client is allowed to access. Alternatively, the iSCSI boot client can query the iSNS Discovery Service to verify if the targets in particular Discovery Domain are bootable [Tseng03].
iSCSIブートクライアントが任意のターゲット名の情報を持っていない場合はiSCSIのSLP相互作用ドキュメントのセクション6.2で指定されているように、iSCSIブートクライアントはその後、iSCSIターゲットコンクリートサービスタイプテンプレートのクエリ文字列4とSLPディスカバリサービスに照会することができる[Bakke02] 。このクエリに応答して、SLPディスカバリサービスは、ブート・クライアントがアクセスを許可されているiSCSIブートサーバーのリストにブートクライアントを提供します。また、iSCSIブートクライアントには、特定の検出ドメイン内のターゲットは、[Tseng03]ブート可能かどうかを確認するためにiSNSのディスカバリサービスを照会することができます。
If the list of iSCSI boot servers is empty, subsequent actions are left to the discretion of the implementor. Otherwise, the iSCSI boot client may contact any iSCSI boot server in the list. Moreover, the order in which iSCSI boot servers are contacted is also left to the discretion of the implementor.
iSCSIブートサーバーのリストが空の場合は、後続のアクションは、実装者の裁量に委ねられています。それ以外の場合は、iSCSIブートクライアントは、リスト内の任意のiSCSIブートサーバーに連絡することができます。また、iSCSIブートサーバが接触される順番も実装者の裁量に任されています。
Once the iSCSI boot client has obtained the minimum information to open an iSCSI session with the iSCSI boot server, the actual booting process can start.
iSCSIブートクライアントは、iSCSIブートサーバーとのiSCSIセッションを開くための最低限の情報を取得した後は、実際の起動プロセスを開始することができます。
The actual sequence of iSCSI commands that are needed to complete the boot process is left to the implementor. This was done because of varying requirements from different vendors and equipment, making it difficult to specify a common subset of the iSCSI standard that would be acceptable to everybody.
ブートプロセスを完了するのに必要とされたiSCSIコマンドの実際の配列は、実装者に任されています。これは、それが困難皆に許容可能であるのiSCSI標準の共通サブセットを指定すること、理由は異なるベンダーや機器からの様々な要求のために行われました。
The iSCSI session established for boot may be taken over by the booted software in the iSCSI boot client.
ブートのために設立されたiSCSIセッションは、iSCSIブートクライアントで起動ソフトウェアによって引き継がれていてもよいです。
The security discussion is centered around securing the communication involved in the iSCSI boot process.
セキュリティの議論は、iSCSIブートプロセスに関与する通信の確保を中心とします。
However, the issue of applying credentials to a boot image loaded through the iSCSI boot mechanism is outside the scope of this document. One key difference between the iSCSI boot mechanism and BOOTP-based image loading is the fact that the identity of a boot image may not be known when the Boot stage starts. The identity of certain boot images and their locations are known only after the contents of a boot disk exposed by the iSCSI boot service are examined. Furthermore, images themselves may recursively load other images based on both hardware configurations and user input. Consequently, a practical way to verify loaded boot images is to make sure that each image loading software verifies the image to be loaded using a mechanism of their choice.
しかし、iSCSIブート機構を介してロードされたブートイメージに資格証明書を適用する問題は、この文書の範囲外です。 iSCSIブート機構とBOOTPベース画像のロードとの間の1つの重要な違いは、ブート段階の開始時にブートイメージのアイデンティティが知られていないかもしれないという事実です。特定のブートイメージとその場所のアイデンティティは、iSCSIブートサービスによって公開されたブートディスクの内容を検討された後にのみ知られています。また、画像自体を再帰的ハードウェア構成およびユーザ入力の両方に基づいて他の画像をロードすることができます。その結果、ロードされたブートイメージを確認するための実用的な方法は、各画像の読み込みソフトウェアが彼らの選択のメカニズムを使用してロードする画像を確認することを確認することです。
The considerations involved in designing a security architecture for the iSCSI boot process include configuration, deployment, and provisioning issues apart from typical security considerations. Enabling iSCSI boot creates a critical operational dependence on an external system with obvious security implications, and thus administrator awareness of this enablement is extremely important. Therefore, iSCSI boot SHOULD NOT be enabled or put high in the boot order without an explicit administrative action.
iSCSIブート・プロセスのためのセキュリティアーキテクチャを設計に関わる検討事項は、構成、展開、および一般的なセキュリティ上の配慮から離れて問題のプロビジョニングが含まれます。 iSCSIブートを有効にすると、明らかなセキュリティ上の意味を持つ外部システム上の重要な業務の依存を作成し、この有効化のため、管理者の意識が非常に重要です。したがって、iSCSIブートを有効にするか、明示的な管理操作なしでブート順で高く置かれるべきではありません。
In all phases of the boot process, a client must ensure that a server is authorized to send it certain information. This means that the authenticated identity of a server must have an authorization indication. A list of authorized servers can be pre-configured into a client, or the list can be downloaded in an authenticated form from a prior stage in the boot process.
ブートプロセスのすべての段階では、クライアントは、サーバがそれに特定の情報を送信することを許可されていることを確認する必要があります。これは、サーバーの認証されたアイデンティティが許可表示を持たなければならないことを意味します。承認されたサーバーのリストがクライアントに予め設定することができ、またはリストは、ブートプロセスの前の段階から認証された形式でダウンロードすることができます。
The software stage SHOULD NOT be involved in a secure iSCSI boot process, as this would add the additional complexity of trying to secure the process of loading the software necessary to run the later stages of iSCSI boot. Authentication and integrity protection of downloaded boot software has proven to be difficult and complex due to administrative issues and limitations of the BIOS environment. It is therefore assumed that all the necessary software is resident on the iSCSI boot client.
これは、iSCSIブートの後の段階を実行するために必要なソフトウェアをロードするプロセスを確保しようとしているの追加の複雑さを追加することになり、ソフトウェアのステージは、セキュアなiSCSIブートプロセスに関与すべきでありません。ダウンロードされたブートソフトウェアの認証と完全性保護が原因BIOS環境の管理上の問題と制限に困難かつ複雑であることが証明されました。したがって、必要なすべてのソフトウェアは、iSCSIブートクライアントに常駐していることが想定されます。
If the DHCP stage is implemented using the DHCP protocol, the iSCSI boot client SHOULD implement the DHCP authentication ([Droms01], [Droms02] for IPv6). In this case, an administration interface SHOULD be provided for the configuration of the DHCP authentication credentials, both when the network interface is on the motherboard and when it is removable. Note that DHCP authentication ([Droms01],[Droms02] for IPv6) is focused on intra-domain authentication, which is assumed to be enough for iSCSI boot scenarios. In the context of the secure iSCSI boot process, the reply from the DHCP server in the DHCP stage SHOULD include the serverName in IPv4 (or IPv6) format to avoid reliance on a DNS server (for resolving names) or a Discovery Service entity (to look up targetnames). This reduces the number of entities involved in the secure iSCSI boot process.
DHCPステージはDHCPプロトコルを使用して実装されている場合は、iSCSIブートクライアントには、（[Droms01]、[Droms02] IPv6用）DHCP認証を実装する必要があります。この場合、管理インタフェースは、DHCP認証クレデンシャルの構成に提供されるべき両方のネットワークインタフェースは、マザーボード上にある場合、それは取り外し可能である場合。そのDHCP認証（[Droms01]、[Droms02] IPv6用）iSCSIブートのシナリオのために十分であると仮定され、ドメイン内の認証、に焦点を当てていることに注意してください。セキュアなiSCSIブート・プロセスのコンテキストでは、DHCPの段階でのDHCPサーバからの応答がIPv4（またはIPv6）のServerNameを含むべきである（名前を解決するための）DNSサーバへの依存を避けるために、フォーマットやディスカバリサービスエンティティ（へ）targetnamesを見上げます。これは、セキュアなiSCSIブートプロセスに関与するエンティティの数を減らすことができます。
If the Discovery Service stage is implemented using SLP, the iSCSI boot client SHOULD provide IPsec support (OPTIONAL to use) for the SLP protocol, as defined in [Bakke02] and [Aboba03]. If the Discovery Service stage is implemented using iSNS, the iSCSI boot client SHOULD provide IPsec support (OPTIONAL to use) for the iSNS protocol, as defined in [Tseng03] and [Aboba03]. When iSNS or SLP are used to distribute security policy or configuration information, at a minimum, per-packet data origin authentication, integrity, and replay protection SHOULD be used to protect the discovery protocol.
ディスカバリサービスステージはSLPを使用して実装されている場合、iSCSIブートクライアントは、[Aboba03] [Bakke02]で定義されるように、SLPプロトコルに（使用するオプションの）IPsecサポートを提供すべきです。ディスカバリサービスステージはISNを使用して実装されている場合[Aboba03] [Tseng03]で定義されたように、iSCSIブートクライアントは、iSNSのプロトコルのために（使用するオプションの）IPsecサポートを提供すべきです。 iSNSのか、SLPは、セキュリティポリシーや設定情報を配布するために使用されている場合は、最低でも、パケット単位のデータ発信元認証、完全性、および再生保護を発見プロトコルを保護するために使用されるべきです。
For the final communication between the iSCSI boot client and the iSCSI boot server in the Boot stage, IPsec and in-band authentication SHOULD be implemented according to the guidelines in the main iSCSI draft [Satran02] and [Aboba03]. Due to memory constraints, it is expected that iSCSI boot clients will only support the pre-shared key authentication in IKE. Where the host IP address is assigned dynamically, IKE main mode SHOULD NOT be used, as explained in [Satran02] and [Aboba03]. Regardless of the way parameters in previous stages (DHCP, SLP, iSNS) were obtained (securely or not), the iSCSI boot session is vulnerable as any iSCSI session (see [Satran02] and [Aboba03] for iSCSI security threats). Therefore, security for this session SHOULD be configured and used according to [Satran02] and [Aboba03] guidelines.
iSCSIブートクライアントとブート段階でiSCSIブートサーバとの間の最終的な通信のために、IPsecとインバンド認証は、メインのiSCSIドラフト[Satran02]及び[Aboba03]のガイドラインに従って実施されるべきです。メモリの制約のために、iSCSIブートクライアントにのみIKEで事前共有キー認証をサポートすることが期待されます。ホストのIPアドレスが動的に割り当てられている場合、IKEメインモードは、[Aboba03] [Satran02]で説明したように、使用されるべきではありません。かかわらず、前の段階（DHCP、SLP、iSNSの）内のパラメータが得られた方法（安全かどうか）の、iSCSIブートセッションは、任意のiSCSIセッションとして脆弱である（[Satran02]を参照し、[Aboba03] iSCSIセキュリティの脅威のために）。したがって、このセッションのセキュリティは[Satran02]及び[Aboba03]ガイドラインに従って構成及び使用されるべきです。
Note that if a boot image inherits an iSCSI session from a previously loaded boot image, it also inherits the security properties of the iSCSI session.
ブートイメージがあらかじめロードされたブートイメージからiSCSIセッションを継承した場合、それはまた、iSCSIセッションのセキュリティプロパティを継承することに注意してください。
Acknowledgements
謝辞
We wish to thank John Hufferd for taking the initiative to form the iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran, and Mallikarjun Chadalapaka for helpful suggestions and pointers regarding the draft document.
私たちは、iSCSIブートチームを形成するためのイニシアチブを取るためにジョンHufferdに感謝したいです。また、ドラフト文書に関する有用な提案やポインタのためのダグ・オーティス、ジュリアンSatran、バーナードAboba、デビッド・ロビンソン、マーク・Bakke、オフェルBiran、およびMallikarjun Chadalapakaに感謝したいです。
Normative References
引用規格
[Aboba03] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
【Aboba03] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[Alexander93] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[Alexander93]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[Bakke02] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)", RFC 4018, April 2005.
サービスロケーションプロトコルバージョン2を用いて[Bakke02] Bakke、M.、Hufferd、J.、Voruganti、K.、クルーガー、M.、およびT.スペリー、「検索インターネットスモールコンピュータシステムインタフェース（iSCSIの）ターゲットとネームサーバ（ SLPv2の）」、RFC 4018、2005年4月。
[Bakke04] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[Bakke04] Bakke、M.、RFC 3722 "インターネット小型コンピュータシステムインタフェース（iSCSIの）名前のストリングプロフィール"、2004年4月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Croft85] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
【Croft85]クロフト、W.及びJ.ギルモア、 "ブートストラッププロトコル"、RFC 951、1985年9月。
[Droms93] Droms, R., "Interoperation Between DHCP and BOOTP", RFC 1534, October 1993.
[Droms93] Droms、R.、 "DHCPとBOOTPの間の相互運用"、RFC 1534、1993年10月。
[Droms97] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[Droms97] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[Droms01] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[Droms01] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[Droms02] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
【Droms02] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[Guttman99] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
【Guttman99]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[Hinden99] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
"URLの中にリテラルIPv6アドレスのフォーマット" [Hinden99] HindenとR.、大工、B.、およびL. Masinter、RFC 2732、1999年12月。
[Lee98] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[Lee98]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, August 1993.
[Reynolds93]レイノルズ、J.、 "BOOTPベンダ情報拡張機能"、RFC 1497、1993年8月。
[Satran02] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
【Satran02] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[Tseng03] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, April 2005.
【Tseng03]ツェン、J.、ギボンズ、K.、Travostino、F.、デュレイニー、C.、およびJ. Souzaの、 "インターネットストレージネームサービス（iSNSの）"、RFC 4171、2005年4月。
[Yergeau98] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
【Yergeau98] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[Wimer 93] Wimer、WITH。、 "ブートストラップ・プロトコルのための明確化と拡大"、RFC 1542、1993年10月。
Informative References
参考文献
[Brownell96] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.
[Brownell96]ブラウネル、D.は、RFC 1931、1996年4月 "自動ネットワークの動的RARP拡張機能は、買収アドレス"。
[Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
【Finlayson84】フィンレイソン、R.、マン、T.、モーグル、J.、およびM. Theimer、 "逆アドレス解決プロトコル"、STD 38、RFC 903、1984年6月。
[Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
【Sollins81] Sollins、K.、 "TFTPプロトコル（改訂第2版）"、STD 33、RFC 1350、1992年7月。
Authors' Addresses
著者のアドレス
Prasenjit Sarkar IBM Almaden Research Center 650 Harry Road San Jose, CA 95120, USA
PrasenjitサルカールIBMアルマデン研究センター650ハリー・ロードサンノゼ、CA 95120、USA
Phone: +1 408 927 1417 EMail: psarkar@almaden.ibm.com
電話：+1 408 927 1417 Eメール：psarkar@almaden.ibm.com
Duncan Missimer Hewlett-Packard Company 10955 Tantau Ave Cupertino, CA 95014, USA
ダンカンMissimer米国Hewlett-Packard Company 10955 Tantauアベニュークパチーノ、CA 95014、USA
EMail: duncan.missimer@ieee.org
メールアドレス：duncan.missimer@ieee.org
Constantine Sapuntzakis Stanford University 353 Serra Hall #407 Stanford, CA 94305, USA
コンスタンティンSapuntzakisスタンフォード大学353セラホール＃407スタンフォード、CA 94305、USA
EMail: csapuntz@alum.mit.edu
メールアドレス：csapuntz@alum.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。