idnits 2.17.1 draft-zeilenga-ldup-harmful-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 270: '... An LDAP server MUST act in accordanc...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 351 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (3 February 2004) is 7387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LDUPURP' is mentioned on line 153, but not defined == Missing Reference: 'ReadEntry' is mentioned on line 218, but not defined == Unused Reference: 'READENTRY' is defined on line 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-zeilenga-ldap-modify-increment-xx - is the name correct? -- No information found for draft-zeilenga-ldap-readentry-xx - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Informational OpenLDAP Foundation 4 Expires in six months 3 February 2004 6 LDAP Multi-master Replication Considered Harmful 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document may take place on the IETF LDUP Working Group mailing list at 16 . Please send editorial comments directly to the 17 document editor at . 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 . The list of 29 Internet-Draft Shadow Directories can be accessed at 30 . 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Please see the Full Copyright section near the end of this document 35 for more information. 37 Abstract 39 Over the last few years there has been significant development of 40 Lightweight Directory Access Protocol (LDAP) replication mechanisms 41 supporting multi-master service models. While multi-master 42 replication may be useful in some situations, the deployment of 43 multi-master replication alters the standard LDAP service model in a 44 manner which can be harmful. Specifically, the atomicity, 45 consistency, isolation, and durability (ACID) properties of the LDAP 46 service model would be lost. 48 This memo discusses the LDAP service model, how multi-master 49 replication alters the service model, and how this alteration is 50 harmful to existing directory applications. 52 1. Introduction 54 The Lightweight Directory Access Protocol (LDAP) [RFC3377] is a 55 protocol for accessing directory services which act in accordance with 56 the X.500 [X.500] information and service models [X.501][X.511]. 57 There has been significant consumer demand for "multi-master" 58 replication of LDAP-based directory servers. However, there appears 59 to be continued consumer confusion over data consistency issues 60 introduced by the forms of multi-master replication being developed. 61 Consumers tend to want "high availability", "scalability", "strong 62 data consistency" and other qualities all at once. When engineering 63 an information service, a balance between these qualities must be 64 found which meets the design objectives. 66 The designers of X.500 and LDAP specified an information service which 67 offers "high-availability" and "scalability" of read-access through 68 shadowing (replication) to slave (read-only) servers and "strong data 69 consistency" through a "single master" (authoritative) server. 71 The introduction of multi-master replication, as described in 72 [RFC3384], to LDAP will significantly change the service model. In 73 particular, as no one server is authoritative over an object, the 74 protocol would not guarantee strong data consistency between its 75 peers. That is, the directory service would no longer be capable of 76 managing the concurrency of independent modifiers of directory 77 content. 79 Changing the service model change will break applications which rely 80 on current semantics and, hence, should not be made. Instead, a new 81 directory access protocol should be developed to accommodate the 82 desired semantics. 84 To understand why the introduction of multi-master replication to 85 LDAP-enabled directories is harmful, one must first understand the 86 X.500 information and service models as used in LDAP. These models 87 are discussed in Section 2. 89 The introduction of multi-master replication would significantly alter 90 these models. Section 3 discusses these alterations. 92 These alterations will break existing directory applications. A 93 couple of examples of affected applications are provided in Section 4. 95 Security Considerations are discussed in Section 5. 97 Conclusions are discussed in Section 6. 99 2. X.500/LDAP Models 101 The X.500 information model [X.501] is hierarchical, object-oriented, 102 and designed to distributed directory systems. The model also 103 supports single-master replication [X.525]. LDAP is defined in terms 104 of X.500 as an X.500 access protocol [RFC2251]. The X.500 service 105 model [X.511] provides atomicity, consistency, isolation, and 106 durability properties ([ACID]). 108 The X.500 service model requires atomicity (i.e. "all or nothing"). 109 That is, either all the parts of the update operation are committed to 110 the Directory or none are. 112 The X.500 service model requires consistency. That is, an successful 113 update operation creates a new and valid directory state and a failed 114 update operation leaves the directory unchanged. 116 The X.500 service model requires isolation. That is, no part of the 117 update operation becomes visible to other operations until its been 118 committed to the directory. 120 The X.500 service model assumes durability ("updates will not be 121 lost"). That is, the X.500 assumes that updates committed to the 122 Directory are held by the responsible directory system agents (DSAs or 123 servers). However, the specification does not explicitly state a 124 requirement that servers ensures correct state is maintained in the 125 face of unexpected and/or unusual faults (like power outages). 127 It is noted that X.500 replication (shadowing) model allows for 128 transient inconsistencies to exist between the master and shadow 129 copies of directory information. As applications which update 130 information operate upon the master copy, any inconsistencies in 131 shadow copies are not evident to these applications. 133 3. Multi-master Changes to LDAP Service Model 135 RFC 3384 defines multi-master replication as follows: 137 Multi-Master Replication - A replication model where entries can 138 be written and updated on any of several master replica copies 139 without requiring communication with other master replicas before 140 the write or update is performed. 142 For example, if two directory user agents (DUAs or clients) 143 independently attempt to add different entries with the same name but 144 against different masters, both operations could indicate a successful 145 result despite the name conflict. Likewise, if two clients 146 independently attempted to add the same attribute but with different 147 values, both attempts could be successful despite the attribute value 148 conflict if issued against different masters. 150 Depending particulars of the multi-master replication system, such 151 conflicts are resolved either automatically or manually. Generally, 152 automated reconciliation procedures are used which rely simply 153 ignoring certain updates [LDUPURP]. These procedures can lead to 154 reconciliation to a directory state not requested by the user. 156 Obviously, the introduction of multi-master significantly changes the 157 X.500/LDAP service model. Atomicity is lost as the final state of the 158 directory may not incorporate all portions of an update request. 159 Consistency is lost because a successful update operation may not 160 result new and valid directory state being created. Isolation is 161 moot. No durability is provided as updates may be lost under normal 162 operating conditions. 164 4. Harm to existing directory applications 166 All directory applications which are designed to support concurrent 167 administration of user application information rely, to some degree, 168 on the service model's ACID properties. The severity of the harm done 169 to these applications will depend on a number of factors. In many 170 cases, the harm is irreparable. This section offers a few simple 171 examples intended to demonstrate the kind of harm that would can be 172 inflicted. In many other cases, the harm done may be quite subtle but 173 no less real. 175 4.1. Allocation of service entries 176 Many directory applications allocate unique service entries for users. 177 For instance, white pages application may allow concurrent addition of 178 users (using the naming plan for Internet directory applications 179 [RFC2377] and inetOrgPerson schema [RFC2798]) and rely on the 180 directory service to ensure that each DN uniquely identifies a user. 181 One client interacting with master server might attempt to add an 182 entry for Joe Smith called and 183 another client interacting with a second master server might attempt 184 to add an entry for Joe Jones . 185 Both of these additions could be successful. 187 The introduction of multi-master replication would cause great harm to 188 such deployments as it would allow both adds to succeed. 190 4.2. Allocation of serial numbers 192 Many directory applications require each object (in a particular class 193 or set of classes) to have a unique serial number assigned to it. For 194 instance, in Network Information Service [RFC2307] system, uidNumber 195 associated with a user must be unique within an administrative domain. 197 One approach which allows multiple instances of the administrative 198 client to allocate unique serial numbers, is to have an entry in the 199 directory which holds the last assigned uidNumber. Then clients can 200 read the uidNumber and attempt to increment it as follows: 202 dn: cn=Last UID,dc=example,dc=com 203 changetype: modify 204 modify: delete 205 delete: uidNumber 206 uidNumber: 1020 207 - 208 modify: add 209 add: uidNumber 210 uidNumber: 1021 211 - 213 where 1020 was the value uidNumber read and 1021 is the desired value. 214 If the modify fails because the value to be deleted no longer exists, 215 the client can repeat as necessary. 217 (Another approach is to use a modify/increment with atomic read entry 218 features [X.511][Increment][ReadEntry].) 220 The introduction of multi-master replication would cause great harm to 221 such applications, resulting in same serial number being assigned to 222 different objects. 224 4.3. Allocation of single-valued authority information 226 Some applications rely on the value of a single valued attribute to 227 indicate which service or process currently has authority over an 228 object. For example, say the single valued attribute 'authority' is 229 defined in the schema to represent the service or process which is 230 currently responsible for administration of the object. If one 231 client tries to add "authority: A" and another tries to add 232 "authority: B" to an entry which presently has no authority attribute, 233 both of these operations cannot be successful. 235 The introduction of multi-master replication would cause great harm to 236 such applications, resulting in exclusive authority being granted to 237 multiple services or processes. 239 4.4. Entry resurrection 241 Applications and administrator generally do not expect entries they 242 delete to be resurrected. For example, if an administrator deletes a 243 user entry, the administrator would likely be very surprised if it 244 later found that user entry had been resurrected. 246 The introduction of multi-master replication can lead to such as a 247 replication conflict, due to the addition of a child entry subordinate 248 the user entry on another master, can result in the user entry being 249 resurrected. 251 5. Security Considerations 253 It is unclear how one can build secure directory applications where 254 update operations do not have the atomicity, consistency, isolation, 255 and durability properties. 257 It is unclear how one can secure the directory when updates to 258 authentication credentials and security and other policy information 259 may be lost. 261 6. Conclusions 263 The X.500/LDAP information and service models does not support 264 multi-master replication and cannot be altered to support multi-master 265 replication without causing significant harm to existing directory 266 applications. LDAP developers should heed this implementation 267 absolute imperative [RFC 2251, Section 3.3]: 269 This document defines LDAP in terms of X.500 as an X.500 access 270 mechanism. An LDAP server MUST act in accordance with the 271 X.500(1993) series of ITU recommendations when providing the 272 service. However, it is not required that an LDAP server make use 273 of any X.500 protocols in providing this service, e.g. LDAP can be 274 mapped onto any other directory system so long as the X.500 data 275 and service model as used in LDAP is not violated in the LDAP 276 interface. 278 7. Normative References 280 [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory 281 Access Protocol (v3)", RFC 2251, December 1997. 283 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 284 Protocol (v3): Technical Specification", RFC 3377, 285 September 2002. 287 [X.500] International Telecommunication Union - 288 Telecommunication Standardization Sector, "The Directory 289 -- Overview of concepts, models and services," 290 X.500(1993) (also ISO/IEC 9594-1:1994). 292 [X.501] International Telecommunication Union - 293 Telecommunication Standardization Sector, "The Directory 294 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 296 [X.511] International Telecommunication Union - 297 Telecommunication Standardization Sector, "The Directory: 298 Abstract Service Definition", X.511(1993). 300 [X.525] International Telecommunication Union - 301 Telecommunication Standardization Sector, "The Directory: 302 Replication", X.525(1993). 304 [RFC3384] E. Stokes, et. al., "LDAPv3 Replication Requirements", 305 RFC3384, October 2002. 307 8. Informative References 309 [ACID] Section 4 of ISO/IEC 10026-1:1992. 311 [RFC2307] Howard, L, "An Approach for Using LDAP as a Network 312 Information Service", RFC 2307, March 1998. 314 [RFC2377] Grimstad, A., R. Huber, S. Sataluri, and M. Wahl, 315 "Naming Plan for Internet Directory-Enabled 316 Applications", RFC 2377, September 1998. 318 [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC 319 2798, April 2000. 321 [Increment] Zeilenga, K., "LDAP Modify/Increment Extension", 322 draft-zeilenga-ldap-modify-increment-xx.txt (to be 323 submitted soon), a work in progress. 325 [READENTRY] Zeilenga, K., "LDAP Read Entry Controls", 326 draft-zeilenga-ldap-readentry-xx.txt, a work in progress. 328 9. IANA Considerations 330 No IANA actions are requested. 332 10. Authors' Address 334 Kurt D. Zeilenga 335 OpenLDAP Foundation 337 Email: Kurt@OpenLDAP.org 339 Full Copyright 341 Copyright (C) The Internet Society (2004). All Rights Reserved. 343 This document and translations of it may be copied and furnished to 344 others, and derivative works that comment on or otherwise explain it 345 or assist in its implementation may be prepared, copied, published and 346 distributed, in whole or in part, without restriction of any kind, 347 provided that the above copyright notice and this paragraph are 348 included on all such copies and derivative works. However, this 349 document itself may not be modified in any way, such as by removing 350 the copyright notice or references to the Internet Society or other 351 Internet organizations, except as needed for the purpose of 352 developing Internet standards in which case the procedures for 353 copyrights defined in the Internet Standards process must be followed, 354 or as required to translate it into languages other than English.