[nfsv4] [FedFS] Meeting Minutes, 12/03/2009

[James Lentini <[e-mail]>]

FedFS Meeting Minutes, 12/03/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (EMC)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - Chris Stacey will writeup a description of an SNMP MIB.

    Complete.

    Chris summarized our discussions over that past few weeks in an 
    email to the list. Chris summarized the genesis of the idea 
    standardizing statistics, asked if this was within the scope 
    of the NFSv4 WG, and asked for feedback on how to approach the 
    problem.

    Chris is going to chat with his colleagues about SMI-S. Sorin 
    is going to investigate the SNMP MIB.

+ Mailing List Questions

  We discussed Paul's mailing list questions.

  - NFS URL

    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL 
    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS. 

    This was not the type of NFS URL Paul was asking about.

    Trond noted the NFSv4 has a public filehandle concept, but the 
    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is 
    different from WebNFS.

    We discussed the difference between a fileserver's namespace and a 
    federated namespace. An NFSv4 fileserver has a / pseudo root directory.  
    Such a fileserver may also host the root of a federated namespace. For 
    example, the federated namespace root for example.net would be located at 
    /.domain-root-example.net on an NFSv4 fileserver. 

    A fileserver's pseudo root and federated namespace root are intentionally 
    different. This allows for greater flexibility. A single server can be 
    the root of multiple namespaces, contain other directories, etc. 

    A junction may be present at any point beneath the federated root and 
    point to an arbitrary location (the target of a junction does not need 
    to be beneath /.domain-root-example.net).

  - Client Processing of an NFS SRV RR 
    (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)

    To mount a federated namespace, say example.net's namespace, the NFS client 
    will look up the NFS SRV record at_nfs4._write._domainroot._tcp.example.net
    in DNS (assuming the client wants a read/write view of the namespace).
    The SRV record will have one or more host names implementing the service
    (e.g. nfs1tr.example.net).

    The NFS client will then mount nfs1tr.example.net://.domain-root-example.net 
    at /nfs4/example.net in the client's local namespace.

    Craig noted that there were two ways of naming a particular point. 
    There is the traditional way, server://path/to/file, and a new 
    SRV based name, roughly <domain> + <federated namespace path>.

    Paul speculated that the behavior of the OS mount command could be updated
    to incorporate the federated naming. In particular, he wondered if the 
    mount command would take a domain and mount the domain's federated root. 

    We noted that an OS mount command could be augmented to include the 
    process of (1) mapping from a domain to an SRV query string, 
    (2) performing the SRV query and extracting the host fileservers running 
    the service, and (3) mounting the fileserver + ".domain-root-<domain>" 
    path. Another option would be to perform steps (1) and (2) separately 
    and then input the result into the standard mount command.

+ Admin NSDB Trust Anchor Management

  We briefly reviewed the mechanisms by which LDAP can be secured. LDAP 
  connections can be secured using TLC or SASL. [Editor's note see RFC4513].

  We discussed the following question who or what determines if a fileserver's
  NSDB connections are secure. We asked if the ONC RPC Administrative protocol 
  should indicate, possibly at junction create time, the desired security 
  properties to use for an FSN's resolution.

  There are at least three different ways the security properties of an NSDB 
  connection could be derived: (1) each implementation could have its own 
  policy and settings, (2) the ONC RPC Admin protocol could indicate the 
  desired security mechanism, or (3) the NSDB could require a particular 
  security mechanism.

  We reviewed some of the advantages and disadvantages of these options.

  Trond asked if there was a standard way for LDAP to indicate the required 
  level of security. If so, it could be used as an auto configuration 
  mechanism. James noted that there are ways for a user to indicate to 
  an LDAP client that a security mechanism should be used (ldap:// versus
  ldaps:// to request standard versus SSL/TLS connections respectively or 
  the various SASL configuration settings). James was not aware of any 
  way to automatically determine if an LDAP directory should be contacted 
  via TLS, SASL, etc. 

  [AI] James Lentini will investigate if an LDAP client can automatically 
       determine the security properties of an LDAP directory.

  James suggested that it could be dangerous for a fileserver to depend 
  totally on an NSDB for indicating the security mechanism for an LDAP 
  connection. For example, a impostor might setup a rogue NSDB that 
  indicated no security was necessary (and hence the NSDB did not need to 
  be authenticated).

  We discussed the security properties desired for an NSDB connection.
  If security is a concern, the fileserver will want to authenticate the 
  identity of the NSDB and have protect the integrity of the LDAP connection. 
  Privacy did not stand out as a concern on the call. [editor's note: while 
  writing up these notes, I realized that privacy is also desirable. The 
  contents of an FSL, for example the path name, may convey information 
  that the federation members which to keep private].

  James suggested that the fileserver administrator would have a 
  vested interest in ensuring that the fileserver's referrals were 
  valid. Therefore, the administrator will want the ability to 
  configure the security properties used to resolve an FSN.

  Trond pointed out that the fileserver must be able to query the NSDB 
  over a long period of time. This leads inevitably to the topic of 
  key/certificate management.

  [time - we plan to continue discussing this topic on the WG email 
   list and at next week's meeting]