idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1813' is defined on line 438, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Everhart 3 Internet-Draft W. Adamson 4 Intended status: Standards Track NetApp 5 Expires: September 9, 2012 J. Zhang 6 Google 7 March 8, 2012 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt 12 Abstract 14 The NFS version 4 protocol provides a mechanism for a collection of 15 NFS file servers to collaborate in providing an organization-wide 16 file name space. The DNS SRV RR allows a simple way for an 17 organization to publish the root of its filesystem name space, even 18 to clients that might not be intimately associated with such an 19 organization. The DNS SRV RR can be used to join these organization- 20 wide file name spaces together to allow construction of a global, 21 uniform NFS file name space. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 70 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4 72 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 73 4.1. Globally-useful names: conventional mount point . . . . . 6 74 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 76 4.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Where is this integration carried out? . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Background 93 Version 4 of the NFS protocol [RFC3530] introduced the fs_locations 94 attribute. Use of this attribute was elaborated further in the NFS 95 Version 4 Minor Version 1 protocol [RFC5661], which also defined an 96 extended version of the attribute as fs_locations_info. With the 97 advent of these attributes, NFS servers can cooperate to build a file 98 name space that crosses server boundaries. The fs_locations and 99 fs_locations_info attributes are used as referrals, so that a file 100 server may indicate to its client that the file name tree beneath a 101 given name in the server is not present on itself, but is represented 102 by a filesystem in some other set of servers. The mechanism is 103 general, allowing servers to describe any filesystem as being 104 reachable by requests to any of a set of servers. Thus, starting 105 with a single NFS Version 4 server, using these referrals, an NFS 106 Version 4 client could see a large name space associated with a 107 collection of interrelated NFS Version 4 file servers. An 108 organization could use this capability to construct a uniform file 109 name space for itself. 111 An organization might wish to publish the starting point for this 112 name space to its clients. In many cases, the organization will want 113 to publish this starting point to a broader set of possible clients. 114 At the same time, it is useful to require clients to know only the 115 smallest amount of information in order to locate the appropriate 116 name space. Simultaneously, that required information should be 117 constant through the life of an organization if the clients are not 118 to require reconfiguration as administrative events change, for 119 instance, a server's name or address. 121 3. Use of SRV Resource Record in DNS 123 Providing an organization's published filesystem name space is a 124 service, and the DNS [RFC1034][RFC1035] provides methods for 125 discovery of that service. This standard defines a mapping from a 126 DNS name to the NFS filesystem(s) providing the root of the 127 filesystem name space associated with that DNS name; such filesystems 128 are called "domain root" filesystems. From such filesystems, like 129 other NFS filesystems, an NFS client can use the standard NFS 130 mechanisms to navigate the rest of the NFS file servers that make up 131 the filesystem name space for the given domain. 133 Such "domain root" filesystems are mounted at a conventional point in 134 the NFS client namespace. The mechanism results in a uniform cross- 135 organizational file name space, similar to that seen in both AFS 136 [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the 137 domain name for an organization in order to locate the filesystem 138 name space published by that organization. 140 The DNS SRV resource record type [RFC2782] is used to locate "domain 141 root" file servers. The format of the DNS SRV record is as follows: 143 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 145 The Service name used is "_nfs-domainroot", in conformance with RFC 146 6335 [RFC6335]. The Protocol name used is "_tcp", for NFS service 147 over TCP. Future NFS services using other protocols MUST use another 148 Protocol name. The "_udp" label MUST NOT be used to imply use of UDP 149 with NFSv4, as neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661] 150 defines NFSv4 over UDP. The Target fields give the domain names of 151 the NFS servers that export filesystems for the domain's root. An 152 NFS client may then interpret any of the exported root filesystems as 153 the root of the filesystem published by the organization with the 154 given domain name. 156 The domain root service is not useful for NFS versions prior to v4, 157 as the fs_locations attribute was introduced only in NFSv4 (as 158 described in Section 2). 160 In order to allow the NFSv4 servers so given to export a variety of 161 filesystems, those file servers MUST export the given domain's root 162 filesystems at "/.domainroot/{Name}" within their pseudo-filesystems, 163 where the "{Name}" is the name of the organization as used in the SRV 164 RR. 166 As an example, suppose a client wished to locate the root of the 167 filesystem published by organization example.net. The DNS servers 168 for the domain would publish records like 170 $ORIGIN example.net. 171 _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 172 _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net. 174 The result domain names nfs1tr.example.net and nfs2ex.example.net 175 indicate NFS Version 4 file servers that export the root of the 176 published name space for the example.net domain. In accordance with 177 RFC 2782 [RFC2782], these records are to be interpreted using the 178 Priority and Weight field values, selecting an appropriate file 179 server with which to begin a network conversation. The two file 180 servers would export filesystems that would be found at 181 "/.domainroot/example.net" in their pseudo-filesystems, which clients 182 would mount. Clients then carry out subsequent accesses in 183 accordance with the ordinary NFS Version 4 protocol. The first 184 record uses the port number 2049 assigned to NFS, and another port is 185 specified for the second record; the NFS servers would provide NFS 186 service at their indicated port numbers, and NFS clients would 187 connect to the service via the corresponding port numbers on those 188 indicated servers. 190 Other filesystem protocols could make use of the same "domain root" 191 abstraction, necessarily under different Service names not specified 192 here. 194 4. Integration with Use of NFS Version 4 196 NFSv4 clients adhering to this specification implement a special 197 directory, analogous to an Automounter [AMD1][AMD2] directory, the 198 entries in which are domain names that have recently been traversed. 199 When an application attempts to traverse a new name in that special 200 directory, the NFSv4 client consults DNS to obtain the SRV data for 201 the given name, and if successful, it mounts the indicated 202 filesystem(s) in that name in the special directory. The goal is 203 that NFSv4 applications will be able to lookup an organization's 204 domain name in the special directory, and the NFSv4 client will be 205 able to discover the filesystem that that organization publishes. 206 Entries in the special directory will be domain names, and they will 207 each appear to the application as a directory name pointing to the 208 root directory of the filesystem published by the organization 209 responsible for that domain name. 211 As noted in Section 3, the domain root service is not useful for NFS 212 versions prior to version 4. 214 4.1. Globally-useful names: conventional mount point 216 In order that the inter-organizational name space function as a 217 global name space, the client-side mount point for that name space 218 must be the same on different clients. Conventionally, on POSIX 219 machines, the name /nfs4/ is be used so that names on one machine 220 will be directly usable on any machine. Thus, the example.net 221 published filesystem would be accessible as 223 /nfs4/example.net/ 225 on any POSIX client. Using this convention, "/nfs4/" is the name of 226 the special directory that is populated with domain names, leading to 227 file servers and filesystems that capture the results of SRV record 228 lookups. 230 4.2. Mount options 232 SRV records are necessarily less complete than the information in the 233 existing NFS Version 4 attributes fs_locations [RFC3530] or 234 fs_locations_info [RFC5661]. For the rootpath field of fs_location, 235 or the fli_fs_root of fs_locations_info, NFS servers MUST use the 236 "/.domainroot/{Name}" string. Thus, the servers listed as targets 237 for the SRV resource records MUST export the root of the 238 organization's published filesystem as the directory "/.domainroot/ 239 {Name}" (for the given organization Name) in their exported NFS 240 namespaces. For example, for organization "example.net", the 241 directory "/.domainroot/example.net" would be used. 243 Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the 244 approach that an NFS client should take to navigating 245 fs_locations_info information. 247 The process of mounting an organization's name space should permit 248 the use of what is likely to impose the lowest cost on the server. 249 Thus, the NFS client SHOULD NOT insist on using a writable copy of 250 the filesystem if read-only copies exist, or a zero-age copy rather 251 than a copy that may be a little older. The organization's file 252 system representatives can be navigated to provide access to higher- 253 cost properties such as writability or freshness as necessary, but 254 that the default use when navigating to the base information for an 255 organization ought to be as low-overhead as possible. 257 4.3. Filesystem integration issues 259 The result of the DNS search SHOULD appear as a (pseudo-)directory in 260 the client name space. A further refinement is RECOMMENDED: that 261 only fully-qualified domain names appear as directories. That is, in 262 many environments, DNS names may be abbreviated from their fully- 263 qualified form. In such circumstances, multiple names might be given 264 to NFS clients that all resolve to the same DNS SRV RRs. The 265 abbreviated form SHOULD be represented in the client's name space 266 cache as a symbolic link, pointing to the fully-qualified name. This 267 will allow pathnames obtained with, say, getcwd() to include the DNS 268 name that is most likely to be usable outside the scope of any 269 particular DNS abbreviation convention. 271 4.4. Multicast DNS 273 Location of the NFS domain root by this SRV record is intended to be 274 performed with unicast by using ordinary DNS [RFC1034][RFC1035] 275 protocol. 277 This document does not define the use of this DNS SRV record format 278 in conjunction with Multicast DNS (mDNS). While mDNS could be used 279 to locate a local domain root via these SRV records, no other 280 domain's root could be discovered. This means that mDNS has too 281 little value to use in locating NFSv4 domain roots. 283 5. Where is this integration carried out? 285 The NFS client is responsible for interpreting SRV records. Using 286 something like Automounter [AMD1] [AMD2] technology, the client 287 interprets names under a particular directory, discovering the 288 appropriate filesystem to mount, and mounting it in the specified 289 place in the client name space before returning control to the 290 application doing a lookup. The result of the DNS lookup should be 291 cached (obeying TTL) so that the result could be returned more 292 quickly the next time. 294 6. Security Considerations 296 This functionality introduces a new reliance of NFSv4 on the 297 integrity of DNS. Forged SRV records in DNS could cause the NFSv4 298 client to connect to the file servers of an attacker, not the file 299 servers of an organization. This is similar to attacks that can be 300 made on the base NFSv4 protocol, if server names are given in 301 fs_location attributes: the client can be made to connect to the file 302 servers of an attacker, not the file servers intended to be the 303 target for the fs_location attributes. 305 If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both 306 such attacks. Domain-based service principal names are an additional 307 mechanism that also apply in this case, and it would be prudent to 308 use them. They provide a mapping from the domain name that the user 309 specified to names of security principals used on the NFSv4 servers 310 that are indicated as the targets in the SRV records (as providing 311 file service for the root filesystems). 313 With domain-based service principal names, the idea is that one wants 314 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 315 host.fqdn}, when the server is a domain's root file server obtained 316 through a DNS SRV RR lookup that may or may not have been secure. 318 The domain administrator can thus ensure that only domain root NFSv4 319 servers have credentials for such domain-based service principal 320 names. 322 Domain-based service principal names are defined in RFCs 5178 323 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 324 names, the syntax for "domain-based-name" MUST be used with a service 325 of "nfs", a domain matching the name of the organization whose root 326 filesystem is being sought, and a hostname given in the target of the 327 DNS SRV resource record. Thus, in the example above, two file 328 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 329 hosting the root filesystem for the organization example.net. To 330 communicate with, for instance, the second of the given file servers, 331 GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE 332 defined in RFC 5178 and with a symbolic name of 334 nfs@example.net@nfs2ex.example.net 336 in order to verify that the named server (nfs2ex.example.net) is 337 authorized to provide the root filesystem for the example.net 338 organization. 340 NFSv4 itself contains a facility for the negotiation of security 341 mechanisms to be used between NFS clients and NFS servers. Section 342 3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both 343 describe how security mechanisms are to be negotiated. As such, 344 there is no need for this document to describe how that negotiation 345 is to be carried out when the NFS client contacts the NFS server for 346 the specified domain root filesystem(s). 348 Using SRV records to advertise the locations of NFS servers may 349 expose those NFS servers to attacks. Organizations should carefully 350 consider whether they wish their DNS servers to respond 351 differentially to different DNS clients, perhaps exposing their SRV 352 records to only those DNS requests that originate within a given 353 perimeter, in order to reduce this exposure. 355 7. IANA Considerations 356 This document requests the assignment of a new Service name without 357 an associated port number (as defined in RFC 6335 [RFC6335]), for 358 TCP. For this new Service, the Reference is this document. 360 Service name: nfs-domainroot 361 Transport Protocol(s) TCP 362 Assignee (REQUIRED) IESG (iesg@ietf.org) 363 Contact (REQUIRED) IETF Chair (chair@ietf.org) 364 Description (REQUIRED) NFS service for the domain root, the root of 365 an organization's published file name space. 366 Reference (REQUIRED) This document 367 Port Number (OPTIONAL) 368 Service Code (REQUIRED for DCCP only) 369 Known Unauthorized Uses (OPTIONAL) 370 Assignment Notes (OPTIONAL) 372 8. References 374 8.1. Normative References 376 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 377 RFC 1034, November 1987. 379 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 380 Specification", RFC 1035, November 1987. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", March 1997. 385 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 386 specifying the location of services (DNS SRV)", RFC 2782, 387 February 2000. 389 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 390 Beame, C., Eisler, M., and D. Noveck, "Network File System 391 (NFS) version 4 Protocol", RFC 3530, April 2003. 393 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 394 Rose, "DNS Security Introduction and Requirements", 395 RFC 4033, March 2005. 397 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 398 Application Program Interface (GSS-API) 399 Internationalization and Domain-Based Service Names and 400 Name Type", RFC 5178, May 2008. 402 [RFC5179] Williams, N., "Generic Security Service Application 403 Program Interface (GSS-API) Domain-Based Service Names 404 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 405 May 2008. 407 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network 408 File System (NFS) Version 4 Minor Version 1 Protocol", 409 RFC 5661, January 2010. 411 [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, 412 April 2010. 414 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 415 Cheshire, "Internet Assigned Numbers Authority (IANA) 416 Procedures for the Management of the Service Name and 417 Transport Protocol Port Number Registry", RFC 6335, 418 August 2011. 420 8.2. Informative References 422 [AFS] Howard, J., "An Overview of the Andrew File System"", 423 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 425 [AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 426 Reference Manual", March 1991, 427 . 429 [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997, 430 35es Article 4, March 1997. 432 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 433 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 434 and E. Zayas, "DEcorum File System Architectural 435 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 436 June 1990. 438 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 439 Version 3 Protocol Specification", RFC 1813, June 1995. 441 Authors' Addresses 443 Craig Everhart 444 NetApp 445 800 Cranberry Woods Drive, Ste. 300 446 Cranberry Township, PA 16066 447 US 449 Phone: +1 724 741 5101 450 Email: everhart@netapp.com 452 W.A. (Andy) Adamson 453 NetApp 454 495 East Java Drive 455 Sunnyvale, CA 94089 456 US 458 Phone: +1 734 665 1204 459 Email: andros@netapp.com 461 Jiaying Zhang 462 Google 463 604 Arizona Avenue 464 Santa Monica, CA 90401 465 US 467 Phone: +1 310 309 6884 468 Email: jiayingz@google.com