rfc2624.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页


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