idnits 2.17.1 draft-ietf-nfsv4-designconsider-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2054' on line 843 looks like a reference -- Missing reference section? 'RFC2055' on line 849 looks like a reference -- Missing reference section? 'RFC1831' on line 819 looks like a reference -- Missing reference section? 'XDSM' on line 956 looks like a reference -- Missing reference section? 'HPFS' on line 902 looks like a reference -- Missing reference section? 'Nagar' on line 921 looks like a reference -- Missing reference section? 'DCEACL' on line 897 looks like a reference -- Missing reference section? 'RFC2203' on line 867 looks like a reference -- Missing reference section? 'RFC2246' on line 885 looks like a reference -- Missing reference section? 'RFC2025' on line 837 looks like a reference -- Missing reference section? 'RFC1510' on line 807 looks like a reference -- Missing reference section? 'RFC2401' on line 891 looks like a reference -- Missing reference section? 'RFC1832' on line 825 looks like a reference -- Missing reference section? 'Unicode1' on line 943 looks like a reference -- Missing reference section? 'RFC1094' on line 801 looks like a reference -- Missing reference section? 'RFC1813' on line 813 looks like a reference -- Missing reference section? 'RFC1833' on line 831 looks like a reference -- Missing reference section? 'RFC2078' on line 855 looks like a reference -- Missing reference section? 'RFC2152' on line 861 looks like a reference -- Missing reference section? 'RFC2222' on line 873 looks like a reference -- Missing reference section? 'RFC2279' on line 879 looks like a reference -- Missing reference section? 'Hutson' on line 906 looks like a reference -- Missing reference section? 'Kistler' on line 911 looks like a reference -- Missing reference section? 'Mummert' on line 916 looks like a reference -- Missing reference section? 'Sandberg' on line 925 looks like a reference -- Missing reference section? 'Satyanarayanan1' on line 933 looks like a reference -- Missing reference section? 'Satyanarayanan2' on line 937 looks like a reference -- Missing reference section? 'Unicode2' on line 950 looks like a reference -- Missing reference section? 'XNFS' on line 961 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Spencer Shepler 2 Document: draft-ietf-nfsv4-designconsider-02.txt 4 NFS Version 4 Design Considerations 6 Status of this Memo 8 This document is an Internet-Draft and is in full conformance with 9 all provisions of Section 10 of RFC2026. 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 The main task of the NFS version 4 working group is to create a 30 protocol definition for a distributed file system that focuses on the 31 following items: improved access and good performance on the 32 Internet, strong security with negotiation built into the protocol, 33 better cross-platform interoperability, and designed for protocol 34 extensions. NFS version 4 will owe its general design to the 35 previous versions of NFS. It is expected, however, that many 36 features will be quite different in NFS version 4 than previous 37 versions to facilitate the goals of the working group and to address 38 areas that NFS version 2 and 3 have not. 40 This design considerations document is meant to present more detail 41 than the working group charter. Specifically, it presents the areas 42 that the working group will investigate and consider while developing 43 a protocol specification for NFS version 4. Based on this 44 investigation the working group will decide the features of the new 45 protocol based on the cost and benefits within the specific feature 46 areas. 48 Copyright 50 Copyright (C) The Internet Society (1999). All Rights Reserved. 52 Key Words 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 Table of Contents 60 1. NFS Version 4 Design Considerations . . . . . . . . . . . . . 4 61 2. Ease of Implementation or Complexity of Protocol . . . . . . 4 62 2.1. Extensibility / layering . . . . . . . . . . . . . . . . . 4 63 2.2. Managed Extensions or Minor Versioning . . . . . . . . . . 4 64 2.3. Relationship with Older Versions of NFS . . . . . . . . . . 6 65 3. Reliable and Available . . . . . . . . . . . . . . . . . . . 6 66 4. Scalable Performance . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Throughput and Latency via the Network . . . . . . . . . . 7 68 4.2. Client Caching . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Disconnected Client Operation . . . . . . . . . . . . . . . 9 70 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1. Platform Specific Behavior . . . . . . . . . . . . . . . . 9 72 5.2. Additional or Extended Attributes . . . . . . . . . . . . . 9 73 5.3. Access Control Lists . . . . . . . . . . . . . . . . . . 10 74 6. RPC Mechanism and Security . . . . . . . . . . . . . . . . 11 75 6.1. User identification . . . . . . . . . . . . . . . . . . . 12 76 6.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2.1. Transport Independence . . . . . . . . . . . . . . . . 13 78 6.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 13 79 6.2.3. Data Integrity . . . . . . . . . . . . . . . . . . . . 13 80 6.2.4. Data Privacy . . . . . . . . . . . . . . . . . . . . . 13 81 6.2.5. Security Negotiation . . . . . . . . . . . . . . . . . 14 82 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7. Internet Accessibility . . . . . . . . . . . . . . . . . . 15 84 7.1. Congestion Control and Transport Selection . . . . . . . 15 85 7.2. Firewalls and Proxy Servers . . . . . . . . . . . . . . . 16 86 7.3. Multiple RPCs and Latency . . . . . . . . . . . . . . . . 16 87 8. File locking / recovery . . . . . . . . . . . . . . . . . . 17 88 9. Internationalization . . . . . . . . . . . . . . . . . . . 18 89 10. Security Considerations . . . . . . . . . . . . . . . . . 19 90 10.1. Denial of Service . . . . . . . . . . . . . . . . . . . 19 91 11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 20 92 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 25 93 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 25 94 14. Full Copyright Statement . . . . . . . . . . . . . . . . . 26 96 1. NFS Version 4 Design Considerations 98 As stated in the charter, the first deliverable for the NFS version 4 99 working group is this design considerations document. This document 100 is to cover the "limitations and deficiencies of NFS version 3". 101 This document will also be used as a mechanism to focus discussion 102 and avenues of investigation as the definition of NFS version 4 103 progresses. Therefore, the contents of this document cover the 104 general functional/feature areas that are anticipated for NFS version 105 4. Where appropriate, discussion of current NFS version 2 and 3 106 practice will be presented along with other appropriate references to 107 current distributed file system practice. 109 2. Ease of Implementation or Complexity of Protocol 111 One of the strengths of NFS has been the ability to implement a 112 client or server with relative ease. The eventual size of a basic 113 implementation is relatively small. The main reason for keeping NFS 114 as simple as possible is that a simple protocol design can be 115 described in a simple specification that promotes straightforward, 116 interoperable implementations. All protocols can run into problems 117 when deployed on real networks, but simple protocols yield problems 118 that are easier to diagnose and correct. 120 2.1. Extensibility / layering 122 With NFS' relative simplicity, the addition or layering of 123 functionality has been easy to accomplish. The addition of features 124 like the client automount or autofs, client side disk caching and 125 high availability servers are examples. This type of extensibility 126 is desirable in an environment where problem solutions do not require 127 protocol revision. This extensibility can also be helpful in the 128 future where unforeseen problems or opportunities can be solved by 129 layering functionality on an existing set of tools or protocol. 131 2.2. Managed Extensions or Minor Versioning 133 For those cases where the NFS protocol is deficient or where a minor 134 modification is the best solution for a problem, a minor version or a 135 managed extension could be helpful. There have been instances with 136 NFS version 2 and 3 where small straightforward functional additions 137 would have increased the overall value of the protocol immensely. 138 For instance, the PATHCONF procedure that was added to version 2 of 139 the MOUNT protocol would have been more appropriate for the NFS 140 protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP 141 procedure for NFS versions 2 and 3 would have been more cleanly 142 implemented in a new LOOKUP procedure. 144 However, the perceived size and burden of using a change of RPC 145 version number for the introduction of new functionality led to no or 146 slow change. It is possible that a new NFS protocol could allow for 147 the rare instance where protocol extension within the RPC version 148 number is the most prudent course and an RPC revision would be 149 unnecessary or impractical. 151 The areas of an NFS protocol which are most obviously volatile are 152 new orthogonal procedures, new well-defined file or directory 153 attributes and potentially new file types. As an example, potential 154 file types of the future could be a type such as "attribute" that 155 represents a named file stream or a "dynamic" file type that 156 generates dynamic data in response to a "query" procedure from the 157 client. 159 It is possible and highly desirable that these types of additions be 160 done without changing the overall design model of NFS without 161 significant effort or delay. 163 A strong consideration should be given to a NFS protocol mechanism 164 for the introduction of this type of new functionality. This is 165 obviously in contrast to using the standard RPC version mechanism to 166 provide minor changes. The process of using RPC version numbers to 167 introduce new functionality brings with it a lot of history which may 168 not technically prevent its use. However, the historical issues 169 involved will need to be addressed as part of the NFS version 4 170 protocol work; this should increase the ability for current and 171 future success of the protocol. 173 As background, the RPC protocol described in [RFC1831] uses a version 174 number to describe the set of procedure calls, replies, and their 175 semantics. Any change in this set must be reflected in a new version 176 number for the program. An example of this was the 177 MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT 178 protocol. Except for the addition of this new procedure, the 179 protocol was unchanged. Many thought this protocol revision was 180 unnecessary, since the RPC protocol already allows certain procedures 181 not be implemented and defines a PROC_UNAVAIL error. 183 Another historical data-point from NFS version 2 and 3 is the support 184 (or lack) of symbolic links. Servers that cannot support this 185 feature will simply reject calls to the SYMLINK and READLINK 186 procedures. Additionally, NFS version 4 may describe many file 187 attributes which cannot be supported by the server or file systems on 188 the server. Therefore, the protocol must support a discovery 189 mechanism that allows clients to determine which features of the 190 protocol are supported by a server. 192 2.3. Relationship with Older Versions of NFS 194 NFS version 4 will be a self contained protocol in that it will not 195 have any dependencies on the previous versions of NFS. Stated 196 another way, an NFS version 4 server or client will not require a 197 NFSv2 or NFSv3 implementation be present for NFS version 4 to 198 function as designed. It should also be noted that having an NFS 199 version 2 or 3 implementation present at the client or server will 200 not enhance the functionality of an NFS version 4 implementation. 202 In the case where an NFS client has a choice of using various NFS 203 protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms 204 will allow the client to appropriately choose an available version of 205 the protocol at the NFS server. The ONCRPC protocol contains the 206 semantics and error returns for the case where an RPC server program 207 does not support a particular version. This mechanism is used by the 208 NFS client to receive notification of an unavailable version and in 209 conjunction with the error the client will also receive the range of 210 versions (min to max) that are available. Therefore, the ONCRPC 211 mechanism can be used by implementors of both clients and servers to 212 provide for the transitioning to or installation of NFS version 4 213 services. 215 3. Reliable and Available 217 Current NFS protocol design, while placing an emphasis on simple 218 server design, has led to timely recovery from server and client 219 failure. This and other aspects to the design have provided a basis 220 for layered technologies like high availability and clustered 221 servers. Providing a protocol design approach that lends itself to 222 these types of reliability and availability features is very 223 desirable. 225 For the next version of NFS, consideration should be given to client 226 side availability schemes such as client switching between or fail- 227 over to available server replicas. NFS currently requires that file 228 handles be immutable; this requirement adds unnecessarily to the 229 complexity of building fail-over configurations. If possible, the 230 protocol should allow for or ease the building of such layered 231 solutions. 233 For the next version of NFS, consideration should be given to schemes 234 that support client switching between server replicas or highly 235 available NFS servers that provide paths to data through multiple 236 servers. For example: NFS currently requires that filehandles be 237 unchanging for any instance of a file or directory. This requirement 238 makes it more difficult for a client to switch from one server to 239 another, since each server may construct filehandles differently. 240 Protocol support could allow the client to handle a filehandle 241 change. 243 4. Scalable Performance 245 In designing and developing an NFS protocol from a performance 246 viewpoint there are several different points to consider. Each can 247 play a significant role in perceived and real performance from the 248 user's perspective. The three main areas of interest are: throughput 249 and latency via the network, server work load or scalability and 250 client side caching. 252 4.1. Throughput and Latency via the Network 254 NFS currently has characteristics that provide good throughput for 255 reading and writing file data. This is commonly achieved by the 256 client's use of pipelining or windowing multiple RPC READ/WRITE 257 requests to the server. The flexibility of the NFS and ONCRPC 258 protocols allow for implementations to use this type of adaptation to 259 provide efficient use of the network connection. 261 However, the number of RPCs required to accomplish some tasks 262 combined with high latency network environments may lead to sluggish 263 single user or single client response. The protocol should continue 264 to provide good raw read and write throughput while addressing the 265 issue of network latency. This issue is discussed further in the 266 section on Internet Accessibility. 268 4.2. Client Caching 270 In an attempt to speed response time and to reduce network and server 271 load, NFS clients have always cached directory and file data. 273 However, this has usually been done as memory cache and in relatively 274 recent history, local disk caching has been added. 276 It is very desirable to have the NFS client cache directory and file 277 data. Other distributed file systems have shown that aggressive 278 client side caching can be very visible to the end user in the form 279 of decreasing overall response time. For AFS and DCE/DFS, caching is 280 accomplished by the utilization of server call backs to notify the 281 client of potential cache invalidation. CIFS and its opportunistic 282 locks provide a similar call back mechanism. Clients in both of 283 these environments are able to cache data while avoiding interaction 284 with the network and server. 286 With these protocols it is also possible to cache or delay certain 287 protocol requests at the client which further reduces the protocol 288 traffic flowing between client and server. In the case of CIFS, it 289 is possible for a client to obtain an opportunistic lock for a file 290 and subsequently process file lock requests completely at the client. 291 If there are no conflicts with other clients for file data access, 292 the server is never contacted for the file locking traffic generated 293 by the user application. This behavior is not a protocol requirement 294 but is allowed by the protocol as an implementation option to improve 295 performance. 297 NFS versions 2 and 3 make no caching requirements. Implementations 298 typically implement close-to-open cache consistency which requires 299 clients flush all changes to the server on each file close, and check 300 for file changes on the server on each file open. The consistency 301 check required on each file open can generate a large amount of 302 GETATTR traffic. With this approach, there are windows when the 303 client can still be acting with stale data between the open and close 304 of a file. 306 Client caching is increasingly important for Internet environments 307 where throughput can be limited and response time can grow 308 significantly. Therefore the NFS version 4 caching design will need 309 to take into account the full spectrum of caching designs as 310 exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS, 311 etc. in determining an appropriate design. This will need to be done 312 while weighing the complexity of each possible approach with the need 313 of the eventual users and operating environments into which NFS 314 version 4 may be deployed. Some of these considerations are: 315 Internet accessibility, firewall traversal (call back availability), 316 proxy caching, low-overhead or simple clients. 318 4.3. Disconnected Client Operation 320 An extension of client caching is the provision for disconnected 321 operation at the client. With the ability to cache directory and 322 file data aggressively, a client could then provide service to the 323 end user while disconnected from the server or network. 325 While very desirable, disconnected operation has the potential to 326 inflict itself upon the NFS protocol in an undesirable way as 327 compared to traditional client caching. Given the complexities of 328 disconnected client operation and subsequent resolution of client 329 data modification through various playback or data selection 330 mechanisms, disconnected operation should not be a requirement for 331 the NFS effort. Even so, the NFS protocol should consider the 332 potential layering of disconnected operation solutions on top of the 333 NFS protocol (as with other server and client solutions). The 334 experiences with Coda, disconnected AFS and others should be helpful 335 in this area. (see references) 337 5. Interoperability 339 The NFS protocols are available for many different operating 340 environments. Even though this shows the protocol's ability to 341 provide distributed file system service for more than a single 342 operating system, the design of NFS is certainly Unix-centric. The 343 next NFS protocol needs to be more inclusive of platform or file 344 system features beyond those of traditional Unix. 346 5.1. Platform Specific Behavior 348 Because of Unix-centric origins, NFS version 2 and 3 protocol 349 requirements have been difficult to implement in some environments. 350 For example, persistent file handles (unique identifiers of file 351 system objects), Unix uid/gid mappings, directory modification time, 352 accurate file sizes, file/directory locking semantics (SHAREs, PC- 353 style locking). In the design of NFS version 4, these areas and 354 others not mentioned will need to be considered and, if possible, 355 cross-platform solutions developed. 357 5.2. Additional or Extended Attributes 359 NFS versions 2 and 3 do not provide for file or directory attributes 360 beyond those that are found in the traditional Unix environment. For 361 example the user identifier/owner of the file, a permission or access 362 bitmap, time stamps for modification of the file or directory and 363 file size to name a few. While the current set of attributes has 364 usually been sufficient, the file system's ability to manage 365 additional information associated with a file or directory can be 366 useful. 368 There are many possibilities for additional attributes in the next 369 version of NFS. Some of these include: object creation timestamp, 370 user identifier of file's creator, timestamp of last backup or 371 archival bit, version number, file content type (MIME type), 372 existence of data management involvement (i.e. DMAPI [XDSM]). 374 This list is representative of the possibilities and is meant to show 375 the need for an additional attribute set. Enumerating the 'correct' 376 set of attributes, however, is difficult. This is one of the reasons 377 for looking towards a minor versioning mechanism as a way to provide 378 needed extensibility. Another way to provide some extensibility is 379 to support a generalized named attribute mechanism. This mechanism 380 would allow a client to name, store and retrieve arbitrary data and 381 have it associated as an attribute of a file or directory. 383 One difficulty in providing named attributes is determining if the 384 protocol should specify the names for the attributes, their type or 385 structure. How will the protocol determine or allow for attributes 386 that can be read but not written is another issue. Yet another could 387 be the side effects that these attributes have on the core set of 388 file properties such as setting a size attribute to 0 and having 389 associated file data deleted. 391 As these brief examples show, this type of extended attribute 392 mechanism brings with it a large set of issues that will need to be 393 addressed in the protocol specification while keeping the overall 394 goal of simplicity in mind. 396 There are operating environments that provide named or extended 397 attribute mechanisms. Digital Unix provides for the storage of 398 extended attributes with some generalized format. HPFS[HPFS] and 399 NTFS [Nagar] also provide for named data associated with traditional 400 files. SGI's local file system, XFS, also provides for this type of 401 name/value extended attributes. However, there does not seem to be a 402 clear direction that can be taken from these or other environments. 404 5.3. Access Control Lists 406 Access Control Lists (ACL) can be viewed as one specific type of 407 extended attribute. This attribute is a designation of user access 408 to a file or directory. Many vendors have created ancillary 409 protocols to NFS to extend the server's ACL mechanism across the 410 network. Generally this has been done for homogeneous operating 411 environments. Even though the server still interprets the ACL and has 412 final control over access to a file system object, the client is able 413 to manipulate the ACL via these additional protocols. Other 414 distributed file systems have also provided ACL support (DFS, AFS and 415 CIFS). 417 The basic factor driving the requirement for ACL support in all of 418 these file systems has been the user's desire to grant and restrict 419 access to file system data on a per user basis. Based on the desire 420 of the user and current distributed file system support, it seems to 421 be a requirement that NFS provide this capability as well. 423 Because many local and distributed file system ACL implementations 424 have been done without a common architecture, the major issue is one 425 of compatibility. Although the POSIX draft, DCE/DFS [DCEACL] and 426 Windows NT ACLs have a similar structure in an array of Access 427 Control Entries consisting of a type field, identity, and permission 428 bits, the similarity ends there. Each model defines its own variants 429 of entry types, identifies users and groups differently, provides 430 different kinds of permission bits, and describes different 431 procedures for ACL creation, defaults, and evaluation. 433 In the least it will be problematic to create a workable ACL 434 mechanism that will encompass a reasonable set of functionality for 435 all operating environments. Even with the complicated nature of ACL 436 support it is still worthwhile to work towards a solution that can at 437 least provide basic functionality for the user. 439 6. RPC Mechanism and Security 441 NFS relies on the security mechanisms provided by the ONCRPC 442 [RFC1831] protocol. Until the introduction of the ONCRPC RPCSEC_GSS 443 security flavor [RFC2203], NFS security was generally limited to none 444 (AUTH_SYS) or DES (AUTH_DH). The AUTH_DH security flavor was not 445 successful in providing readily available security for NFS because of 446 a lack of widespread implementation which precluded widespread 447 deployment. Also the Diffie-Hellman 192 bit public key modulus used 448 for the AUTH_DH security flavor quickly became too small for 449 reasonable security. 451 6.1. User identification 453 NFS has been limited to the use of the Unix-centric user 454 identification mechanism of numeric user id based on the available 455 file system attributes and the use of the ONCRPC. However, for NFS 456 to move beyond the limits of large work groups, user identification 457 should be string based and the definition of the user identifier 458 should allow for integration into an external naming service or 459 services. 461 Internet scaling should also be considered for this as well. The 462 identification mechanism should take into account multiple naming 463 domains and multiple naming mechanisms. Flexibility is the key to a 464 solution that can grow with the needs of the user and administrator. 466 If NFS is to move among various naming and security services, it may 467 be necessary to stay with a string based identification. This would 468 allow for servers and clients to translate between the external 469 string representation to a local or internal numeric (or other 470 identifier) which matches internal implementation needs. 472 As an example, DFS uses a string based naming scheme but translates 473 the name to a UUID (16 byte identifier) that is used for internal 474 protocol representations. The DCE/DFS string name is a combination of 475 cell (administrative domain) and user name. As mentioned, NFS 476 clients and servers map a Unix user name to a 32 bit user identifier 477 that is then used for ONCRPC and NFS protocol fields requiring the 478 user identifier. 480 6.2. Security 482 Because of the aforementioned problems, user authentication has been 483 a major issue for ONCRPC and hence NFS. To satisfy requirements of 484 the IETF and to address concerns and requirements from users, NFS 485 version 4 must provide for the use of acceptable security mechanisms. 486 The various mechanisms currently available should be explored for 487 their appropriate use with NFS version 4 and ONCRPC. Some of these 488 mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510], 489 IPSEC [RFC2401]. Since ONCRPC is the basis for NFS client and server 490 interaction, the RPCSEC_GSS [RFC2203] framework should be strongly 491 considered since it provides a method to employ mechanisms like SPKM 492 and KerberosV5. Before a security mechanism can be evaluated, the 493 NFS environment and requirements must be discussed. 495 6.2.1. Transport Independence 497 As mentioned later in this document in the section "Internet 498 Accessibility", transport independence is an asset for NFS and ONCRPC 499 and is a general requirement. This allows for transport choice based 500 on the target environment and specific application of NFS. The most 501 common transports in use with NFS are UDP and TCP. This ability to 502 choose transport should be maintained in combination with the user's 503 choice of a security mechanism. This implies that "mandatory to 504 implement" security mechanisms for NFS should allow for both 505 connection-less and connection-oriented transports. 507 6.2.2. Authentication 509 As should be expected, strong authentication is a requirement for NFS 510 version 4. Each operation generated via ONCRPC contains user 511 identification and authentication information. It is common in NFS 512 version 2 and 3 implementations to multiplex various users' requests 513 over a single or few connections to the NFS server. This allows for 514 scalability in the number of clients systems. Security mechanisms or 515 frameworks should allow for this multiplexing of requests to sustain 516 the implementation model that is available today. 518 6.2.3. Data Integrity 520 Until the introduction of RPCSEC_GSS, the ability to provide data 521 integrity over ONCRPC and to NFS was not available. Since file and 522 directory data is the essence of a distributed file service, the NFS 523 protocol should provide to the users of the file service a reasonable 524 level of data integrity. The security mechanisms chosen must provide 525 for NFS data protection with a cryptographically strong checksum. As 526 with other aspects within NFS version 4, the user or administrator 527 should be able to choose whether data integrity is employed. This 528 will provide needed flexibility for a variety of NFS version 4 529 solutions. 531 6.2.4. Data Privacy 533 Data privacy, while desirable, is not as important in all 534 environments as authentication and integrity. For example, in a LAN 535 environment the performance overhead of data privacy may not be 536 required to meet an organization's data protection policies. It may 537 also be the case that the performance of the distributed file system 538 solution is more important than the data privacy of that solution. 539 Even with these considerations, the user or administrator must have 540 the choice of data privacy and therefore it must be included in NFS 541 version 4. 543 6.2.5. Security Negotiation 545 With the ability to provide security mechanism choices to the user or 546 administrator, NFS version 4 should offer reasonable flexibility for 547 application of local security policies. However, this presents the 548 problem of negotiating the appropriate security mechanism between 549 client and server. It is unreasonable to require the client know the 550 server's chosen mechanism before initial contact. The issue is 551 further complicated by an administrator who may choose more than one 552 security mechanism for the various file system resources being shared 553 by an NFS server. These types of choices and policies require that 554 NFS version 4 deal with negotiating the appropriate security 555 mechanism based on mechanism availability and policy deployment at 556 client and server. This negotiation will need to take into account 557 the possibility of a change in policy as an NFS client crosses 558 certain file system boundaries at the server. The security 559 mechanisms required may change at these boundaries and therefore the 560 negotiation must be included within the NFS protocol itself to be 561 done properly (i.e. securely). 563 6.3. Summary 565 Other distributed file system solutions such as AFS and DFS provide 566 strong authentication mechanisms. CIFS does provide authentication 567 at initial server contact and a message signing option for subsequent 568 interaction. Recent NFS version 2 and 3 implementations, with the 569 use of RPCSEC_GSS, provide strong authentication, integrity, and 570 privacy. 572 NFS version 4 must provide for strong authentication, integrity, and 573 privacy. This must be part of the protocol so that users have the 574 choice to use strong security if their environment or policies 575 warrant such use. 577 Based on the requirements presented, the ONCRPC RPCSEC_GSS security 578 flavor seems to provide an appropriate framework for satisfying these 579 requirements. RPCSEC_GSS provides for authentication, integrity, and 580 privacy. The RPCSEC_GSS is also extensible in that it provides for 581 both public and private key security mechanisms along with the 582 ability to plug in various mechanisms in such a way that it does not 583 significantly disrupt ONCRPC or NFS implementations. 585 With RPCSEC_GSS' ability to support both public and private key 586 mechanisms, NFS version 4 should consider "mandatory to implement" 587 choices from both. The intent is to provide a security solution that 588 will flexibly scale to match the needs of end users. Providing this 589 range of solutions will allow for appropriate usage based on policy 590 and available resources for deployment. Note that, in the end, the 591 user must have a choice and that choice may be to use all of the 592 available mechanisms in NFS version 4 or none of them. 594 7. Internet Accessibility 596 Being a product of an IETF working group, the NFS protocol should not 597 only be built upon IETF technologies where possible but should also 598 work well within the broader Internet environment. 600 7.1. Congestion Control and Transport Selection 602 As with any network protocol, congestion control is a major issue and 603 the transport mechanisms that are chosen for NFS should take this 604 into account. Traditionally, implementations of NFS have been 605 deployed using both UDP and TCP. With the use of UDP, most 606 implementations provide a rudimentary attempt control congestion with 607 simple back-off algorithms and round trip timers. While this may be 608 sufficient in today's NFS deployments, as an Internet protocol NFS 609 will need to ensure sufficient congestion control or management. 611 With congestion control in mind, NFS must use TCP as a transport (via 612 ONCRPC). The UDP transport provides its own advantages in certain 613 circumstances. In today's NFS implementations, UDP has been shown to 614 produce greater throughput as compared to similarly configured 615 systems that use TCP. This issue will need to be investigated such 616 that a determination can be made as to whether the differences are 617 within implementation details. If UDP is supplied as an NFS 618 transport mechanism, then the congestion controls issues will need 619 resolution to make its use suitable. 621 7.2. Firewalls and Proxy Servers 623 NFS's protocol design should allow its use via Internet firewalls. 624 The protocol should also allow for the use of file system proxy/cache 625 servers. Proxy servers can be very useful for scalability and other 626 reasons. The NFS protocol needs to address the need of proxy servers 627 in a way that will deal with the issues of security, access control, 628 and content control. It is possible that these issues can be 629 addressed by documenting the related issues of proxy server usage. 630 However, it is likely that the NFS protocol will need to support 631 proxy servers directly through the NFS protocol. 633 The protocol could allow a request to be sent to a proxy that 634 contains the name of the target NFS server to which the request might 635 be forwarded, or from which a response might be cached. In any case, 636 the NFS proxy server should be considered during protocol 637 development. 639 The problems encountered in making the NFS protocol work through 640 firewalls are described in detail in [RFC2054] and [RFC2055]. 642 7.3. Multiple RPCs and Latency 644 As an application at the NFS client performs simple file system 645 operations, multiple NFS operations or RPCs may be executed to 646 accomplish the work for the application. While the NFS version 3 647 protocol addressed some of this by returning file and directory 648 attributes for most procedures, hence reducing follow up GETATTR 649 requests, there is still room for improvement. Reducing the number 650 of RPCs will lead to a reduction of processing overhead on the server 651 (transport and security processing) along with reducing the time 652 spent at the client waiting for the server's individual responses. 653 This issue is more prominent in environments with larger degrees of 654 latency. 656 The CIFS file access protocol supports 'batched requests' that allow 657 multiple requests to be batched, therefore reducing the number of 658 round trip messages between client and server. 660 This same approach can be used by NFS to allow the grouping of 661 multiple procedure calls together in a traditional RPC request. Not 662 only would this reduce protocol imposed latency but it would reduce 663 transport and security processing overhead and could allow a client 664 to complete more complex tasks by combining procedures. 666 8. File locking / recovery 668 NFS provided Unix file locking and DOS SHARE capability with the use 669 of an ancillary protocol (Network Lock Manager / NLM). The DOS SHARE 670 mechanism is the DOS equivalent of file locking in that it provides 671 the basis for sharing or exclusive access to file and directory data 672 without risk of data corruption. The NLM protocol provides file 673 locking and recovery of those locks in the event of client or server 674 failure. The NLM protocol requires that the server make call backs 675 to the client for certain scenarios and therefore is not necessarily 676 well suited for Internet firewall traversal. 678 Available and correct file locking support for NFS version 2 and 3 679 clients and servers has historically been problematic. The 680 availability of NLM support has traditionally been a problem and 681 seems to be most related to the fact that NFS and NLM are two 682 separate protocols. It is easy to deliver an NFS client and server 683 implementation and then add NLM support later. This led to a general 684 lack of NLM support early on in NFS' lifetime. One of the reasons 685 that NLM was delivered separately has been its relative complexity 686 which has in turn led to poor implementations and testing 687 difficulties. Even in later implementations where reliability and 688 performance had been increased to acceptable levels for NLM, users 689 still chose to avoid the use of the protocol and its support. The 690 last issue with NLM is the presence of minor protocol design flaws 691 that relate to high network load and recovery. 693 Based on the experiences with NLM, locking support for NFS version 4 694 should strive to meet or at least consider the following (in order of 695 importance): 697 o Integration with the NFS protocol and ease of implementation. 699 o Interoperability between operating environments. The protocol 700 should make a reasonable effort to support the locking semantics 701 of both PC and Unix clients and servers. This will allow for 702 greater integration of all environments. 704 o Scalable solutions - thousands of clients. The server should 705 not be required to maintain significant client file locking 706 state between server instantiations. 708 o Internet capable (firewall traversal, latency sensitive). The 709 server should not be required to initiate TCP connections to 710 clients. 712 o Timely recovery in the event of client/server or network 713 failure. Server recovery should be rapid. The protocol should 714 allow clients to detect the loss of a lock. 716 9. Internationalization 718 NFS version 2 and 3 are currently limited in the character encoding 719 of strings. In the NFS protocols, strings are used for file and 720 directory names, and symbolic link contents. Although the XDR 721 definition [RFC1832] limits strings in the NFS protocol to 7-bit US- 722 ASCII, common usage is to encode filenames in 8-bit ISO-Latin-1. 723 However, there is no mechanism available to tag XDR character strings 724 to indicate the character encoding used by the client or server. 725 Obviously this limits NFS' usefulness in an environment with clients 726 that may operate with various character sets. 728 One approach to address this deficiency is to use the Unicode 729 Standard [Unicode1] as the means to exchange character strings for 730 the NFS version 4 protocol. The Unicode Standard is a 16 bit encoding 731 that supports full multilingual text. The Unicode Standard is code- 732 for-code identical with International Standard ISO/IEC 10646-1:1993. 733 "Information Technology -- Universal Multiple-Octet Coded Character 734 Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because 735 Unicode is a 16 bit encoding, it may be more efficient for the NFS 736 version 4 protocol to use an encoding for wire transfer that will be 737 useful for a majority of usage. One possible encoding is the UCS 738 transformation format (UTF). UTF-8 is an encoding method for UCS-4 739 characters which allows for the direct encoding of US-ASCII 740 characters but expands for the correct encoding of the full UCS-4 31 741 bit definitions. Currently, the UCS-4 and Unicode standards do not 742 diverge. 744 This Unicode/UTF-8 encoding can be used for places in the protocol 745 that a traditional string representation is needed. This includes 746 file and directory names along with symlink contents. This should 747 also include other file and directory attributes that are eventually 748 defined as strings. 750 The Unicode standard is applicable to the well defined strings within 751 the protocol. Dealing with file content is much more difficult. NFS 752 has traditionally dealt with file data as an opaque byte stream. No 753 other structure or content specification has been levied upon the 754 file content. The main advantage to this approach is its flexibility. 755 This byte stream can contain any data content and may be accessed in 756 any sequential or random fashion. Unfortunately, it is left to the 757 application or user to make the determination of file content and 758 format. It is possible to construct a mechanism in the protocol that 759 specifies file data type while maintaining the byte stream model for 760 data access. However, this approach may be limiting in ways unclear 761 to the designers of the NFS version 4 protocol. An expandable and 762 adaptable approach is to use the previously discussed extended 763 attributes as the mechanism to specify file content and format. The 764 use of extended attributes allows for future definition and growth as 765 various data types are created and allows for maintaining a simple 766 file data model for the NFS protocol. 768 It should be noted that as the Unicode standards are currently 769 defined there is the possibility for minor inconsistencies when 770 converting from local character representations to Unicode and then 771 back again. This should not be a problem with single client and 772 server interaction but may become apparent with the interaction of 773 two or more clients with separate conversion implementations. 774 Therefore, as NFS version 4 progresses in its development, these 775 types of Unicode issues need to be tracked and understood for their 776 potential impact on client/server interaction. In any case, Unicode 777 seems to be the best selection for NFS version 4 based on its 778 standards background and apparent future direction. 780 10. Security Considerations 782 Two previous sections within this document deal with security issues. 783 The section covering 'Access Control Lists' covers the mechanisms 784 that need to be investigated for file system level control. The 785 section that covers RPC security deals with individual user 786 authentication along with data integrity and privacy issues. This 787 section also covers negotiation of security mechanisms. These 788 sections should be consulted for additional discussion and detail. 790 10.1. Denial of Service 792 As with all services, the denial of service by either incorrect 793 implementations or malicious agents is always a concern. With the 794 target of providing NFS version 4 for Internet use, it is all the 795 more important that all aspects of the NFS version 4 protocol be 796 reviewed for potential denial of service scenarios. When found these 797 potential problems should be mitigated as much as possible. 799 11. Bibliography 801 [RFC1094] 802 Sun Microsystems, Inc., "NFS: Network File System Protocol 803 Specification", RFC1094, March 1989. 805 http://www.ietf.org/rfc/rfc1094.txt 807 [RFC1510] 808 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 809 (V5)", RFC1510, Digital Equipment Corporation, ISI, September 1993. 811 http://www.ietf.org/rfc/rfc1510.txt 813 [RFC1813] 814 Callaghan, B., Pawlowski, B., Staubach, P., "NFS Version 3 Protocol 815 Specification", RFC1813, Sun Microsystems, Inc., June 1995. 817 http://www.ietf.org/rfc/rfc1813.txt 819 [RFC1831] 820 Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification 821 Version 2", RFC1831, Sun Microsystems, Inc., August 1995. 823 http://www.ietf.org/rfc/rfc1831.txt 825 [RFC1832] 826 Srinivasan, R., "XDR: External Data Representation Standard", 827 RFC1832, Sun Microsystems, Inc., August 1995. 829 http://www.ietf.org/rfc/rfc1832.txt 831 [RFC1833] 832 Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC1833, 833 Sun Microsystems, Inc., August 1995. 835 http://www.ietf.org/rfc/rfc1833.txt 837 [RFC2025] 838 Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC2025, 839 Bell-Northern Research, October 1996. 841 http://www.ietf.org/rfc/rfc2025.txt 843 [RFC2054] 844 Callaghan, B., "WebNFS Client Specification", RFC2054, Sun 845 Microsystems, Inc., October 1996 847 http://www.ietf.org/rfc/rfc2054.txt 849 [RFC2055] 850 Callaghan, B., "WebNFS Server Specification", RFC2054, Sun 851 Microsystems, Inc., October 1996 853 http://www.ietf.org/rfc/rfc2055.txt 855 [RFC2078] 856 Linn, J., "Generic Security Service Application Program Interface, 857 Version 2", RFC2078, OpenVision Technologies, January 1997. 859 http://www.ietf.org/rfc/rfc2078.txt 861 [RFC2152] 862 Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode", 863 RFC2152, Apple Computer, Inc., May 1997 865 http://www.ietf.org/rfc/rfc2152.txt 867 [RFC2203] 868 Eisler, M., Chiu, A., Ling, L., "RPCSEC_GSS Protocol Specification", 869 RFC2203, Sun Microsystems, Inc., August 1995. 871 http://www.ietf.org/rfc/rfc2203.txt 873 [RFC2222] 874 Myers, J., "Simple Authentication and Security Layer (SASL)", 875 RFC2222, Netscape Communications, October 1997. 877 http://www.ietf.org/rfc/rfc2222.txt 879 [RFC2279] 880 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC2279, 881 Alis Technologies, January 1998. 883 http://www.ietf.org/rfc/rfc2279.txt 885 [RFC2246] 886 Dierks, T., Allen, C. "The TLS Protocols Version 1.0", RFC 2246, 887 Certicom, January 1999. 889 http://www.ietf.org/rfc/rfc2246.txt 891 [RFC2401] 892 Kent, S., Atkinson, R., "Security Architecture for the Internet 893 Protocol", RFC2401, BBN Corp., @Home Network, November 1998. 895 http://www.ietf.org/rfc/rfc2401.txt 897 [DCEACL] 898 The Open Group, Open Group Technical Standard, "DCE 1.1: 899 Authentication and Security Services," Document Number C311, August 900 1997. Provides a discussion of DEC ACL structure and semantics. 902 [HPFS] 903 Les Bell and Associates Pty Ltd, "The HPFS FAQ," 904 http://www.lesbell.com.au/hpfsfaq.html 906 [Hutson] 907 Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June 908 1993. Proc. USENIX Symp. on Mobile and Location-Independent 909 Computing, Cambridge, August 1993. 911 [Kistler] 912 Kistler, James J., Satyanarayanan, M., "Disconnected Operations in 913 the Coda File System," ACM Trans. on Computer Systems, vol. 10, no. 914 1, pp. 3-25, Feb. 1992. 916 [Mummert] 917 Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak 918 Connectivity for Mobile File Access," Proc. of the 15th ACM Symp. on 919 Operating Systems Principles Dec. 1995. 921 [Nagar] 922 Nagar, R., "Windows NT File System Internals," ISBN 1565922492, 923 O`Reilly & Associates, Inc. 925 [Sandberg] 926 Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design 927 and Implementation of the Sun Network Filesystem," USENIX Conference 928 Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The 929 basic paper describing the SunOS implementation of the NFS version 2 930 protocol, and discusses the goals, protocol specification and trade- 931 offs. 933 [Satyanarayanan1] 934 Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," 935 Proc. of the ACM Principles of Distributed Computing, 1995. 937 [Satyanarayanan2] 938 Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R., 939 Kumar, P. , Lu, Q., "Experience with disconnected operation in 940 mobile computing environment," Proc. of the USENIX Symp. on Mobile 941 and Location-Independent Computing, Jun. 1993. 943 [Unicode1] 944 "Unicode Technical Report #8 - The Unicode Standard, Version 2.1", 945 Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose, CA 946 95710-0519 USA, September 1998 948 http://www.unicode.org/unicode/reports/tr8.html 950 [Unicode2] 951 "Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O. Box 952 700519, San Jose, CA 95710-0519 USA, October 1998 954 http://www.unicode.org/unicode/standard/unsupported.html 956 [XDSM] 957 The Open Group, Open Group Technical Standard, "Systems Management: 958 Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January 959 1997. 961 [XNFS] 962 The Open Group, Protocols for Interworking: XNFS, Version 3W, The 963 Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025, ISBN 964 1-85912-184-5, February 1998. 966 HTML version available: http://www.opengroup.org 968 12. Acknowledgments 970 o Brent Callaghan for content contributions. 972 13. Author's Address 974 Address comments related to this memorandum to: 976 spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com 978 Spencer Shepler 979 Sun Microsystems, Inc. 980 7808 Moonflower Drive 981 Austin, Texas 78750 983 Phone: (512) 349-9376 984 E-mail: spencer.shepler@eng.sun.com 986 14. Full Copyright Statement 988 "Copyright (C) The Internet Society (1999). All Rights Reserved. 990 This document and translations of it may be copied and furnished to 991 others, and derivative works that comment on or otherwise explain it 992 or assist in its implmentation may be prepared, copied, published and 993 distributed, in whole or in part, without restriction of any kind, 994 provided that the above copyright notice and this paragraph are 995 included on all such copies and derivative works. However, this 996 document itself may not be modified in any way, such as by removing 997 the copyright notice or references to the Internet Society or other 998 Internet organizations, except as needed for the purpose of 999 developing Internet standards in which case the procedures for 1000 copyrights defined in the Internet Standards process must be 1001 followed, or as required to translate it into languages other than 1002 English. 1004 The limited permissions granted above are perpetual and will not be 1005 revoked by the Internet Society or its successors or assigns. 1007 This document and the information contained herein is provided on an 1008 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1009 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1010 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1011 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1012 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."