idnits 2.17.1 draft-cel-nfsv4-federated-fs-nce-06.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 date (October 25, 2016) is 2732 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track S. Sorce 5 Expires: April 28, 2017 Red Hat 6 October 25, 2016 8 A Simpler Mechanism For Organizing FedFS NSDBs 9 draft-cel-nfsv4-federated-fs-nce-06 11 Abstract 13 This document describes a new, simpler mechanism for searching FedFS 14 NSDBs (Name Space Data Bases) for FedFS records. This mechanism 15 replaces the mechanism described in existing FedFS Proposed 16 Standards. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Altering rootDSEs Considered Hazardous . . . . . . . . . 3 60 2. Simplifying NCE Discovery . . . . . . . . . . . . . . . . . . 5 61 2.1. NSDB Configuration . . . . . . . . . . . . . . . . . . . 5 62 2.2. fedfsNsdbContainerEntry . . . . . . . . . . . . . . . . . 7 63 2.3. NSDB Container Entry (NCE) Enumeration . . . . . . . . . 7 64 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8 65 3.1. NSDB server compatibility . . . . . . . . . . . . . . . . 8 66 3.2. NSDB client compatibility . . . . . . . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. LDAP Descriptor Deprecation . . . . . . . . . . . . . . . 9 70 5.2. LDAP Descriptor Registration . . . . . . . . . . . . . . 9 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 6.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 A FedFS junction is an object stored on a fileserver that redirects 80 file-access clients to other fileserver shares. Using junctions, 81 multiple fileserver shares on many fileservers can be joined into a 82 single filename namespace. Think of a junction as a symlink that 83 points to the root directory of a share stored on another fileserver. 85 The target locations of these remote shares are not stored in FedFS 86 junctions. Instead, a junction contains a reference to a set of 87 location information stored in an LDAP directory. The LDAP directory 88 is referred to as a Name Space Data Base, or NSDB. 90 The fundamental and most frequent operation performed with an NSDB is 91 "FSN resolution," described in section 5.2.2 of [RFC7532]. This is 92 the act of reading the reference stored in a junction, retrieving the 93 referenced location information from an NSDB, and forming a 94 filesystem referral to send to file-access clients using a native 95 filesystem protocol. In this scenario, a fileserver acts as an NSDB 96 client. 98 FedFS records in any NSDB are stored as descendants of an NSDB 99 Container Entry, or NCE, for short. An NSDB client specifies a 100 search base when forming an LDAP query to search an NSDB for FedFS 101 records. The Distinguished Name of an NCE is that search base. 103 FedFS junctions contain only the hostname and port of the NSDB 104 service and a UUID. NSDB clients use a standard procedure for 105 probing NSDBs for their NCEs. For the purposes of this discussion, 106 we refer to procedures which retrieve putative NCEs from an NSDB as 107 "NCE discovery mechanisms." 109 Implementation experience has shown that the NCE discovery mechanism 110 currently defined in sections 4.1 and 5.2.1 of [RFC7532] can be 111 problematic for some LDAP server implementations or deployments. In 112 particular, altering the rootDSE of LDAP servers in any way is an 113 onerous requirement. We present a new mechanism for expressing NCEs 114 that does not require alteration of the rootDSE. 116 1.1. Altering rootDSEs Considered Hazardous 118 As described in Section 4.1 of [RFC7532], the LDAP naming context 119 that is superior to an NCE is modified to include the 120 fedfsNsdbContainerInfo object class. This object class carries the 121 mandatory fedfsNceDN attribute, whose value is the Distinguished Name 122 of the NCE that resides under that naming context. 124 To discover all NCEs on an NSDB, NSDB clients use the procedure 125 described in Section 5.2.1 of [RFC7532]. NSDB clients look for 126 naming context entries that include the fedfsNsdbContainerInfo object 127 class. The fedfsNceDN attribute points directly to the NCE under 128 that root suffix. 130 Difficulty arises because there is often a high bar to altering an 131 LDAP server's rootDSE. 133 o Because rootDSE's typically contain read-mostly or even read-only 134 data, an LDAP server implementation may simulate its rootDSE, 135 rather than storing it as regular LDAP records. Code changes 136 would be necessary for such an LDAP server implementation to act 137 as an NSDB. 139 o For security reasons, some LDAP server deployments may not wish to 140 grant unauthenticated access to their rootDSE information. 142 o Typically, a separate NSDB administrator account is used to manage 143 NSDB entries under an NCE, but LDAP server administrator 144 privileges (essentially, a root password for the LDAP server) are 145 required if an NCE needs to be added, moved, or deleted. Some 146 LDAP server administrators may prefer using Access Control Lists 147 (ACLs) to manage access to all FedFS record types, including NCEs. 149 o The schema specified in [RFC7532] limits the number of NCEs per 150 naming context to one. There does not appear to be any other 151 architected limit in the NSDB protocol that requires a one-to-one 152 relationship between naming context and NCE. 154 Neither [RFC7532] nor [RFC5716] discuss the motivation for referring 155 to an NCE record via the rootDSE. The use of the current NCE 156 discovery mechanism is simply a convenience that enables the contents 157 of junctions to exclude the LDAP search base when specifying the LDAP 158 record containing the junction's target locations. 160 Originally, an NSDB Container Entry DN was stored in each junction, 161 along with an FSN UUID and the name of the NSDB where the FSN was 162 stored. 164 To simplify the contents of junctions, the NCE DN was removed from 165 junctions as the design of the NSDB protocol was finalized. NSDB 166 clients were tasked with discovering the correct LDAP search base to 167 use by searching the target NSDB's rootDSE for the NCE DN. 169 The current approach is described in Section 5.2.2 of [RFC7532]: 171 1. The NSDB client obtains a list of the target NSDB's naming 172 contexts. 174 2. The NSDB client obtains a list of NCEs that reside on the target 175 NSDB by searching each of the NSDB's naming contexts for the 176 fedfsNsdbContainerInfo object class. 178 3. Finally, the NSDB client forms a series of LDAP queries using 179 each NCE as the search base. The client supplies a filter to 180 retrieve only objects in the fedfsFsl object class. 182 The search stops when one or more FSLs are returned or when all NCEs 183 have been searched. 185 Without the fedfsNsdbContainerInfo object class, a root suffix DN is 186 an adequate LDAP search base to use when searching for FSL records. 187 For administrative purposes, however, the construct of NCE is 188 maintained. 190 2. Simplifying NCE Discovery 192 Rather than relying on a Distinguish Name stored in an attribute by 193 an administrative tool, an NSDB client might instead use a search 194 query that is natural to LDAP to obtain that DN. 196 Currently an NSDB Container Entry record is entirely unremarkable, 197 except for its position in the DIT. It includes no special object 198 class, Distinguished Name, or attribute that defines it as an NCE. 199 It becomes an NCE only because its parent naming context points to it 200 via the context's fedfsNceDN attribute. 202 If each NCE were instead tagged with an object class specific only to 203 NCEs, NSDB clients could discover NCEs simply by filtering on that 204 object class. Then no change to the LDAP server's rootDSE is 205 required. 207 The following sections provide a protocol specification, similar to 208 [RFC7532], for the new NCE discovery mechanism. 210 2.1. NSDB Configuration 212 An NSDB is constructed using an LDAP Directory. This LDAP Directory 213 can have multiple naming contexts. The LDAP Directory's DSA-specific 214 entry (its rootDSE) has a multi-valued namingContext attribute. Each 215 value of the namingContext attribute is the DN of the naming 216 context's root entry (see [RFC4512]). 218 For each naming context that contains federation entries (e.g., FSNs 219 and FSLs): 221 1. Typically, all of a naming context's federation entries are 222 descended from one LDAP entry in the Directory Information Tree 223 (DIT). This entry is termed an NSDB Container Entry (NCE). 225 2. NSDB clients filter with "(objectClass=fedfsNsdbContainerEntry)" 226 to locate the naming context's NCEs. Therefore, every NCE MUST 227 include fedfsNsdbContainerEntry as one of its object classes. 229 3. NSDB clients search for FSNs with a scope ONE search, based on an 230 NCE. Therefore, all FSN entries under the naming context MUST be 231 immediate children of an NCE. 233 4. NSDB clients search for FSLs with a scope ONE search, based on an 234 FSN entry. Therefore, all FSL entries under the naming context 235 MUST be immediate children of an FSN entry. 237 An NCE may have no children. When an NSDB is first created, there 238 are no federation entries aside from the NCE, which therefore has no 239 federation-related descendents. 241 NSDB administrative operations, such as those described in 242 Section 5.1 of [RFC7532], may use NCEs to demark the position of 243 repositories for federation entries. 245 If a naming context does not host an NSDB DIT, it MUST NOT contain an 246 entry that includes the fedfsNsdbContainerEntry object class. For 247 example, an LDAP directory might have the following entries: 249 -+ [root DSE] 250 | namingContext: o=fedfs 251 | namingContext: dc=example,dc=com 252 | namingContext: ou=system 253 | 254 | 255 +---- [o=fedfs] 256 | objectClass: fedfsNsdbContainerEntry 257 | 258 | 259 +---- [dc=example,dc=com] 260 | 261 +-------- [ou=corp-it,dc=example,dc=com] 262 | 263 +------------ [ou=fedfs,ou=corp-it,dc=example,dc=com] 264 | objectClass: fedfsNsdbContainerEntry 265 | 266 | 267 +---- [ou=system] 269 In this case, the o=fedfs naming context is also an NSDB Container 270 Entry; the dc=example,dc=com naming context has an NSDB Container 271 Entry at ou=fedfs,ou=corp-it,dc=example,dc=com, and the ou=system 272 naming context has no NSDB Container Entry. 274 The NSDB SHOULD be configured with one or more privileged LDAP users. 275 These users are able to modify the contents of the LDAP database. To 276 perform the operations described in Section 5.1 of [RFC7532], a user 277 SHOULD authenticate using the DN of a privileged LDAP user. 279 It MUST be possible for an unprivileged (unauthenticated) user to 280 perform LDAP queries that access NSDB data. A fileserver performs 281 the operations described in Section 5.2 of [RFC7532] as an 282 unprivileged user. 284 All NSDB implementations SHOULD use the same schema. At minimum, 285 each MUST use a schema that includes all attributes and objects named 286 in Section 4.2 of [RFC7532] and in Section 2.2. If it is necessary 287 for an implementation to privately extend the schema defined there, 288 consider using one of the following ways: 290 o Define a fedfsAnnotation key and values (see Section 4.2.1.6 of 291 [RFC7532]). Register the new key and values with IANA. 293 o Define additional attribute types and object classes, then have 294 entries inherit from a class defined in Section 4.1 of [RFC7532] 295 and in Section 2.2, and from the implementation-defined ones. 297 2.2. fedfsNsdbContainerEntry 299 This section is an addendum to the FedFS NSDB schema specified in 300 Section 4.1 of [RFC7532]. 302 The fedfsNsdbContainerEntry object class signifies that an LDAP 303 record acts as an NSDB Container Entry (NCE). 305 A fedfsNsdbContainerEntry's has no mandatory attributes. A 306 fedfsNsdbContainerEntry's fedfsAnnotation and fedfsDescr attributes 307 are OPTIONAL. 309 311 /// 312 /// objectclass ( 313 /// a.b.c.d.e.f.g.h.i NAME 'fedfsNsdbContainerEntry' 314 /// DESC 'Denotes an NSDB Container Entry' 315 /// SUP top AUXILIARY 316 /// MAY ( 317 /// fedfsAnnotation 318 /// $ fedfsDescr 319 /// )) 320 /// 322 324 2.3. NSDB Container Entry (NCE) Enumeration 326 To find NCEs residing on the NSDB nsdb.example.com, an NSDB client 327 SHOULD do the following: 329 330 nce_list = empty 331 connect to the LDAP directory at nsdb.example.com 332 for each namingContext value $BAR in the root DSE 333 /* $BAR is a DN */ 334 query for fedfsNsdbContainerEntry objects under $BAR 335 include the DN of such objects on the nce_list 337 339 The [RFC4516] LDAP URL for the search query inside the loop would be: 341 ldap://nsdb.example.com:389/$BAR??sub? 342 (objectClass=fedfsNsdbContainerEntry) 344 3. Backwards Compatibility 346 3.1. NSDB server compatibility 348 NSDBs might serve NSDB client populations that contain clients that 349 comply only with [RFC7532] as well as clients that use the query 350 described in Section 2.3. 352 In this case, both the mechanism described in Section 2.1 and the 353 mechanism described in [RFC7532] can be concurrently implemented in 354 the NSDB to support both types of NSDB client. 356 To remain compatible with NSDB clients that comply with [RFC7532], 357 each naming context on such an NSDB MUST contain either zero or one 358 NCE records. 360 3.2. NSDB client compatibility 362 During a transition period to the new NCE discovery mechanism, NSDB 363 clients may have to resolve FSNs on NSDBs that comply with [RFC7532] 364 as well as NSDBs that have deployed the mechanism described in 365 Section 2.1. 367 In this case, an NSDB client can try the query described in 368 Section 2.3 first. If no NCE is found by this method, the NSDB 369 client can try the query described in Section 5.2.1 of [RFC7532]. 371 An NSDB client that encounters more than one NCE record under a 372 naming context MUST return FEDFS_ERR_NSDB_NONCE if it does not 373 support multiple NCEs per naming context. 375 4. Security Considerations 377 To maintain separation of privileges, privileged users that are 378 permitted to perform NSDB administrative operations should not be 379 permitted access to other areas of the LDAP server's DIT. The use of 380 LDAP ACLs is recommended to permit unauthenticated access to FedFS 381 records (FSNs, FSLs, and NCEs) while restricting the ability to 382 change these records to one or a few privileged user accounts. 384 5. IANA Considerations 386 5.1. LDAP Descriptor Deprecation 388 IANA is to update the registry entitled "FedFS Object Identifiers" 389 for the purpose of recording the change in status of existing FedFS 390 Object Identifiers (OIDs) mentioned by this document. This includes 391 the fedfsNceDN entry (OID 1.3.6.1.4.1.31103.1.14) and the 392 fedfsNsdbContainerInfo entry (OID 1.3.6.1.4.1.31103.1.1001). The 393 designation of "historic" is to be added to the "Reference" column of 394 both entries. 396 In accordance with Section 5.2 of [RFC4520], object identifier 397 descriptors for the fedfsNsdbContainerInfo object class and the 398 fedfsNceDN attribute are to be marked as "historic in nature" in 399 IANA's LDAP parameters "Object Identifier Descriptors" table, after 400 Expert Review. 402 5.2. LDAP Descriptor Registration 404 In accordance with Section 3.4 and Section 4 of [RFC4520], object 405 identifier descriptors for the new fedfsNsdbContainerEntry object 406 class defined in this document will be assigned and registered via 407 the Expert Review process. 409 Subject: Request for LDAP Descriptor Registration 411 Person & email address to contact for further information: See 412 "Author/Change Controller" 414 Specification: draft-cel-nfsv4-federated-fs-nce 416 Author/Change Controller: IESG (iesg@ietf.org) 418 Object Identifier: TBD 420 Descriptor (short name): fedfsNsdbContainerEntry 422 Usage: object class 424 6. References 426 6.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 434 (LDAP): Directory Information Models", RFC 4512, 435 DOI 10.17487/RFC4512, June 2006, 436 . 438 [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access 439 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 440 DOI 10.17487/RFC4516, June 2006, 441 . 443 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 444 Considerations for the Lightweight Directory Access 445 Protocol (LDAP)", BCP 64, RFC 4520, DOI 10.17487/RFC4520, 446 June 2006, . 448 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 449 Database (NSDB) Protocol for Federated File Systems", 450 RFC 7532, DOI 10.17487/RFC7532, March 2015, 451 . 453 6.2. Informative References 455 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 456 Naik, "Requirements for Federated File Systems", RFC 5716, 457 DOI 10.17487/RFC5716, January 2010, 458 . 460 Appendix A. Acknowledgements 462 The author of this document gratefully acknowledges the contributions 463 and patience of Rob Thurlow, Tom Haynes, and David Noveck. This work 464 would not have been possible without the efforts of the authors and 465 contributors to [RFC7532]. 467 Authors' Addresses 468 Charles Lever 469 Oracle Corporation 470 1015 Granger Avenue 471 Ann Arbor, MI 48104 472 USA 474 Phone: +1 734 274 2396 475 Email: chuck.lever@oracle.com 477 Simo Sorce 478 Red Hat, Inc. 480 Email: simo.sorce@redhat.com