idnits 2.17.1 draft-ietf-nfsv4-pnfs-block-disk-protection-03.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 22, 2012) is 4324 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GPT' 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 D. Black (ed.) 2 Internet-Draft EMC Corporation 3 Intended status: Proposed Standard J. Glasgow 4 Expires: December YY, 2012 Google 5 Updates: 5663 S. Faibish 6 EMC Corporation 7 June 22, 2012 9 pNFS block disk protection 10 draft-ietf-nfsv4-pnfs-block-disk-protection-03 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 December 23, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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 updates RFC 5663 to add a mechanism 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. References.....................................................6 74 6.1. Normative References......................................6 75 6.2. Informative References....................................6 76 Acknowledgements..................................................6 77 Authors' Addresses................................................7 79 1. Introduction 81 Figure 1 shows the overall architecture of a Parallel NFS (pNFS) 82 system: 84 +-----------+ 85 |+-----------+ +-----------+ 86 ||+-----------+ | | 87 ||| | NFSv4.1 + pNFS | | 88 +|| Clients |<------------------------------>| MDS | 89 +| | | | 90 +-----------+ | | 91 ||| +-----------+ 92 ||| | 93 ||| | 94 ||| Storage +-----------+ | 95 ||| Protocol |+-----------+ | 96 ||+----------------||+-----------+ Control | 97 |+-----------------||| | Protocol | 98 +------------------+|| Storage |------------+ 99 +| Devices | 100 +-----------+ 102 Figure 1 pNFS Architecture 104 In this document, "storage device" is used as a general term for a 105 data server and/or storage server for any pNFS layout type. The 106 MetaData Server (MDS) is the NFSv4 server that provides pNFS layouts 107 to clients and handles operations on file metadata (e.g., names, 108 attributes). 110 For the pNFS block protocol as specified in [RFC5663], client 111 identification of pNFS storage devices requires contacting the MDS to 112 obtain device signature information. It is not possible for a pNFS 113 client to reliably identify pNFS block storage devices without 114 contacting the MDS because the device signature location and contents 115 may vary among devices and servers; both device signature location 116 and contents are determined by the MDS, not the client. 118 Typical operating system (OS) boot functionality scans and activates 119 block devices (e.g., SCSI) before activating the NFS client 120 (including pNFS functionality). That sequence of operations creates 121 a window of time during which the client OS may modify a pNFS block 122 device without contacting the server (e.g., by attempting to mount or 123 initialize a local physical filesystem). This document specifies an 124 identification mechanism for pNFS block storage devices that can be 125 used by an OS implementation to remove this window of vulnerability. 127 Many storage area network (SAN) storage systems provide quasi-static 128 access control mechanisms (e.g., Logical Unit Number (LUN) mapping 129 and/or masking) that operate at the granularity of individual hosts. 130 While it is feasible to use such mechanisms to remove this window 131 (e.g., by only enabling a client to access pNFS block storage devices 132 after the client has contacted the responsible MDS), that usage is 133 undesirable and potentially problematic. This is because the storage 134 access control mechanisms are quasi-static; they are typically 135 configured once to allow client access to the block pNFS storage 136 devices and not reconfigured dynamically (e.g., based on crashes and 137 reboots). Block storage access controls can be changed to respond to 138 unusual circumstances (e.g., to fence [remove access from] an 139 uncooperative pNFS client), but should not be used as part of routine 140 client operations (e.g., reboot). A different mechanism is needed. 142 This document specifies an entry in the GUID partition table (GPT) 143 that can be used by a pNFS server to label pNFS storage devices. This 144 GPT entry is intended for shared pNFS storage devices that are 145 accessible to pNFS clients and servers, and that may be accessible to 146 other hosts or systems. This entry enables pNFS clients as well as 147 other hosts and systems to avoid accessing pNFS storage devices via 148 means other than pNFS. 150 2. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC-2119 [RFC2119]. 156 3. GPT Partition Table Entry 158 The following mechanism enables pNFS clients to identify pNFS block 159 storage devices without contacting the server: 161 - Each block storage device dedicated to pNFS includes a GUID 162 partition table (GPT) [GPT]. 164 - The pNFS Block Storage partitions are identified in the GPT with 165 GUID e5b72a69-23e5-4b4d-b176-16532674fc34 which has been 166 generated for this purpose. GPT GUID usage is well understood 167 and implemented. This document provides a definition for this 168 GUID and its usage. A central registration mechanism does not 169 exist for GPT GUIDs, or GUIDs in general by design, see 170 [RFC4122]. 172 This mechanism enables an operating system to prevent non-pNFS access 173 to pNFS block storage immediately upon boot. Servers that support 174 pNFS block layouts SHOULD use the GPT and this GUID for all pNFS 175 block storage devices. 177 A pNFS client operating system that supports block layouts SHOULD 178 recognize this GUID and SHOULD use its presence to prevent data 179 access to pNFS block devices until a layout that includes the device 180 is received from the MDS. 182 Data stored on pNFS block layout storage devices can be better 183 protected by incorporating checks for this GUID into other hosts and 184 systems that do not support pNFS block layouts. If pNFS block 185 storage devices are presented to such hosts or systems by mistake, 186 the check for presence of this GUID can be used to prevent writes 187 that could otherwise corrupt stored pNFS data. 189 Many current operating system versions support the GPT [GPT-W]. 191 4. Security Considerations 193 The pNFS block layout security considerations in [RFC5663] apply to 194 this document. 196 The security considerations in [RFC4122] apply to the GUID specified 197 in this document. 199 5. IANA Considerations 201 There are no IANA considerations in this document. 203 6. References 205 6.1. Normative References 207 [GPT] Unified EFI Forum, "Unified Extensible Firmware Interface 208 Specification", Version 2.3.1, Errata A, Section 5.3, 209 September 2011, available from http://www.uefi.org . 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC5663] Black, D., Glasgow, J., Fridella, S., "Parallel NFS (pNFS) 215 Block/Volume Layout", RFC 5663, January 2010. 217 6.2. Informative References 219 [GPT-W] http://en.wikipedia.org/wiki/GUID_Partition_Table 221 [RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique 222 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 224 Acknowledgements 226 This document was produced by the IETF NFSv4 Working Group. Review 227 comments from members of the working group improved this document and 228 are gratefully acknowledged. The authors would like to thank Tom 229 Talpey, and members of the IESG for helpful comments on this 230 document, and also Alex Burlyga for providing an appropriate 231 reference for the format of the GPT. 233 This document was prepared using 2-Word-v2.0.template.dot. 235 Authors' Addresses 237 David L. Black (editor) 238 EMC Corporation 239 176 South Street 240 Hopkinton, MA 01748 241 US 243 Phone: +1 (508) 293-7953 244 Email: david.black@emc.com 246 Jason Glasgow 247 Google 248 5 Cambridge Center, Floors 3-6 249 Cambridge, MA 02142 250 US 252 Phone: +1 (617) 575-1599 253 Email: jglasgow@google.com 255 Sorin Faibish 256 EMC Corporation 257 228 South Street 258 Hopkinton, MA 01748 259 US 261 Phone: +1 (508) 305-8545 262 Email: sfaibish@emc.com