rfc-6688

Parallel NFS (pNFS) Block Disk Protection

D. Black (Editor), J. Glasgow, S. Faibish

date2012-07 streamIETF areawit wgnfsv4 statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6688 doi10.17487/RFC6688

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. [STANDARDS-TRACK]

updates

rfc-5663 — Parallel NFS (pNFS) Block/Volume Layout

Extracted elements (10)

design-rationale §3

No central registration mechanism exists for GPT GUIDs, or GUIDs in general, by design (per RFC 4122). This document defines the GUID e5b72a69-23e5-4b4d-b176-16532674fc34 and its usage without requiring any central registry entry.

registry

design-rationale §1

OS boot sequences scan and activate block devices (e.g., SCSI) before activating the NFS/pNFS client, creating a window during which the client OS may modify a pNFS block device without contacting the server. This document specifies a GPT-based identification mechanism to close this vulnerability at boot time.

realtime, security

design-rationale §1

SAN access control mechanisms (LUN mapping/masking) are quasi-static and configured once; using them to gate pNFS device access dynamically (e.g., per reboot) is undesirable and potentially problematic. A different, lightweight mechanism is therefore needed for routine client operations.

security

design-rationale §1

Without this mechanism, a pNFS client cannot reliably identify pNFS block storage devices without contacting the MDS, because device signature location and contents vary among devices and servers and are determined by the MDS, not the client.

interoperability-note §3

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 by mistake, the GUID check can prevent writes that would otherwise corrupt pNFS data.

security

normative-requirement §3 SHOULD

A pNFS client operating system that supports block layouts SHOULD recognize the pNFS block storage 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.

security

normative-requirement §3 SHOULD

Servers that support pNFS block layouts SHOULD use the GPT and the GUID e5b72a69-23e5-4b4d-b176-16532674fc34 for all pNFS block storage devices.

protocol-element §3

Each block storage device dedicated to pNFS includes a GUID Partition Table (GPT). pNFS block storage partitions are identified in the GPT with GUID e5b72a69-23e5-4b4d-b176-16532674fc34, defined specifically for this purpose by this document.

registry

security-consideration §4

The pNFS block layout security considerations in RFC 5663 apply to this document in full.

security

security-consideration §4

The security considerations in RFC 4122 apply to the GUID specified in this document, including considerations around GUID uniqueness and the absence of a central registry.

security