GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2624

Network Working Group S. Shepler Request for Comments: 2624 Sun Microsystems, Inc. Category: Informational June 1999

                NFS Version 4 Design Considerations

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

 The main task of the NFS version 4 working group is to create a
 protocol definition for a distributed file system that focuses on the
 following items: improved access and good performance on the
 Internet, strong security with negotiation built into the protocol,
 better cross-platform interoperability, and designed for protocol
 extensions.  NFS version 4 will owe its general design to the
 previous versions of NFS.  It is expected, however, that many
 features will be quite different in NFS version 4 than previous
 versions to facilitate the goals of the working group and to address
 areas that NFS version 2 and 3 have not.
 This design considerations document is meant to present more detail
 than the working group charter.  Specifically, it presents the areas
 that the working group will investigate and consider while developing
 a protocol specification for NFS version 4.  Based on this
 investigation the working group will decide the features of the new
 protocol based on the cost and benefits within the specific feature
 areas.

Key Words

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119.

Shepler Informational [Page 1] RFC 2624 NFSv4 Design Considerations June 1999

Table of Contents

 1.  NFS Version 4 Design Considerations . . . . . . . . . . . . . 2
 2.  Ease of Implementation or Complexity of Protocol  . . . . . . 3
 2.1.  Extensibility / layering  . . . . . . . . . . . . . . . . . 3
 2.2.  Managed Extensions or Minor Versioning  . . . . . . . . . . 3
 2.3.  Relationship with Older Versions of NFS . . . . . . . . . . 4
 3.  Reliable and Available  . . . . . . . . . . . . . . . . . . . 5
 4.  Scalable Performance  . . . . . . . . . . . . . . . . . . . . 5
 4.1.  Throughput and Latency via the Network  . . . . . . . . . . 6
 4.2.  Client Caching  . . . . . . . . . . . . . . . . . . . . . . 6
 4.3.  Disconnected Client Operation . . . . . . . . . . . . . . . 7
 5.  Interoperability  . . . . . . . . . . . . . . . . . . . . . . 7
 5.1.  Platform Specific Behavior  . . . . . . . . . . . . . . . . 8
 5.2.  Additional or Extended Attributes . . . . . . . . . . . . . 8
 5.3.  Access Control Lists  . . . . . . . . . . . . . . . . . .   9
 6.  RPC Mechanism and Security  . . . . . . . . . . . . . . . .  10
 6.1.  User identification . . . . . . . . . . . . . . . . . . .  10
 6.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  10
 6.2.1.  Transport Independence  . . . . . . . . . . . . . . . .  11
 6.2.2.  Authentication  . . . . . . . . . . . . . . . . . . . .  11
 6.2.3.  Data Integrity  . . . . . . . . . . . . . . . . . . . .  11
 6.2.4.  Data Privacy  . . . . . . . . . . . . . . . . . . . . .  12
 6.2.5.  Security Negotiation  . . . . . . . . . . . . . . . . .  12
 6.3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  12
 7.  Internet Accessibility  . . . . . . . . . . . . . . . . . .  13
 7.1.  Congestion Control and Transport Selection  . . . . . . .  13
 7.2.  Firewalls and Proxy Servers . . . . . . . . . . . . . . .  14
 7.3.  Multiple RPCs and Latency . . . . . . . . . . . . . . . .  14
 8.  File locking / recovery . . . . . . . . . . . . . . . . . .  15
 9.  Internationalization  . . . . . . . . . . . . . . . . . . .  16
 10.  Security Considerations  . . . . . . . . . . . . . . . . .  17
 10.1.  Denial of Service  . . . . . . . . . . . . . . . . . . .  17
 11.  Bibliography . . . . . . . . . . . . . . . . . . . . . . .  18
 12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  21
 13.  Author's Address . . . . . . . . . . . . . . . . . . . . .  21
 14.  Full Copyright Statement . . . . . . . . . . . . . . . . .  22

1. NFS Version 4 Design Considerations

 As stated in the charter, the first deliverable for the NFS version 4
 working group is this design considerations document.  This document
 is to cover the "limitations and deficiencies of NFS version 3".
 This document will also be used as a mechanism to focus discussion
 and avenues of investigation as the definition of NFS version 4
 progresses.  Therefore, the contents of this document cover the
 general functional/feature areas that are anticipated for NFS version
 4.  Where appropriate, discussion of current NFS version 2 and 3

Shepler Informational [Page 2] RFC 2624 NFSv4 Design Considerations June 1999

 practice will be presented along with other appropriate references to
 current distributed file system practice.

2. Ease of Implementation or Complexity of Protocol

 One of the strengths of NFS has been the ability to implement a
 client or server with relative ease.  The eventual size of a basic
 implementation is relatively small.  The main reason for keeping NFS
 as simple as possible is that a simple protocol design can be
 described in a simple specification that promotes straightforward,
 interoperable implementations.  All protocols can run into problems
 when deployed on real networks, but simple protocols yield problems
 that are easier to diagnose and correct.

2.1. Extensibility / layering

 With NFS' relative simplicity, the addition or layering of
 functionality has been easy to accomplish.  The addition of features
 like the client automount or autofs, client side disk caching and
 high availability servers are examples.  This type of extensibility
 is desirable in an environment where problem solutions do not require
 protocol revision.  This extensibility can also be helpful in the
 future where unforeseen problems or opportunities can be solved by
 layering functionality on an existing set of tools or protocol.

2.2. Managed Extensions or Minor Versioning

 For those cases where the NFS protocol is deficient or where a minor
 modification is the best solution for a problem, a minor version or a
 managed extension could be helpful.  There have been instances with
 NFS version 2 and 3 where small straightforward functional additions
 would have increased the overall value of the protocol immensely.
 For instance, the PATHCONF procedure that was added to version 2 of
 the MOUNT protocol would have been more appropriate for the NFS
 protocol. WebNFS [RFC2054][RFC2055] overloading of the LOOKUP
 procedure for NFS versions 2 and 3 would have been more cleanly
 implemented in a new LOOKUP procedure.
 However, the perceived size and burden of using a change of RPC
 version number for the introduction of new functionality led to no or
 slow change.  It is possible that a new NFS protocol could allow for
 the rare instance where protocol extension within the RPC version
 number is the most prudent course and an RPC revision would be
 unnecessary or impractical.
 The areas of an NFS protocol which are most obviously volatile are
 new orthogonal procedures, new well-defined file or directory
 attributes and potentially new file types.  As an example, potential

Shepler Informational [Page 3] RFC 2624 NFSv4 Design Considerations June 1999

 file types of the future could be a type such as "attribute" that
 represents a named file stream or a "dynamic" file type that
 generates dynamic data in response to a "query" procedure from the
 client.
 It is possible and highly desirable that these types of additions be
 done without changing the overall design model of NFS without
 significant effort or delay.
 A strong consideration should be given to a NFS protocol mechanism
 for the introduction of this type of new functionality.  This is
 obviously in contrast to using the standard RPC version mechanism to
 provide minor changes.  The process of using RPC version numbers to
 introduce new functionality brings with it a lot of history which may
 not technically prevent its use.  However, the historical issues
 involved will need to be addressed as part of the NFS version 4
 protocol work; this should increase the ability for current and
 future success of the protocol.
 As background, the RPC protocol described in [RFC1831] uses a version
 number to describe the set of procedure calls, replies, and their
 semantics.  Any change in this set must be reflected in a new version
 number for the program.  An example of this was the
 MOUNTPROC_PATHCONF procedure added in version 2 of the MOUNT
 protocol.  Except for the addition of this new procedure, the
 protocol was unchanged.  Many thought this protocol revision was
 unnecessary, since the RPC protocol already allows certain procedures
 not be implemented and defines a PROC_UNAVAIL error.
 Another historical data-point from NFS version 2 and 3 is the support
 (or lack) of symbolic links.  Servers that cannot support this
 feature will simply reject calls to the SYMLINK and READLINK
 procedures.  Additionally, NFS version 4 may describe many file
 attributes which cannot be supported by the server or file systems on
 the server.  Therefore, the protocol must support a discovery
 mechanism that allows clients to determine which features of the
 protocol are supported by a server.

2.3. Relationship with Older Versions of NFS

 NFS version 4 will be a self contained protocol in that it will not
 have any dependencies on the previous versions of NFS.  Stated
 another way, an NFS version 4 server or client will not require a
 NFSv2 or NFSv3 implementation be present for NFS version 4 to
 function as designed.  It should also be noted that having an NFS
 version 2 or 3 implementation present at the client or server will
 not enhance the functionality of an NFS version 4 implementation.

Shepler Informational [Page 4] RFC 2624 NFSv4 Design Considerations June 1999

 In the case where an NFS client has a choice of using various NFS
 protocol versions (i.e. 2, 3 and 4), the underlying ONCRPC mechanisms
 will allow the client to appropriately choose an available version of
 the protocol at the NFS server.  The ONCRPC protocol contains the
 semantics and error returns for the case where an RPC server program
 does not support a particular version.  This mechanism is used by the
 NFS client to receive notification of an unavailable version and in
 conjunction with the error the client will also receive the range of
 versions (min to max) that are available.  Therefore, the ONCRPC
 mechanism can be used by implementors of both clients and servers to
 provide for the transitioning to or installation of NFS version 4
 services.

3. Reliable and Available

 Current NFS protocol design, while placing an emphasis on simple
 server design, has led to timely recovery from server and client
 failure.  This and other aspects to the design have provided a basis
 for layered technologies like high availability and clustered
 servers.  Providing a protocol design approach that lends itself to
 these types of reliability and availability features is very
 desirable.
 For the next version of NFS, consideration should be given to client
 side availability schemes such as client switching between or fail-
 over to available server replicas.  NFS currently requires that file
 handles be immutable; this requirement adds unnecessarily to the
 complexity of building fail-over configurations.  If possible, the
 protocol should allow for or ease the building of such layered
 solutions.
 For the next version of NFS, consideration should be given to schemes
 that support client switching between server replicas or highly
 available NFS servers that provide paths to data through multiple
 servers. For example: NFS currently requires that filehandles be
 unchanging for any instance of a file or directory. This requirement
 makes it more difficult for a client to switch from one server to
 another, since each server may construct filehandles differently.
 Protocol support could allow the client to handle a filehandle
 change.

4. Scalable Performance

 In designing and developing an NFS protocol from a performance
 viewpoint there are several different points to consider.  Each can
 play a significant role in perceived and real performance from the
 user's perspective.  The three main areas of interest are: throughput
 and latency via the network, server work load or scalability and

Shepler Informational [Page 5] RFC 2624 NFSv4 Design Considerations June 1999

 client side caching.

4.1. Throughput and Latency via the Network

 NFS currently has characteristics that provide good throughput for
 reading and writing file data. This is commonly achieved by the
 client's use of pipelining or windowing multiple RPC READ/WRITE
 requests to the server. The flexibility of the NFS and ONCRPC
 protocols allow for implementations to use this type of adaptation to
 provide efficient use of the network connection.
 However, the number of RPCs required to accomplish some tasks
 combined with high latency network environments may lead to sluggish
 single user or single client response.  The protocol should continue
 to provide good raw read and write throughput while addressing the
 issue of network latency.  This issue is discussed further in the
 section on Internet Accessibility.

4.2. Client Caching

 In an attempt to speed response time and to reduce network and server
 load, NFS clients have always cached directory and file data.
 However, this has usually been done as memory cache and in relatively
 recent history, local disk caching has been added.
 It is very desirable to have the NFS client cache directory and file
 data.  Other distributed file systems have shown that aggressive
 client side caching can be very visible to the end user in the form
 of decreasing overall response time.  For AFS and DCE/DFS, caching is
 accomplished by the utilization of server call backs to notify the
 client of potential cache invalidation.  CIFS and its opportunistic
 locks provide a similar call back mechanism.  Clients in both of
 these environments are able to cache data while avoiding interaction
 with the network and server.
 With these protocols it is also possible to cache or delay certain
 protocol requests at the client which further reduces the protocol
 traffic flowing between client and server.  In the case of CIFS, it
 is possible for a client to obtain an opportunistic lock for a file
 and subsequently process file lock requests completely at the client.
 If there are no conflicts with other clients for file data access,
 the server is never contacted for the file locking traffic generated
 by the user application. This behavior is not a protocol requirement
 but is allowed by the protocol as an implementation option to improve
 performance.

Shepler Informational [Page 6] RFC 2624 NFSv4 Design Considerations June 1999

 NFS versions 2 and 3 make no caching requirements.  Implementations
 typically implement close-to-open cache consistency which requires
 clients flush all changes to the server on each file close, and check
 for file changes on the server on each file open.  The consistency
 check required on each file open can generate a large amount of
 GETATTR traffic.  With this approach, there are windows when the
 client can still be acting with stale data between the open and close
 of a file.
 Client caching is increasingly important for Internet environments
 where throughput can be limited and response time can grow
 significantly. Therefore the NFS version 4 caching design will need
 to take into account the full spectrum of caching designs as
 exemplified by the current technologies of NFS, AFS, DCE/DFS, CIFS,
 etc. in determining an appropriate design.  This will need to be done
 while weighing the complexity of each possible approach with the need
 of the eventual users and operating environments into which NFS
 version 4 may be deployed.  Some of these considerations are:
 Internet accessibility, firewall traversal (call back availability),
 proxy caching, low-overhead or simple clients.

4.3. Disconnected Client Operation

 An extension of client caching is the provision for disconnected
 operation at the client.  With the ability to cache directory and
 file data aggressively, a client could then provide service to the
 end user while disconnected from the server or network.
 While very desirable, disconnected operation has the potential to
 inflict itself upon the NFS protocol in an undesirable way as
 compared to traditional client caching.  Given the complexities of
 disconnected client operation and subsequent resolution of client
 data modification through various playback or data selection
 mechanisms, disconnected operation should not be a requirement for
 the NFS effort.  Even so, the NFS protocol should consider the
 potential layering of disconnected operation solutions on top of the
 NFS protocol (as with other server and client solutions).  The
 experiences with Coda, disconnected AFS and others should be helpful
 in this area. (see references)

5. Interoperability

 The NFS protocols are available for many different operating
 environments.  Even though this shows the protocol's ability to
 provide distributed file system service for more than a single
 operating system, the design of NFS is certainly Unix-centric.  The
 next NFS protocol needs to be more inclusive of platform or file
 system features beyond those of traditional Unix.

Shepler Informational [Page 7] RFC 2624 NFSv4 Design Considerations June 1999

5.1. Platform Specific Behavior

 Because of Unix-centric origins, NFS version 2 and 3 protocol
 requirements have been difficult to implement in some environments.
 For example, persistent file handles (unique identifiers of file
 system objects), Unix uid/gid mappings, directory modification time,
 accurate file sizes, file/directory locking semantics (SHAREs, PC-
 style locking). In the design of NFS version 4, these areas and
 others not mentioned will need to be considered and, if possible,
 cross-platform solutions developed.

5.2. Additional or Extended Attributes

 NFS versions 2 and 3 do not provide for file or directory attributes
 beyond those that are found in the traditional Unix environment. For
 example the user identifier/owner of the file, a permission or access
 bitmap, time stamps for modification of the file or directory and
 file size to name a few.  While the current set of attributes has
 usually been sufficient, the file system's ability to manage
 additional information associated with a file or directory can be
 useful.
 There are many possibilities for additional attributes in the next
 version of NFS.  Some of these include: object creation timestamp,
 user identifier of file's creator, timestamp of last backup or
 archival bit, version number, file content type (MIME type),
 existence of data management involvement (i.e. DMAPI [XDSM]).
 This list is representative of the possibilities and is meant to show
 the need for an additional attribute set.  Enumerating the 'correct'
 set of attributes, however, is difficult.  This is one of the reasons
 for looking towards a minor versioning mechanism as a way to provide
 needed extensibility.  Another way to provide some extensibility is
 to support a generalized named attribute mechanism.  This mechanism
 would allow a client to name, store and retrieve arbitrary data and
 have it associated as an attribute of a file or directory.
 One difficulty in providing named attributes is determining if the
 protocol should specify the names for the attributes, their type or
 structure.  How will the protocol determine or allow for attributes
 that can be read but not written is another issue.  Yet another could
 be the side effects that these attributes have on the core set of
 file properties such as setting a size attribute to 0 and having
 associated file data deleted.
 As these brief examples show, this type of extended attribute
 mechanism brings with it a large set of issues that will need to be
 addressed in the protocol specification while keeping the overall

Shepler Informational [Page 8] RFC 2624 NFSv4 Design Considerations June 1999

 goal of simplicity in mind.
 There are operating environments that provide named or extended
 attribute mechanisms.  Digital Unix provides for the storage of
 extended attributes with some generalized format.  HPFS [HPFS] and
 NTFS [Nagar] also provide for named data associated with traditional
 files.  SGI's local file system, XFS, also provides for this type of
 name/value extended attributes. However, there does not seem to be a
 clear direction that can be taken from these or other environments.

5.3. Access Control Lists

 Access Control Lists (ACL) can be viewed as one specific type of
 extended attribute.  This attribute is a designation of user access
 to a file or directory.  Many vendors have created ancillary
 protocols to NFS to extend the server's ACL mechanism across the
 network.  Generally this has been done for homogeneous operating
 environments. Even though the server still interprets the ACL and has
 final control over access to a file system object, the client is able
 to manipulate the ACL via these additional protocols.  Other
 distributed file systems have also provided ACL support (DFS, AFS and
 CIFS).
 The basic factor driving the requirement for ACL support in all of
 these file systems has been the user's desire to grant and restrict
 access to file system data on a per user basis.  Based on the desire
 of the user and current distributed file system support, it seems to
 be a requirement that NFS provide this capability as well.
 Because many local and distributed file system ACL implementations
 have been done without a common architecture, the major issue is one
 of compatibility.  Although the POSIX draft, DCE/DFS [DCEACL] and
 Windows NT ACLs have a similar structure in an array of Access
 Control Entries consisting of a type field, identity, and permission
 bits, the similarity ends there.  Each model defines its own variants
 of entry types, identifies users and groups differently, provides
 different kinds of permission bits, and describes different
 procedures for ACL creation, defaults, and evaluation.
 In the least it will be problematic to create a workable ACL
 mechanism that will encompass a reasonable set of functionality for
 all operating environments.  Even with the complicated nature of ACL
 support it is still worthwhile to work towards a solution that can at
 least provide basic functionality for the user.

Shepler Informational [Page 9] RFC 2624 NFSv4 Design Considerations June 1999

6. RPC Mechanism and Security

 NFS relies on the security mechanisms provided by the ONCRPC
 [RFC1831] protocol.  Until the introduction of the ONCRPC RPCSEC_GSS
 security flavor [RFC2203], NFS security was generally limited to none
 (AUTH_SYS) or DES (AUTH_DH).  The AUTH_DH security flavor was not
 successful in providing readily available security for NFS because of
 a lack of widespread implementation which precluded widespread
 deployment.  Also the Diffie-Hellman 192 bit public key modulus used
 for the AUTH_DH security flavor quickly became too small for
 reasonable security.

6.1. User identification

 NFS has been limited to the use of the Unix-centric user
 identification mechanism of numeric user id based on the available
 file system attributes and the use of the ONCRPC.  However, for NFS
 to move beyond the limits of large work groups, user identification
 should be string based and the definition of the user identifier
 should allow for integration into an external naming service or
 services.
 Internet scaling should also be considered for this as well.  The
 identification mechanism should take into account multiple naming
 domains and multiple naming mechanisms.  Flexibility is the key to a
 solution that can grow with the needs of the user and administrator.
 If NFS is to move among various naming and security services, it may
 be necessary to stay with a string based identification.  This would
 allow for servers and clients to translate between the external
 string representation to a local or internal numeric (or other
 identifier) which matches internal implementation needs.
 As an example, DFS uses a string based naming scheme but translates
 the name to a UUID (16 byte identifier) that is used for internal
 protocol representations. The DCE/DFS string name is a combination of
 cell (administrative domain) and user name.  As mentioned, NFS
 clients and servers map a Unix user name to a 32 bit user identifier
 that is then used for ONCRPC and NFS protocol fields requiring the
 user identifier.

6.2. Security

 Because of the aforementioned problems, user authentication has been
 a major issue for ONCRPC and hence NFS.  To satisfy requirements of
 the IETF and to address concerns and requirements from users, NFS
 version 4 must provide for the use of acceptable security mechanisms.
 The various mechanisms currently available should be explored for

Shepler Informational [Page 10] RFC 2624 NFSv4 Design Considerations June 1999

 their appropriate use with NFS version 4 and ONCRPC.  Some of these
 mechanisms are: TLS [RFC2246], SPKM [RFC2025], KerberbosV5 [RFC1510],
 IPSEC [RFC2401].  Since ONCRPC is the basis for NFS client and server
 interaction, the RPCSEC_GSS [RFC2203] framework should be strongly
 considered since it provides a method to employ mechanisms like SPKM
 and KerberosV5.  Before a security mechanism can be evaluated, the
 NFS environment and requirements must be discussed.

6.2.1. Transport Independence

 As mentioned later in this document in the section "Internet
 Accessibility", transport independence is an asset for NFS and ONCRPC
 and is a general requirement.  This allows for transport choice based
 on the target environment and specific application of NFS.  The most
 common transports in use with NFS are UDP and TCP.  This ability to
 choose transport should be maintained in combination with the user's
 choice of a security mechanism.  This implies that "mandatory to
 implement" security mechanisms for NFS should allow for both
 connection-less and connection-oriented transports.

6.2.2. Authentication

 As should be expected, strong authentication is a requirement for NFS
 version 4.  Each operation generated via ONCRPC contains user
 identification and authentication information.  It is common in NFS
 version 2 and 3 implementations to multiplex various users' requests
 over a single or few connections to the NFS server.  This allows for
 scalability in the number of clients systems.  Security mechanisms or
 frameworks should allow for this multiplexing of requests to sustain
 the implementation model that is available today.

6.2.3. Data Integrity

 Until the introduction of RPCSEC_GSS, the ability to provide data
 integrity over ONCRPC and to NFS was not available.  Since file and
 directory data is the essence of a distributed file service, the NFS
 protocol should provide to the users of the file service a reasonable
 level of data integrity.  The security mechanisms chosen must provide
 for NFS data protection with a cryptographically strong checksum.  As
 with other aspects within NFS version 4, the user or administrator
 should be able to choose whether data integrity is employed.  This
 will provide needed flexibility for a variety of NFS version 4
 solutions.

Shepler Informational [Page 11] RFC 2624 NFSv4 Design Considerations June 1999

6.2.4. Data Privacy

 Data privacy, while desirable, is not as important in all
 environments as authentication and integrity.  For example, in a LAN
 environment the performance overhead of data privacy may not be
 required to meet an organization's data protection policies.  It may
 also be the case that the performance of the distributed file system
 solution is more important than the data privacy of that solution.
 Even with these considerations, the user or administrator must have
 the choice of data privacy and therefore it must be included in NFS
 version 4.

6.2.5. Security Negotiation

 With the ability to provide security mechanism choices to the user or
 administrator, NFS version 4 should offer reasonable flexibility for
 application of local security policies.  However, this presents the
 problem of negotiating the appropriate security mechanism between
 client and server.  It is unreasonable to require the client know the
 server's chosen mechanism before initial contact.  The issue is
 further complicated by an administrator who may choose more than one
 security mechanism for the various file system resources being shared
 by an NFS server.  These types of choices and policies require that
 NFS version 4 deal with negotiating the appropriate security
 mechanism based on mechanism availability and policy deployment at
 client and server.  This negotiation will need to take into account
 the possibility of a change in policy as an NFS client crosses
 certain file system boundaries at the server.  The security
 mechanisms required may change at these boundaries and therefore the
 negotiation must be included within the NFS protocol itself to be
 done properly (i.e. securely).

6.3. Summary

 Other distributed file system solutions such as AFS and DFS provide
 strong authentication mechanisms.  CIFS does provide authentication
 at initial server contact and a message signing option for subsequent
 interaction.  Recent NFS version 2 and 3 implementations, with the
 use of RPCSEC_GSS, provide strong authentication, integrity, and
 privacy.
 NFS version 4 must provide for strong authentication, integrity, and
 privacy.  This must be part of the protocol so that users have the
 choice to use strong security if their environment or policies
 warrant such use.

Shepler Informational [Page 12] RFC 2624 NFSv4 Design Considerations June 1999

 Based on the requirements presented, the ONCRPC RPCSEC_GSS security
 flavor seems to provide an appropriate framework for satisfying these
 requirements.  RPCSEC_GSS provides for authentication, integrity, and
 privacy.  The RPCSEC_GSS is also extensible in that it provides for
 both public and private key security mechanisms along with the
 ability to plug in various mechanisms in such a way that it does not
 significantly disrupt ONCRPC or NFS implementations.
 With RPCSEC_GSS' ability to support both public and private key
 mechanisms, NFS version 4 should consider "mandatory to implement"
 choices from both.  The intent is to provide a security solution that
 will flexibly scale to match the needs of end users.  Providing this
 range of solutions will allow for appropriate usage based on policy
 and available resources for deployment.  Note that, in the end, the
 user must have a choice and that choice may be to use all of the
 available mechanisms in NFS version 4 or none of them.

7. Internet Accessibility

 Being a product of an IETF working group, the NFS protocol should not
 only be built upon IETF technologies where possible but should also
 work well within the broader Internet environment.

7.1. Congestion Control and Transport Selection

 As with any network protocol, congestion control is a major issue and
 the transport mechanisms that are chosen for NFS should take this
 into account.  Traditionally, implementations of NFS have been
 deployed using both UDP and TCP.  With the use of UDP, most
 implementations provide a rudimentary attempt control congestion with
 simple back-off algorithms and round trip timers.  While this may be
 sufficient in today's NFS deployments, as an Internet protocol NFS
 will need to ensure sufficient congestion control or management.
 With congestion control in mind, NFS must use TCP as a transport (via
 ONCRPC).  The UDP transport provides its own advantages in certain
 circumstances.  In today's NFS implementations, UDP has been shown to
 produce greater throughput as compared to similarly configured
 systems that use TCP.  This issue will need to be investigated such
 that a determination can be made as to whether the differences are
 within implementation details.  If UDP is supplied as an NFS
 transport mechanism, then the congestion controls issues will need
 resolution to make its use suitable.

Shepler Informational [Page 13] RFC 2624 NFSv4 Design Considerations June 1999

7.2. Firewalls and Proxy Servers

 NFS's protocol design should allow its use via Internet firewalls.
 The protocol should also allow for the use of file system proxy/cache
 servers.  Proxy servers can be very useful for scalability and other
 reasons.  The NFS protocol needs to address the need of proxy servers
 in a way that will deal with the issues of security, access control,
 content control, and cache content validation.  It is possible that
 these issues can be addressed by documenting the related issues of
 proxy server usage.  However, it is likely that the NFS protocol will
 need to support proxy servers directly through the NFS protocol.
 The protocol could allow a request to be sent to a proxy that
 contains the name of the target NFS server to which the request might
 be forwarded, or from which a response might be cached.  In any case,
 the NFS proxy server should be considered during protocol
 development.
 The problems encountered in making the NFS protocol work through
 firewalls are described in detail in [RFC2054] and [RFC2055].

7.3. Multiple RPCs and Latency

 As an application at the NFS client performs simple file system
 operations, multiple NFS operations or RPCs may be executed to
 accomplish the work for the application.  While the NFS version 3
 protocol addressed some of this by returning file and directory
 attributes for most procedures, hence reducing follow up GETATTR
 requests, there is still room for improvement.  Reducing the number
 of RPCs will lead to a reduction of processing overhead on the server
 (transport and security processing) along with reducing the time
 spent at the client waiting for the server's individual responses.
 This issue is more prominent in environments with larger degrees of
 latency.
 The CIFS file access protocol supports 'batched requests' that allow
 multiple requests to be batched, therefore reducing the number of
 round trip messages between client and server.
 This same approach can be used by NFS to allow the grouping of
 multiple procedure calls together in a traditional RPC request.  Not
 only would this reduce protocol imposed latency but it would reduce
 transport and security processing overhead and could allow a client
 to complete more complex tasks by combining procedures.

Shepler Informational [Page 14] RFC 2624 NFSv4 Design Considerations June 1999

8. File locking / recovery

 NFS provided Unix file locking and DOS SHARE capability with the use
 of an ancillary protocol (Network Lock Manager / NLM).  The DOS SHARE
 mechanism is the DOS equivalent of file locking in that it provides
 the basis for sharing or exclusive access to file and directory data
 without risk of data corruption. The NLM protocol provides file
 locking and recovery of those locks in the event of client or server
 failure.  The NLM protocol requires that the server make call backs
 to the client for certain scenarios and therefore is not necessarily
 well suited for Internet firewall traversal.
 Available and correct file locking support for NFS version 2 and 3
 clients and servers has historically been problematic.  The
 availability of NLM support has traditionally been a problem and
 seems to be most related to the fact that NFS and NLM are two
 separate protocols.  It is easy to deliver an NFS client and server
 implementation and then add NLM support later.  This led to a general
 lack of NLM support early on in NFS' lifetime.  One of the reasons
 that NLM was delivered separately has been its relative complexity
 which has in turn led to poor implementations and testing
 difficulties.  Even in later implementations where reliability and
 performance had been increased to acceptable levels for NLM, users
 still chose to avoid the use of the protocol and its support.  The
 last issue with NLM is the presence of minor protocol design flaws
 that relate to high network load and recovery.
 Based on the experiences with NLM, locking support for NFS version 4
 should strive to meet or at least consider the following (in order of
 importance):
 o    Integration with the NFS protocol and ease of implementation.
 o    Interoperability between operating environments. The protocol
      should make a reasonable effort to support the locking semantics
      of both PC and Unix clients and servers. This will allow for
      greater integration of all environments.
 o    Scalable solutions - thousands of clients.  The server should
      not be required to maintain significant client file locking
      state between server instantiations.
 o    Internet capable (firewall traversal, latency sensitive).  The
      server should not be required to initiate TCP connections to
      clients.

Shepler Informational [Page 15] RFC 2624 NFSv4 Design Considerations June 1999

 o    Timely recovery in the event of client/server or network
      failure.  Server recovery should be rapid. The protocol should
      allow clients to detect the loss of a lock.

9. Internationalization

 NFS version 2 and 3 are currently limited in the character encoding
 of strings. In the NFS protocols, strings are used for file and
 directory names, and symbolic link contents. Although the XDR
 definition [RFC1832] limits strings in the NFS protocol to 7-bit US-
 ASCII, common usage is to encode filenames in 8-bit ISO-Latin-1.
 However, there is no mechanism available to tag XDR character strings
 to indicate the character encoding used by the client or server.
 Obviously this limits NFS' usefulness in an environment with clients
 that may operate with various character sets.
 One approach to address this deficiency is to use the Unicode
 Standard [Unicode1] as the means to exchange character strings for
 the NFS version 4 protocol. The Unicode Standard is a 16 bit encoding
 that supports full multilingual text. The Unicode Standard is code-
 for-code identical with International Standard ISO/IEC 10646-1:1993.
 "Information Technology -- Universal Multiple-Octet Coded Character
 Set (UCS)-Part 1: Architecture and Basic Multilingual Plane." Because
 Unicode is a 16 bit encoding, it may be more efficient for the NFS
 version 4 protocol to use an encoding for wire transfer that will be
 useful for a majority of usage.  One possible encoding is the UCS
 transformation format (UTF).  UTF-8 is an encoding method for UCS-4
 characters which allows for the direct encoding of US-ASCII
 characters but expands for the correct encoding of the full UCS-4 31
 bit definitions.  Currently, the UCS-4 and Unicode standards do not
 diverge.
 This Unicode/UTF-8 encoding can be used for places in the protocol
 that a traditional string representation is needed.  This includes
 file and directory names along with symlink contents.  This should
 also include other file and directory attributes that are eventually
 defined as strings.
 The Unicode standard is applicable to the well defined strings within
 the protocol. Dealing with file content is much more difficult. NFS
 has traditionally dealt with file data as an opaque byte stream. No
 other structure or content specification has been levied upon the
 file content. The main advantage to this approach is its flexibility.
 This byte stream can contain any data content and may be accessed in
 any sequential or random fashion. Unfortunately, it is left to the
 application or user to make the determination of file content and
 format. It is possible to construct a mechanism in the protocol that
 specifies file data type while maintaining the byte stream model for

Shepler Informational [Page 16] RFC 2624 NFSv4 Design Considerations June 1999

 data access.  However, this approach may be limiting in ways unclear
 to the designers of the NFS version 4 protocol. An expandable and
 adaptable approach is to use the previously discussed extended
 attributes as the mechanism to specify file content and format. The
 use of extended attributes allows for future definition and growth as
 various data types are created and allows for maintaining a simple
 file data model for the NFS protocol.
 It should be noted that as the Unicode standards are currently
 defined there is the possibility for minor inconsistencies when
 converting from local character representations to Unicode and then
 back again.  This should not be a problem with single client and
 server interaction but may become apparent with the interaction of
 two or more clients with separate conversion implementations.
 Therefore, as NFS version 4 progresses in its development, these
 types of Unicode issues need to be tracked and understood for their
 potential impact on client/server interaction. In any case, Unicode
 seems to be the best selection for NFS version 4 based on its
 standards background and apparent future direction.

10. Security Considerations

 Two previous sections within this document deal with security issues.
 The section covering 'Access Control Lists' covers the mechanisms
 that need to be investigated for file system level control. The
 section that covers RPC security deals with individual user
 authentication along with data integrity and privacy issues. This
 section also covers negotiation of security mechanisms.  These
 sections should be consulted for additional discussion and detail.

10.1. Denial of Service

 As with all services, the denial of service by either incorrect
 implementations or malicious agents is always a concern.  With the
 target of providing NFS version 4 for Internet use, it is all the
 more important that all aspects of the NFS version 4 protocol be
 reviewed for potential denial of service scenarios.  When found these
 potential problems should be mitigated as much as possible.

Shepler Informational [Page 17] RFC 2624 NFSv4 Design Considerations June 1999

11. Bibliography

 [RFC1094]
 Sun Microsystems, Inc., "NFS: Network File System Protocol
 Specification", RFC 1094, March 1989.
 http://www.ietf.org/rfc/rfc1094.txt
 [RFC1510]
 Kohl, J. and C. Neuman, "The Kerberos Network Authentication
 Service (V5)", RFC 1510, September 1993.
 http://www.ietf.org/rfc/rfc1510.txt
 [RFC1813]
 Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3
 Protocol Specification", RFC 1813, June 1995.
 http://www.ietf.org/rfc/rfc1813.txt
 [RFC1831]
 Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification
 Version 2", RFC 1831, August 1995.
 http://www.ietf.org/rfc/rfc1831.txt
 [RFC1832]
 Srinivasan, R., "XDR: External Data Representation Standard",
 RFC 1832, August 1995.
 http://www.ietf.org/rfc/rfc1832.txt
 [RFC1833]
 Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC
 1833, August 1995.
 http://www.ietf.org/rfc/rfc1833.txt
 [RFC2025]
 Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
 RFC 2025, October 1996.
 http://www.ietf.org/rfc/rfc2025.txt
 [RFC2054]
 Callaghan, B., "WebNFS Client Specification", RFC 2054, October
 1996.
 http://www.ietf.org/rfc/rfc2054.txt
 [RFC2055]
 Callaghan, B., "WebNFS Server Specification", RFC 2055, October
 1996.
 http://www.ietf.org/rfc/rfc2055.txt

Shepler Informational [Page 18] RFC 2624 NFSv4 Design Considerations June 1999

 [RFC2078]
 Linn, J., "Generic Security Service Application Program Interface,
 Version 2", RFC 2078, January 1997.
 http://www.ietf.org/rfc/rfc2078.txt
 [RFC2152]
 Goldsmith, D., "UTF-7 A Mail-Safe Transformation Format of Unicode",
 RFC 2152, May 1997.
 http://www.ietf.org/rfc/rfc2152.txt
 [RFC2203]
 Eisler, M., Chiu, A. and L.  Ling, "RPCSEC_GSS Protocol
 Specification", RFC 2203, August 1995.
 http://www.ietf.org/rfc/rfc2203.txt
 [RFC2222]
 Myers, J., "Simple Authentication and Security Layer (SASL)",
 RFC 2222, October 1997.
 http://www.ietf.org/rfc/rfc2222.txt
 [RFC2279]
 Yergeau, F., "UTF-8, a transformation format of ISO 10646",
 RFC 2279, January 1998.
 http://www.ietf.org/rfc/rfc2279.txt
 [RFC2246]
 Dierks, T. and C. Allen, "The TLS Protocols Version 1.0", RFC 2246,
 Certicom, January 1999.
 http://www.ietf.org/rfc/rfc2246.txt
 [RFC2401]
 Kent, S. and R. Atkinson, "Security Architecture for the Internet
 Protocol", RFC 2401, November 1998.
 http://www.ietf.org/rfc/rfc2401.txt
 [DCEACL]
 The Open Group, Open Group Technical Standard, "DCE 1.1:
 Authentication and Security Services," Document Number C311, August
 1997. Provides a discussion of DEC ACL structure and semantics.
 [HPFS]
 Les Bell and Associates Pty Ltd, "The HPFS FAQ,"
 http://www.lesbell.com.au/hpfsfaq.html
 [Hutson]
 Huston, L.B., Honeyman, P., "Disconnected Operation for AFS," June
 1993. Proc. USENIX Symp. on Mobile and Location-Independent
 Computing, Cambridge, August 1993.

Shepler Informational [Page 19] RFC 2624 NFSv4 Design Considerations June 1999

 [Kistler]
 Kistler, James J., Satyanarayanan, M., "Disconnected Operations in
 the Coda File System," ACM Trans. on Computer Systems, vol. 10, no.
 1, pp. 3-25, Feb. 1992.
 [Mummert]
 Mummert, L. B., Ebling, M. R., Satyanarayanan, M., "Exploiting Weak
 Connectivity for Mobile File Access," Proc. of the 15th ACM Symp.
 on Operating Systems Principles Dec. 1995.
 [Nagar]
 Nagar, R., "Windows NT File System Internals," ISBN 1565922492,
 O`Reilly & Associates, Inc.
 [Sandberg]
 Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B.  Lyon, "Design
 and Implementation of the Sun Network Filesystem," USENIX
 Conference Proceedings, USENIX Association, Berkeley, CA, Summer
 1985.  The basic paper describing the SunOS implementation of the
 NFS version 2 protocol, and discusses the goals, protocol
 specification and trade-offs.
 [Satyanarayanan1]
 Satyanarayanan, M., "Fundamental Challenges in Mobile Computing,"
 Proc. of the ACM Principles of Distributed Computing, 1995.
 [Satyanarayanan2]
 Satyanarayanan, M., Kistler, J. J., Mummert L. B., Ebling M. R.,
 Kumar, P. , Lu,  Q., "Experience with disconnected operation in
 mobile computing environment," Proc. of the USENIX Symp. on Mobile
 and Location-Independent Computing, Jun. 1993.
 [Unicode1]
 "Unicode Technical Report #8 - The Unicode Standard, Version 2.1",
 Unicode, Inc., The Unicode Consortium, P.O. Box 700519, San Jose,
 CA 95710-0519 USA, September 1998
 http://www.unicode.org/unicode/reports/tr8.html
 [Unicode2]
 "Unsupported Scripts" Unicode, Inc., The Unicode Consortium, P.O.
 Box 700519, San Jose, CA 95710-0519 USA, October 1998
 http://www.unicode.org/unicode/standard/unsupported.html
 [XDSM]
 The Open Group, Open Group Technical Standard, "Systems Management:
 Data Storage Management (XDSM) API," ISBN 1-85912-190-X, January
 1997.

Shepler Informational [Page 20] RFC 2624 NFSv4 Design Considerations June 1999

 [XNFS]
 The Open Group, Protocols for Interworking: XNFS, Version 3W, The
 Open Group, 1010 El Camino Real Suite 380, Menlo Park, CA 94025,
 ISBN 1-85912-184-5, February 1998.
 HTML version available: http://www.opengroup.org

12. Acknowledgments

 o    Brent Callaghan for content contributions.

13. Author's Address

 Address comments related to this memorandum to:
 spencer.shepler@eng.sun.com -or- nfsv4-wg@sunroof.eng.sun.com
 Spencer Shepler
 Sun Microsystems, Inc.
 7808 Moonflower Drive
 Austin, Texas 78750
 Phone: (512) 349-9376
 EMail: spencer.shepler@eng.sun.com

Shepler Informational [Page 21] RFC 2624 NFSv4 Design Considerations June 1999

14. Full Copyright Statement

 Copyright (C) The Internet Society (1999).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Shepler Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2624.txt · Last modified: 1999/06/24 23:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki