draft-ietf-nfsv4-multi-domain-fs-reqs-00.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-01.txt 
NFSv4 Working Group W. Adamson NFSv4 Working Group W. Adamson
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: April 26, 2015 Cryptonector Expires: July 27, 2015 Cryptonector
October 23, 2014 January 23, 2015
Multiple NFSv4 Domain File System Requirements Multiple NFSv4 Domain Namespace Deployment Guidelines
draft-ietf-nfsv4-multi-domain-fs-reqs-00 draft-ietf-nfsv4-multi-domain-fs-reqs-01
Abstract Abstract
This document describes constraints to the NFSv4.0 and NFSv4.1 This document describes administrative constraints to the deployment
protocols as well as the use of multi-domain capable file systems, of the NFSv4 protocols required for the construction of an NFSv4 file
name resolution services, and security services required to fully system namespace supporting the use of multiple NFSv4 domains and
enable a multiple NFSv4 domain file system, such as a multiple NFSv4 utilizing multi-domain capable file systems. Also described are
domain Federated File System. administrative constraints to name resolution and security services
appropriate to such a system. Such a namespace is a suitable way to
enable a Federated File System supporting the use of multiple NFSv4
domains.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 41 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2015. This Internet-Draft will expire on July 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 4 3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 4
4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5
4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6
4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6
4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 6 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7
5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8
5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 8 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 9
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9 5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9
5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 9 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10
6. Resolving Multi-domain Authorization Information . . . . . . 10 6. Resolving Multi-domain Authorization Information . . . . . . 10
7. Stand-alone Examples and Multi NFSv4 Domain FedFS . . . . . . 11 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
An NFSv4 domain is defined as a set of users, groups and computers An NFSv4 domain is defined as a set of users, groups and computers
running NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661] running NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661]
(hereafter referred to as NFSv4) protocols identified by an NFSv4 (hereafter referred to as NFSv4) protocols identified by an NFSv4
domain name. domain name.
The Federated File System (FedFS) [RFC5716] describes the The Federated File System (FedFS) [RFC5716] describes the
skipping to change at page 3, line 15 skipping to change at page 3, line 21
Stand-alone NFSv4 domains can be run in many ways. While a FedFS can Stand-alone NFSv4 domains can be run in many ways. While a FedFS can
be run within all stand-alone NFSv4 domain configurations some of be run within all stand-alone NFSv4 domain configurations some of
these configurations (Section 4) are not compatible with joining a these configurations (Section 4) are not compatible with joining a
multiple NFSv4 domain FedFS namespace. multiple NFSv4 domain FedFS namespace.
Multi NFSv4 domain file systems require support for global identities Multi NFSv4 domain file systems require support for global identities
in name services, security services, and in the exporting of on-disk in name services, security services, and in the exporting of on-disk
local identity representation. Many of the stand-alone NFSv4 domain local identity representation. Many of the stand-alone NFSv4 domain
deployments do not provide full support for global identities. deployments do not provide full support for global identities.
This document describes constraints to the NFSv4 protocols as well as This document describes administrative constraints to the deployment
the use of multi-domain capable file systems, name resolution of the NFSv4 protocols required for the construction of an NFSv4 file
services, and security services required to fully enable a multiple system namespace supporting the use of multiple NFSv4 domains and
NFSv4 domain file system, such as a multiple NFSv4 domain FedFS. utilizing multi-domain capable file systems. Also described are
administrative constraints to name resolution and security services
appropriate to such a system. Such a namespace is a suitable way to
enable a Federated File System supporting the use of multiple NFSv4
domains.
2. Terminology 2. Terminology
Name Service: provides the mapping between {NFSv4 domain, group or Name Service: provides the mapping between {NFSv4 domain, group or
user name} and {NFSv4 domain, local ID}, as well as the mapping user name} and {NFSv4 domain, local ID}, as well as the mapping
between {security principal} and {NFSv4 domain, local ID} via between {security principal} and {NFSv4 domain, local ID} via
lookups. Can be applied to local or remote domains. Often lookups. Can be applied to local or remote domains. Often
provided by a Directory Service such as LDAP. provided by a Directory Service such as LDAP.
Domain: This term is used in multiple contexts where it has Domain: This term is used in multiple contexts where it has
skipping to change at page 3, line 47 skipping to change at page 4, line 8
running a single security protocol and administered by a single running a single security protocol and administered by a single
entity, for example a Kerberos realm. entity, for example a Kerberos realm.
NFSv4 domain: a set of users, groups, and computers running NFSv4 domain: a set of users, groups, and computers running
NFSv4 protocols identified by a unique NFSv4 domain name. See NFSv4 protocols identified by a unique NFSv4 domain name. See
[RFC5661] Section 5.9 "Interpreting owner and owner_group". [RFC5661] Section 5.9 "Interpreting owner and owner_group".
Multi-domain: In this document this always refers to multiple Multi-domain: In this document this always refers to multiple
NFSv4 domains. NFSv4 domains.
FedFS domain: A file name space that can cross multiple shares FedFS domain: A file namespace that can cross multiple shares
on multiple file servers using file-access protocols such as on multiple file servers using file-access protocols such as
NFSv4. A FedFS domain is typically a single administrative NFSv4. A FedFS domain is typically a single administrative
entity, and has a name that is similar to a DNS domain name. entity, and has a name that is similar to a DNS domain name.
Also known as a Federation. Also known as a Federation.
Administrative domain: a set of users, groups, computers, and Administrative domain: a set of users, groups, computers, and
services administered by a single entity. Can include multiple services administered by a single entity. Can include multiple
DNS domains, NFSv4 domains, security domains, and FedFS DNS domains, NFSv4 domains, security domains, and FedFS
domains. domains.
skipping to change at page 8, line 20 skipping to change at page 8, line 32
the @REALM is used, then the domain portion of name@domain can be the @REALM is used, then the domain portion of name@domain can be
ignored, and even be different for each client and server in the ignored, and even be different for each client and server in the
domain. domain.
5.1.1. NFSv4 Domain and DNS Services 5.1.1. NFSv4 Domain and DNS Services
Here we address the relationship between NFSv4 domain name and DNS Here we address the relationship between NFSv4 domain name and DNS
domain name in a multiple NFSv4 domain deployment. domain name in a multiple NFSv4 domain deployment.
The definition of an NFSv4 domain name needs clarification to work in The definition of an NFSv4 domain name needs clarification to work in
a multiple NFSv4 domain file system name space. Section 5.9 a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661]
[RFC5661] loosely defines the NFSv4 domain name as a DNS domain name. loosely defines the NFSv4 domain name as a DNS domain name. This
This loose definition for the NFSv4 domain is a good one, as DNS loose definition for the NFSv4 domain is a good one, as DNS domain
domain names are globally unique. As noted above in Section 5.1, any names are globally unique. As noted above in Section 5.1, any choice
choice of NFSv4 domain name can work within a stand-alone NFSv4 of NFSv4 domain name can work within a stand-alone NFSv4 domain
domain deployment whereas the NFSv4 domain is required to be unique deployment whereas the NFSv4 domain is required to be unique in a
in a multiple NFSv4 domain deployment. multiple NFSv4 domain deployment.
A typical configuration is that there is a single NFSv4 domain that A typical configuration is that there is a single NFSv4 domain that
is served by a single DNS domain. In this case the NFSv4 domain name is served by a single DNS domain. In this case the NFSv4 domain name
can be the same as the DNS domain name. can be the same as the DNS domain name.
An NFSv4 domain can span multiple DNS domains. In this case, one of An NFSv4 domain can span multiple DNS domains. In this case, one of
the DNS domain names can be chosen as the NFSv4 domain name. the DNS domain names can be chosen as the NFSv4 domain name.
Multiple NFSv4 domains can also share a DNS domain. In this case, Multiple NFSv4 domains can also share a DNS domain. In this case,
only one of the NFSv4 domains can use the DNS domain name, the other only one of the NFSv4 domains can use the DNS domain name, the other
NFSv4 domains must choose another unique NFSv4 domain name. NFSv4 domains must choose another unique NFSv4 domain name.
5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems
As noted above in Section 5.1, each name@domain is unique across the As noted above in Section 5.1, each name@domain is unique across the
multiple NFSv4 domain namespace, and maps to a local representation multiple NFSv4 domain namespace, and maps to a local representation
of ID in each NFSv4 domain. This means that each NFSv4 domain has a of ID in each NFSv4 domain. This means that each NFSv4 domain has a
single name resolution service exporting the NFSv4 domain local ID single name resolution service exporting the NFSv4 domain local ID
name space. namespace.
An NFSv4 domain administrator that wants to give NFSv4 local file An NFSv4 domain administrator that wants to give NFSv4 local file
access to a remote user from a remote NFSv4 domain needs to create a access to a remote user from a remote NFSv4 domain needs to create a
local ID for the remote user which can then be assigned on-disk and local ID for the remote user which can then be assigned on-disk and
used for local access decisions. Since the local ID for the remote used for local access decisions. Since the local ID for the remote
user must be able to be mapped to a name@remote-domain, only multi- user must be able to be mapped to a name@remote-domain, only multi-
domain capable file systems can be exported in a multiple NFSv4 domain capable file systems can be exported in a multiple NFSv4
domain FedFS. domain namespace.
We note that many file systems exported by NFSv4 use 32 bit POSIX UID We note that many file systems exported by NFSv4 use 32 bit POSIX UID
and GIDs as a local ID form and as this local ID form has no domain and GIDs as a local ID form and as this local ID form has no domain
component, these file systems are not domain aware and can not component, these file systems are not domain aware and can not
participate in a multiple NFSv4 domain FedFS. There are ways to participate in a multiple NFSv4 domain namespace. There are ways to
overcome this deficiency, but these practices are beyond the scope of overcome this deficiency, but these practices are beyond the scope of
this document. this document.
5.2. RPC Security Constraints 5.2. RPC Security Constraints
As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors":
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. NFSv4.1 clients and servers MUST implement RPCSEC_GSS.
(This requirement to implement is not a requirement (This requirement to implement is not a requirement
to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS,
MAY be implemented as well. MAY be implemented as well.
The underlying RPCSEC_GSS security mechanism used in a multiple NFSv4 The underlying RPCSEC_GSS security mechanism used in a multiple NFSv4
domain FedFS is REQUIRED to employ a method of cross NFSv4 domain domain namespace is REQUIRED to employ a method of cross NFSv4 domain
trust so that a principal from a security service in one NFSv4 domain trust so that a principal from a security service in one NFSv4 domain
can be authenticated in another NFSv4 domain that uses a security can be authenticated in another NFSv4 domain that uses a security
service with the same security mechanism. Kerberos, and PKU2U service with the same security mechanism. Kerberos, and PKU2U
[I-D.zhu-pku2u] are examples of such security services. [I-D.zhu-pku2u] are examples of such security services.
The AUTH_NONE security flavor can be useful in a multiple NFSv4 The AUTH_NONE security flavor can be useful in a multiple NFSv4
domain FedFS to grant universal access to public data without any domain namespace to grant universal access to public data without any
credentials. credentials.
The AUTH_SYS security flavor uses a host-based authentication model The AUTH_SYS security flavor uses a host-based authentication model
where the weakly authenticated host (the NFSv4 client) asserts the where the weakly authenticated host (the NFSv4 client) asserts the
user's authorization identities using small integers, uidNumber, and user's authorization identities using small integers, uidNumber, and
gidNumber [RFC2307], as user and group identity representations. gidNumber [RFC2307], as user and group identity representations.
Because this authorization ID representation has no domain component, Because this authorization ID representation has no domain component,
AUTH_SYS can only be used in a name space where all NFSv4 clients and AUTH_SYS can only be used in a namespace where all NFSv4 clients and
servers share an [RFC2307] name service. A shared name service is servers share an [RFC2307] name service. A shared name service is
required because uidNumbers and gidNumbers are passed in the RPC required because uidNumbers and gidNumbers are passed in the RPC
credential; there is no negotiation of namespace in AUTH_SYS. credential; there is no negotiation of namespace in AUTH_SYS.
Collisions can occur if multiple name services are used, so AUTH_SYS Collisions can occur if multiple name services are used, so AUTH_SYS
MUST NOT be used in a multiple NFSv4 domain file system. MUST NOT be used in a multiple NFSv4 domain file system.
5.2.1. NFSv4 Domain and Security Services 5.2.1. NFSv4 Domain and Security Services
As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4
domain security services are RPCSEC_GSS based with the Kerberos 5 domain security services are RPCSEC_GSS based with the Kerberos 5
skipping to change at page 11, line 25 skipping to change at page 11, line 39
presented to the NFSv4 server is in the same form as a query for presented to the NFSv4 server is in the same form as a query for
a local principal. a local principal.
3. An authenticated direct query from the NFSv4 server to the 3. An authenticated direct query from the NFSv4 server to the
principal's NFSv4 domain authoritative name service. This principal's NFSv4 domain authoritative name service. This
requires the NFSv4 server to have detailed knowledge of the requires the NFSv4 server to have detailed knowledge of the
remote NFSv4 domain's authoritative name service and detailed remote NFSv4 domain's authoritative name service and detailed
knowledge of the syntax of the resultant authorization context knowledge of the syntax of the resultant authorization context
information. information.
7. Stand-alone Examples and Multi NFSv4 Domain FedFS 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces
Revisiting the stand-alone (Section 4) NFSv4 domain deployment Revisiting the stand-alone (Section 4) NFSv4 domain deployment
examples, we note that due to the use of AUTH_SYS, neither examples, we note that due to the use of AUTH_SYS, neither
Section 4.1 nor Section 4.2 configurations are suitable for multiple Section 4.1 nor Section 4.2 configurations are suitable for multiple
NFSv4 domain deployments. NFSv4 domain deployments.
The Section 4.3 configuration example can participate in a multiple The Section 4.3 configuration example can participate in a multiple
NFSv4 domain FedFS deployment if: NFSv4 domain namespace deployment if:
o The NFSv4 domain name is unique across the FedFS. o The NFSv4 domain name is unique across the namespace.
o All exported file systems are multi-domain capable. o All exported file systems are multi-domain capable.
o A secure method is used to resolve remote NFSv4 domain principals o A secure method is used to resolve remote NFSv4 domain principals
authorization information from an authoritative source. authorization information from an authoritative source.
8. Security Considerations 8. Security Considerations
There are no security considerations introduced by this document There are no security considerations introduced by this document
beyond those described in NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and beyond those described in NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and
skipping to change at page 12, line 51 skipping to change at page 13, line 14
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716, Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010. January 2010.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Andy Adamson would like to thank NetApp, Inc. for its funding of his Andy Adamson would like to thank NetApp, Inc. for its funding of his
time on this project. time on this project.
We thank Chuck Lever, Tom Haynes, Brian Reitz, and Bruce Fields for We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and
their review. David Noveck for their review.
Authors' Addresses Authors' Addresses
William A. (Andy) Adamson William A. (Andy) Adamson
NetApp NetApp
Email: andros@netapp.com Email: andros@netapp.com
Nicolas Williams Nicolas Williams
Cryptonector Cryptonector
 End of changes. 23 change blocks. 
40 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/