idnits 2.17.1 draft-cel-nfsv4-mv0-trunking-update-00.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 13, 2017) is 2356 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) == Outdated reference: A later version (-16) exists of draft-ietf-nfsv4-migration-issues-13 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever, Ed. 3 Internet-Draft Oracle 4 Updates: 7530 (if approved) D. Noveck 5 Intended status: Standards Track NetApp 6 Expires: May 17, 2018 November 13, 2017 8 NFS version 4.0 Trunking Update 9 draft-cel-nfsv4-mv0-trunking-update-00 11 Abstract 13 Location-related attributes in NFS version 4.0 are used to support 14 the migration and replication of server file systems. In this 15 document, we describe an additional use for these attributes as a 16 mechanism to enable client discovery of an NFS version 4.0 server's 17 trunking capabilities. The interaction of trunking with migration 18 and replication is also clarified. This document updates RFC 7530. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 17, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Document Organization . . . . . . . . . . . . . . . . . . 4 59 3.3. Document Goals . . . . . . . . . . . . . . . . . . . . . 5 60 4. Overview of changes in RFC7530 Section 8 . . . . . . . . . . 5 61 5. Location Attributes (as Updated) . . . . . . . . . . . . . . 6 62 6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 7 63 6.1. Introduction to uses of Location Information (as updated) 7 64 6.2. Trunking Discovery and Detection (to be added) . . . . . 8 65 6.3. File System Replication and Trunking (as updated) . . . . 9 66 6.4. File System Migration (as updated) . . . . . . . . . . . 10 67 6.5. Interaction of Trunking, Migration, and Replication (to 68 be added) . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. Location Entries and Server Identity Update (as updated) . . 12 70 8. Updates to RFC7530 Outside Section Eight . . . . . . . . . . 12 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Appendix A. Section Classification . . . . . . . . . . . . . . . 15 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 The NFS version 4.0 specification [RFC7530] defines a migration 83 feature which enables the transfer of a file system from one server 84 to another without disruption of client activity. There were a 85 number of issues with the original definition of this feature, which 86 are described in [I-D.ietf-nfsv4-migration-issues], and are resolved 87 with the publication of [RFC7931]. 89 The latter document introduces into NFS version 4.0 a means of 90 trunking detection as a means to determine whether two network 91 addresses are connected to the same NFS version 4.0 server instance. 92 Even though migration recovery is closely related to handling 93 trunking, the NFS version 4.0 specification remains without a 94 complete discussion of trunking. 96 File system migration, replication, and trunking discovery are 97 distinct protocol features. However, it is not appropriate to treat 98 each of these features in isolation. For example, client migration 99 recovery processing needs to deal with the possibility of multiple 100 server addresses in fs_location attributes. In addition, fs_location 101 attributes, which both provide trunking-related and replication 102 information, may change over repeated retrievals, requiring an 103 integrated description of how clients are to deal with such changes. 105 In addition, the NFS version 4.0 specification needs clarification as 106 to how the client is to respond to changes in trunking arrangements 107 when migration occurs, as well as in some other important cases. All 108 of the issues discussed in the current document relate to the 109 interpretation of the fs_locations attribute and to the proper client 110 and server handling of changes in fs_location attribute values. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [RFC2119] 117 [RFC8174] when, and only when, they appear in all capitals, as shown 118 here. 120 3. Preliminaries 122 3.1. Terminology 124 Most of the terms related to handling location attributes are 125 appropriately defined in Section 5 below. However, there are a few 126 terms used outside that context that require further elucidation. 127 Particularly important is the distinction between trunking detection 128 and trunking discovery. The definitions we present are applicable to 129 all minor versions of NFSv4, but we put particular emphasis on how 130 these terms apply to NFS version 4.0. 132 o Trunking detection refers to ways of determining whether two 133 unique network addresses are associated with the same NFSv4 server 134 instance. The means available to make this determination depends 135 on the protocol version and, in some cases, on the client 136 implementation. 138 In the case of NFS version 4.0, the means to be used are described 139 in [RFC7931] and require use of the Uniform Client String approach 140 to be effective. This is in contrast to later minor versions for 141 which the means of trunking detection is described by [RFC5661] 142 and is available to every client. 144 o Trunking discovery is a process by which a client, accessing one 145 server network address, can obtain other addresses that are 146 associated with the same server instance. Typically it builds on 147 a trunking detection facility by providing one or more methods by 148 which candidate addresses are made available to the client, who 149 then uses trunking detection to appropriately filter them. 151 Trunking discovery is not described in [RFC7530] and no 152 description of it is provided in [RFC7931]. 154 3.2. Document Organization 156 The sections of the current document are divided into four types 157 based on how they relate to the eventual updating of the NFS verion 158 4.0 specification. Once this update is published, NFS version 4.0 159 will be specified by multiple documents that need to be read 160 together, until such time as a consolidated replacement specification 161 is produced. 163 o The base specification [RFC7530]. 165 o The migration-related update [RFC7931]. 167 o An eventual RFC based on the current document. 169 The section types are as follows. See Appendix A for a 170 classification of each section of the current document. 172 o An explanatory section does not contain any material that is meant 173 to update the specification of NFS version 4.0. Such sections may 174 contain explanation about why and how changes are to be done, but 175 do not include any text that is to update [RFC7530] or appear in 176 an eventual consolidated document. 178 o A replacement section contains text that is to replace and thus 179 supersede text within [RFC7530] and then appear in an eventual 180 consolidated document. 182 o An additional section contains text which, although not replacing 183 anything in [RFC7530], will be part of the specification of NFS 184 version 4.0 and will be expected to be part of an eventual 185 consolidated document. 187 o An editing section contains some text that replaces text within 188 [RFC7530], although the entire section will not consist of such 189 text and will include other text as well. Such sections make 190 relatively minor adjustments in the existing NFS version 4.0 191 specification which are expected to be reflected in an eventual 192 consolidated document. Generally such replacement text appears as 193 a quotation, possibly taking the form of an indented set of 194 paragraphs. 196 3.3. Document Goals 198 The goals of this document are as follows: 200 o To provide NFS version 4.0 with a means of trunking discovery, 201 compatible with the means of trunking detection introduced by 202 [RFC7931]. 204 o To describe how NFS version 4.0 clients are to handle the presence 205 of multiple network addresses associated to the same server, when 206 recovering from a replication and migration event. 208 o To describe how NFS version 4.0 clients are to handle changes in 209 the location attributes returned, including those that indicate 210 changes in the responding NFS version 4.0 server's trunking 211 configuration. 213 The current document pursues these goals by presenting a set of 214 updates to [RFC7530] as summarized in Section 4 below. 216 4. Overview of changes in RFC7530 Section 8 218 With a few small exceptions (see below), all of the updates to 219 [RFC7530] to provide support for trunking using the fs_locations 220 attribute apply to Section 8 of that document, entitled "Multi-Server 221 Namespace". 223 o Section 5 replaces Section 8.1 of [RFC7530], entitled "Location 224 Attributes". This section has been reorganized and extended to 225 explicitly allow the use of fs_locations to provide trunking- 226 related information that appropriately interacts with the 227 migration, replication and referral features of fs_location. 228 Terminology used to describe the interactions is added. 230 o Section 6 updates Section 8.4 of [RFC7530], entitled "Uses of 231 Location Information". This section comprises the bulk of the 232 updates. Each paragraph of Section 8.4 and its sub-sections has 233 been reviewed to clarify the provision of trunking-related 234 information using the fs_locations attribute. 236 * Section 6.1 replaces the introductory material within 237 Section 8.4 of [RFC7530]. 239 * Section 6.2 is to be added after the introductory material 240 within Section 8.4 of [RFC7530]. 242 * Section 6.3 replaces Section 8.4.1 of [RFC7530], entitled "File 243 System Replication". 245 * Section 6.4 replaces Section 8.4.2 of [RFC7530], entitled "File 246 System Migration". 248 * Section 6.5 is to be added after the updated Section 8.4.2 of 249 [RFC7530]. 251 o Section 7 replaces Section 8.5 of [RFC7530], entitled "Location 252 Entries and Server Identity". The last paragraph of the existing 253 section has been removed. 255 o A small set of updates outside Section 8 of [RFC7530] are 256 presented in Section 8. 258 o Section 9 introduces additional security considerations that are 259 to be added to those within Section 19 of [RFC7530], entitled 260 "Security Considerations". 262 5. Location Attributes (as Updated) 264 The fs_locations RECOMMENDED attribute allows specification of file 265 system locations where the data corresponding to a given file system 266 may be accessed. This attribute represents such file system 267 instances as a server address target (as either a DNS name 268 representing one or more IP addresses, or a literal IP address) 269 together with the path of that file system within the associated 270 single-server namespace. Individual fs_location entries can express 271 trunkable addresses, locations of file system replicas on other 272 servers, migration targets, or pure referrals. 274 We introduce the following terminology: 276 o Two network addresses connected to the same server are said to be 277 server-trunkable. 279 o Trunking detection refers to ways of deciding whether two specific 280 network addresses are connected to the same NFSv4 server. 282 o Trunking discovery is a process by which a client using one 283 network address can obtain other addresses that are server- 284 trunkable with it. 286 Regarding terminology relating to attributes used in trunking 287 discovery and other multi-server namespace features: 289 o Location entries (fs_location4, defined in [RFC7530] 290 Section 2.2.6) are the individual file system locations in the 291 fs_locations attribute (defined in [RFC7530] Section 2.2.7). 293 o Location elements are derived from location entries. If a 294 location entry specifies an IP address there is only a single 295 corresponding location element. Location entries that contain a 296 host name are resolved by the client, and may result in one or 297 more location elements. 299 o All location elements consist of a location address, which is the 300 IP address of an interface to a server, and an fs name, which is 301 the location of the file system within the server's pseudo-fs. 303 o The fs name is empty if the server has no pseudo-fs and only a 304 single exported file system at the root filehandle. 306 6. Updates to RFC7530 Section 8.4 (Uses of Location Information) 308 The subsections below provide replacement sections for existing 309 sections within Section 8.4 of [RFC7530] or new sub-sections to be 310 added to that section. 312 6.1. Introduction to uses of Location Information (as updated) 314 The location-bearing attribute fs_locations provides, together with 315 the possibility of absent file systems, a number of important 316 facilities in providing reliable, manageable, and scalable data 317 access. 319 When a file system is present, these attributes can provide 320 alternative locations, to be used to access the same data, in the 321 event of server failures, communications problems, or other 322 difficulties that make continued access to the current file system 323 impossible or otherwise impractical. Provision of such alternative 324 locations is referred to as "replication". 326 One type of replication is trunking, where the location entries do 327 not in fact reside on different servers, but are instead different 328 network paths to the same server. A client may use location elements 329 simultaneously to provide higher-performance access to the target 330 file system. The client utilizes trunking detection and/or discovery 331 (see Section 6.2) to determine if two location elements are server- 332 trunkable. 334 When a file system is present and subsequently becomes absent, 335 clients can be given the opportunity to have continued access to 336 their data, at an alternative location. Transfer of the file system 337 contents to the new location is referred to as "migration". See 338 Section 6.4 and Section 6.5 (of the current document) for details. 340 Alternative locations may be physical replicas of the file system 341 data or, in the case of various forms of server clustering, another 342 server providing access to the same physical file system. The 343 client's responsibilities in dealing with this transition depend on 344 the specific nature of the new access path as well as how and whether 345 data was in fact migrated. These issues will be discussed in detail 346 below. 348 Where a file system was not previously present, specification of file 349 system location provides a means by which file systems located on one 350 server can be associated with a namespace defined by another server, 351 thus enabling the creation of a multi-server namespace. A 352 designation of such a location, in place of an absent file system, is 353 called a "referral". A particularly important case is that of a 354 "pure referral", in which the absent file system has never been 355 present on the source server. 357 Because client support for location-related attributes is OPTIONAL, a 358 server may (but is not required to) take action to hide migration and 359 referral events from such clients, by acting as a proxy, for example. 361 6.2. Trunking Discovery and Detection (to be added) 363 Trunking detection refers to a way for an NFSv4 client to determine 364 whether two independently acquired network addresses are connected to 365 the same NFSv4 server. Section 5.8 of [RFC7931] describes an 366 OPTIONAL means by which it can be determined if two server network 367 addresses correspond to the same server instance. Without trunking 368 detection, a client has no way to determine that two network 369 addresses are server-trunkable. 371 In the context of NFS version 4.0, trunking detection requires that 372 the client support the Uniform Client ID String approach (UCS), 373 described in Section 5.6 of [RFC7931]. Any NFS version 4.0 client 374 that supports migration or trunking detection needs to present a 375 Uniform Client ID String to all servers. If it does not do so, it 376 will be unable to perform trunking detection. 378 Trunking discovery is the process by which an NFSv4 client using one 379 server network address can obtain other server addresses that are 380 trunkable with it; i.e., the set of addresses connected to the same 381 server instance. Location entries that specify a server host name 382 that resolves via DNS into multiple addresses provide a list of 383 server-trunkable addresses. 385 An NFS version 4.0 client can discover a set of server-trunkable 386 network addresses in a number of ways: 388 1. If the client is accessing a server using its host name, that 389 host name can be resolved to one or more IP addresses using DNS. 390 If multiple addresses are present in the DNS query result, these 391 addresses are server-trunkable and can be used together to access 392 the server. 394 2. A client connected to a server without knowledge of its host name 395 can obtain the value of a location attribute (i.e., 396 fs_locations). Where a location entry within that attribute 397 specifies a server host name, DNS can be used to obtain one or 398 more network addresses corresponding to that host name. In cases 399 in which one of those addresses is the address being used, the 400 other addresses corresponding to that host name are server- 401 trunkable and can be used to access the server. 403 3. A client can obtain the value of an fs_location attribute and use 404 location entries that specify network addresses. When there is a 405 means of trunking detection available all of addresses that are 406 determined to correspond to the same server can be used to access 407 that server. 409 6.3. File System Replication and Trunking (as updated) 411 On first access to a file system, the client should obtain the value 412 of the set of alternative locations by interrogating the fs_locations 413 attribute. Trunking discovery and/or detection can then be applied 414 to the location entries to separate the potential server-trunkable 415 addresses from the replica addresses that provide alternative 416 locations of the file system. Server-trunkable addresses may be used 417 simultaneously to provide higher performance through the exploitation 418 of multiple paths between client and target file system. 420 In the event that server failures, communications problems, or other 421 difficulties make continued access to the current file system 422 impossible or otherwise impractical, the client can use the 423 alternative locations as a way to get continued access to its data. 424 See Section 6.5 (of the current document) for more detail. 426 6.4. File System Migration (as updated) 428 When a file system is present and becomes absent, clients can be 429 given the opportunity to have continued access to their data, at an 430 alternative location, as specified by the fs_locations attribute. 431 Typically, a client will be accessing the file system in question, 432 get an NFS4ERR_MOVED error, and then use the fs_locations attribute 433 to determine the new location of the data. See Section 6.5 (of the 434 current document) for more detail. 436 Such migration can be helpful in providing load balancing or general 437 resource reallocation. The protocol does not specify how the file 438 system will be moved between servers. It is anticipated that a 439 number of different server-to-server transfer mechanisms might be 440 used, with the choice left to the server implementer. The NFSv4 441 protocol specifies the method used to communicate the migration event 442 between client and server. 444 When an alternative location is designated as the target for 445 migration, it must designate the same data. Where file systems are 446 writable, a change made on the original file system must be visible 447 on all migration targets. Where a file system is not writable but 448 represents a read-only copy (possibly periodically updated) of a 449 writable file system, similar requirements apply to the propagation 450 of updates. Any change visible in the original file system must 451 already be effected on all migration targets, to avoid any 452 possibility that a client, in effecting a transition to the migration 453 target, will see any reversion in file system state. 455 6.5. Interaction of Trunking, Migration, and Replication (to be added) 457 When the set of network addresses designated by a location attribute 458 changes, NFS4ERR_MOVED might or might not result. In some of the 459 cases in which NFS4ERR_MOVED is returned migration has occurred, 460 while in others there is a shift in the network addresses used to 461 access a particular file system (no migration occurred). 463 1. When the list of network addresses is a superset of that 464 previously in effect, there is no need for migration or any other 465 sort of client adjustment. Nevertheless, the client is free to 466 use an additional address in the replacement list if that address 467 provides another path to the same server. Or, the client may use 468 an additional address in the replacement list if server addresses 469 it is currently using become unavailable without warning. 471 2. When the list of networks addresses is a subset of that 472 previously in effect, immediate action is not needed if an 473 address missing in the replacement list is not currently in use 474 by the client. The client should avoid using it in the future, 475 whether the address is for a replica or a potential additional 476 path to the server being used. 478 3. When an address being removed is one of a number of paths to the 479 current server, the client may continue to use it until 480 NFS4ERR_MOVED is received. This is not considered a migration 481 event unless the last available path to the server has become 482 unusable. 484 When migration does occur, multiple addresses may be in use on the 485 server previous to migration and multiple addresses may be available 486 for use on the destination server. 488 With regard to the server in use, it may be that return of 489 NFS4ERR_MOVED indicates that a particular network address is no 490 longer to be used, without implying that migration of the file system 491 to a different server is needed. In light of this possibility, 492 clients are best off not concluding that migration has occurred until 493 concluding that all the network addresses known to be associated with 494 the server are not usable. 496 It should be noted that the need to defer this determination is not 497 absolute. If a client is not aware of all network addresses for any 498 reason, it may conclude that migration has occurred when it has not 499 and treat a switch to a different server address as if it were a 500 migration event. This is generally harmless since the use of the 501 same server via a new address will appear as a successful Transparent 502 State Migration. 504 While significant harm will not arise from this misapprehension, it 505 can give rise to disconcerting situations. For example, if a lock 506 has been revoked during the address shift, it will appear to the 507 client as if the lock has been lost during migration, normally 508 calling for it to be recoverable via an fs-specific grace period 509 associated with the migration event. 511 With regard to the destination server, it is desirable for the client 512 to be aware of all the valid network addresses that can be used to 513 access the destination server. However, there is no need for this to 514 be done immediately. Implementations can process the additional 515 location elements in parallel with normal use of the first valid 516 location entry found to access the destination. 518 7. Location Entries and Server Identity Update (as updated) 520 As mentioned above, a single location entry may have a server address 521 target in the form of a DNS name that may represent multiple IP 522 addresses, while multiple location entries may have their own server 523 address targets that reference the same server. 525 When server-trunkable addresses for a server exist, the client may 526 assume that for each file system in the namespace of a given server 527 network address, there exist file systems at corresponding namespace 528 locations for each of the other server network addresses. It may do 529 this even in the absence of explicit listing in fs_locations. Such 530 corresponding file system locations can be used as alternative 531 locations, just as those explicitly specified via the fs_locations 532 attribute. 534 8. Updates to RFC7530 Outside Section Eight 536 Since the existing description of NFS4ERR_MOVED (in Section 13.1.2.4 537 of [RFC7530]) does not take proper account of trunking, it needs to 538 be modified by replacing the first two sentences of the description 539 with the following material: 541 The file system that contains the current filehandle object cannot 542 be accessed using the current network address. It may be 543 accessible using other network addresses connected to the same 544 server, it may have been relocated to another server, or it may 545 never have been present. 547 9. Security Considerations 549 The Security Considerations section of [RFC7530] needs the additions 550 below to properly address some aspects of trunking discovery, 551 referral, migration and replication. 553 The possibility that requests to determine the set of network 554 addresses corresponding to a given server might be interfered with 555 or have their responses corrupted needs to be taken into account. 557 o When DNS is used to convert NFS server host names to network 558 addresses and DNSSEC [RFC4033] is not available, the validity 559 of the network addresses returned cannot be relied upon. 560 However, when the client uses RPCSEC_GSS [RFC7861] to access 561 NFS servers, it is possible for mutual authentication to detect 562 invalid server addresses. Other forms of transport layer 563 security (e.g., [RFC5246]) can also offer strong authentication 564 of NFS servers. 566 o Fetching location information SHOULD be performed using 567 RPCSEC_GSS with integrity protection, as previously explained 568 in the Security Considerations section of [RFC7530]. Making a 569 request of this sort without using strong integrity protection 570 permits corruption during transit of returned location 571 information. The client implementer needs to recognize that 572 using such information to access an NFS server without use of 573 RPCSEC_GSS (e.g., by using AUTH_SYS) can result in the client 574 interacting with an unverified network address that is posing 575 as an NFS server. 577 o Despite the fact that it is a REQUIREMENT of [RFC7530] that 578 "implementations" provide "support" for use of RPCSEC_GSS, it 579 cannot be assumed that use of RPCSEC_GSS is always available 580 between any particular client-server pair. 582 o Returning only network addresses to a client with no trusted 583 DNS resolution service can hamper its ability to use 584 RPCSEC_GSS. 586 Therefore an NFS server SHOULD present location entries that 587 correspond to file systems on other servers using only host names. 588 This enables the client to interrogate the fs_locations on the 589 destination server to obtain trunking information (as well as 590 replica information) using RPCSEC_GSS with integrity, validating 591 the name provided while assuring that the response has not been 592 corrupted. 594 When RPCSEC_GSS is not available on an NFS server, returned 595 location information is subject to corruption during transit and 596 cannot be relied upon. In the case of a client being directed to 597 another server after NFS4ERR_MOVED, this could vitiate the 598 authentication provided by the use of RPCSEC_GSS, since the 599 destination server can represent itself as the server to which the 600 client was erroneously directed. [ cel: this is still confusing. 601 ] 603 When a location attribute is fetched upon connecting with an NFS 604 server, it is best for the client to ignore trunking and replica 605 information when RPCSEC_GSS with integrity protection cannot be 606 used. [ cel: why then fetch location information in this case? ] 607 [ cel: should this be normative advice? ] 609 When location information cannot be verified, it can be subjected 610 to additional filtering to prevent the client from being 611 inappropriately directed. [ cel: why can't filtering be used in 612 the previous paragraph? ] 613 To summarize considerations regarding the use of RPCSEC_GSS in 614 fetching location information, consider the following 615 possibilities for requests to interrogate location information, 616 with interrogation approaches on the referring and destination 617 servers arrived at separately: 619 o The use of RPCSEC_GSS with integrity protection is RECOMMENDED 620 in all cases, since the absence of integrity protection exposes 621 the client to the possibility of the results being modified in 622 transit. 624 o The use of RPCSEC_GSS without integrity protection to fetch 625 location information SHOULD NOT be attempted. In cases of 626 migration or referral, this applies both to the referring and 627 destination servers. [ cel: how is this normatively different 628 than the first bullet? ] 630 o The use of requests issued without RPCSEC_GSS (e.g., using 631 AUTH_SYS), while undesirable, might be unavoidable in some 632 cases. Unprotected returned location information should be 633 subject to filtering to eliminate the possibility that the 634 client would treat an invalid address as if it were a trusted 635 NFSv4 server. The specifics will vary depending on the degree 636 of network isolation and whether the request is to the 637 referring or destination servers. 639 10. IANA Considerations 641 This document does not require actions by IANA. 643 11. References 645 11.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 653 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 654 March 2015, . 656 [RFC7931] Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker, 657 "NFSv4.0 Migration: Specification Update", RFC 7931, 658 DOI 10.17487/RFC7931, July 2016, 659 . 661 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 662 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 663 May 2017, . 665 11.2. Informative References 667 [I-D.ietf-nfsv4-migration-issues] 668 Noveck, D., Shivam, P., Lever, C., and B. Baker, "NFSv4 669 Migration and Trunking: Implementation and Specification 670 Issues", draft-ietf-nfsv4-migration-issues-13 (work in 671 progress), May 2017. 673 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 674 Rose, "DNS Security Introduction and Requirements", 675 RFC 4033, DOI 10.17487/RFC4033, March 2005, 676 . 678 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 679 (TLS) Protocol Version 1.2", RFC 5246, 680 DOI 10.17487/RFC5246, August 2008, 681 . 683 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 684 "Network File System (NFS) Version 4 Minor Version 1 685 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 686 . 688 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 689 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 690 November 2016, . 692 Appendix A. Section Classification 694 All sections of this document are considered explanatory with the 695 following exceptions. 697 o Sections 5 and 6.1 are replacement sections. 699 o Section 6.2 is an additional section. 701 o Sections 6.3 and 6.4 are replacement sections. 703 o Section 6.5 is an additional section. 705 o Section 7 is a replacement section. 707 o Section 8 is an editing section. 709 o Section 9 is an additional section. 711 Acknowledgments 713 The authors wish to thank Andy Adamson, who wrote the original 714 version of this document. All the innovation in this document is the 715 result of Andy's work, while mistakes are best ascribed to the 716 current authors. 718 The editor wishes to thank Greg Marsden of Oracle for his support of 719 this work, and Rob Thurlow of Oracle for review and suggestions. 721 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 722 Working Group Chair Spencer Shepler, and NFSV4 Working Group 723 Secretary Thomas Haynes for their support. 725 Authors' Addresses 727 Charles Lever (editor) 728 Oracle Corporation 729 1015 Granger Avenue 730 Ann Arbor, MI 48104 731 United States of America 733 Phone: +1 248 816 6463 734 Email: chuck.lever@oracle.com 736 David Noveck 737 NetApp 738 1601 Trapelo Road 739 Waltham, MA 02451 740 United States of America 742 Phone: +1 781 572 8038 743 Email: davenoveck@gmail.com