idnits 2.17.1 draft-ietf-nfsv4-layout-types-13.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 RFC5661, updated by this document, for RFC5378 checks: 2005-10-21) -- 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 (April 25, 2018) is 2193 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) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) == Outdated reference: A later version (-19) exists of draft-ietf-nfsv4-flex-files-16 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 T. Haynes 3 Internet-Draft Hammerspace 4 Updates: 5661 (if approved) April 25, 2018 5 Intended status: Standards Track 6 Expires: October 27, 2018 8 Requirements for pNFS Layout Types 9 draft-ietf-nfsv4-layout-types-13.txt 11 Abstract 13 This document defines the requirements which individual pNFS layout 14 types need to meet in order to work within the parallel NFS (pNFS) 15 framework as defined in RFC5661. In so doing, it aims to clearly 16 distinguish between requirements for pNFS as a whole and those 17 specifically directed to the pNFS File Layout. The lack of a clear 18 separation between the two set of requirements has been troublesome 19 for those specifying and evaluating new Layout Types. In this 20 regard, this document updates RFC5661. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 27, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Use of the Terms "Data Server" and "Storage Device" . . . 5 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 60 3. The Control Protocol . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Control Protocol Requirements . . . . . . . . . . . . . . 8 62 3.2. Previously Undocumented Protocol Requirements . . . . . . 10 63 3.3. Editorial Requirements . . . . . . . . . . . . . . . . . 10 64 4. Specifications of Original Layout Types . . . . . . . . . . . 11 65 4.1. File Layout Type . . . . . . . . . . . . . . . . . . . . 11 66 4.2. Block Layout Type . . . . . . . . . . . . . . . . . . . . 13 67 4.3. Object Layout Type . . . . . . . . . . . . . . . . . . . 14 68 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 73 8.2. Informative References . . . . . . . . . . . . . . . . . 16 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 75 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 The concept of layout type has a central role in the definition and 81 implementation of Parallel Network File System (pNFS) (see 82 [RFC5661]). Clients and servers implementing different layout types 83 behave differently in many ways while conforming to the overall pNFS 84 framework defined in [RFC5661] and this document. Layout types may 85 differ as to: 87 o The method used to do I/O operations directed to data storage 88 devices. 90 o The requirements for communication between the metadata server 91 (MDS) and the storage devices. 93 o The means used to ensure that I/O requests are only processed when 94 the client holds an appropriate layout. 96 o The format and interpretation of nominally opaque data fields in 97 pNFS-related NFSv4.x data structures. 99 Each layout type will define the needed details for its usage in the 100 specifciation for that layout type; layout type specifications are 101 always standards-track RFCs. Except for the files layout type, which 102 was defined in Section 13 of [RFC5661], existing layout types are 103 defined in their own standards-track documents and it is anticipated 104 that new layout types will be defined in similar documents. 106 The file layout type was defined in the Network File System (NFS) 107 version 4.1 protocol specification [RFC5661]. The block layout type 108 was defined in [RFC5663] while the object layout type was defined in 109 [RFC5664]. Subsequently, the SCSI layout type was defined in 110 [RFC8154]. 112 Some implementers have interpreted the text in Sections 12 ("Parallel 113 NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File 114 Layout Type") of [RFC5661] as both being applying only to the file 115 layout type. Because Section 13 was not covered in a separate 116 standards-track document such as those for both the block and object 117 layout types, there had been some confusion as to the 118 responsibilities of both the metadata server and the data servers 119 (DS) which were laid out in Section 12. 121 As a consequence, authors of new specifications (see [FlexFiles] and 122 [Lustre]) may struggle to meet the requirements to be a pNFS layout 123 type. This document gathers the requirements from all of the 124 original layout type standard documents and then specifies the 125 requirements placed on all layout types independent of the particular 126 type chosen. 128 2. Definitions 130 control communication requirement: is the specification for 131 information on layouts, stateids, file metadata, and file data 132 which must be communicated between the metadata server and the 133 storage devices. There is a separate set of requirements for each 134 layout type. 136 control protocol: is the particular mechanism that an implementation 137 of a layout type would use to meet the control communication 138 requirement for that layout type. This need not be a protocol as 139 normally understood. In some cases the same protocol may be used 140 as a control protocol and storage protocol. 142 storage protocol: is the protocol used by clients to do I/O 143 operations to the storage device. Each layout type specifies the 144 set of storage protocols. 146 loose coupling: is when the control protocol is a storage protocol. 148 tight coupling: is an arrangement in which the control protocol is 149 one designed specifically for that purpose. It may be either a 150 proprietary protocol, adapted specifically to a a particular 151 metadata server, or one based on a standards-track document. 153 (file) data: is that part of the file system object which contains 154 the data to be read or written. It is the contents of the object 155 rather than the attributes of the object. 157 data server (DS): is a pNFS server which provides the file's data 158 when the file system object is accessed over a file-based 159 protocol. Note that this usage differs from that in [RFC5661] 160 which applies the term in some cases even when other sorts of 161 protocols are being used. Depending on the layout, there might be 162 one or more data servers over which the data is striped. While 163 the metadata server is strictly accessed over the NFSv4.1 164 protocol, the data server could be accessed via any file access 165 protocol that meets the pNFS requirements. 167 See Section 2.1 for a comparison of this term and "data storage 168 device". 170 storage device: is the target to which clients may direct I/O 171 requests when they hold an appropriate layout. Note that each 172 data server is a storage device but that some storage device are 173 not data servers. See Section 2.1 for further discussion. 175 fencing: is the process by which the metadata server prevents the 176 storage devices from processing I/O from a specific client to a 177 specific file. 179 layout: is the information a client uses to access file data on a 180 storage device. This information will include specification of 181 the protocol (layout type) and the identity of the storage devices 182 to be used. 184 The bulk of the contents of the layout are defined in [RFC5661] 185 as nominally opaque, but individual layout types are responsible 186 for specifying the format of the layout data. 188 layout iomode: is a grant of either read or read/write I/O to the 189 client. 191 layout stateid: is a 128-bit quantity returned by a server that 192 uniquely defines the layout state provided by the server for a 193 specific layout that describes a layout type and file (see 194 Section 12.5.2 of [RFC5661]). Further, Section 12.5.3 describes 195 differences in handling between layout stateids and other stateid 196 types. 198 layout type: is a specification of both the storage protocol used to 199 access the data and the aggregation scheme used to lay out the 200 file data on the underlying storage devices. 202 recalling a layout: is a graceful recall, via a callback, of a 203 specific layout by the metadata server to the client. Graceful 204 here means that the client would have the opportunity to flush any 205 writes, etc., before returning the layout to the metadata server. 207 revoking a layout: is an invalidation of a specific layout by the 208 metadata server. Once revocation occurs, the metadata server will 209 not accept as valid any reference to the revoked layout and a 210 storage device will not accept any client access based on the 211 layout. 213 (file) metadata: is that part of the file system object that 214 contains various descriptive data relevant to the file object, as 215 opposed to the file data itself. This could include the time of 216 last modification, access time, end-of-file (EOF) position, etc. 218 metadata server (MDS): is the pNFS server which provides metadata 219 information for a file system object. It also is responsible for 220 generating, recalling, and revoking layouts for file system 221 objects, for performing directory operations, and for performing I 222 /O operations to regular files when the clients direct these to 223 the metadata server itself. 225 stateid: is a 128-bit quantity returned by a server that uniquely 226 defines the set of locking-related state provided by the server. 227 Stateids may designate state related to open files, to byte-range 228 locks, to delegations, or to layouts. 230 2.1. Use of the Terms "Data Server" and "Storage Device" 232 In [RFC5661], these two terms of "Data Server" and "Storage Device" 233 are used somewhat inconsistently: 235 o In chapter 12, where pNFS in general is discussed, the term 236 "storage device" is used. 238 o In chapter 13, where the file layout type is discussed, the term 239 "data server" is used. 241 o In other chapters, the term "data server" is used, even in 242 contexts where the storage access type is not NFSv4.1 or any other 243 file access protocol. 245 As this document deals with pNFS in general, it uses the more generic 246 term "storage device" in preference to "data server". The term "data 247 server" is used only in contexts in which a file server is used as a 248 storage device. Note that every data server is a storage device but 249 storage devices which use protocols which are not file access 250 protocols (such as NFS) are not data servers. 252 Since a given storage device may support multiple layout types, a 253 given device can potentially act as a data server for some set of 254 storage protocols while simultaneously acting as a storage device for 255 others. 257 2.2. Requirements Language 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 261 "OPTIONAL" in this document are to be interpreted as described in BCP 262 14 [RFC2119] [RFC8174] when, and only when, they appear in all 263 capitals, as shown here. 265 This document differs from most standards-track documents in that it 266 specifies requirements for those defining future layout types rather 267 than defining the requirements for implementations directly. This 268 document makes clear whether: 270 (1) any particular requirement applies to implementations. 272 (2) any particular requirement applies to those defining layout 273 types. 275 (3) the requirement is a general requirement which implementations 276 need to conform to, with the specific means left to layout type 277 definitions type to specify. 279 3. The Control Protocol 281 A layout type has to meet the requirements that apply to the 282 interaction between the metadata server and the storage device such 283 that they present to the client a consistent view of stored data and 284 lock state (Section 12.2.6 of [RFC5661]). Particular implementations 285 may satisfy these requirements in any manner they choose and the 286 mechanism chosen need not be described as a protocol. Specifications 287 defining layout types need to clearly show how implementations can 288 meet the requirements discussed below, especially with respect to 289 those that have security implications. In addition, such 290 specifications may find it necessary to impose requirements on 291 implementations of the layout type to ensure appropriate 292 interoperability. 294 In some cases, there may be no control protocol other than the 295 storage protocol. This is often described as using a "loose 296 coupling" model. In such cases, the assumption is that the metadata 297 server, storage devices, and client may be changed independently and 298 that the implementation requirements in the layout type specification 299 need to ensure this degree of interoperability. This model is used 300 in the block and object layout type specification. 302 In other cases, it is assumed that there will be a purpose-built 303 control protocol which may be different for different implementations 304 of the metadata server and data server. The assumption here is that 305 the metadata server and data servers are designed and implemented as 306 a unit and interoperability needs to be assured between clients and 307 metadata-data server pairs, developed independently. This is the 308 model used for the files layout. 310 Another possibility is for the definition of a control protocol to be 311 specified in a standards-track document. There are two subcases to 312 consider: 314 o A new layout type includes a definition of a particular control 315 protocol whose use is obligatory for metadata servers and storage 316 devices implementing the layout type. In this case the 317 interoperability model is similar to the first case above and the 318 defining document should assure interoperability among metadata 319 servers, storage devices, and clients developed independently. 321 o A control protocol is defined in a standards-track document which 322 meets the control protocol requirements for one of the existing 323 layout types. In this case, the new document's job is to assure 324 interoperability between metadata servers and storage devices 325 developed separately. The existing definition document for the 326 selected layout type retains the function of assuring 327 interoperability between clients and a given collection of 328 metadata servers and storage devices. In this context, 329 implementations that implement the new protocol are treated in the 330 same way as those that use an internal control protocol or a 331 functional equivalent. 333 An example of this last case is the SCSI layout type [RFC8154], which 334 extends the block layout type. The block layout type had a 335 requirement for fencing of clients, but did not present a way for the 336 control protocol (in this case the SCSI storage protocol) to fence 337 the client. The SCSI layout type remedies that in [RFC8154] and in 338 effect has a tightly coupled model. 340 3.1. Control Protocol Requirements 342 The requirements of interactions between the metadata server and the 343 storage devices are: 345 (1) The metadata server MUST be able to service the client's I/O 346 requests if the client decides to make such requests to the 347 metadata server instead of to the storage device. The metadata 348 server must be able to retrieve the data from the constituent 349 storage devices and present it back to the client. A corollary 350 to this is that even though the metadata server has successfully 351 given the client a layout, the client MAY still send I/O 352 requests to the metadata server. 354 (2) The metadata server MUST be able to restrict access to a file on 355 the storage devices when it revokes a layout. The metadata 356 server typically would revoke a layout whenever a client fails 357 to respond to a recall or a client's lease is expired due to 358 non-renewal. It might also revoke the layout as a means of 359 enforcing a change in locking state or access permissions that 360 the storage device cannot directly enforce. 362 Effective revocation may require client co-operation in using a 363 particular stateid (files layout) or principal (e,g., flexible 364 files layout) when performing I/O. 366 In contrast, there is no requirement to restrict access to a 367 file on the storage devices when a layout is recalled. It is 368 only after the metadata server determines that the client is not 369 gracefully returning the layout and starts the revocation that 370 this requirement is enforced. 372 (3) A pNFS implementation MUST NOT allow the violation of NFSv4.1's 373 access controls: ACLs and file open modes. Section 12.9 of 374 [RFC5661] specifically lays this burden on the combination of 375 clients, storage devices, and the metadata server. However the 376 specification of the individual layout type might create 377 requirements as to how this is to be done. This may include a 378 possible requirement for the metadata server to update the 379 storage device so that it can enforce security. 381 The file layout requires the storage device to enforce access 382 whereas the flex file layout requires both the storage device 383 and the client to enforce security. 385 (4) Interactions between locking and I/O operations MUST obey 386 existing semantic restrictions. In particular, if an I/O 387 operation would be invalid when directed at the metadata server, 388 it is not to be allowed when performed on the storage device. 390 For the block and SCSI layout, as the storage device is not able 391 to reject the I/O operation, the client is responsible for 392 enforcing this requirement. 394 (5) Any disagreement between the metadata server and the data server 395 as to the value of attributes such as modify time, the change 396 attribute, and the EOF position MUST be of limited duration with 397 clear means of resolution of any discrepancies being provided. 398 Note that 400 (a) Discrepancies need not be resolved unless any client has 401 accessed the file in question via the metadata server, 402 typically by performing a GETATTR. 404 (b) A particular storage device might be striped such it has no 405 information regarding the EOF position. 407 (c) Both clock skew and network delay can lead to the metadata 408 server and the storage device having different values of 409 the time attributes. As long as those differences can be 410 accounted for in what is presented to the client in a 411 GETATTR, then no violation results. 413 (d) A LAYOUTCOMMIT requires that changes in attributes 414 resulting from operations on the storage device need to be 415 reflected in the metadata server by the completion of the 416 operation. 418 These requirements may be satisfied in different ways by different 419 layout types. As an example, while the file layout type uses the 420 stateid to fence off the client, there is no requirement that other 421 layout types use this stateid approach. 423 Each new standards-track document for a layout types MUST address how 424 the client, metadata server, and storage devices are to interact to 425 meet these requirements. 427 3.2. Previously Undocumented Protocol Requirements 429 While not explicitly stated as requirements in Section 12 of 430 [RFC5661], the existing layout types do have more requirements that 431 they need to enforce. 433 The client has these obligations when making I/O requests to the 434 storage devices: 436 (1) Clients MUST NOT perform I/O to the storage device if they do 437 not have layouts for the files in question. 439 (2) Clients MUST NOT perform I/O operations outside of the specified 440 ranges in the layout segment. 442 (3) Clients MUST NOT perform I/O operations which would be 443 inconsistent with the iomode specified in the layout segments it 444 holds. 446 Under the file layout type, the storage devices are able to reject 447 any request made not conforming to these requirements. This may not 448 be possible for other known layout types, which puts the burden of 449 enforcing such violations solely on the client. For these layout 450 types: 452 (1) The metadata server MAY use fencing operations to the storage 453 devices to enforce layout revocation against the client. 455 (2) The metadata server MUST allow the clients to perform data I/O 456 against it, even if it has already granted the client a layout. 457 A layout type might discourage such I/O, but it can not forbid 458 it. 460 (3) The metadata server MUST be able to do storage allocation, 461 whether that is to create, delete, extend, or truncate files. 463 The means to address these requirements will vary with the layout 464 type. A control protocol will be used to effect these, whether a 465 purpose-built one, one identical to the storage protocol, or a new 466 standards-track control protocol. 468 3.3. Editorial Requirements 470 This section discusses how the protocol requirements discussed above 471 need to be addressed in documents specifying a new layout type. 472 Depending on the interoperability model for the layout type in 473 question, this may involve the imposition of layout-type-specific 474 requirements that ensure appropriate interoperability of pNFS 475 components which are developed separately. 477 The specification of the layout type needs to make clear how the 478 client, metadata server, and storage device act together to meet the 479 protocol requirements discussed previously. If the document does not 480 impose implementation requirements sufficient to ensure that these 481 semantic requirements are met, it is not appropriate for publication 482 as an IETF-stream RFC. 484 Some examples include: 486 o If the metadata server does not have a means to invalidate a 487 stateid issued to the storage device to keep a particular client 488 from accessing a specific file, then the layout type specification 489 has to document how the metadata server is going to fence the 490 client from access to the file on that storage device. 492 o If the metadata server implements mandatory byte-range locking 493 when accessed directly by the client, then the layout type 494 specification must require that this also be done when data is 495 read or written using the designated storage protocol. 497 4. Specifications of Original Layout Types 499 This section discusses how the original layout types interact with 500 Section 12 of [RFC5661], which enumerates the requirements of pNFS 501 layout type specifications. It is not normative with regards to the 502 file layout type presented in Section 13 of [RFC5661], the block 503 layout type [RFC5663], and the object layout type [RFC5664]. These 504 are discussed here only to illuminate the updates made in Section 3 505 of this document to Section 12 of [RFC5661]. 507 4.1. File Layout Type 509 Because the storage protocol is a subset of NFSv4.1, the semantics of 510 the file layout type comes closest to the semantics of NFSv4.1 in the 511 absence of pNFS. In particular, the stateid and principal used for I 512 /O MUST have the same effect and be subject to the same validation on 513 a data server as it would have if the I/O were being performed on the 514 metadata server itself. The same set of validations are applied 515 whether pNFS is in effect or not. 517 And while for most implementations the storage devices can do the 518 following validations: 520 (1) client holds a valid layout, 521 (2) client I/O matches the layout iomode, and, 523 (3) client does not go out of the byte ranges, 525 these are each presented as a "SHOULD" and not a "MUST". Actually, 526 the first point is presented in [RFC5661] as both: 528 "MUST": in Section 13.6 530 "As described in Section 12.5.1, a client MUST NOT send an I/O to 531 a data server for which it does not hold a valid layout; the data 532 server MUST reject such an I/O." 534 "SHOULD": in Section 13.8 536 "The iomode need not be checked by the data servers when clients 537 perform I/O. However, the data servers SHOULD still validate that 538 the client holds a valid layout and return an error if the client 539 does not." 541 It should be noted that it is just these layout specific checks that 542 are optional, not the normal file access semantics. The storage 543 devices MUST make all of the required access checks on each READ or 544 WRITE I/O as determined by the NFSv4.1 protocol. If the metadata 545 server would deny a READ or WRITE operation on a file due to its ACL, 546 mode attribute, open access mode, open deny mode, mandatory byte- 547 range lock state, or any other attributes and state, the storage 548 device MUST also deny the READ or WRITE operation. Also while the 549 NFSv4.1 protocol does not mandate export access checks based on the 550 client's IP address, if the metadata server implements such a policy, 551 then that counts as such state as outlined above. 553 The data filehandle provided by the PUTFH operation to the data 554 server provides sufficient context to enable the data server to 555 ensure that for the subsequent READ or WRITE operation in the 556 compound, that the client has a valid layout for the I/O being 557 performed. 559 Finally, the data server can check the stateid presented in the READ 560 or WRITE operation to see if that stateid has been rejected by the 561 metadata server in order to cause the I/O to be fenced. Whilst it 562 might just be the open owner or lock owner on that client being 563 fenced, the client should take the NFS4ERR_BAD_STATEID error code to 564 mean it has been fenced from the file and contact the metadata 565 server. 567 4.2. Block Layout Type 569 With the block layout type, the storage devices are generally not 570 able to enforce file-based security. Typically, storage area network 571 (SAN) disk arrays and SAN protocols provide coarse-grained access 572 control mechanisms (e.g., Logical Unit Number (LUN) mapping and/or 573 masking), with a target granularity of disks rather than individual 574 blocks and a source granularity of individual hosts rather than of 575 users or owners. Access to block storage is logically at a lower 576 layer of the I/O stack than NFSv4. Since NFSv4 security is not 577 directly applicable to protocols that access such storage directly, 578 Section 2.1 [RFC5663] specifies that: 580 "in environments where pNFS clients cannot be trusted to enforce 581 such policies, pNFS block layout types SHOULD NOT be used." 583 Due to these granularity issues, the security burden has been shifted 584 from the storage devices to the client. Those deploying 585 implementations of this layout type need to be sure that the client 586 implementation can be trusted This is not a new sort of requirement 587 in the context of SAN protocols. In such environments, the client is 588 expected to provide block-based protection. 590 This shift of the burden also extends to locks and layouts. The 591 storage devices are not able to enforce any of these and the burden 592 is pushed to the client to make the appropriate checks before sending 593 I/O to the storage devices. For example, the server may use a layout 594 iomode only allowing reading to enforce a mandatory read-only lock, 595 In such cases, the client has to support that use by not sending 596 WRITEs to the storage devices. The fundamental issue here is that 597 the storage device is treated by this layout type in the same fashion 598 as a local disk device. Once the client has access to the storage 599 device, it is able to perform both READ and WRITE I/O to the entire 600 storage device. The byte ranges in the layout, any locks, the layout 601 iomode, etc, can only be enforced by the client. Therefore, the 602 client is required to provide that enforcement. 604 In the context of fencing off of the client upon revocation of a 605 layout, these limitations come into play again, i.e., the granularity 606 of the fencing can only be at the host/logical-unit level. Thus, if 607 one of a client's layouts is revoked by the server, it will 608 effectively revoke all of the client's layouts for files located on 609 the storage units comprising the logical volume. This may extend to 610 the client's layouts for files in other file systems. Clients need 611 to be prepared for such revocations and reacquire layouts as needed. 613 4.3. Object Layout Type 615 With the object layout type, security checks occur during the 616 allocation of the layout. The client will typically ask for layouts 617 covering all of the file and may do so for either READ or READ/WRITE. 618 This enables it to do subsequent I/O operations without the need to 619 obtain layouts for specific byte ranges. At that time, the metadata 620 server should verify permissions against the layout iomode, the file 621 mode bits or ACLs, etc. As the client may be acting for multiple 622 local users, it MUST authenticate and authorize the user by issuing 623 respective OPEN and ACCESS calls to the metadata server, similar to 624 having NFSv4 data delegations. 626 Upon successful authorization, the client receives within the layout 627 a set of object capabilities allowing it I/O access to the specified 628 objects corresponding to the requested iomode. These capabilities 629 are used to enforce access control and locking semantics at the 630 storage devices. Whenever one of the following occur on the metadata 631 server: 633 o the permissions on the object change, 635 o a conflicting mandatory byte-range lock is granted, or 637 o a layout is revoked and reassigned to another client, 639 then the metadata server MUST change the capability version attribute 640 on all objects comprising the file to in order to invalidate any 641 outstanding capabilities before committing to one of these changes. 643 When the metadata server wishes to fence off a client to a particular 644 object, then it can use the above approach to invalidate the 645 capability attribute on the given object. The client can be informed 646 via the storage device that the capability has been rejected and is 647 allowed to fetch a refreshed set of capabilities, i.e., re-acquire 648 the layout. 650 5. Summary 652 In the three original layout types, the burden of enforcing the 653 security of NFSv4.1 can fall to either the storage devices (files), 654 the client (blocks), or the metadata server (objects). Such choices 655 are conditioned by the native capabilities of the storage devices - 656 if a control protocol can be implemented, then the burden can be 657 shifted primarily to the storage devices. 659 In the context of this document, we treat the control protocol as a 660 set of requirements. And as new layout types are published, the 661 defining documents MUST address: 663 (1) The fencing of clients after a layout is revoked. 665 (2) The security implications of the native capabilities of the 666 storage devices with respect to the requirements of the NFSv4.1 667 security model. 669 In addition, these defining documents need to make clear how other 670 semantic requirements of NFSv4.1 (e.g., locking) are met in the 671 context of the proposed layout type. 673 6. Security Considerations 675 This section does not deal directly with security considerations for 676 existing or new layout types. Instead, it provides a general 677 framework for understating security-related issues within the pNFS 678 framework. Specific security considerations will be addressed in the 679 Security Considerations sections of documents specifying layout 680 types. For example, in Section 5 of [RFC5663], the lack of finer- 681 than-physical disk access control necessitates that the client is 682 delegated the responsibility to enforce the access provided to them 683 in the layout extent which they were granted by the metadata server. 685 The layout type specification must ensure that only data accesses 686 consistent with the NFSV4.1 security model are allowed. It may do 687 this directly, by providing that appropriate checks be performed at 688 the time each access is performed. It may do it indirectly by 689 allowing the client or the storage device to be responsible for 690 making the appropriate checks. In the latter case, I/O access rights 691 are reflected in layouts and the layout type must provide a way to 692 prevent inappropriate access due to permissions changes between the 693 time a layout is granted and the time the access is performed. 695 The metadata server MUST be able to fence off a client's access to 696 the data file on a storage device. When it revokes the layout, the 697 client's access MUST be terminated at the storage devices. The 698 client has a subsequent opportunity to re-acquire the layout and 699 perform the security check in the context of the newly current access 700 permissions. 702 7. IANA Considerations 704 This document has no actions for IANA. 706 8. References 708 8.1. Normative References 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 712 RFC2119, March 1997, . 715 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 716 "Network File System (NFS) Version 4 Minor Version 1 717 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 718 . 720 [RFC5663] Black, D., Fridella, S., and J. Glasgow, "Parallel NFS 721 (pNFS) Block/Volume Layout", RFC 5663, DOI 10.17487/ 722 RFC5663, January 2010, . 725 [RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based 726 Parallel NFS (pNFS) Operations", RFC 5664, DOI 10.17487/ 727 RFC5664, January 2010, . 730 [RFC8154] Hellwig, C., "Parallel NFS (pNFS) Small Computer System 731 Interface (SCSI) Layout", RFC 8154, DOI 10.17487/RFC8154, 732 May 2017, . 734 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 735 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 736 May 2017, . 738 8.2. Informative References 740 [FlexFiles] 741 Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible 742 File Layout", draft-ietf-nfsv4-flex-files-16 (Work In 743 Progress), January 2018. 745 [Lustre] Faibish, S. and P. Tao, "Parallel NFS (pNFS) Lustre Layout 746 Operations", draft-faibish-nfsv4-pnfs-lustre-layout-07 747 (Work In Progress), April 2014. 749 Appendix A. Acknowledgments 751 Dave Noveck provided an early review that sharpened the clarity of 752 the definitions. He also provided a more comprehensive review of the 753 document. 755 Both Chuck Lever and Christoph Helwig provided insightful comments 756 during the WGLC. 758 Appendix B. RFC Editor Notes 760 [RFC Editor: please remove this section prior to publishing this 761 document as an RFC] 763 [RFC Editor: prior to publishing this document as an RFC, please 764 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 765 RFC number of this document] 767 Author's Address 769 Thomas Haynes 770 Hammerspace 771 4300 El Camino Real Ste 105 772 Los Altos, CA 94022 773 USA 775 Email: loghyr@gmail.com