Subject: [Ldap-dir] Concerns about draft-ietf-nfsv4-federated-fs-protocol

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 11:09:52 -0500

Dear LDAP directorate,

I have several issues with draft-ietf-nfsv4-federated-fs-protocol-03, of
which at least two remain outstanding, and which the authors do not wish
to address.  My concerns:

1) It requires that searches have scope=one and base-DN="o=fedfs":

"
   The base name (or suffix) of the NSDB directory information tree
   (DIT) is "o=fedfs".
"

and

"
                            The scope value of "one" restricts the
   search to the entry's children (rather than the entire subtree below
   the entry) and the filter ensures that only FSL entries are returned.
"

I believe this unnecessarily constrains deployment and will cause many
problems.  I also believe that this is probably an artifact of one or
more of the authors needing to furnish a base DN to typical LDAP APIs,
and the simplest (but wrong) thing to do was to hardcode it.

The document also says the following, which, incidentally, is
practically a corollary of the o=fedfs requirement:

"
   Given the above configuration guidelines, an NSDB SHOULD be
   constructed using a dedicated LDAP directory.  Separate LDAP
   directories may be used for other purposes, such as storing user
   account information.  By using an LDAP directory dedicated to storing
   NSDB records, there is no need to disturb the configuration of any
   other LDAP directories that store information unrelated to an NSDB.
"

I don't think an RFC should make such a recommendation (really, a
requirement).  But more than anything I don't think an RFC should
mandate the names of a DIT's namingContexts.

(The example searches don't filter on objectClass, which may be another
reason why the authors chose to segregate the NSDB from the rest of the
DIT.)

2) The use of UUIDs for object naming to guarantee object DN uniqueness,
while not necessarily a problem, seems unnecessary: the directory should
ensure object DN uniqueness, thus there is no need to enforce uniqueness
at the application layer!

Specifically the I-D says:

"
   Since LDAP requires a DN to be unique, this ensures that each FSN
   entry has a unique UUID value within the LDAP directory.
"

In particular it seems that the use of UUIDs derives from the fact that
an NFSv4 federation is expected to consist of per-domain "NSDBs", where
each NSDB is an LDAP DS or more, all with a flat NSDB object naming
scheme (see issue (1)), but which is still expected to have federation-
wide unique NSDB object names.  That's where UUIDs as object names come
in.  Of course, there's no way in this scheme to know where an NSDB
resides just from its name -- which begs the question of why a flat
global NSDB object namespace is needed in the first place.

I believe this document represents a gross misuse of LDAP.  But I cannot
convince the authors that that is the case.  Hopefully the App Area will
have a chance to review this document and review my concerns.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 10 Sep 2009 17:58:05 +0200

> which at least two remain outstanding, and which the authors do not wish

I had a conversation with them at the last IETF and voiced similar concerns. 
While I mostly agree with you (comments on details in line) I'm not sure how 
serious they are for practical deployment of this stuff.

> reason why the authors chose to segregate the NSDB from the rest of the

It is quite possible (and I explained how in Stockholm) to redesign the 
searches to remove all of these requirements.

However I'm not sure anyone will ever deploy NSDB along with any other
directory information anyway because NSDB requires read access to all
data in the subtree. I've found that most directory admins can't manage
access rights and asking them to stick a large dataset in their systems 
with public access is like asking a DNS admin to add a RR for which there is 
no GUI in the admin tool. The result is consternation at best.

I believe that practically speaking NSDB will run on dedicated directory 
servers administrated separately from other directory servers in the
enterprise no matter how hard you try and I don't see how that is 
such a big problem...

Having said that I do agree with the technical points you make.

> at the application layer!

Well yes but since you can't "lock" a name you can't first figure out which
name to give your new entry and then go away and create it - unless you
depend on extensions for transaction-like grouping of operations in LDAP.

Personally I think its fine to say MUST be unique and suggest (in an 
implementation note) how you can achieve uniqueness using UUIDs.

> have a chance to review this document and review my concerns.

I think gross misuse is an overstatement. Do they use LDAP the way a
normal identity-oriented directory does? Nope. Will that be the end of
the world as we know it? Probably not.

Let me emphasise that I mostly agree with your points and that I've 
explained how to avoid some of these issues to the authors. My 
impression is that if there are good reasons to redesign the spec then
the authors would do that. They don't strike me as unreasonable.

The problem is that I can't really see how a redesign will have a 
significant impact on the real-world deployment of this or (conversely) 
how this spec fundamentally hurts LDAP. I would love to be wrong about
this though!

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 10 Sep 2009 11:52:40 -0500

> serious they are for practical deployment of this stuff.

They are.  I spoke to one of them yesterday, and will speak to the rest
today, and I understand better why they made some of their design
choices.  For example: the objects they have are all named from UUIDs,
and represent nothing special, access wise, so that letting anonymous
principals read them is perfectly reasonable.  And for publishing the
only control needed is a resource consumption control.  There's not much
benefit to re-using an existing directory infrastructure then, not
beyond the hardware (and software license) re-use aspect.

But I still think that the model should allow for re-use of existing
directory infrastructure.  After talking to one of them about it I've
concluded that mostly that would just mean that their "NSDB name"
attribute (fedfsNsdbName) needs to track not just the name of the NSDB,
but also a base DN for it.

That's another thing, the NSDB name is just a hostname; it's expected
to have multiple A RRs if there are multiple NSDB servers.  An SRV RR
would be better, but it's not clear how to name it: a domain could
have more than one distinct NSDB, which means that simply naming the SRV
RR something like _nsdb._ldap._tcp.<domainname> wouldn't work.

> searches to remove all of these requirements.

Yes, but it should be possible to avoid an extensive redesign.

Allowing arbitrary DN suffixes is just a matter of adding an attribute
to FSNs and to junctions (which are a server-local concept, without an
NSDB object class to represent them) to track the base DN of the NSDB.
I think that'd be sufficient.

Fileservers store {UUID, NSDB name} in their 'junctions'.  They'd have
to store {UUID, NSDB name, NSDB base DN} to allow for arbitrary base
DNs.  To avoid the use of UUIDs, scope=one and o=fedfs container,
fileservers would have to store {FSN DN, NSDB name} or {FSN RDN, NSDB
name, NSDB base DN}.  It might be too late to change from using UUIDs to
name FSNs, in which case, for uniqueness, one would want all FSNs in one
container, so it may not be possible to remove the o=fedfs requirement,
but we might still be able to get an NSDB base DN attribute added to the
mix.

> no GUI in the admin tool. The result is consternation at best.

Interesting.  Of course, some directory servers make it trivial to setup
inherittable ACLs so the right thing happens...

> enterprise no matter how hard you try and I don't see how that is 

Interesting.  Well, I may well just give then.

> Having said that I do agree with the technical points you make.

Well, if no one would ever want to deploy NSDBs in existing directory
infrastructure, then my technical points would be rendered irrelevant.
Don't you agree?

If so then I would withdraw all my complaints.

> depend on extensions for transaction-like grouping of operations in LDAP.

LDAP is supposed to ensure DN uniqueness atomically, is it not?

You'd create the FSLs first, then the creat/update FSNs to refer to the
FSLs.

> the world as we know it? Probably not.

Now that I understand the federated FS proposal better I agree.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 11 Sep 2009 10:01:45 +0200

> LDAP is supposed to ensure DN uniqueness atomically, is it not?

Yes but only in a single operation. I suspect (but I may be wrong) that 
several of the logical operations they need to perform would need to
span multiple LDAP operations creating race conditions on the name.

> You'd create the FSLs first, then the creat/update FSNs to refer to the

That might work unless a semi-populated FSL entry is dangerous. 

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Sep 2009 12:03:26 -0500

> span multiple LDAP operations creating race conditions on the name.

I think they do not.

> That might work unless a semi-populated FSL entry is dangerous. 

An FSL alone is utterly useless and harmless.  An FSN alone too is
utterly useless.  It's only when junctions (which are local to servers)
refer to FSNs, which in turn refer to FSLs, that FSNs and FSLs matter.

Incidentaly the elephant in the I-D that wasn't specifically called out,
but which should have been, is that references to FSNs must be small and
fixed sized.  By using {UUID, NSDB hostname} they were able to keep
references very small: 16 + 256 bytes, or if you intern the NSDB
hostnames, possibly as small as 20 bytes.  This was crucial to my
understanding of the design :(