idnits 2.17.1 draft-ietf-nfsv4-layout-types-05.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 (July 20, 2017) is 2443 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-11 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 Primary Data 4 Updates: 5661 (if approved) July 20, 2017 5 Intended status: Standards Track 6 Expires: January 21, 2018 8 Requirements for pNFS Layout Types 9 draft-ietf-nfsv4-layout-types-05.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 more 16 clearly distinguish between requirements for pNFS as a whole and 17 those those specifically directed to the pNFS File Layout. The lack 18 of a clear separation between the two set of requirements has been 19 troublesome for those specifying and evaluating new Layout Types. In 20 this regard, this document effectively 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 January 21, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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. Protocol REQUIREMENTS . . . . . . . . . . . . . . . . . . 7 62 3.2. Undocumented Protocol REQUIREMENTS . . . . . . . . . . . 9 63 3.3. Editorial Requirements . . . . . . . . . . . . . . . . . 10 64 4. Specifications of Existing Layout Types . . . . . . . . . . . 10 65 4.1. File Layout Type . . . . . . . . . . . . . . . . . . . . 10 66 4.2. Block Layout Type . . . . . . . . . . . . . . . . . . . . 12 67 4.3. Object Layout Type . . . . . . . . . . . . . . . . . . . 13 68 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 8.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 75 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 15 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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). Clients and 82 servers implementing different layout types behave differently in 83 many ways while conforming to the overall pNFS framework defined in 84 [RFC5661] and this document. Layout types may differ in: 86 o The method used to do I/O operations directed to data storage 87 devices. 89 o The requirements for communication between the metadata server 90 (MDS) and the storage devices. 92 o The means used to ensure that I/O requests are only processed when 93 the client holds an appropriate layout. 95 o The format and interpretation of nominally opaque data fields in 96 pNFS-related NFSv4.x data structures. 98 Such matters are defined in a standards-track layout type 99 specification. Except for the files layout type, which was defined 100 in Section 13 of [RFC5661], existing layout types are defined in 101 their own standards-track documents and it is anticipated that new 102 layout type will be defined in similar documents. 104 The file layout type was defined in the Network File System (NFS) 105 version 4.1 protocol specification [RFC5661]. The block layout type 106 was defined in [RFC5663] and the object layout type was in turn 107 defined in [RFC5664]. 109 Some implementers have interpreted the text in Sections 12 ("Parallel 110 NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File 111 Layout Type") of [RFC5661] as both being applying only to the file 112 layout type. Because Section 13 was not covered in a separate 113 standards-track document like those for both the block and object 114 layout types, there had been some confusion as to the 115 responsibilities of both the metadata server and the data servers 116 (DS) which were laid out in Section 12. 118 As a consequence, new internet drafts (see [FlexFiles] and [Lustre]) 119 may struggle to meet the requirements to be a pNFS layout type. This 120 document specifies the layout type independent requirements placed on 121 all layout types, whether one of the original three or any new 122 variant. 124 2. Definitions 126 control communication requirements: define for a layout type the 127 details regarding information on layouts, stateids, file metadata, 128 and file data which must be communicated between the metadata 129 server and the storage devices. 131 control protocol: defines a particular mechanism that an 132 implementation of a layout type would use to meet the control 133 communication requirement for that layout type. This need not be 134 a protocol as normally understood. In some cases the same 135 protocol my be used as a control protocol and data access 136 protocol. 138 (file) data: is that part of the file system object which contains 139 the data to read or writen. It is the contents of the object and 140 not the attributes of the object. 142 data server (DS): is a pNFS server which provides the file's data 143 when the file system object is accessed over a file-based 144 protocol. Note that this usage differs from that in [RFC5661] 145 which applies the term in some cases even when other sorts of 146 protocols are being used. Depending on the layout, there might be 147 one or more data servers over which the data is striped. While 148 the metadata server is strictly accessed over the NFSv4.1 149 protocol, depending on the layout type, the data server could be 150 accessed via any file access protocol that meets the pNFS 151 requirements. 153 See Section 2.1 for a comparison of this term and "data storage 154 device". 156 fencing: is the process by which the metadata server prevents the 157 storage devices from processing I/O from a specific client to a 158 specific file. 160 layout: contains information a client uses to access file data on a 161 storage device. This information will include specification of 162 the protocol (layout type) and the identity of the storage devices 163 to be used. 165 The bulk of the contents of the layout are defined in [RFC5661] 166 as nominally opaque, but individual layout types may specify their 167 own interpretation of layout data. 169 layout iomode: see Section 1. 171 layout stateid: is a 128-bit quantity returned by a server that 172 uniquely defines the layout state provided by the server for a 173 specific layout that describes a layout type and file (see 174 Section 12.5.2 of [RFC5661]). Further, Section 12.5.3 describes 175 differences in handling between layout stateids and other stateid 176 types. 178 layout type: describes both the storage protocol used to access the 179 data and the aggregation scheme used to lay out the file data on 180 the underlying storage devices. 182 loose coupling: describes when the control protocol, between a 183 metadata server and storage device, is a storage protocol. 185 (file) metadata: is that part of the file system object that 186 contains various descriptive data relevant to the file object, as 187 opposed to the file data itself. This could include the time of 188 last modification, access time, eof position, etc. 190 metadata server (MDS): is the pNFS server which provides metadata 191 information for a file system object. It also is responsible for 192 generating, recalling, and revoking layouts for file system 193 objects, for performing directory operations, and for performing I 194 /O operations to regular files when the clients direct these to 195 the metadata server itself. 197 recalling a layout: occurs when the metadata server issues a callbck 198 to inform the client that the layout is to be returned in a 199 graceful manner. Note that the client could be able to flush any 200 writes, etc., before replying to the metadata server. 202 revoking a layout: occurs when the metadata server invalidates a 203 specific layout Once revocation occurs, the metadata server will 204 not accept as valid any reference to the revoked layout and a 205 storage device will not accept any client access based on the 206 layout. 208 stateid: is a 128-bit quantity returned by a server that uniquely 209 defines the set of locking-related state provided by the server. 210 Stateids may designate state related to open files, to byte-range 211 locks, to delegations, or to layouts. 213 storage device: designates the target to which clients may direct I/ 214 O requests when they hold an appropriate layout. Note that each 215 data server is a storage device but that some storage device are 216 not data servers. See Section 2.1 for further discussion. 218 storage protocol: is the protocol used by clients to do I/O 219 operations to the storage device, Each layout type may specify its 220 own storage protocol. It is possible for a layout type to specify 221 multiple access protocols. 223 tight coupling: describes when the control protocol, between a 224 metadata server and storage device, is either a propritary 225 approach or based on a standards-track document. 227 2.1. Use of the Terms "Data Server" and "Storage Device" 229 In [RFC5661], these the two terms of "Data Server" and "Storage 230 Device" are used somewhat inconsistently: 232 o In chapter 12, where pNFS in general is discussed, the term 233 "storage device" is used. 235 o In chapter 13, where the file layout type is discussed, the term 236 "data server" is used. 238 o In other chapters, the term "data server" is used, even in 239 contexts where the storage access type is not NFSv4.1 or any other 240 file access protocol. 242 As this document deals with pNFS in general, it uses the more generic 243 term "storage device" in preference to "data server". The term "data 244 server" is used only in contexts in which a file server is used as a 245 storage device. Note that every data server is a storage device but 246 that storage devices which use protocols which are not file access 247 protocol are not data servers. 249 Since a given storage device may support multiple layout types, a 250 given device can potentially act as a data server for some set of 251 storage protocols while simultaneously acting as a non-data-server 252 storage device for others. 254 2.2. Requirements Language 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 3. The Control Protocol 262 In Section 12.2.6 of [RFC5661], the control protocol was introduced. 263 There have been no published specifications for control protocols as 264 yet. The control protocol denotes any mechanism used to meet the 265 requirements that apply to the interaction between the metadata 266 server and the storage device such that they present a consistent 267 interface to the client. Particular implementations may satisfy this 268 requirement in any manner they choose and the mechanism chosen may 269 not be described as a protocol. Specifications defining layout types 270 need to clearly show how implementations can meet the requirements 271 discussed below, especially with respect to those that have security 272 implications. In addition, such specifications may find it necessary 273 to impose requirements on implementations of the layout type to 274 ensure appropriate interoperability. 276 In some cases, there may be no control protocol other than the 277 storage protocol. This is often described as using a "loose 278 coupling" model. In such cases, the assumption is that the metadata 279 server, storage devices, and client may be changed independently and 280 that the implementation requirements in the layout type specification 281 need to ensure this degree of interoperability. This model is used 282 in the block and object layout type specification. 284 In some cases, there may be no control protocol other than the 285 storage In other cases, it is assumed that there may be purpose-built 286 control protocol which may be different for different implementations 287 of the metadata server and data server. In such cases, the 288 assumption is that the metadata server and data servers are designed 289 and implemented as a unit and interoperability needs to be assured 290 between clients and metadata-data server pairs, developed 291 independently. This is the model used for the files layout. 293 In some cases, there may be no control protocol other than the 294 storage Another possibility, not so far realized, is for the 295 definition of a control protocol to be specified in a standards-track 296 document. There are two subcases to consider: 298 o A new layout type includes a definition of a particular control 299 protocol whose use is obligatory for metadata serverss and storage 300 devices implementing the layout type. In this case the 301 interoperability model is similar to the first case above and the 302 defining document should assure interoperability among metadata 303 servers, storage devices, and clients developed independently. 305 o A control protocol is defined in a standards-track document which 306 meets the control protocol requirements for one of the existing 307 layout types. In this case, the new document's job is to assure 308 interoperability between metadata servers and storage devices 309 developed separately. The existing definition document for the 310 selected layout type retains the function of assuring 311 interoperability between clients and a given collection of 312 metadata servers and storage devices. In this context, 313 implementations that implement the new protocol are treated in the 314 same way as those that use an internal control protocol or a 315 functional equivalent. 317 3.1. Protocol REQUIREMENTS 319 The REQUIREMENTS of such interactions between the metadata server and 320 the storage devices are: 322 (1) The metadata server MUST be able to service the client's I/O 323 requests if the client decides to make such requests to the 324 metadata server instead of to the storage device. The metadata 325 server must be able to retrieve the data from the constituent 326 storage devices and present it back to the client. A corollary 327 to this is that even though the metadata server has successfully 328 given the client a layout, the client MAY still send I/O 329 requests to the metadata server. 331 Whether the metadata server allows access over other protocols 332 (e.g., NFSv3, Server Message Block (SMB), etc) is strictly an 333 implementation choice, just as it is in the case of any other 334 (i.e., non-pNFS-supporting) NFSv4.1 server. 336 (2) The metadata server MUST be able to restrict access to a file on 337 the storage devices when it revokes a layout. The metadata 338 server typically would revoke a layout whenever a client fails 339 to respond to a recall or a client's lease is expired due to 340 non-renewal. It might also revoke the layout as a means of 341 enforcing a change in locking state or access permissions that 342 the storage device cannot directly enforce. 344 Effective revocation may require client co-operation in using a 345 particular stateid (files layout) or principal (e,g., flexible 346 files layout) when performing I/O. 348 (3) A pNFS impelementation MUST NOT remove NFSv4.1's access 349 controls: ACLs and file open modes. While Section 12.9 of 350 [RFC5661] specifically lays this burden on the combination of 351 clients, storage devices, and the metadata server, depending on 352 the implementation, there might be a requirement that the 353 metadata server update the storage device such that it can 354 enforce security. 356 The file layout requires the storage device to enforce access 357 whereas the flex file layout requires both the storage device 358 and the client to enforce security. 360 (4) Locking MUST be respected. 362 (5) The metadata server and the storage devices MUST agree on 363 attributes like modify time, the change attribute, and the end- 364 of-file (EOF) position. 366 (a) "Agree" in the sense that some while state changes need not 367 be propagated immediately, they must be propagated when 368 accessed by the client. This access is typically in 369 response to a GETATTR of those attributes. 371 (b) A particular storage device might be striped such it knows 372 nothing about the EOF position. It still meets the 373 requirement of agreeing on that fact with the metadata 374 server. 376 (c) Both clock skew and network delay can lead to the metadata 377 server and the storage device having different concepts of 378 the time attributes. As long as those differences can be 379 accounted for what is presented to the client in a GETATTR, 380 then the two "agree". 382 (d) A LAYOUTCOMMIT requires that storage device generated 383 changes in attributes need be reflected in the metadata 384 server by the completion of the operation. 386 These requirements may be satisfied in different ways by different 387 layout types. As an example, while the file layout type does use the 388 stateid to fence off the client, there is no requirement that other 389 layout types use this stateid approach. 391 Each new standards-track document for a layout types MUST address how 392 the client, metadata server, and storage devices interact to meet 393 these requirements. 395 3.2. Undocumented Protocol REQUIREMENTS 397 In gathering the requirements from Section 12 of [RFC5661], there are 398 some which are notable in their absence: 400 (1) Clients MUST NOT perform I/O to the storage device if they do 401 not have layouts for the files in question. 403 (2) Clients MUST be allowed to perform I/O to the metadata server 404 even if they already have a LAYOUT. A layout type might 405 discourage such I/O, but it can not forbid it. 407 (3) Clients MUST NOT perform I/O operations outside of the specified 408 ranges in the layout segment. 410 (4) Clients MUST NOT perform I/O operations which would be 411 inconsistent with the iomode specified in the layout segments it 412 holds. 414 (5) The metadata server MUST be able to do allocation and 415 deallocation of storage. I.e., creating and deleting files. 417 Under the file layout type, the storage devices are able to meet all 418 of these requirements. However, this is not the case with the other 419 known layout types, Instead, the burden is shifted to both: 421 (1) The client itself. 423 (2) The interaction of the metadata server and the client. 425 The metadata server is responsible for giving the client enough 426 information to make informed decisions and for trusting the client 427 implementation to do so. This communication would be through the 428 callback operatios available to the metadata server, e.g., recalling 429 a layout, a delegation, etc. 431 3.3. Editorial Requirements 433 This section discusses how the protocol requirements discussed above 434 need to be addressed in documents specifying a new layout type. 435 Depending on the interoperability model for the layout type in 436 question, this may involve the imposition of layout-type-specific 437 requirements that ensure appropriate interoperability of pNFS 438 components which are developed separately. 440 The specification of the layout type needs to make clear how the 441 client, metadata server, and storage device act together to meet the 442 protocol requirements discussed previously. If the document does not 443 impose implementation requirements sufficient to ensure that these 444 semantic requirements are met, it is not appropriate for the working 445 group to allow the document to move forward. 447 Some examples include: 449 o If the metadata server does not have a means to invalidate a 450 stateid issued to the storage device to keep a particular client 451 from accessing a specific file, then the layout type spefication 452 has to document how the metadata server is going to fence the 453 client from access to the file on that storage device. 455 o If the metadata server implements mandatory byte-range locking 456 when accessed directly by the client, it must do so when data is 457 read or written using the designated storage protocol. 459 4. Specifications of Existing Layout Types 461 This section is not normative with regards to each of the presented 462 types. This document does not update the specification of either the 463 block layout type (see [RFC5663]) or the object layout type (see 464 [RFC5664]). Nor does it update Section 13 of [RFC5661], but rather 465 Section 12 of that document. In other words, it is the pNFS 466 requirements being updated, not the specification of the file layout 467 type. 469 4.1. File Layout Type 471 Because the storage protocol is a subset of NFSv4.1, the semantics of 472 the file layout type comes closest to the semantics of NFSv4.1 in the 473 absence of pNFS. In particular, the stateid and principal used for I 474 /O MUST have the same effect and be subject to the same validation on 475 a data server as it would if the I/O were being performed on the 476 metadata server itself. The same set of validations apply whether 477 pNFS is in effect or not. 479 And while for most implementations the storage devices can do the 480 following validations: 482 (1) client holds a valid layout, 484 (2) client I/O matches the layout iomode, and, 486 (3) client does not go out of the byte ranges, 488 these are each presented as a "SHOULD" and not a "MUST". Actually, 489 the first point is presented as both: 491 "MUST": in Section 13.6 of [RFC5661] 493 "As described in Section 12.5.1, a client MUST NOT send an I/O to 494 a data server for which it does not hold a valid layout; the data 495 server MUST reject such an I/O." 497 "SHOULD": in Section 13.8 of [RFC5661] 499 "The iomode need not be checked by the data servers when clients 500 perform I/O. However, the data servers SHOULD still validate that 501 the client holds a valid layout and return an error if the client 502 does not." 504 However, it is just these layout specific checks that are optional, 505 not the normal file access semantics. The storage devices MUST make 506 all of the required access checks on each READ or WRITE I/O as 507 determined by the NFSv4.1 protocol. If the metadata server would 508 deny a READ or WRITE operation on a file due to its ACL, mode 509 attribute, open access mode, open deny mode, mandatory byte-range 510 lock state, or any other attributes and state, the storage device 511 MUST also deny the READ or WRITE operation. And note that while the 512 NFSv4.1 protocol does not mandate export access checks based on the 513 client's IP address, if the metadata server implements such a policy, 514 then that counts as such state as outlined above. 516 The data filehandle provided by the PUTFH operation to the data 517 server is sufficient to ensure that for the subsequent READ or WRITE 518 operation in the compound, that the client has a valid layout for the 519 I/O being performed. 521 Finally, the data server can check the stateid presented in the READ 522 or WRITE operation to see if that stateid has been rejected by the 523 metadata server such to cause the I/O to be fenced. Whilst it might 524 just be the open owner or lock owner on that client being fenced, the 525 client should take the NFS4ERR_BAD_STATEID error code to mean it has 526 been fenced from the file and contact the metadata server. 528 4.2. Block Layout Type 530 With the block layout type, the storage devices are not guaranteed to 531 be able to enforce file-based security. Typically, storage area 532 network (SAN) disk arrays and SAN protocols provide access control 533 mechanisms (e.g., Logical Unit Number (LUN) mapping and/or masking), 534 which operate at the granularity of individual hosts, not individual 535 blocks. Access to block storage is logically at a lower layer of the 536 I/O stack than NFSv4, and hence NFSv4 security is not directly 537 applicable to protocols that access such storage directly. As such, 538 Section 2.1 [RFC5663] specifies that: 540 "in environments where pNFS clients cannot be trusted to enforce 541 such policies, pNFS block layout types SHOULD NOT be used." 543 As a result of these granularity issues, the security burden has been 544 shifted from the storage devices to the client. Those deploying 545 implementations of this layout type need to be sure that the client 546 implementation can be trusted This is not a new sort of requirement 547 in the context of SAN protocols. In such environments, the client is 548 expected to provide block-based protection. 550 This shift of the burden also extends to locks and layouts. The 551 storage devices are not able to enforce any of these and the burden 552 is pushed to the client to make the appropriate checks before sending 553 I/O to the storage devices. For example, the server may use a layout 554 iomode only allowing reading to enforce a mandatory read-only lock, 555 In such cases, the client has to support that use by not sending 556 WRITEs to the storage devices. The fundamental issue here is that 557 the storage device is treated by this layout type as a local dumb 558 disk. Once the client has access to the storage device, it is able 559 to perform both READ and WRITE I/O to the entire storage device. The 560 byte ranges in the layout, any locks, the layout iomode, etc, can 561 only be enforced by the client. Therefore, the client is required to 562 provide that enforcement. 564 In the context of fencing off of the client upon revocation of a 565 layout, these limitations come into play again, i.e., the granularity 566 of the fencing can only be at the host/logical-unit level. Thus, if 567 one of a client's layouts is revoked by the server, it will 568 effectively revoke all of the client's layouts for files located on 569 the storage units comprising the logical volume. This may extend to 570 the client's layouts for files in other file systems. Clients need 571 to be prepared for such revocations and reacquire layouts as needed. 573 4.3. Object Layout Type 575 With the object layout type, security checks occur during the 576 allocation of the layout. The client will typically ask for layouts 577 covering all of the file and may do so for either READ or READ/WRITE. 578 This enables it to do subsequent I/O operations without the need to 579 obtain layouts for specific byte ranges. At that time, the metadata 580 server should verify permissions against the layout iomode, the file 581 mode bits or ACLs, etc. As the client may be acting for multiple 582 local users, it MUST authenticate and authorize the user by issuing 583 respective OPEN and ACCESS calls to the metadata server, similar to 584 having NFSv4 data delegations. 586 Upon successful authorization, the client receives within the layout 587 a set of object capabilities allowing it I/O access to the specified 588 objects corresponding to the requested iomode. These capabilities 589 are used to enforce access control and locking semantics at the 590 storage devices. Whenever one of the following occur on the metadata 591 server: 593 o the permissions on the object change, 595 o a conflicting mandatory byte-range lock is granted, or 597 o a layout is revoked and reassigned to another client, 599 then the metadate server MUST change the capability version attribute 600 on all objects comprising the file to in order to invalidate any 601 outstanding capabilities before committing to one of these changes. 603 When the metadata server wishes to fence off a client to a particular 604 object, then it can use the above approach to invalidate the 605 capability attribute on the given object. The client can be informed 606 via the storage device that the capability has been rejected and is 607 allowed to fetch a refreshed set of capabilities, i.e., re-acquire 608 the layout. 610 5. Summary 612 In the three published layout types, the burden of enforcing the 613 security of NFSv4.1 can fall to either the storage devices (files), 614 the client (blocks), or the metadata server (objects). Such choices 615 are conditioned by the native capabilities of the storage devices - 616 if a control protocol can be implemented, then the burden can be 617 shifted primarily to the storage devices. 619 In the context of this document, we treat the control protocol as a 620 set of requirements. And as new layout types are published, the 621 defining documents MUST address: 623 (1) The fencing of clients after a layout is revoked. 625 (2) The security implications of the native capabilities of the 626 storage devices with respect to the requirements of the NFSv4.1 627 security model. 629 In addition, these defining documents need to make clear how other 630 semantic requirements of NFSv4.1 (e.g., locking) are met in the 631 context of the proposed layout type. 633 6. Security Considerations 635 This section does not deal directly with security considerations for 636 existing or new layout types. Instead, it provides a general 637 framework for understating security-related issues within the pNFS 638 framework. Specific security considerations will be addressed in the 639 Security Considerations sections of documents specifying layout 640 types. 642 The layout type specification must ensure that only data accesses 643 consistent with the NFSV4.1 security model are allowed. It may do 644 this directly, by providing that appropriate checks be performed at 645 the time the access is performed. It may do it indirectly by 646 allowing the client or the storage device to be responsible for 647 making the appropriate checks. In the latter case, I/O access writes 648 are reflected in layouts and the layout type must provide a way to 649 prevent inappropriate access due to permissions changes between the 650 time a layout is granted and the time the access is performed. 652 The metadata server MUST be able to fence off a client's access to 653 the data file on a storage device. When it revokes the layout, the 654 client's access MUST be terminated at the storage devices. The 655 client the has the opportunity to re-acquire the layout and perform 656 the security check in the context of the newly current access 657 permissions. 659 7. IANA Considerations 661 This document has no actions for IANA. 663 8. References 665 8.1. Normative References 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", March 1997. 670 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 671 System (NFS) Version 4 Minor Version 1 Protocol", RFC 672 5661, January 2010. 674 [RFC5663] Black, D., Fridella, S., and J. Glasgow, "pNFS Block/ 675 Volume Layout", RFC 5663, January 2010. 677 [RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based 678 Parallel NFS (pNFS) Operations", RFC 5664, January 2010. 680 8.2. Informative References 682 [FlexFiles] 683 Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible 684 File Layout", draft-ietf-nfsv4-flex-files-11 (Work In 685 Progress), July 2017. 687 [Lustre] Faibish, S. and P. Tao, "Parallel NFS (pNFS) Lustre Layout 688 Operations", draft-faibish-nfsv4-pnfs-lustre-layout-07 689 (Work In Progress), April 2014. 691 Appendix A. Acknowledgments 693 Dave Noveck provided an early review that sharpened the clarity of 694 the definitions. He also provided a more comprehensive review of the 695 document. 697 Appendix B. RFC Editor Notes 699 [RFC Editor: please remove this section prior to publishing this 700 document as an RFC] 702 [RFC Editor: prior to publishing this document as an RFC, please 703 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 704 RFC number of this document] 706 Author's Address 707 Thomas Haynes 708 Primary Data, Inc. 709 4300 El Camino Real Ste 100 710 Los Altos, CA 94022 711 USA 713 Phone: +1 408 215 1519 714 Email: thomas.haynes@primarydata.com