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/