draft-ietf-nfsv4-federated-fs-dns-srv-namespace-07.txt		draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt
	Network Working Group C. Everhart		Network Working Group C. Everhart
	Internet-Draft W. Adamson		Internet-Draft W. Adamson
	Intended status: Standards Track NetApp		Intended status: Standards Track NetApp
	Expires: August 27, 2011 J. Zhang		Expires: March 5, 2012 J. Zhang
	Google		Google
	February 23, 2011		September 2, 2011
	Using DNS SRV to Specify a Global File Name Space with NFS version 4		Using DNS SRV to Specify a Global File Name Space with NFS version 4
	draft-ietf-nfsv4-federated-fs-dns-srv-namespace-07.txt		draft-ietf-nfsv4-federated-fs-dns-srv-namespace-08.txt
	Abstract		Abstract
	The NFS version 4 protocol provides a natural way for a collection of		The NFS version 4 protocol provides a natural way for a collection of
	NFS file servers to collaborate in providing an organization-wide		NFS file servers to collaborate in providing an organization-wide
	file name space. The DNS SRV RR allows a simple and appropriate way		file name space. The DNS SRV RR allows a simple and appropriate way
	for an organization to publish the root of its name space, even to		for an organization to publish the root of its name space, even to
	clients that might not be intimately associated with such an		clients that might not be intimately associated with such an
	organization. The DNS SRV RR can be used to join these organization-		organization. The DNS SRV RR can be used to join these organization-
	wide file name spaces together to allow construction of a global,		wide file name spaces together to allow construction of a global,
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 August 27, 2011.		This Internet-Draft will expire on March 5, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 6, line 22		skipping to change at page 6, line 22
	successful, it mounts the indicated filesystem(s) in that name in the		successful, it mounts the indicated filesystem(s) in that name in the
	special directory. The goal is that NFSv4 applications will be able		special directory. The goal is that NFSv4 applications will be able
	to lookup an organization's domain name in the special directory, and		to lookup an organization's domain name in the special directory, and
	the NFSv4 client will be able to discover the filesystem that that		the NFSv4 client will be able to discover the filesystem that that
	organization publishes. Entries in the special directory will be		organization publishes. Entries in the special directory will be
	domain names, and they will each appear to the application as a		domain names, and they will each appear to the application as a
	directory name pointing to the root directory of the filesystem		directory name pointing to the root directory of the filesystem
	published by the organization responsible for that domain name.		published by the organization responsible for that domain name.
	This functionality does not require or use any list of organizations		This functionality does not require or use any list of organizations
	that are known to provide file service, as AFS did with its		that are known to provide file service, such as was required with the
	"root.afs" functionality.		"root.afs" functionality in AFS.
	This DNS SRV record evaluation could, in principle, be done either in		This DNS SRV record evaluation could, in principle, be done either in
	the NFSv4 client or in an NFSv4 server. In either case, the result		the NFSv4 client or in an NFSv4 server. In either case, the result
	would appear the same to applications on the NFSv4 client.		would appear the same to applications on the NFSv4 client. This is
			discussed further in section 5 of this document.
	4.1. Globally-useful names: conventional mount point		4.1. Globally-useful names: conventional mount point
	For the inter-organizational name space to be a global name space, it		For the inter-organizational name space to be a global name space, it
	is useful for its mount point in local systems to be uniform as well.		is useful for its mount point in local systems to be uniform as well.
	On POSIX machines, the name /nfs4/ SHOULD be used so that names on		On POSIX machines, the name /nfs4/ SHOULD be used so that names on
	one machine will< be directly usable on any machine. Thus, the		one machine will be directly usable on any machine. Thus, the
	example.net published filesystem would be accessible as		example.net published filesystem would be accessible as
	/nfs4/example.net/		/nfs4/example.net/
	on any POSIX client. Using this convention, "/nfs4/" is the name of		on any POSIX client. Using this convention, "/nfs4/" is the name of
	the special directory that is populated with domain names, leading to		the special directory that is populated with domain names, leading to
	file servers and filesystems that capture the results of SRV record		file servers and filesystems that capture the results of SRV record
	lookups.		lookups.
	4.2. Mount options		4.2. Mount options
	skipping to change at page 9, line 9		skipping to change at page 9, line 10
	appropriate filesystem to mount, and mounting it in the appropriate		appropriate filesystem to mount, and mounting it in the appropriate
	place in the client name space before returning control to the		place in the client name space before returning control to the
	application doing a lookup. Alternatively, one could imagine the		application doing a lookup. Alternatively, one could imagine the
	existence of an NFS version 4 server that awaited similar domain-name		existence of an NFS version 4 server that awaited similar domain-name
	lookups, then consulted the SRV records in DNS to determine the		lookups, then consulted the SRV records in DNS to determine the
	servers for the indicated published filesystem, and then returned		servers for the indicated published filesystem, and then returned
	that information as an NFS Version 4 referral. In either case, the		that information as an NFS Version 4 referral. In either case, the
	result of the DNS lookup should be cached (obeying TTL) so that the		result of the DNS lookup should be cached (obeying TTL) so that the
	result could be returned more quickly the next time.		result could be returned more quickly the next time.
	We strongly suggest that this functionality be implemented by NFS		NFS clients compliant to this standard MUST implement this
	clients. While we recognize that it would be possible to configure		functionality. While we recognize that it would be possible to
	clients so that they relied on a specially-configured server to do		configure clients so that they relied on a specially-configured
	their SRV lookups for them, we feel that such a requirement would		server to do their SRV lookups for them, we feel that such a
	impose unusual dependencies and vulnerabilities for the deployers of		requirement would impose unusual dependencies and vulnerabilities for
	such clients. Yet even if it is desirable to deploy this		the deployers of such clients.
	functionality on the NFS client side, it may be valuable as a
	transition aid for a site to be able to deploy it on the NFS server
	side: it may be easier for them to install it on special NFS servers
	rather than install it on all their NFS clients. Thus, from an
	implementation standpoint, NFS clients SHOULD implement the
	functionality, and NFS servers MAY implement it.
	6. Security Considerations		6. Security Considerations
	Naive use of the DNS may effectively give clients published server		This functionality introduces a new reliance of NFSv4 on the
	referrals that are intrusive substitutes for the servers intended by		integrity of DNS. Spoofed SRV records in DNS could cause the NFSv4
	domain administrators.		client to connect to the file servers of an attacker, not the file
			servers of an organization. This is similar to attacks that can be
			made on the base NFSv4 protocol, if server names are given in
			fs_location attributes: the client can be made to connect to the file
			servers of an attacker, not the file servers intended to be the
			target for the fs_location attributes.
	It may be possible to build a trust chain by using DNSSEC [RFC4033]		If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both
	to implement this function on the client, or by implementing this		such attacks. Domain-based service principal names are a mechanism
	function on an NFS Version 4 server that uses DNSSEC and maintaining		that also apply in this case, and it would be prudent to use them.
	a trust relationship with that server. This trust chain also breaks		They provide a mapping from the domain name that the user specified
	if the SRV interpreter accepts responses from insecure DNS zones.		to names of security principals used on the NFSv4 servers that are
	Thus, it would likely be prudent also to use domain-based service		indicated as the targets in the SRV records (as providing file
	principal names for the servers for the root filesystems as indicated		service for the root filesystems).
	as the targets of the SRV records. The idea here is that one wants
			With domain-based service principal names, the idea is that one wants
	to authenticate {nfs, domainname, host.fqdn}, not simply {nfs,		to authenticate {nfs, domainname, host.fqdn}, not simply {nfs,
	host.fqdn}, when the server is a domain's root file server obtained		host.fqdn}, when the server is a domain's root file server obtained
	through an insecure DNS SRV RR lookup. The domain administrator can		through a DNS SRV RR lookup that may or may not have been secure.
	thus ensure that only domain root NFSv4 servers have credentials for		The domain administrator can thus ensure that only domain root NFSv4
	such domain-based service principal names.		servers have credentials for such domain-based service principal
			names.
	Domain-based service principal names are defined in RFCs 5178		Domain-based service principal names are defined in RFCs 5178
	[RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based		[RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based
	names, the syntax for "domain-based-name" MUST be used with a service		names, the syntax for "domain-based-name" MUST be used with a service
	of "nfs", a domain matching the name of the organization whose root		of "nfs", a domain matching the name of the organization whose root
	filesystem is being sought, and a hostname given in the target of the		filesystem is being sought, and a hostname given in the target of the
	DNS SRV resource record. Thus, in the example above, two file		DNS SRV resource record. Thus, in the example above, two file
	servers (nfs1tr.example.net and nfs2ex.example.net) are located as		servers (nfs1tr.example.net and nfs2ex.example.net) are located as
	hosting the root filesystem for the organization example.net. To		hosting the root filesystem for the organization example.net. To
	communicate with, for instance, the second of the given file servers,		communicate with, for instance, the second of the given file servers,
	GSS-API should be used with the name-type of		GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE
	GSS_C_NT_DOMAINBASED_SERVICE defined in RFC 5178 and with a symbolic		defined in RFC 5178 and with a symbolic name of
	name of
	nfs@example.net@nfs2ex.example.net		nfs@example.net@nfs2ex.example.net
	in order to verify that the named server (nfs2ex.example.net) is		in order to verify that the named server (nfs2ex.example.net) is
	authorized to provide the root filesystem for the example.net		authorized to provide the root filesystem for the example.net
	organization.		organization.
	7. IANA Considerations		7. IANA Considerations
	None.		None.
End of changes. 12 change blocks.
	37 lines changed or deleted		38 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/