--- 1/draft-ietf-nfsv4-federated-fs-reqts-04.txt 2009-10-16 17:12:10.000000000 +0200 +++ 2/draft-ietf-nfsv4-federated-fs-reqts-05.txt 2009-10-16 17:12:10.000000000 +0200 @@ -1,23 +1,23 @@ NFSv4 Working Group J. Lentini Internet-Draft C. Everhart Intended status: Informational NetApp -Expires: April 4, 2010 D. Ellard +Expires: April 19, 2010 D. Ellard BBN Technologies R. Tewari M. Naik IBM Almaden - October 1, 2009 + October 16, 2009 Requirements for Federated File Systems - draft-ietf-nfsv4-federated-fs-reqts-04 + draft-ietf-nfsv4-federated-fs-reqts-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -36,21 +36,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 4, 2010. + This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. @@ -84,23 +84,23 @@ 3.3. Junction Creation . . . . . . . . . . . . . . . . . . . . 11 4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Proposed Requirements . . . . . . . . . . . . . . . . . . . . 16 5.1. Basic Assumptions . . . . . . . . . . . . . . . . . . . . 16 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 6. Non-Requirements . . . . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 - 9.2. Informational References . . . . . . . . . . . . . . . . . 29 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9.2. Informational References . . . . . . . . . . . . . . . . . 30 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Overview This document describes and lists the functional requirements of a federated file system and defines related terms. We do not describe the mechanisms that might be used to implement this functionality except in cases where specific mechanisms, in our opinion, follow inevitably from the requirements. Our focus is on the interfaces between the entities of the system, not on the @@ -122,21 +122,23 @@ called an "FSN" (fileset name), and each physical filesystem has a fileset location ("FSL"). A fileset is a directory tree containing files and directories, and it may also contain references to other filesets. These references are called "junctions". To provide location independence, a junction does not contain information about the location of the real resource(s), but instead contains an FSN that can be used to look up the location information. The service that can be used to map from FSN to FSL(s) is called a namespace database (NSDB) service. The NSDB provides a level of indirection from the virtual paths in the uniform namespace to the actual - locations of files. + locations of files. By design, the NSDB does not store the + junctions. This allows junction administration and NSDB + administration to be separate roles. The servers direct clients to the proper locations by existing mechanisms (e.g. the referrals mechanism within [RFC3530] and [NFSv4.1]). Updates to the locations make it possible to support migration and replication of physical filesystems that comprise the namespace, in a way that is transparent to filesystem applications. Figure 1 shows an example of a federation. This federation has two members, named ALPHA and BETA. Federation members may contain an arbitrary number of file servers and NSDB nodes; in this illustration @@ -429,21 +431,21 @@ same. Junction: A filesystem object used to link a directory name in the current fileset with an object within another fileset. The server-side "link" from a leaf node in one fileset to the root of another fileset. Namespace: A filename/directory tree that a sufficiently-authorized client can observe. - NSDB (Namespace Database Service): A service that maps FSNs to FSLs. + NSDB (Namespace Database) Service: A service that maps FSNs to FSLs. The NSDB may also be used to store other information, such as annotations for these mappings and their components. NSDB Node: The name or location of a server that implements part of the NSDB service and is responsible for keeping track of the FSLs (and related info) that implement a given partition of the FSNs. Referral: A server response to a client access that directs the client to evaluate the current object as a reference to an object at a different location (specified by an FSL) in another fileset, @@ -637,20 +639,27 @@ to FSL(s) change under these transformations. d. All files accessible from the global namespace MUST be part of a fileset that has an assigned FSN. Not all filesets in the federation are required to have an FSN or be reachable by an FSL. Only those filesets that are the target of a junction (as described in R3) are required to have an FSN. + The FSN format MAY be variable size. If the format is variable + size, fileserver implementations MAY have a maximum supported + FSN size. By bounding the FSN size, some fileserver + implementations might be able to efficiently organize FSNs in + stable storage. For interoperability, the federation protocols + SHOULD define an FSN size that all fileservers support. + R2: USING THE FEDERATION INTERFACES, it MUST be possible to create an FSN for a fileset, and it must be possible to bind an FSL to that FSN. These operations are NSDB operations and do not require any action on the part of a file server. It is possible to create an FSN for a fileset that has not actually been created. It is also possible to bind a nonexistent FSL to an FSN. It is also possible to create a fileset without assigning it an FSN. The binding between an FSN and an FSL is defined entirely within the context of the @@ -966,20 +975,41 @@ Well-established techniques for providing authenticated channels may be used to defeat these attacks, and the protocol MUST support at least one of them. For example, if LDAP is used to implement the query mechanism [RFC4510], then TLS may be used to provide both authentication and integrity [RFC5246] [RFC4513]. If the query protocol is implemented on top of ONC/RPC, then RPCSEC_GSS may be used to fill the same role [RFC2203] [RFC2743]. + A federation could contain multiple Public Key Infrastructure (PKI) + trust anchors [RFC5280]. The federation protocols SHOULD define a + mechanism for managing a fileserver's NSDB trust anchors + [TA-MGMT-REQS]. A general purpose trust anchor management protocol + [TAMP] would be appropriate, though it might be desirable for the + federation protocols to facilitate trust anchor management by, for + example, using trust anchor interchange formats [TA-FORMAT]. + + It is useful to note that the requirements described in this document + lead naturally to a system with distributed authorization, which has + scalability and manageability benefits. + + FSNs are likely to be long lived resources. Therefore, the privilege + to create FSNs SHOULD be carefully controlled. To assist in + determining if an FSN is referenced by a junction somewhere in the + federation, the NSDB records SHOULD include non-authoritative + informational annotations recording the locations of any such + junctions. These annotations are non-authoritative because a + junction might be created, deleted, or modified by an individual that + does not have permission to modify the NSDB records. + 8. IANA Considerations This document has no actions for IANA. 9. References 9.1. Normative References [NFSv4.1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work @@ -1010,33 +1040,55 @@ (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + 9.2. Informational References [RFC1094] Nowicki, B., "NFS: Network File System Protocol specification", RFC 1094, March 1989. [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. + [TA-FORMAT] + Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor + Format", draft-ietf-pkix-ta-format-03 (work in progress), + May 2009. + + [TA-MGMT-REQS] + Reddy, R. and C. Wallace, "Trust Anchor Management + Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in + progress), September 2009. + + [TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor + Management Protocol (TAMP)", draft-ietf-pkix-tamp-03 (work + in progress), October 2009. + Appendix A. Acknowledgments We would like to thank Robert Thurlow of Sun Microsystems for helping to author this document. + We would also like to thank Peter McCann and and Nicolas Williams for + their comments and suggestions. + Authors' Addresses James Lentini NetApp 1601 Trapelo Rd, Suite 16 Waltham, MA 02451 US Phone: +1 781-768-5359 Email: jlentini@netapp.com