[要約] RFC 4173は、iSCSIプロトコルを使用してクライアントを起動するための手法を提供しています。このRFCの目的は、ネットワーク経由でクライアントを起動するための標準的な手順を定義することです。
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
インターネットを使用してクライアントをブートストラップする小さなコンピューターシステムインターフェイス（ISCSI）プロトコル
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).
Copyright（c）The Internet Society（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.
Internet Small Computer System Interface（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.
Small Computer Systems Interface（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ネットワークは、SCSIの輸送の建築およびパフォーマンスの要件を満たし、ISCSIプロトコルへの道を開きます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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アドレス（IPv6またはIPv4）。（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.
3. ISCSIブートクライアントは、上記の情報や能力を開始時に使用しないことができます。
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.
5. ISCSIセッションに必要な最小情報が提供されていない場合、追加のプロトコルソフトウェア（たとえば、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）[Brownell96]で定義された拡張機能を介して、逆アドレス解像度プロトコル（RARP）[Finlayson84]は、ネットワークアドレスの発見の問題に明示的に対処し、自動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サーバーには、Bootクライアントからのリクエストに応じてソフトウェア画像を提供できるサーバーの場所を提供する機能があります。
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.
起動時に、この情報はすべて、または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.
Power-onでIPアドレスがわからないISCSIブートクライアントは、BOOTPまたはDHCP（V4またはV6）を介して、またはIPv6アドレスAutoconfigurationを介して取得する場合があります。DHCP設定（DHCPV6のRA設定など）は、ISCSIブート情報の分布における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>
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.
フィールド「servername」、「ポート」、「プロトコル」、および「lun」はオプションであり、対応する値がない場合は空白のままにする必要があります。「TargetName」フィールドはオプションではなく、提供する必要があります。
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.
「servername」はISCSIサーバーの名前であり、有効なドメイン名、リテラルIPv4アドレス、またはリテラルIPv6アドレスのいずれかが含まれています。Servernameは、URI仕様[LEE98] [HindEN99]のセクション3.2.2で概説されている仕様に従う必要があります。許可されている文字は、同じ仕様のセクション2.2にも準拠する必要があります。この分野では、servername圧縮を使用しないでください。
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が承認した文字列の小数表現です。プロトコルフィールドが左銀行である場合、デフォルト値は
"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ブートサーバーが聴いているポートの小数表現です。指定されていない場合、ポートはよく知られている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.
SCSIターゲットは、異なるSCSIイニシエーターに異なるLU番号を提示することが許可されていることに注意してください。したがって、私たちの知る限り、SCSIターゲットは、いくつかの異なるLUSをそれぞれのLUN 0としていくつかの異なるSCSIイニシエーターにエクスポートすることを妨げるものはありません。
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].
「TargetName」フィールドは、ISCSI標準[SATRAN02]によって定義されるISCSI名です。ISCSIターゲットを一意に識別します。TargetNameフィールドの承認された文字は、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).
「servername」フィールドがbootpまたはdhcpによって提供されている場合、そのフィールドは他の関連フィールドと併用して、ブートステージのブートサーバーに連絡します（セクション7）。ただし、「servername」フィールドが提供されていない場合、「TargetName」フィールドが他の関連フィールドと組み合わせてディスカバリーサービス段階で使用されます（セクション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サーバーがTargetName以外の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段階でISCSIブートサーバーのターゲット名を取得した可能性があります（セクション5）。その場合、ISCSIブートクライアントは、ISCSI SLPインタラクションドキュメント[bakke02]のセクション6.2で指定されているISCSIターゲットコンクリートサービスタイプテンプレートのクエリ文字列1を使用して、SLPディスカバリーサービスをクエリし、ターゲット名をIPアドレスに解決し、ポート番号。あるいは、ISCSIブートクライアントは、Queryパラメーター[TSENG03]としてTargetNameを使用したデバイス属性クエリを使用して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ブートクライアントは、ISCSI SLP相互作用ドキュメント[bakke02]のセクション6.2で指定されているISCSIターゲットコンクリートサービスタイプテンプレートのクエリ文字列4でSLPディスカバリーサービスを照会することができます。。このクエリに応じて、SLP Discovery ServiceはブートクライアントにISCSIブートサーバーのリストを提供します。ブートクライアントはアクセスできます。あるいは、ISCSIブートクライアントは、ISNSディスカバリーサービスを照会して、特定のディスカバリードメインのターゲットが起動可能かどうかを確認できます[TSENG03]。
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つの重要な違いは、ブートステージが起動したときにブートイメージのIDがわからない可能性があるという事実です。特定のブートイメージとその場所の身元は、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ブートクライアントはDHCP認証（[DROMS01]、[DROMS02]をIPv6の[DROMS02]）を実装する必要があります。この場合、ネットワークインターフェイスがマザーボード上にあり、それが取り外し可能な場合の両方で、DHCP認証資格情報の構成には、管理インターフェイスを提供する必要があります。DHCP認証（IPv6の[DROMS01]、[DROMS02]）は、ISCSIブートシナリオで十分であると想定されるドメイン内認証に焦点を当てていることに注意してください。安全なISCSIブートプロセスのコンテキストでは、DHCP段階のDHCPサーバーからの返信には、DNSサーバー（名前の解決用）またはディスカバリーサービスエンティティへの依存を避けるために、IPv4（またはIPv6）形式のServername（またはIPv6）形式を含める必要があります。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.
[Bakke02]および[aboba03]で定義されているように、ISCSIブートクライアントはSLPを使用して実装されている場合、ISCSIブートクライアントはSLPプロトコルにIPSECサポート（使用をオプション）を提供する必要があります。ISNSを使用してディスカバリーサービス段階が実装されている場合、ISCSIブートクライアントは、[TSENG03]および[Aboba03]で定義されている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およびINバンド認証は、主要なISCSIドラフト[SATRAN02]および[Aboba03]のガイドラインに従って実装する必要があります。メモリの制約により、ISCSIブートクライアントは、IKEの事前共有キー認証のみをサポートすることが予想されます。ホストIPアドレスが動的に割り当てられている場合、[satran02]および[aboba03]で説明されているように、ikeメインモードを使用しないでください。以前の段階（DHCP、SLP、ISNS）のパラメーターが取得された方法（安全かどうか）に関係なく、ISCSIブートセッションは、ISCSIセッションのように脆弱です（ISCSIセキュリティの脅威については[satran02]および[aboba03]を参照）。したがって、このセッションのセキュリティは、[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ブートチームを設立するためのイニシアチブを取ってくれたJohn Hufferdに感謝したいと思います。また、Doug Otis、Julian Satran、Bernard Aboba、David Robinson、Mark Bakke、Ofer 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.、Tseng、J.、Walker、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] Alexander、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.
[Bakke02] Bakke、M.、Hufferd、J.、Voruganti、K.、Krueger、M.、およびT. Sperry、「インターネット小型コンピューターシステムインターフェイス（ISCSI）ターゲットと名前サーバーを使用して、Service Location Protocolバージョン2（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。、「インターネット小型コンピューターシステムインターフェイス（ISCSI）名前の文字列プロファイル」、RFC 3722、2004年4月。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Croft85] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[Croft85] Croft、W。およびJ. Gilmore、「Bootstrap Protocol」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[Guttman99] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[Guttman99] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン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.
[Hinden99] Hinden、R.、Carpenter、B。、およびL. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[Lee98] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[Lee98] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, August 1993.
[Reynolds93] Reynolds、J。、「Bootp Vendor Information Extensions」、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.、Meth、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] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、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.
[Wimer93] Wimer、W。、「ブートストラッププロトコルの明確化と拡張」、RFC 1542、1993年10月。
Informative References
参考引用
[Brownell96] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.
[Brownell96] Brownell、D。、「自動ネットワークアドレスの取得のための動的RARP拡張機能」、RFC 1931、1996年4月。
[Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[Finlayson84] Finlayson、R.、Mann、T.、Mogul、J。、およびM. Theimer、「Reverse Address Resolution Protocol」、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 Sarkar IBM Almaden Research Center 650 Harry Road San Jose、CA 95120、USA
Phone: +1 408 927 1417
EMail: psarkar@almaden.ibm.com
Duncan Missimer Hewlett-Packard Company 10955 Tantau Ave Cupertino, CA 95014, USA
Duncan Missimer Hewlett-Packard Company 10955 Tantau Ave Cupertino、CA 95014、USA
EMail: duncan.missimer@ieee.org
Constantine Sapuntzakis Stanford University 353 Serra Hall #407 Stanford, CA 94305, USA
コンスタンティン・サプンツァキス・スタンフォード大学353セラ・ホール＃407スタンフォード、カリフォルニア州94305、米国
EMail: csapuntz@alum.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。