NFS version 4.0 Trunking Update
draft-ietf-nfsv4-mv0-trunking-update-02

Internet-Draft           NFSv4.0 Trunking Update           November 2018

   replicas to use, scanning for available network addresses could
   potentially be a long process.  To keep this process as short as
   possible, Servers are REQUIRED to place file system location entries
   that represent addresses usable with the current server or a
   migration target before those associated with replicas.  A client can
   then cease scanning for trunkable file system location entries once
   it encounters a file system location element whose fs_name differs
   from the current fs_name, or whose address is not server-trunkable
   with the one it is currently using.

5.3.  Updated Section 8.5 of [RFC7530], entitled "Location Entries and
      Server Identity Update"

   As mentioned above, a single file system location entry may have a
   server address target in the form of a DNS host name that resolves to
   multiple network addresses, while multiple file system location
   entries may have their own server address targets that reference the
   same server.

   When server-trunkable addresses for a server exist, the client may
   assume that for each file system in the namespace of a given server
   network address, there exist file systems at corresponding namespace
   locations for each of the other server network addresses.  It may do
   this even in the absence of explicit listing in fs_locations.  Such
   corresponding file system locations can be used as alternative
   locations, just as those explicitly specified via the fs_locations
   attribute.

6.  Updates to [RFC7530] Outside Section Eight

   Since the existing description of NFS4ERR_MOVED in Section 13.1.2.4
   of [RFC7530] does not take proper account of trunking, it needs to be
   modified by replacing the first two sentences of the description with
   the following material:

      The file system that contains the current filehandle object cannot
      be accessed using the current network address.  It may be
      accessible using other network addresses connected to the same
      server, it may have been relocated to another server, or it may
      never have been present.

7.  Security Considerations

   The Security Considerations section of [RFC7530] needs the additions
   below to properly address some aspects of trunking discovery,
   referral, migration, and replication.

Lever & Noveck             Expires May 9, 2019                 [Page 14]
Internet-Draft           NFSv4.0 Trunking Update           November 2018

      The possibility that requests to determine the set of network
      addresses corresponding to a given server might be interfered with
      or have their responses corrupted needs to be taken into account.

      o  When DNS is used to convert NFS server host names to network
         addresses and DNSSEC [RFC4033] is not available, the validity
         of the network addresses returned cannot be relied upon.
         However, when the client uses RPCSEC_GSS [RFC7861] to access
         NFS servers, it is possible for mutual authentication to detect
         invalid server addresses.  Other forms of transport layer
         security (e.g., [RFC8446]) can also offer strong authentication
         of NFS servers.

      o  Fetching file system location information SHOULD be performed
         using RPCSEC_GSS with integrity protection, as previously
         explained in the Security Considerations section of [RFC7530].
         Making a request of this sort without using strong integrity
         protection permits corruption during transit of returned file
         system location information.  The client implementer needs to
         recognize that using such information to access an NFS server
         without use of RPCSEC_GSS (e.g., by using AUTH_SYS as defined
         in [RFC5531]) can result in the client interacting with an
         unverified network address that is posing as an NFSv4 server.

      o  Despite the fact that it is a REQUIREMENT of [RFC7530] that
         "implementations" provide "support" for the use of RPCSEC_GSS,
         it cannot be assumed that use of RPCSEC_GSS is always possible
         between any particular client-server pair.

      o  Returning only network addresses to a client that has no
         trusted DNS resolution service can hamper its ability to use
         RPCSEC_GSS.

      Therefore an NFSv4 server SHOULD present file system location
      entries that correspond to file systems on other servers using
      only host names.  This enables the client to interrogate the
      fs_locations on the destination server to obtain trunking
      information (as well as replica information) using RPCSEC_GSS with
      integrity, validating the host name provided while assuring that
      the response has not been corrupted.

      When RPCSEC_GSS is not available on an NFS server, returned file
      system location information is subject to corruption during
      transit and cannot be relied upon.  In the case of a client being
      directed to another server after NFS4ERR_MOVED, this could vitiate
      the authentication provided by the use of RPCSEC_GSS on the
      destination.  Even when RPCSEC_GSS authentication is available on
      the destination, this server might validly represent itself as the

Lever & Noveck             Expires May 9, 2019                 [Page 15]
Internet-Draft           NFSv4.0 Trunking Update           November 2018

      server to which the client was erroneously directed.  Without a
      way to decide wether the server is a valid one, the client can
      only determine, using RPCSEC_GSS, that the server corresponds to
      the host name provided, with no basis for trusting that server.
      The client should not use such unverified file system location
      entries as a basis for migration, even though RPCSEC_GSS might be
      available on the destination server.

      When a file system location attribute is fetched upon connecting
      with an NFSv4 server, it SHOULD, as stated above, be done using
      RPCSEC_GSS with integrity protection.

      When file system location information cannot be protected in
      transit, the client can subject it to additional filtering to
      prevent the client from being inappropriately directed.  For
      example, if a range of network addresses can be determined that
      assure that the servers and clients using AUTH_SYS are subject to
      appropriate constraints (such as physical network isolation and
      the use of administrative controls within the operating systems),
      then network adresses in this range can be used with others
      discarded or restricted in their use of AUTH_SYS.

      When neither integrity protection nor filtering is possible, it is
      best for the client to ignore trunking and replica information or
      simply not fetch the file system location information for these
      purposes.

      To summarize considerations regarding the use of RPCSEC_GSS in
      fetching file system location information, consider the following
      possibilities for requests to interrogate location information,
      with interrogation approaches on the referring and destination
      servers arrived at separately:

      o  The use of RPCSEC_GSS with integrity protection is RECOMMENDED
         in all cases, since the absence of integrity protection exposes
         the client to the possibility of the results being modified in
         transit.

      o  The use of requests issued without RPCSEC_GSS (e.g., using
         AUTH_SYS), while undesirable, might be unavoidable in some
         cases.  Where the use of returned file system location
         information cannot be avoided, it should be subject to
         filtering to eliminate untrusted network addresses.  The
         specifics will vary depending on the degree of network
         isolation and whether the request is to the referring or
         destination servers.

Lever & Noveck             Expires May 9, 2019                 [Page 16]
Internet-Draft           NFSv4.0 Trunking Update           November 2018

8.  IANA Considerations

   This document does not require actions by IANA.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5531]  Thurlow, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 5531, DOI 10.17487/RFC5531,
              May 2009, <https://www.rfc-editor.org/info/rfc5531>.

   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File System
              (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
              March 2015, <https://www.rfc-editor.org/info/rfc7530>.

   [RFC7931]  Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
              "NFSv4.0 Migration: Specification Update", RFC 7931,
              DOI 10.17487/RFC7931, July 2016,
              <https://www.rfc-editor.org/info/rfc7931>.

   [RFC8166]  Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct
              Memory Access Transport for Remote Procedure Call Version
              1", RFC 8166, DOI 10.17487/RFC8166, June 2017,
              <https://www.rfc-editor.org/info/rfc8166>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
              <https://www.rfc-editor.org/info/rfc5661>.

Lever & Noveck             Expires May 9, 2019                 [Page 17]
Internet-Draft           NFSv4.0 Trunking Update           November 2018

   [RFC7861]  Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
              Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
              November 2016, <https://www.rfc-editor.org/info/rfc7861>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Appendix A.  Section Classification

   All sections of this document are considered explanatory with the
   following exceptions.

   o  Sections 5.1 and 5.2.1 are replacement sections.

   o  Section 5.2.2 is an additional section.

   o  Sections 5.2.4 and 5.2.5 are replacement sections.

   o  Section 5.2.6 is an additional section.

   o  Section 5.3 is a replacement section.

   o  Section 6 is an editing section.

   o  Section 7 is an additional section.

Acknowledgments

   The authors wish to thank Andy Adamson, who wrote the original
   version of this document.  All the innovation in this document is the
   result of Andy's work, while mistakes are best ascribed to the
   current authors.

   The editor wishes to thank Greg Marsden for his support of this work,
   and Robert Thurlow for review and suggestions.

   Special thanks go to Transport Area Director Spencer Dawkins, NFSV4
   Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
   Working Group Secretary Thomas Haynes for their ongoing support.

Authors' Addresses

Lever & Noveck             Expires May 9, 2019                 [Page 18]
Internet-Draft           NFSv4.0 Trunking Update           November 2018

   Charles Lever (editor)
   Oracle Corporation
   1015 Granger Avenue
   Ann Arbor, MI  48104
   United States of America

   Phone: +1 248 816 6463
   Email: chuck.lever@oracle.com

   David Noveck
   NetApp
   1601 Trapelo Road
   Waltham, MA  02451
   United States of America

   Phone: +1 781 572 8038
   Email: davenoveck@gmail.com

Lever & Noveck             Expires May 9, 2019                 [Page 19]