Internet DRAFT - draft-cel-nfsv4-federated-fs-nce

draft-cel-nfsv4-federated-fs-nce







Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Intended status: Standards Track                                S. Sorce
Expires: April 28, 2017                                          Red Hat
                                                        October 25, 2016


             A Simpler Mechanism For Organizing FedFS NSDBs
                  draft-cel-nfsv4-federated-fs-nce-06

Abstract

   This document describes a new, simpler mechanism for searching FedFS
   NSDBs (Name Space Data Bases) for FedFS records.  This mechanism
   replaces the mechanism described in existing FedFS Proposed
   Standards.

Requirements Language

   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 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 28, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Lever & Sorce            Expires April 28, 2017                 [Page 1]

Internet-Draft           FedFS NSDB Organization            October 2016


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Altering rootDSEs Considered Hazardous  . . . . . . . . .   3
   2.  Simplifying NCE Discovery . . . . . . . . . . . . . . . . . .   5
     2.1.  NSDB Configuration  . . . . . . . . . . . . . . . . . . .   5
     2.2.  fedfsNsdbContainerEntry . . . . . . . . . . . . . . . . .   7
     2.3.  NSDB Container Entry (NCE) Enumeration  . . . . . . . . .   7
   3.  Backwards Compatibility . . . . . . . . . . . . . . . . . . .   8
     3.1.  NSDB server compatibility . . . . . . . . . . . . . . . .   8
     3.2.  NSDB client compatibility . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  LDAP Descriptor Deprecation . . . . . . . . . . . . . . .   9
     5.2.  LDAP Descriptor Registration  . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   A FedFS junction is an object stored on a fileserver that redirects
   file-access clients to other fileserver shares.  Using junctions,
   multiple fileserver shares on many fileservers can be joined into a
   single filename namespace.  Think of a junction as a symlink that
   points to the root directory of a share stored on another fileserver.

   The target locations of these remote shares are not stored in FedFS
   junctions.  Instead, a junction contains a reference to a set of
   location information stored in an LDAP directory.  The LDAP directory
   is referred to as a Name Space Data Base, or NSDB.

   The fundamental and most frequent operation performed with an NSDB is
   "FSN resolution," described in section 5.2.2 of [RFC7532].  This is
   the act of reading the reference stored in a junction, retrieving the
   referenced location information from an NSDB, and forming a
   filesystem referral to send to file-access clients using a native
   filesystem protocol.  In this scenario, a fileserver acts as an NSDB
   client.



Lever & Sorce            Expires April 28, 2017                 [Page 2]

Internet-Draft           FedFS NSDB Organization            October 2016


   FedFS records in any NSDB are stored as descendants of an NSDB
   Container Entry, or NCE, for short.  An NSDB client specifies a
   search base when forming an LDAP query to search an NSDB for FedFS
   records.  The Distinguished Name of an NCE is that search base.

   FedFS junctions contain only the hostname and port of the NSDB
   service and a UUID.  NSDB clients use a standard procedure for
   probing NSDBs for their NCEs.  For the purposes of this discussion,
   we refer to procedures which retrieve putative NCEs from an NSDB as
   "NCE discovery mechanisms."

   Implementation experience has shown that the NCE discovery mechanism
   currently defined in sections 4.1 and 5.2.1 of [RFC7532] can be
   problematic for some LDAP server implementations or deployments.  In
   particular, altering the rootDSE of LDAP servers in any way is an
   onerous requirement.  We present a new mechanism for expressing NCEs
   that does not require alteration of the rootDSE.

1.1.  Altering rootDSEs Considered Hazardous

   As described in Section 4.1 of [RFC7532], the LDAP naming context
   that is superior to an NCE is modified to include the
   fedfsNsdbContainerInfo object class.  This object class carries the
   mandatory fedfsNceDN attribute, whose value is the Distinguished Name
   of the NCE that resides under that naming context.

   To discover all NCEs on an NSDB, NSDB clients use the procedure
   described in Section 5.2.1 of [RFC7532].  NSDB clients look for
   naming context entries that include the fedfsNsdbContainerInfo object
   class.  The fedfsNceDN attribute points directly to the NCE under
   that root suffix.

   Difficulty arises because there is often a high bar to altering an
   LDAP server's rootDSE.

   o  Because rootDSE's typically contain read-mostly or even read-only
      data, an LDAP server implementation may simulate its rootDSE,
      rather than storing it as regular LDAP records.  Code changes
      would be necessary for such an LDAP server implementation to act
      as an NSDB.

   o  For security reasons, some LDAP server deployments may not wish to
      grant unauthenticated access to their rootDSE information.

   o  Typically, a separate NSDB administrator account is used to manage
      NSDB entries under an NCE, but LDAP server administrator
      privileges (essentially, a root password for the LDAP server) are
      required if an NCE needs to be added, moved, or deleted.  Some



Lever & Sorce            Expires April 28, 2017                 [Page 3]

Internet-Draft           FedFS NSDB Organization            October 2016


      LDAP server administrators may prefer using Access Control Lists
      (ACLs) to manage access to all FedFS record types, including NCEs.

   o  The schema specified in [RFC7532] limits the number of NCEs per
      naming context to one.  There does not appear to be any other
      architected limit in the NSDB protocol that requires a one-to-one
      relationship between naming context and NCE.

   Neither [RFC7532] nor [RFC5716] discuss the motivation for referring
   to an NCE record via the rootDSE.  The use of the current NCE
   discovery mechanism is simply a convenience that enables the contents
   of junctions to exclude the LDAP search base when specifying the LDAP
   record containing the junction's target locations.

   Originally, an NSDB Container Entry DN was stored in each junction,
   along with an FSN UUID and the name of the NSDB where the FSN was
   stored.

   To simplify the contents of junctions, the NCE DN was removed from
   junctions as the design of the NSDB protocol was finalized.  NSDB
   clients were tasked with discovering the correct LDAP search base to
   use by searching the target NSDB's rootDSE for the NCE DN.

   The current approach is described in Section 5.2.2 of [RFC7532]:

   1.  The NSDB client obtains a list of the target NSDB's naming
       contexts.

   2.  The NSDB client obtains a list of NCEs that reside on the target
       NSDB by searching each of the NSDB's naming contexts for the
       fedfsNsdbContainerInfo object class.

   3.  Finally, the NSDB client forms a series of LDAP queries using
       each NCE as the search base.  The client supplies a filter to
       retrieve only objects in the fedfsFsl object class.

   The search stops when one or more FSLs are returned or when all NCEs
   have been searched.

   Without the fedfsNsdbContainerInfo object class, a root suffix DN is
   an adequate LDAP search base to use when searching for FSL records.
   For administrative purposes, however, the construct of NCE is
   maintained.








Lever & Sorce            Expires April 28, 2017                 [Page 4]

Internet-Draft           FedFS NSDB Organization            October 2016


2.  Simplifying NCE Discovery

   Rather than relying on a Distinguish Name stored in an attribute by
   an administrative tool, an NSDB client might instead use a search
   query that is natural to LDAP to obtain that DN.

   Currently an NSDB Container Entry record is entirely unremarkable,
   except for its position in the DIT.  It includes no special object
   class, Distinguished Name, or attribute that defines it as an NCE.
   It becomes an NCE only because its parent naming context points to it
   via the context's fedfsNceDN attribute.

   If each NCE were instead tagged with an object class specific only to
   NCEs, NSDB clients could discover NCEs simply by filtering on that
   object class.  Then no change to the LDAP server's rootDSE is
   required.

   The following sections provide a protocol specification, similar to
   [RFC7532], for the new NCE discovery mechanism.

2.1.  NSDB Configuration

   An NSDB is constructed using an LDAP Directory.  This LDAP Directory
   can have multiple naming contexts.  The LDAP Directory's DSA-specific
   entry (its rootDSE) has a multi-valued namingContext attribute.  Each
   value of the namingContext attribute is the DN of the naming
   context's root entry (see [RFC4512]).

   For each naming context that contains federation entries (e.g., FSNs
   and FSLs):

   1.  Typically, all of a naming context's federation entries are
       descended from one LDAP entry in the Directory Information Tree
       (DIT).  This entry is termed an NSDB Container Entry (NCE).

   2.  NSDB clients filter with "(objectClass=fedfsNsdbContainerEntry)"
       to locate the naming context's NCEs.  Therefore, every NCE MUST
       include fedfsNsdbContainerEntry as one of its object classes.

   3.  NSDB clients search for FSNs with a scope ONE search, based on an
       NCE.  Therefore, all FSN entries under the naming context MUST be
       immediate children of an NCE.

   4.  NSDB clients search for FSLs with a scope ONE search, based on an
       FSN entry.  Therefore, all FSL entries under the naming context
       MUST be immediate children of an FSN entry.





Lever & Sorce            Expires April 28, 2017                 [Page 5]

Internet-Draft           FedFS NSDB Organization            October 2016


   An NCE may have no children.  When an NSDB is first created, there
   are no federation entries aside from the NCE, which therefore has no
   federation-related descendents.

   NSDB administrative operations, such as those described in
   Section 5.1 of [RFC7532], may use NCEs to demark the position of
   repositories for federation entries.

   If a naming context does not host an NSDB DIT, it MUST NOT contain an
   entry that includes the fedfsNsdbContainerEntry object class.  For
   example, an LDAP directory might have the following entries:


           -+ [root DSE]
            |  namingContext: o=fedfs
            |  namingContext: dc=example,dc=com
            |  namingContext: ou=system
            |
            |
            +---- [o=fedfs]
            |      objectClass: fedfsNsdbContainerEntry
            |
            |
            +---- [dc=example,dc=com]
            |
            +-------- [ou=corp-it,dc=example,dc=com]
            |
            +------------ [ou=fedfs,ou=corp-it,dc=example,dc=com]
            |              objectClass: fedfsNsdbContainerEntry
            |
            |
            +---- [ou=system]


   In this case, the o=fedfs naming context is also an NSDB Container
   Entry; the dc=example,dc=com naming context has an NSDB Container
   Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system
   naming context has no NSDB Container Entry.

   The NSDB SHOULD be configured with one or more privileged LDAP users.
   These users are able to modify the contents of the LDAP database.  To
   perform the operations described in Section 5.1 of [RFC7532], a user
   SHOULD authenticate using the DN of a privileged LDAP user.

   It MUST be possible for an unprivileged (unauthenticated) user to
   perform LDAP queries that access NSDB data.  A fileserver performs
   the operations described in Section 5.2 of [RFC7532] as an
   unprivileged user.



Lever & Sorce            Expires April 28, 2017                 [Page 6]

Internet-Draft           FedFS NSDB Organization            October 2016


   All NSDB implementations SHOULD use the same schema.  At minimum,
   each MUST use a schema that includes all attributes and objects named
   in Section 4.2 of [RFC7532] and in Section 2.2.  If it is necessary
   for an implementation to privately extend the schema defined there,
   consider using one of the following ways:

   o  Define a fedfsAnnotation key and values (see Section 4.2.1.6 of
      [RFC7532]).  Register the new key and values with IANA.

   o  Define additional attribute types and object classes, then have
      entries inherit from a class defined in Section 4.1 of [RFC7532]
      and in Section 2.2, and from the implementation-defined ones.

2.2.  fedfsNsdbContainerEntry

   This section is an addendum to the FedFS NSDB schema specified in
   Section 4.1 of [RFC7532].

   The fedfsNsdbContainerEntry object class signifies that an LDAP
   record acts as an NSDB Container Entry (NCE).

   A fedfsNsdbContainerEntry's has no mandatory attributes.  A
   fedfsNsdbContainerEntry's fedfsAnnotation and fedfsDescr attributes
   are OPTIONAL.

   <CODE BEGINS>


         ///
         /// objectclass (
         ///     a.b.c.d.e.f.g.h.i NAME 'fedfsNsdbContainerEntry'
         ///     DESC 'Denotes an NSDB Container Entry'
         ///     SUP top AUXILIARY
         ///     MAY (
         ///             fedfsAnnotation
         ///             $ fedfsDescr
         ///     ))
         ///


   <CODE ENDS>

2.3.  NSDB Container Entry (NCE) Enumeration

   To find NCEs residing on the NSDB nsdb.example.com, an NSDB client
   SHOULD do the following:

   <CODE BEGINS>



Lever & Sorce            Expires April 28, 2017                 [Page 7]

Internet-Draft           FedFS NSDB Organization            October 2016


         nce_list = empty
         connect to the LDAP directory at nsdb.example.com
         for each namingContext value $BAR in the root DSE
             /* $BAR is a DN */
             query for fedfsNsdbContainerEntry objects under $BAR
             include the DN of such objects on the nce_list


   <CODE ENDS>

   The [RFC4516] LDAP URL for the search query inside the loop would be:


         ldap://nsdb.example.com:389/$BAR??sub?
                 (objectClass=fedfsNsdbContainerEntry)


3.  Backwards Compatibility

3.1.  NSDB server compatibility

   NSDBs might serve NSDB client populations that contain clients that
   comply only with [RFC7532] as well as clients that use the query
   described in Section 2.3.

   In this case, both the mechanism described in Section 2.1 and the
   mechanism described in [RFC7532] can be concurrently implemented in
   the NSDB to support both types of NSDB client.

   To remain compatible with NSDB clients that comply with [RFC7532],
   each naming context on such an NSDB MUST contain either zero or one
   NCE records.

3.2.  NSDB client compatibility

   During a transition period to the new NCE discovery mechanism, NSDB
   clients may have to resolve FSNs on NSDBs that comply with [RFC7532]
   as well as NSDBs that have deployed the mechanism described in
   Section 2.1.

   In this case, an NSDB client can try the query described in
   Section 2.3 first.  If no NCE is found by this method, the NSDB
   client can try the query described in Section 5.2.1 of [RFC7532].

   An NSDB client that encounters more than one NCE record under a
   naming context MUST return FEDFS_ERR_NSDB_NONCE if it does not
   support multiple NCEs per naming context.




Lever & Sorce            Expires April 28, 2017                 [Page 8]

Internet-Draft           FedFS NSDB Organization            October 2016


4.  Security Considerations

   To maintain separation of privileges, privileged users that are
   permitted to perform NSDB administrative operations should not be
   permitted access to other areas of the LDAP server's DIT.  The use of
   LDAP ACLs is recommended to permit unauthenticated access to FedFS
   records (FSNs, FSLs, and NCEs) while restricting the ability to
   change these records to one or a few privileged user accounts.

5.  IANA Considerations

5.1.  LDAP Descriptor Deprecation

   IANA is to update the registry entitled "FedFS Object Identifiers"
   for the purpose of recording the change in status of existing FedFS
   Object Identifiers (OIDs) mentioned by this document.  This includes
   the fedfsNceDN entry (OID 1.3.6.1.4.1.31103.1.14) and the
   fedfsNsdbContainerInfo entry (OID 1.3.6.1.4.1.31103.1.1001).  The
   designation of "historic" is to be added to the "Reference" column of
   both entries.

   In accordance with Section 5.2 of [RFC4520], object identifier
   descriptors for the fedfsNsdbContainerInfo object class and the
   fedfsNceDN attribute are to be marked as "historic in nature" in
   IANA's LDAP parameters "Object Identifier Descriptors" table, after
   Expert Review.

5.2.  LDAP Descriptor Registration

   In accordance with Section 3.4 and Section 4 of [RFC4520], object
   identifier descriptors for the new fedfsNsdbContainerEntry object
   class defined in this document will be assigned and registered via
   the Expert Review process.

   Subject:  Request for LDAP Descriptor Registration

   Person & email address to contact for further information:  See
      "Author/Change Controller"

   Specification:  draft-cel-nfsv4-federated-fs-nce

   Author/Change Controller:  IESG (iesg@ietf.org)

   Object Identifier:  TBD

   Descriptor (short name):  fedfsNsdbContainerEntry

   Usage:  object class



Lever & Sorce            Expires April 28, 2017                 [Page 9]

Internet-Draft           FedFS NSDB Organization            October 2016


6.  References

6.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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4512]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512,
              DOI 10.17487/RFC4512, June 2006,
              <http://www.rfc-editor.org/info/rfc4512>.

   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516,
              DOI 10.17487/RFC4516, June 2006,
              <http://www.rfc-editor.org/info/rfc4516>.

   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 4520, DOI 10.17487/RFC4520,
              June 2006, <http://www.rfc-editor.org/info/rfc4520>.

   [RFC7532]  Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace
              Database (NSDB) Protocol for Federated File Systems",
              RFC 7532, DOI 10.17487/RFC7532, March 2015,
              <http://www.rfc-editor.org/info/rfc7532>.

6.2.  Informative References

   [RFC5716]  Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
              Naik, "Requirements for Federated File Systems", RFC 5716,
              DOI 10.17487/RFC5716, January 2010,
              <http://www.rfc-editor.org/info/rfc5716>.

Appendix A.  Acknowledgements

   The author of this document gratefully acknowledges the contributions
   and patience of Rob Thurlow, Tom Haynes, and David Noveck.  This work
   would not have been possible without the efforts of the authors and
   contributors to [RFC7532].

Authors' Addresses







Lever & Sorce            Expires April 28, 2017                [Page 10]

Internet-Draft           FedFS NSDB Organization            October 2016


   Charles Lever
   Oracle Corporation
   1015 Granger Avenue
   Ann Arbor, MI  48104
   USA

   Phone: +1 734 274 2396
   Email: chuck.lever@oracle.com


   Simo Sorce
   Red Hat, Inc.

   Email: simo.sorce@redhat.com





































Lever & Sorce            Expires April 28, 2017                [Page 11]