[要約] RFC 6688は、Parallel NFS（pNFS）ブロックディスク保護に関する要件を定義しています。その目的は、pNFS環境でのデータの保護とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) D. Black, Ed.
Request for Comments: 6688 EMC Corporation
Updates: 5663 J. Glasgow
Category: Standards Track Google
ISSN: 2070-1721 S. Faibish
EMC Corporation
July 2012
Parallel NFS (pNFS) Block Disk Protection
Parallel NFS（pNFS）ブロックディスク保護
Abstract
概要
Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server.
Parallel NFS（pNFS）はNetwork File Systemバージョン4（NFSv4）を拡張して、ストレージデバイス上のファイルデータへの直接クライアントアクセスを可能にし、NFSv4サーバーをバイパスします。これにより、パフォーマンスと並列処理の両方を向上させることができますが、追加のクライアント機能が必要です。その一部は、使用するストレージのタイプによって異なります。ブロックストレージのpNFS仕様（RFC 5663）は、クライアントがpNFSに使用されるボリュームを識別する方法を説明していますが、このメカニズムにはNFSv4サーバーとの通信が必要です。このドキュメントはRFC 5663を更新して、サーバーと通信せずにpNFSファイルシステムで使用されるブロックストレージデバイスを識別できるメカニズムを追加します。これにより、クライアントがNFSv4サーバーと通信できるようになるまで待機するのではなく、クライアントが最初に起動するときに、クライアントはpNFSブロックデバイスへのアクセスを制御できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6688.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6688で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. GPT Partition Table Entry .......................................4
4. Security Considerations .........................................5
5. References ......................................................5
5.1. Normative References .......................................5
5.2. Informative References .....................................6
6. Acknowledgements.................................................6
Figure 1 shows the overall architecture of a Parallel NFS (pNFS) system:
図1は、Parallel NFS（pNFS）システムの全体的なアーキテクチャを示しています。
+-----------+
|+-----------+ +-----------+
||+-----------+ | |
||| | NFSv4.1 + pNFS | |
+|| Clients |<------------------------------>| MDS |
+| | | |
+-----------+ | |
||| +-----------+
||| |
||| |
||| Storage +-----------+ |
||| Protocol |+-----------+ |
||+----------------||+-----------+ Control |
|+-----------------||| | Protocol |
+------------------+|| Storage |------------+
+| Devices |
+-----------+
Figure 1. pNFS Architecture
図1. pNFSアーキテクチャー
In this document, "storage device" is used as a general term for a data server and/or storage server for any pNFS layout type. The MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts to clients and handles operations on file metadata (e.g., names and attributes).
このドキュメントでは、「ストレージデバイス」は、pNFSレイアウトタイプのデータサーバーやストレージサーバーの総称として使用されています。 MetaDataサーバー（MDS）は、クライアントにpNFSレイアウトを提供し、ファイルのメタデータ（名前や属性など）の操作を処理するNFSv4サーバーです。
For the pNFS block protocol as specified in [RFC5663], client identification of pNFS storage devices requires contacting the MDS to obtain device signature information. It is not possible for a pNFS client to reliably identify pNFS block storage devices without contacting the MDS, because the device signature location and contents may vary among devices and servers; both device signature location and contents are determined by the MDS, not the client.
[RFC5663]で指定されているpNFSブロックプロトコルの場合、pNFSストレージデバイスのクライアント識別では、MDSにアクセスしてデバイスの署名情報を取得する必要があります。デバイスシグネチャの場所と内容はデバイスやサーバーによって異なる可能性があるため、pNFSクライアントがMDSにアクセスせずにpNFSブロックストレージデバイスを確実に識別することはできません。デバイスシグネチャの場所と内容は、クライアントではなくMDSによって決定されます。
Typical operating system (OS) boot functionality scans and activates block devices (e.g., Small Computer System Interface (SCSI)) before activating the NFS client (including pNFS functionality). This sequence of operations creates a window of time during which the client OS may modify a pNFS block device without contacting the server (e.g., by attempting to mount or initialize a local physical filesystem). This document specifies an identification mechanism for pNFS block storage devices that can be used by an OS implementation to remove this window of vulnerability.
通常のオペレーティングシステム（OS）ブート機能は、NFSクライアント（pNFS機能を含む）をアクティブにする前に、ブロックデバイス（Small Computer System Interface（SCSI）など）をスキャンしてアクティブにします。この一連の操作により、クライアントOSがサーバーに接続せずに（たとえば、ローカルの物理ファイルシステムをマウントまたは初期化することによって）pNFSブロックデバイスを変更できる時間枠が作成されます。このドキュメントでは、この脆弱性のウィンドウを削除するためにOS実装で使用できるpNFSブロックストレージデバイスの識別メカニズムを指定します。
Many storage area network (SAN) storage systems provide quasi-static access control mechanisms (e.g., Logical Unit Number (LUN) mapping and/or masking) that operate at the granularity of individual hosts. While it is feasible to use such mechanisms to remove this window (e.g., by only enabling a client to access pNFS block storage devices after the client has contacted the responsible MDS), such usage is undesirable and potentially problematic. This is because the storage access control mechanisms are quasi-static; they are typically configured once to allow client access to the block pNFS storage devices and not reconfigured dynamically (e.g., based on crashes and reboots). Block storage access controls can be changed to respond to unusual circumstances (e.g., to fence [remove access from] an uncooperative pNFS client), but should not be used as part of routine client operations (e.g., reboot). A different mechanism is needed.
多くのストレージエリアネットワーク（SAN）ストレージシステムは、個々のホストの粒度で動作する準静的アクセス制御メカニズム（論理ユニット番号（LUN）マッピングやマスキングなど）を提供します。このようなメカニズムを使用してこのウィンドウを削除することは可能ですが（たとえば、クライアントが担当のMDSにアクセスした後でクライアントがpNFSブロックストレージデバイスにアクセスできるようにするだけで）、そのような使用法は望ましくなく、潜在的に問題があります。これは、ストレージアクセス制御メカニズムが準静的であるためです。これらは通常、クライアントがブロックpNFSストレージデバイスにアクセスできるように一度構成され、動的に再構成されません（たとえば、クラッシュや再起動に基づいて）。ブロックストレージアクセス制御は、異常な状況に対応するように変更できます（たとえば、非協力的なpNFSクライアントを隔離する）ことができますが、通常のクライアント操作（再起動など）の一部として使用しないでください。別のメカニズムが必要です。
This document specifies an entry in the GUID (Globally Unique Identifier) partition table (GPT) that can be used by a pNFS server to label pNFS storage devices. This GPT entry is intended for shared pNFS storage devices that are accessible to pNFS clients and servers, and that may be accessible to other hosts or systems. This entry enables pNFS clients, as well as other hosts and systems, to avoid accessing pNFS storage devices via means other than pNFS.
このドキュメントは、pNFSサーバーがpNFSストレージデバイスにラベルを付けるために使用できるGUID（Globally Unique Identifier）パーティションテーブル（GPT）のエントリを指定します。このGPTエントリは、pNFSクライアントおよびサーバーにアクセスでき、他のホストまたはシステムにアクセスできる共有pNFSストレージデバイスを対象としています。このエントリにより、pNFSクライアントだけでなく他のホストやシステムも、pNFS以外の手段でpNFSストレージデバイスにアクセスする必要がなくなります。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The following mechanism enables pNFS clients to identify pNFS block storage devices without contacting the server:
次のメカニズムにより、pNFSクライアントはサーバーに接続せずにpNFSブロックストレージデバイスを識別できます。
- Each block storage device dedicated to pNFS includes a GUID partition table (GPT) [GPT].
- pNFS専用の各ブロックストレージデバイスには、GUIDパーティションテーブル（GPT）[GPT]が含まれています。
- The pNFS block storage partitions are identified in the GPT with GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been generated for this purpose. GPT GUID usage is well understood and implemented. This document provides a definition for this GUID and its usage. A central registration mechanism does not exist for GPT GUIDs, or GUIDs in general, by design; see [RFC4122].
- pNFSブロックストレージパーティションは、この目的で生成されたGUID e5b72a69-23e5-4b4d-b176-16532674fc34を使用してGPTで識別されます。 GPT GUIDの使用法はよく理解され、実装されています。このドキュメントでは、このGUIDとその使用法の定義を提供します。 GPT GUID、または一般にGUIDの中心的な登録メカニズムは、設計上存在しません。 [RFC4122]を参照してください。
This mechanism enables an operating system to prevent non-pNFS access to pNFS block storage immediately upon boot. Servers that support pNFS block layouts SHOULD use the GPT and this GUID for all pNFS block storage devices.
このメカニズムにより、オペレーティングシステムは、起動直後にpNFSブロックストレージへの非pNFSアクセスを防止できます。 pNFSブロックレイアウトをサポートするサーバーは、すべてのpNFSブロックストレージデバイスに対してGPTとこのGUIDを使用する必要があります（SHOULD）。
A pNFS client operating system that supports block layouts SHOULD recognize this GUID and SHOULD use its presence to prevent data access to pNFS block devices until a layout that includes the device is received from the MDS.
ブロックレイアウトをサポートするpNFSクライアントオペレーティングシステムは、このGUIDを認識し（SHOULD）、その存在を使用して、デバイスを含むレイアウトがMDSから受信されるまで、pNFSブロックデバイスへのデータアクセスを防止する必要があります（SHOULD）。
Data stored on pNFS block layout storage devices can be better protected by incorporating checks for this GUID into other hosts and systems that do not support pNFS block layouts. If pNFS block storage devices are presented to such hosts or systems by mistake, the check for presence of this GUID can be used to prevent writes that could otherwise corrupt stored pNFS data.
pNFSブロックレイアウトをサポートしていない他のホストやシステムにこのGUIDのチェックを組み込むことで、pNFSブロックレイアウトストレージデバイスに保存されているデータをより適切に保護できます。 pNFSブロックストレージデバイスがそのようなホストまたはシステムに誤って提示された場合、このGUIDの存在のチェックを使用して、保存されているpNFSデータを破損する可能性のある書き込みを防止できます。
Many current operating system versions support the GPT [GPT-W].
現在のオペレーティングシステムの多くのバージョンがGPT [GPT-W]をサポートしています。
The pNFS block layout security considerations in [RFC5663] apply to this document.
[RFC5663]のpNFSブロックレイアウトセキュリティの考慮事項がこのドキュメントに適用されます。
The security considerations in [RFC4122] apply to the GUID specified in this document.
[RFC4122]のセキュリティに関する考慮事項は、このドキュメントで指定されているGUIDに適用されます。
[GPT] Unified EFI Forum, "Unified Extensible Firmware Interface Specification", Version 2.3.1, Errata A, Section 5.3, September 2011, available from http://www.uefi.org.
[GPT] Unified EFIフォーラム、「Unified Extensible Firmware Interface Specification」、バージョン2.3.1、エラッタA、セクション5.3、2011年9月、http：//www.uefi.orgから入手可能。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS (pNFS) Block/Volume Layout", RFC 5663, January 2010.
[RFC5663] Black、D.、Fridella、S。、およびJ. Glasgow、「Parallel NFS（pNFS）Block / Volume Layout」、RFC 5663、2010年1月。
[GPT-W] Wikipedia, "GUID Partition Table", July 2012, http://en.wikipedia.org/w/ index.php?title=GUID_Partition_Table&oldid=502098731.
[GPT-W]ウィキペディア、「GUIDパーティションテーブル」、2012年7月、http：//en.wikipedia.org/w/ index.php？title = GUID_Partition_Table＆oldid = 502098731。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、2005年7月。
This document was produced by the IETF NFSv4 Working Group. Review comments from members of the working group improved this document and are gratefully acknowledged. The authors would like to thank Tom Talpey, and members of the IESG for helpful comments on this document, and also Alex Burlyga for providing an appropriate reference for the format of the GPT.
このドキュメントは、IETF NFSv4ワーキンググループによって作成されました。ワーキンググループのメンバーからのレビューコメントは、この文書を改善し、ありがたく認められています。著者は、この文書に関する有益なコメントを提供してくれたTom TalpeyとIESGのメンバーに感謝します。また、GPTの形式について適切なリファレンスを提供してくれたAlex Burlygaにも感謝します。
Authors' Addresses
著者のアドレス
David L. Black (editor) EMC Corporation 176 South Street Hopkinton, MA 01748 USA Phone: +1 (508) 293-7953 EMail: david.black@emc.com
David L. Black（編集者）EMC Corporation 176 South Street Hopkinton、MA 01748 USA電話：+1（508）293-7953メール：david.black@emc.com
Jason Glasgow Google 5 Cambridge Center, Floors 3-6 Cambridge, MA 02142 USA Phone: +1 (617) 575-1599 EMail: jglasgow@google.com
Jason Glasgow Google 5 Cambridge Center、Floors 3-6 Cambridge、MA 02142 USA電話：+1（617）575-1599メール：jglasgow@google.com
Sorin Faibish EMC Corporation 228 South Street Hopkinton, MA 01748 USA Phone: +1 (508) 305-8545 EMail: sfaibish@emc.com
Sorin Faibish EMC Corporation 228 South Street Hopkinton、MA 01748 USA電話：+1（508）305-8545メール：sfaibish@emc.com