[Federated-fs] FedFS Meeting Minutes, 10/2/2008

[James Lentini]

FedFS Meeting Minutes, 10/2/2008
--------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Manoj Naik (IBM/ARC)
Renu Tewari (IBM/ARC)

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 weeks meeting with this announcement.

+ NFSv4 WG publication

  The 4 FedFS drafts were published last Friday as NFSv4 working 
  group documents. The documents are now linked from the NFSv4 
  working group charter website.

  Ideally, someone new will not stumble upon the old individual 
  drafts by accident. 

  Dan Ellard noted the old individual drafts could be re-published 
  with text that pointed to the new documents.

  [AI] James Lentini will research how to deprecate the old 
       individuals drafts.

+ Decommission SDSC mailing list?

  James and Dan noted that managing the fedfs list at SDSC can be 
  a pain.

  Some people have observed duplicate emails and delayed delivery of
  email on the SDSC list.

  Do we want an exclusive list for fedfs or is it ok to mix in with 
  the NFSv4 mailing list?

  We concluded that moving to the NFSv4 mailing list would be best because:
  - Spencer recommended we move our discussions to the NFSv4 mailing list
    https://lists.sdsc.edu/pipermail/federated-fs/2008-September/000213.html
  - there is not much traffic on the fedfs mailing list, therefore we won't
    drowned out discussions on the NFSv4 mailing list
  - SDSC isn't participating in fedfs anymore. Using their facilities to host
    the mailing list may be awkward in the future if they need to bring the 
    server hosting the list down for maintenance, etc.

  [AI] James Lentini will send message to fedfs list notifying subscribers that 
       the fedfs list will be deprecated and instructing people to switch to 
       the NFSv4 list.

  We will keep the SDSC list intact for a reasonable period of time (6 months) 
  so people can switch.

  We will preserve the archives.

  We will send meeting invites and minutes to the SDSC list for the next two
  meetings to give everyone time to switch over.

+ security considerations and requirements

  Our approach has been to divide up the different steps of the protocol and 
  show that each step can be made trustworthy.

  To ensure that the entire process is secure is not possible. What we can
  show is that if good information is entered into the NSDB by an
  administrator, then the client will receive good information. If the administrator 
  enters bad information, then the client will receive bad information.

  In other words, garbage in garbage out.

  The NFSv4 draft recommends how referrals should be protected.

  The DNS SRV draft discusses how the DNS queries can be protected.

  The NSDB draft notes that the existing security facilities in NFSv4 and LDAP
  can be applied to 

  We then discussed ways in which these guarantees could be extended: 

  Would it be possible to authenticate the data end-to-end?

  In other words, would it be possible for the client to check that the 
  referral information was entered by the NSDB?

  Could the fileserver check the authenticity of NSDB information?

  Could the NSDB information be signed?

  The fileserver to NSDB will use TLS. This does not authenticate the entries, 
  it only authenticates that the entry information is coming from the NSDB.

  If the NSDB is caching entries from other NSDBs, then it would be good to have
  provenance to authenticate. At this point, we do not have a mechanism for 
  allowing NSDB's to cache information. If this feature is added in the
  future, we need to consider the security implications.

  Q. If a file server refers a client to an untrusted file server, do we care
     that the untrusted file server can generate a bad referral?
  A. Once you are on a compromised server, anything is possible. A bad
     referral is probably the last thing one needs to worry about.

  From the client's perspective, the federation looks like a big volume. We
  should ensure that the client is no more likely to get bad data using the 
  federation than if the client were using plain old NFS.

+ root fileset, particularly the issue of one root NSDB versus multiple root NSDBs

  This was a recap of last weeks discussion. We reviewed the idea of having one 
  primary root NSDB. With this approach, there is no longer need to synchronize updates
  between multiple NSDBs since there is only one master.

  This is different from the earlier approach that there would be a set of root NSDBs.

  Do we need to address the Global/inter-enterprise use case? 

  If we choose to do one approach now, does that mean we can't do something more
  general later? Could we use the intra-enterprise federation as a building block?

  The idea is to build the infrastructure for creating intra-enterprise
  federations and use this as a building block for inter-enterprise
  federations.

  James noted that the design we are moving towards looks a lot like DNS.
  The root of the namespace is managed by a set of trusted administrators who 
  delegate control of subsets of the namespace to other administrative
  domains.

Next week:
 - Root fileset Schema