idnits 2.17.1 draft-faibish-nfsv4-pnfs-block-disk-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5663, but the abstract doesn't seem to directly say this. It does mention RFC5663 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5663, updated by this document, for RFC5378 checks: 2006-01-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2011) is 4594 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NFSv4 Working Group S. Faibish 2 Internet-Draft EMC Corporation 3 Intended status: draft J. Glasgow 4 Expires: March 28, 2012 Google 5 Updates: 5663 D. Black 6 Intended Status: Proposed Standard EMC Corporation 7 September 27, 2011 9 pNFS block disk protection 10 draft-faibish-nfsv4-pnfs-block-disk-protection-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on March 28, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to 53 enable direct client access to file data on storage, bypassing the 54 NFSv4 server. This can increase both performance and parallelism, 55 but requires additional client functionality, some of which depends 56 upon the type of storage used. The pNFS specification for block 57 storage (RFC 5663) describes how clients can identify the volumes 58 used for pNFS, but this mechanism requires communication with the 59 NFSv4 server. This document adds a mechanism to RFC 5663 that 60 enables identification of block storage devices used by pNFS file 61 systems without communicating with the server. This enables clients 62 to control access to pNFS block devices when the client initially 63 boots, as opposed to waiting until the client can communicate with 64 the NFSv4 server. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Conventions used in this document..............................4 70 3. GPT Partition Table Entry......................................4 71 4. Security Considerations........................................5 72 5. IANA Considerations............................................5 73 6. Conclusions....................................................5 74 7. References.....................................................5 75 7.1. Normative References......................................5 76 Authors' Addresses................................................6 78 1. Introduction 80 Figure 1 shows the overall architecture of a Parallel NFS (pNFS) 81 system: 83 +-----------+ 84 |+-----------+ +-----------+ 85 ||+-----------+ | | 86 ||| | NFSv4.1 + pNFS | | 87 +|| Clients |<------------------------------>| MDS | 88 +| | | | 89 +-----------+ | | 90 ||| +-----------+ 91 ||| | 92 ||| | 93 ||| Storage +-----------+ | 94 ||| Protocol |+-----------+ | 95 ||+----------------||+-----------+ Control | 96 |+-----------------||| | Protocol | 97 +------------------+|| Storage |------------+ 98 +| Devices | 99 +-----------+ 101 Figure 1 pNFS Architecture 103 In this document, "storage device" is used as a general term for a 104 data server and/or storage server for any pNFS layout type. The 105 MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts 106 to clients and handles operations on file metadata (e.g., names, 107 attributes). 109 For the pNFS block protocol as specified in [RFC5663], client 110 identification of pNFS storage devices requires contacting the MDS to 111 obtain device signature information. It is not possible for a pNFS 112 client to reliably identify pNFS block storage devices without 113 contacting the MDS because the device signature location and contents 114 may vary among devices and servers; both device signature location 115 and contents are determined by the MDS, not the client. 117 Typical operating system (OS) boot functionality scans and activates 118 block devices (e.g., SCSI) before activating the NFS client 119 (including pNFS functionality). That sequence of operations creates 120 a window of time during which the client OS may modify a pNFS block 121 device without contacting the server (e.g., by attempting to mount or 122 initialize a local physical filesystem). This document specifies an 123 identification mechanism for pNFS block storage devices that can be 124 used by an OS implementation to remove this window of vulnerability. 126 Many storage area network (SAN) storage systems provide quasi-static 127 access control mechanisms (e.g., Logical Unit Number (LUN) mapping 128 and/or masking) that operate at the granularity of individual hosts. 129 While it is feasible to use such mechanisms to remove this window 130 (e.g., by only enabling a client to access pNFS block storage devices 131 after the client has contacted the responsible MDS), that usage is 132 undesirable and potentially problematic. This is because the storage 133 access control mechanisms are quasi-static; they are typically 134 configured once to allow client access to the block pNFS storage 135 devices and not reconfigured dynamically (e.g., based on crashes and 136 reboots). Block storage access controls can be changed to respond to 137 unusual circumstances (e.g., to fence [remove access from] an 138 uncooperative pNFS client), but should not be used as part of routine 139 client operations (e.g., reboot). A different mechanism is needed. 141 This document specifies an entry in the GUID partition table (GPT) 142 that can be used to identify pNFS devices. This GPT entry is intended 143 for shared storage devices that are accessible to pNFS clients and 144 servers, and that may be accessible to other hosts or systems. 146 2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC-2119 [RFC2119]. 152 3. GPT Partition Table Entry 154 The following mechanism enables pNFS clients to identify pNFS block 155 storage devices without contacting the server: 157 - Each block storage device dedicated to pNFS includes a GUID 158 partition table (GPT) [GPT]. 160 - The pNFS Block Storage partitions are identified in the GPT with 161 GUID e5b72a69-23e5-4b4d-b176-16532674fc34. This GUID has been 162 generated by one of the draft authors for this purpose. 164 This mechanism enables an operating system to prevent non-pNFS access 165 to pNFS block storage immediately upon boot. Servers that support 166 pNFS block layouts SHOULD use the GPT and this GUID for all pNFS 167 block storage devices. 169 A pNFS client operating system that supports block layouts SHOULD 170 recognize this GUID and use its presence to prevent data access to 171 pNFS block devices until a layout that includes the device is 172 received from the MDS. 174 Data stored on pNFS block layout storage devices can be better 175 protected by incorporating checks for this GUID into other hosts and 176 systems that do not support pNFS block layouts. If pNFS block 177 storage devices are presented to such hosts or systems by mistake, 178 the check for presence of this GUID can be used to prevent writes 179 that could otherwise corrupt stored pNFS data. 181 As of 2011 many current operating system versions support GPT 182 including FreeBSD, Linux and Solaris [GPT]. 184 4. Security Considerations 186 The pNFS block layout security considerations in [RFC5663] apply to 187 this document. 189 5. IANA Considerations 191 There are no IANA considerations in this document. 193 6. Conclusions 195 This document specifies an identification mechanism for pNFS block 196 storage devices that can be used to protect those devices during 197 operating system boot before the pNFS meta data server can be 198 contacted. 200 7. References 202 7.1. Normative References 204 [GPT] http://en.wikipedia.org/wiki/GUID_Partition_Table 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, March 1997. 209 [RFC5663] Black, D., Glasgow, J., Fridella, S., "Parallel NFS (pNFS) 210 Block/Volume Layout", http://tools.ietf.org/html/rfc5663, 211 January 2010. 213 This document was prepared using 2-Word-v2.0.template.dot. 215 Authors' Addresses 217 Sorin Faibish (editor) 218 EMC Corporation 219 228 South Street 220 Hopkinton, MA 01748 221 US 223 Phone: +1 (508) 305-8545 224 Email: sfaibish@emc.com 226 Jason Glasgow 227 Google 228 5 Cambridge Center, Floors 3-6 229 Cambridge, MA 02142 230 US 232 Phone: +1 (617) 575 1599 233 Email: jglasgow@google.com 235 David L. Black 236 EMC Corporation 237 176 South Street 238 Hopkinton, MA 01748 239 US 241 Phone: +1 (508) 293-7953 242 Email: david.black@emc.com