idnits 2.17.1 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.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 (October 26, 2011) is 4559 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) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: April 28, 2012 J. Zhang 6 Google 7 October 26, 2011 9 Using DNS SRV to Specify a Global File Name Space with NFS version 4 10 draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.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 April 28, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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, mDNS, and DNS-SD . . . . . . . . . . . . . . . 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 domain name to the NFS filesystem(s) associated with that name; such 127 filesystems are called "domain root" filesystems. From such 128 filesystems, like other NFS filesystems, an NFS client can use the 129 standard NFS mechanisms to navigate the rest of the NFS file servers 130 that make up the filesystem name space for the given domain. 132 Such "domain root" filesystems are mounted at a conventional point in 133 the NFS client namespace. The mechanism results in a uniform cross- 134 organizational file name space, similar to that seen in both AFS 135 [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the 136 domain name for an organization in order to locate the filesystem 137 name space published by that organization. 139 The DNS SRV resource record type [RFC2782] is used to locate "domain 140 root" file servers. The format of the DNS SRV record is as follows: 142 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 144 The Service name is "_nfs._domainroot". The Protocol as of this 145 writing could be either "_tcp" or "_sctp"; version 4 NFS is not 146 defined over UDP. Other transport protocols could be defined in the 147 future, and SRV records that advertise domain root file services with 148 other transport protocols would use the same Service name. The 149 Target fields give the domain names of the NFS servers that export 150 filesystems for the domain's root. An NFS client may then interpret 151 any of the exported root filesystems as the filesystem published by 152 the organization with the given domain name. 154 The domain root service is not useful for NFS versions prior to v4, 155 as the fs_locations attribute was introduced only in NFSv4 (as 156 described in Section 2). The "_nfs." Service name prefix is not 157 limited to NFSv4; it is possible to use that prefix in naming 158 additional Services (and their SRV records) that are also applicable 159 to other versions of NFS (e.g., NFSv3 [RFC1813]. 161 In order to allow the NFSv4 servers so given to export a variety of 162 filesystems, those file servers MUST export the given domain's root 163 filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, 164 where the "{Name}" is the name of the organization as used in the SRV 165 RR. 167 As an example, suppose a client wished to locate the root of the 168 filesystem published by organization example.net. The DNS servers 169 for the domain would publish records like 171 $ORIGIN example.net. 172 _nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net. 173 _nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net. 175 The result domain names nfs1tr.example.net and nfs2ex.example.net 176 indicate NFS Version 4 file servers that export the root of the 177 published name space for the example.net domain. In accordance with 178 RFC 2782 [RFC2782], these records are to be interpreted using the 179 Priority and Weight field values, selecting an appropriate file 180 server with which to begin a network conversation. The two file 181 servers would export filesystems that would be found at 182 "/.domainroot-example.net" in their pseudo-filesystems, which clients 183 would mount. Clients then carry out subsequent accesses in 184 accordance with the ordinary NFS Version 4 protocol. The records use 185 the port number 2049 assigned to NFS, but another port number could 186 be specified here; the NFS servers would provide NFS service at the 187 indicated port number, and NFS clients would connect to the service 188 at that indicated port number. 190 Other filesystem protocols could make use of the same "domain root" 191 abstraction, as well as the same "_domainroot" Service name suffix, 192 but this document discusses only the SRV records indicating NFS 193 servers. 195 4. Integration with Use of NFS Version 4 197 NFSv4 clients adhering to this specification implement a special 198 directory, analogous to an Automounter [AMD1][AMD2] directory, the 199 entries in which are domain names that have recently been traversed. 200 When an application attempts to traverse a new name in that special 201 directory, the NFSv4 client consults DNS to obtain the SRV data for 202 the given name, and if successful, it mounts the indicated 203 filesystem(s) in that name in the special directory. The goal is 204 that NFSv4 applications will be able to lookup an organization's 205 domain name in the special directory, and the NFSv4 client will be 206 able to discover the filesystem that that organization publishes. 207 Entries in the special directory will be domain names, and they will 208 each appear to the application as a directory name pointing to the 209 root directory of the filesystem published by the organization 210 responsible for that domain name. 212 As noted in Section 3, the domain root service is not useful for NFS 213 versions prior to version 4. 215 4.1. Globally-useful names: conventional mount point 217 In order that the inter-organizational name space function as a 218 global name space, the client-side mount point for that name space 219 must be the same on different clients. Conventionally, on POSIX 220 machines, the name /nfs4/ is be used so that names on one machine 221 will be directly usable on any machine. Thus, the example.net 222 published filesystem would be accessible as 224 /nfs4/example.net/ 226 on any POSIX client. Using this convention, "/nfs4/" is the name of 227 the special directory that is populated with domain names, leading to 228 file servers and filesystems that capture the results of SRV record 229 lookups. 231 4.2. Mount options 233 SRV records are necessarily less complete than the information in the 234 existing NFS Version 4 attributes fs_locations [RFC3530] or 235 fs_locations_info [RFC5661]. For the rootpath field of fs_location, 236 or the fli_fs_root of fs_locations_info, NFS servers MUST use the 237 "/.domainroot-{Name}" string. Thus, the servers listed as targets 238 for the SRV resource records MUST export the root of the 239 organization's published filesystem as the directory "/.domainroot- 240 {Name}" (for the given organization Name) in their exported NFS 241 namespaces. For example, for organization "example.net", the 242 directory "/.domainroot-example.net" would be used. 244 Chapter 11 of the NFS Version 4.1 document [RFC5661] describes the 245 approach that an NFS client should take to navigating 246 fs_locations_info information. 248 The process of mounting an organization's name space should permit 249 the use of what is likely to impose the lowest cost on the server. 250 Thus, the NFS client SHOULD NOT insist on using a writable copy of 251 the filesystem if read-only copies exist, or a zero-age copy rather 252 than a copy that may be a little older. We presume that the 253 organization's file name space can be navigated to provide access to 254 higher-cost properties such as writability or freshness as necessary, 255 but that the default use when navigating to the base information for 256 an organization ought to be as low-overhead as possible. 258 4.3. Filesystem integration issues 260 The result of the DNS search SHOULD appear as a (pseudo-)directory in 261 the client name space. A further refinement is RECOMMENDED: that 262 only fully-qualified domain names appear as directories. That is, in 263 many environments, DNS names may be abbreviated from their fully- 264 qualified form. In such circumstances, multiple names might be given 265 to NFS clients that all resolve to the same DNS SRV RRs. The 266 abbreviated form SHOULD be represented in the client's name space 267 cache as a symbolic link, pointing to the fully-qualified name. This 268 will allow pathnames obtained with, say, getcwd() to include the DNS 269 name that is most likely to be usable outside the scope of any 270 particular DNS abbreviation convention. 272 4.4. Multicast, mDNS, and DNS-SD 274 Location of the NFS domain root by this mechanism does not involve 275 IP-layer broadcast, multicast, or anycast communication. 277 It is not expected that this DNS SRV record format will be used in 278 conjunction with Multicast DNS (mDNS) or DNS Service Discovery 279 (DNS-SD). While mDNS could be used to locate a local domain root via 280 these SRV records, no other domain's root could be discovered. This 281 means that mDNS with DNS-SD has too little value to use in locating 282 NFSv4 domain roots. 284 5. Where is this integration carried out? 286 The NFS client is responsible for interpreting SRV records. Using 287 something like Automounter [AMD1] [AMD2] technology, the client 288 interprets names under a particular directory, discovering the 289 appropriate filesystem to mount, and mounting it in the specified 290 place in the client name space before returning control to the 291 application doing a lookup. The result of the DNS lookup should be 292 cached (obeying TTL) so that the result could be returned more 293 quickly the next time. 295 6. Security Considerations 297 This functionality introduces a new reliance of NFSv4 on the 298 integrity of DNS. Forged SRV records in DNS could cause the NFSv4 299 client to connect to the file servers of an attacker, not the file 300 servers of an organization. This is similar to attacks that can be 301 made on the base NFSv4 protocol, if server names are given in 302 fs_location attributes: the client can be made to connect to the file 303 servers of an attacker, not the file servers intended to be the 304 target for the fs_location attributes. 306 If DNSSEC [RFC4033] is available, it SHOULD be used to avoid both 307 such attacks. Domain-based service principal names are an additional 308 mechanism that also apply in this case, and it would be prudent to 309 use them. They provide a mapping from the domain name that the user 310 specified to names of security principals used on the NFSv4 servers 311 that are indicated as the targets in the SRV records (as providing 312 file service for the root filesystems). 314 With domain-based service principal names, the idea is that one wants 315 to authenticate {nfs, domainname, host.fqdn}, not simply {nfs, 316 host.fqdn}, when the server is a domain's root file server obtained 317 through a DNS SRV RR lookup that may or may not have been secure. 319 The domain administrator can thus ensure that only domain root NFSv4 320 servers have credentials for such domain-based service principal 321 names. 323 Domain-based service principal names are defined in RFCs 5178 324 [RFC5178] and 5179 [RFC5179]. To make use of RFC 5178's domain-based 325 names, the syntax for "domain-based-name" MUST be used with a service 326 of "nfs", a domain matching the name of the organization whose root 327 filesystem is being sought, and a hostname given in the target of the 328 DNS SRV resource record. Thus, in the example above, two file 329 servers (nfs1tr.example.net and nfs2ex.example.net) are located as 330 hosting the root filesystem for the organization example.net. To 331 communicate with, for instance, the second of the given file servers, 332 GSS-API is used with the name-type of GSS_C_NT_DOMAINBASED_SERVICE 333 defined in RFC 5178 and with a symbolic name of 335 nfs@example.net@nfs2ex.example.net 337 in order to verify that the named server (nfs2ex.example.net) is 338 authorized to provide the root filesystem for the example.net 339 organization. 341 NFSv4 itself contains a facility for the negotiation of security 342 mechanisms to be used between NFS clients and NFS servers. Section 343 3.3 of RFC 3530 [RFC3530] and Section 2.6 of RFC 5661 [RFC5661] both 344 describe how security mechanisms are to be negotiated. As such, 345 there is no need for this document to describe how that negotiation 346 is to be carried out when the NFS client contacts the NFS server for 347 the specified domain root filesystem(s). 349 Using SRV records to advertise the locations of NFS servers may 350 expose those NFS servers to attacks. Organizations should carefully 351 consider whether they wish their DNS servers to respond 352 differentially to different DNS clients, perhaps exposing their SRV 353 records to only those DNS requests that originate within a given 354 perimeter, in order to reduce this exposure. 356 7. IANA Considerations 357 This document requests the assignment of a new Service name without 358 an associated port numbers (as defined in RFC 6335 [RFC6335], each 359 for both TCP and SCTP. For this new Service, the Reference is this 360 document. 362 Service name: _nfs._domainroot 363 Transport Protocol(s) TCP, SCTP 364 Assignee (REQUIRED) IESG (iesg@ietf.org) 365 Contact (REQUIRED) IETF Chair (chair@ietf.org) 366 Description (REQUIRED) NFS file service for the domain root, the root 367 of the organization's published file name space 368 Reference (REQUIRED) This document 369 Port Number (OPTIONAL) 370 Service Code (REQUIRED for DCCP only) 371 Known Unauthorized Uses (OPTIONAL) 372 Assignment Notes (OPTIONAL) 374 8. References 376 8.1. Normative References 378 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 379 RFC 1034, November 1987. 381 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 382 Specification", RFC 1035, November 1987. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", March 1997. 387 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 388 specifying the location of services (DNS SRV)", RFC 2782, 389 February 2000. 391 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 392 Beame, C., Eisler, M., and D. Noveck, "Network File System 393 (NFS) version 4 Protocol", RFC 3530, April 2003. 395 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 396 Rose, "DNS Security Introduction and Requirements", 397 RFC 4033, March 2005. 399 [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service 400 Application Program Interface (GSS-API) 401 Internationalization and Domain-Based Service Names and 402 Name Type", RFC 5178, May 2008. 404 [RFC5179] Williams, N., "Generic Security Service Application 405 Program Interface (GSS-API) Domain-Based Service Names 406 Mapping for the Kerberos V GSS Mechanism", RFC 5179, 407 May 2008. 409 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network 410 File System (NFS) Version 4 Minor Version 1 Protocol", 411 RFC 5661, January 2010. 413 [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, 414 April 2010. 416 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 417 Cheshire, "Internet Assigned Numbers Authority (IANA) 418 Procedures for the Management of the Service Name and 419 Transport Protocol Port Number Registry", RFC 6335, 420 August 2011. 422 8.2. Informative References 424 [AFS] Howard, J., "An Overview of the Andrew File System"", 425 Proc. USENIX Winter Tech. Conf. Dallas, February 1988. 427 [AMD1] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter 428 Reference Manual", March 1991, 429 . 431 [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997, 432 35es Article 4, March 1997. 434 [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., 435 Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., 436 and E. Zayas, "DEcorum File System Architectural 437 Overview", Proc. USENIX Summer Conf. Anaheim, Calif., 438 June 1990. 440 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 441 Version 3 Protocol Specification", RFC 1813, June 1995. 443 Authors' Addresses 445 Craig Everhart 446 NetApp 447 800 Cranberry Woods Drive, Ste. 300 448 Cranberry Township, PA 16066 449 US 451 Phone: +1 724 741 5101 452 Email: everhart@netapp.com 454 W.A. (Andy) Adamson 455 NetApp 456 495 East Java Drive 457 Sunnyvale, CA 94089 458 US 460 Phone: +1 734 665 1204 461 Email: andros@netapp.com 463 Jiaying Zhang 464 Google 465 604 Arizona Avenue 466 Santa Monica, CA 90401 467 US 469 Phone: +1 310 309 6884 470 Email: jiayingz@google.com