doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc2624.txt b/doc/rfc/rfc2624.txt
new file mode 100644
index 0000000..b2adf35
--- /dev/null
+++ b/doc/rfc/rfc2624.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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]
+