Skip to main content

Last Call Review of draft-ietf-nfsv4-federated-fs-reqts-
review-ietf-nfsv4-federated-fs-reqts-secdir-lc-williams-2009-10-03-00

Request Review of draft-ietf-nfsv4-federated-fs-reqts
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-25
Requested 2009-09-10
Authors Daniel Ellard , James Lentini , Craig Everhart , Renu Tewari , Manoj Naik
I-D last updated 2009-10-03
Completed reviews Secdir Last Call review of -?? by Nicolás Williams
Assignment Reviewer Nicolás Williams
State Completed
Request Last Call review on draft-ietf-nfsv4-federated-fs-reqts by Security Area Directorate Assigned
Completed 2009-10-03
review-ietf-nfsv4-federated-fs-reqts-secdir-lc-williams-2009-10-03-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes the notion of "federated filesystem namespace"
and requirements for specifications of an actual set of federated
filesystem namespace components and even some requirements of actual
implementations.

A federated namespace is one where multiple filesystems (or, rather,
"filesets") are put together into a larger filesystem-like namespace,
but where the various filesystems involved can be owned and administered
by widely varying entities.

Authorization issues arise when filesystems migrate, and these are
neatly resolved in the federated namespace concept by separating the
location of references to filesystems from the location of fileset
location information.  References to filesets ("junctions") live in
actual filesystem (think of a magic symlink or "shortcut").  Fileset
location information lives in a directory whose name is part of the
fileset's name as referenced by any junction that refers to it.

Authorization of junction administration is a matter local to the
filesystems where the junctions live.  Authorization of fileset location
administration is a matter local to the directory where the fileset
location information is published.

There is one more level of separation as well, to allow for filesets
with replicas owned and administered by different entities.  "Fileset
names" (FSNs) refer to directory objects which in turn refer to "fileset
location" objects (FSLs); both, FSNs and FSLs include the name of the
containing directory in their canonical name forms.

The document does not describe the authorization separation involved.
And though it isn't strictly necessary, I believe that it would be
beneficial to have such a description.

The document also does not clearly explain that junctions are not
published in any directory, which confused me greatly at first, as in my
opinion publishing FSN and FSL objects does not make the directories in
which they are published "namespace databases" (NSDBs).  This is not a
security concern, of course.

The document also does not explain that FSNs are intended to be small,
even fixed sized, or with highly compressible variable size portions[*].
But a moment's thought about filesystem designs quickly reveals that
such a requirement is important.  In my opinion such a requirement
should be documented.  This too is not a security concern.

The Security Considerations section is a bit skimpy.  Its claims are
correct in my opinion.  I would, however, add to it the following:

 - A note that the federated namespace concept helps distribute
   responsibility for authorization (a very good thing).

 - A note that orphaned FSNs and FSLs cannot be easily distinguished
   from ones referenced by junctions and FSNs, respectively.  Therefore
   objects will tend to pile up.  This is a resource consumption
   consideration.  Resource control issues are, IMO, a security
   consideration.

Finally, I'm not sure if it's worth saying anything about the fact that
with the NSDB choice being up to the FSN and FSL publishers, there can
be a plethora of NSDBs in a federation, which brings scalability of
distributed authentication and trust into the picture.  For example,
consider an NSDB that uses TLS and a self-signed server certificate to
authenticate itself, then a fingerprint of the certificate will have to
be part and parcel of the FSN/FSL names stored by junctions/FSNs
(respectively).  A PKI would help, of course, but in a sufficiently
large federation it may be necessary to have multiple trust anchors,
rather than a single PKI root, which brings TA administration issues
into the picture.  This is really nothing new, and so perhaps not worth
noting, but the potential for having to store, and the consequences
thereof, FSN NSDB authentication information in junctions, and FSL NSDB
authentication information in FSNs, does seem to me to be worth noting.

[*] For example, assuming many FSNs but relatively few NSDBs, filesystem
    implementors could choose store FSNs as {reference to NSDB name, FSN
    object name relative to NSDB}.  If the second item of the tuple is
    itself fixed-sized then the whole tuple can be fixed sized.  A table
    of {NSDB name, reference} would be needed too, but it may be
    critical to keep "inodes" fixed-sized, with little wastage, in which
    case "interning" NSDB names as described above is a sufficient
    compression technique.

    In fact, draft-ietf-nfsv4-federated-fs-protocol-03 does use UUIDs
    for naming FSNs and FSLs, so that the above technique is certainly a
    feasible way to keep inodes fixed-sized in spite of the fact that
    FSNs are actually variable sized (the NSDB name where the FSN
    resides is part of the FSN's name).

Nico
--