Subject: [nfsv4] Part of open issue NSDB-5: Use of LDAP URLs to identify NSDB services

From: Chuck Lever <[email-masked]>
Date: Wed, 1 Aug 2012 14:47:26 -0700

Rob, Andy and I met yesterday morning to try to work out open issues with the NSDB draft.

Based on Chu's suggestion to use an LDAP URL (or to define a specific URL format for NSDBs) to represent the NSDB service name, we have been considering the function of the fedfsNsdbName attribute stored in FSN records.  The NSDB draft has this rationale in section 5.1.1 for the existence of the attribute in an FSN:

   The NSDB node that receives the request SHOULD check that
   fedfsNsdbName value matches its own value and return an error if it
   does not.  This is to ensure that an FSN is always created by the
   NSDB node encoded within the FSN as its owner.

We don't believe that typical LDAP servers can perform a semantic check of this kind.  Even if a particular LDAP server implementation could perform this check, the spec defines the fedfsNsdbName attribute to inherit from "name" and defines no additional matching rules (see section 4.2.1.5), which suggests there is no standardized way to get an LDAP server to perform such a check.  It would also be difficult to implement in the face of DNS aliasing of the NSDB service.  In our opinion, the WG should consider removing this rationale from the NSDB draft.

Without this check, we don't understand the value of storing the NSDB service name in the FSN.  An NSDB administrative client should already know that it is contacting that NSDB, since it used the NSDB service name to bind to that LDAP server.  Likewise for an NSDB client on a file server.  It is an especially weak check in comparison to using TLS to authenticate the LDAP service.

Is there another way to express that check, or to have another part of the domain administration infrastructure perform the check?  Or is there some other unstated value to keeping the NSDB service name in FSN records?

Or should we simply remove this attribute and the related fedfsNsdbPort from the fedfsFsn object class?

If we keep these attributes, we should consider one or more of:

	• Representing an NSDB service name in an FSN record as a standard LDAP URL
	• Making the fedfsNsdbName attribute optional for the fedfsFsn object class
	• Providing a strong rationale for why the NSDB name attribute is required in a fedfsFsn record
	• Providing some text reminding readers how NSDB clients determine what transport and security is used to contact the NSDB (i.e., why we don't use a standard LDAP URL here)

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: James Lentini <[email-masked]>
Date: Thu, 2 Aug 2012 17:07:11 -0400 (EDT)

On Wed, 1 Aug 2012, Chuck Lever wrote:

> Based on Chu's suggestion to use an LDAP URL (or to define a 
> specific URL format for NSDBs) to represent the NSDB service name, 
> we have been considering the function of the fedfsNsdbName attribute 
> stored in FSN records.  The NSDB draft has this rationale in section 
> 5.1.1 for the existence of the attribute in an FSN:
> 
> We don't believe that typical LDAP servers can perform a semantic 
> check of this kind.  Even if a particular LDAP server implementation 
> could perform this check, the spec defines the fedfsNsdbName 
> attribute to inherit from "name" and defines no additional matching 
> rules (see section 4.2.1.5), which suggests there is no standardized 
> way to get an LDAP server to perform such a check.  It would also be 
> difficult to implement in the face of DNS aliasing of the NSDB 
> service.  In our opinion, the WG should consider removing this 
> rationale from the NSDB draft.
> 
> Without this check, we don't understand the value of storing the 
> NSDB service name in the FSN.  An NSDB administrative client should 
> already know that it is contacting that NSDB, since it used the NSDB 
> service name to bind to that LDAP server.  Likewise for an NSDB 
> client on a file server.  It is an especially weak check in 
> comparison to using TLS to authenticate the LDAP service.
> 
> Is there another way to express that check, or to have another part 
> of the domain administration infrastructure perform the check?  Or 
> is there some other unstated value to keeping the NSDB service name 
> in FSN records?
> 
> Or should we simply remove this attribute and the related 
> fedfsNsdbPort from the fedfsFsn object class?
> 

I can share the history, at least as I know it, behind including the 
fedfsNsdbName attribute in the fedfsFsn LDAP object. I'll defer to 
Craig, Dan, Renu, and Manoj if they remember differently as the 
original LDAP definition for an FSN preceded my involvement.

When the abstract FSN concept was defined in LDAP as the fedfsFsn 
objectclass, the approach was to explicitly include both the NSDB name 
(fedfsNsdbName) and UUID (fedfsFsnUuid). This has nice symmetry with 
the FedFS administration protocol's ONC RPC definition of an FSN. 

If removing the explicit NSDB name from the LDAP representation of an 
FSN doesn't cause any problems, then that seems like the best solution 
to me. As you mention, the LDAP fedfsFsn object's NSDB name is 
implicitly the NSDB service being queried.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 3 Aug 2012 21:45:23 -0400

> implicitly the NSDB service being queried.

Thanks, James.  I'm comfortable removing the fedfsNsdbName and fedfsNsdbPort attributes.

---

From: James Lentini <[email-masked]>
Date: Tue, 7 Aug 2012 17:37:59 -0400 (EDT)

Dan Ellard reminded me of another reason for storing the NSDB name 
inside an FSN. The goal was to support proxying FSNs. This concept is 
mentioned in draft-ietf-nfsv4-federated-fs-protocol-12.txt in Section 
2.9 at the bottom of page 10:

   Each NSDB node stores the definition of the FSNs for which it is
   authoritative.  It also stores the definitions of the FSLs associated
   with those FSNs.  An NSDB node is authoritative for the filesets that
   it defines.  An NSDB node can cache information from a peer NSDB
   node.  The fileserver can always contact a local NSDB node (if it has
   been defined) or directly contact any NSDB node to resolve a
   junction.  Each NSDB node supports an LDAP [RFC4510] interface and
   can be accessed by an LDAP client.

By the way, the LDAP FSLs also contain an NSDB name attribute.

-james

---

From: Chuck Lever <[email-masked]>
Date: Tue, 7 Aug 2012 17:48:13 -0400

>   can be accessed by an LDAP client.

Has anyone tried to implement proxying?  I don't think I could, given this description.

What does "directly contact any NSDB node to resolve a junction" mean, exactly?  Why would a file server bother to connect to any NSDB but the one named in the junction it is trying to resolve?

Even if an NCE was located at a different DN on LDAP servers participating in the same NSDB service, the NCE prefix hunting algorithm would find them.  Or, even better, the UUIDs of the FSNs and FSLs would be the same on all LDAP servers, and universally unique, so you could find them if they were anywhere under the NSDB's NCE.

The NSDB name still isn't needed, I'd think.