draft-ietf-ldup-usage-profile-06.txt
Richard Huber <[email protected]> Fri, 26 Sep 2003 09:27:06 -0400
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------B91BA20B2C46E9D224D677FE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Drafts Editor -
Please publish the attached as draft-ietf-ldup-usage-profile-06.txt.
LDUPers -
Attached is the latest version of the LDUP Profiles draft. Per the
discussion in Vienna, we would like to submit this for WG last call.
Sorry it was delayed a bit; we ran into consecutive vacations of the
authors.
Rick Huber
--------------B91BA20B2C46E9D224D677FE
Content-Type: text/plain; charset=iso-8859-1;
name="draft-ietf-ldup-usage-profile-06.txt"
Content-Disposition: inline;
filename="draft-ietf-ldup-usage-profile-06.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h8QDS0KP088612
=20
=20
Internet-Draft Richard V. Huber
LDAP Duplication/Replication/Update Gerald F. Maziarski
Protocols WG AT&T Laboratories
Intended Category: Informational Ryan D. Moats
Expires: March 2004 Lemur Networks
September 2003
=20
=20
=20
General Usage Profile for LDAPv3 Replication=20
draft-ietf-ldup-usage-profile-06.txt=20
=20
Status of This Memo=20
=20
This document is an Internet-Draft and is in full conformance with all=20
provisions of Section 10 of RFC2026.=20
=20
Internet-Drafts are working documents of the Internet Engineering Task=20
Force (IETF), its areas, and its working groups. Note that other=20
groups may also distribute working documents as Internet-Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six months=20
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as reference=20
material or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/lid-abstracts.txt.=20
=20
The list of Internet-Drafts Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20
=20
Copyright Notice=20
=20
Copyright (C) The Internet Society (2001). All Rights Reserved.=20
=20
=20
Abstract=20
=20
Support for replication in LDAP directory systems is often one of the=20
key factors in the decision to deploy them. But replication brings=20
design constraints along with its benefits.=20
=20
We discuss some of the factors that should be taken into consideration=20
when designing a replicated directory system. Both programming and=20
architectural/operational concerns are addressed and both single- and=20
multi-master directories are considered.=20
Huber, et al Expires March 2004 [Page 1] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
Table of Contents
1 Introduction........................................................3=20
2 Meta-data Considerations............................................3=20
2.1 Schema Considerations............................................3=20
2.2 Replication Agreements...........................................5=20
2.3 Access Control...................................................5=20
2.4 Change Logs......................................................6=20
3 Naming Considerations...............................................6=20
4 Conflict Resolution Considerations..................................7=20
4.1 Consistent Access after Changes..................................7=20
4.2 Conflict Resolution in Single-Master Systems.....................8=20
4.3 Problem Cases....................................................8=20
4.3.1 Atomicity.....................................................8=20
4.3.1.1 Locking...................................................8=20
4.3.1.2 Partitioning..............................................9=20
4.4 General Principles...............................................9=20
5 Failover Considerations............................................10=20
5.1 Common Issues...................................................10=20
5.2 Single Master Issues............................................11=20
5.3 Multi-Master Issues.............................................12=20
6 Other Issues.......................................................12=20
6.1 Locking.........................................................12=20
6.2 Backup and Restore..............................................13=20
7 Impact of Non-LDAP Changes/Constraints.............................13=20
7.1 Changes Outside of LDAP.........................................13=20
7.2 Application Triggers............................................14=20
7.3 Policy Conflicts Across Servers.................................14=20
8 Security Considerations............................................15=20
9 Acknowledgements...................................................15=20
10 References........................................................15=20
Authors' Addresses...................................................16=20
Full Copyright Statement.............................................16=20
=20
Huber, et al Expires March 2004 [Page 2] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
=20
1 Introduction=20
=20
As applications come to rely on LDAP directories as part of their=20
mission-critical infrastructure, the need for highly reliable and=20
highly available LDAP systems will increase. =20
=20
Distributed, replicated directories can increase reliability and=20
reduce capacity problems. Nevertheless, applications which work well=20
with a single, standalone directory may develop problems in a=20
distributed environment unless both the applications and the=20
environment are designed with data distribution as one of the=20
criteria. =20
=20
While the detailed design criteria will depend partly on whether the=20
distributed directory is a single-master or multi-master system many=20
concerns are common to both. This document flags some issues as being=20
specific to either single-master or multi-master directories;=20
unflagged issues pertain to both.=20
=20
Any given class of directory applications (e.g. white pages, policy,=20
authentication and authorization) is not inherently single- or multi-
master. This choice will depend on the requirements=20
(reliability/availability, update procedures, performance, etc.) of a=20
specific instance of the application. Therefore, this document=20
addresses general issues regarding the deployment of single- and=20
multi-master directory systems. There may be future documents that=20
address specific applications.=20
=20
2 Meta-data Considerations=20
=20
Any LDAP directory contains meta-data as well as the user data in the=20
directory. A non-exhaustive list of meta-data includes descriptions=20
of the data in the directory (e.g. schema), policies for use of the=20
data (e.g. access controls), and configuration/status information=20
(e.g. replication agreements). =20
=20
This meta-data is stored in the directory itself, accessible as=20
regular data or as operational attributes. Issues may arise when=20
meta-data stored in the directory is replicated. However, not=20
replicating meta-data may also be problematic.=20
=20
This section examines some of the potential problems.=20
=20
2.1 Schema Considerations=20
=20
If the schema of one or more of the copies of a replica differs from=20
the schema of the other replicas, then there is a possibility of=20
schema mismatch when data is exchanged between them. The schema=20
extensibility feature of LDAP nearly guarantees that replica groups=20
comprised of a heterogeneous mix of systems will not contain=20
Huber, et al Expires December 2003 [Page 3] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
homogeneous schema because of directory vendors' built-in extensions.=20
A given directory may not use all of the elements of its schema, so=20
schema differences do not always lead to schema mismatches during=20
replication.=20
=20
Schema mismatch issues are further complicated by the possibility of=20
replicating the "subschemaSubentry" itself. Some directories use this=20
technique to distribute schema changes. Currently there is no=20
standard for LDAP schema representation within the subschemaSubentry. =20
In the absence of such a standard, full schema interoperability is not=20
possible in the IETF sense. Directory designers should establish=20
common schema on all servers holding a common replica, and should=20
avoid use of vendor-specific attributes. =20
=20
The following is a partial list of possible schema mismatches:=20
=20
1. Object class not defined=20
2. Structure Rule of an object class=20
3. Structural vs. Auxiliary in an object class=20
4. Optional vs. Mandatory attribute in an object class=20
5. Object identifiers differ on an attribute type or on an object=20
class=20
6. Type and number of attributes defined in a class=20
7. Attribute type not defined=20
8. Base syntax of an attribute type=20
9. Multi-valued vs. single-valued attribute types=20
10. Matching rule of an attribute type=20
11. Naming collisions of attribute type names=20
12. Attribute name aliasing ("street" vs. "streetAddress" vs.=20
"Strasse")=20
13. ACL format (and consequently, ACL calculus) =20
=20
Schema mismatches that cause data corruption in one or more of the=20
replicas must result in meta-data (e.g. log entries) in order to=20
comply with Requirement P7 of [RFC3384]. Note that schema differences=20
do not produce corruption in all circumstances. Some schema=20
differences may have little or no impact on the proper storage of=20
replicated data. However, any time data is added to the directory,=20
replication between heterogeneous schemas may result in data=20
corruption due to a schema mismatch. =20
=20
Options for dealing with such potential mismatches include:=20
=20
- Use fractional replication to replicate only those attributes=20
that do not have differences=20
- Remove all schema mismatches =20
- Use the same schema on all systems=20
=20
The tool described by requirement AM8 of [RFC3384] would help=20
designers detect schema conflicts as early as possible.=20
=20
Huber, et al Expires December 2003 [Page 4] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
2.1.1.1 Replication Agreements=20
=20
Replication Agreements are central to replication, as they allow=20
configuration of most of the aspects of the replication process,=20
including the triggers for replica cycles (from Requirement M1 in=20
[RFC3384]), critical OID information (from Requirement M6 in=20
[RFC3384]), and replication process parameters (Requirement M7 in=20
[RFC3384]). Through the use of a standard replication agreement=20
schema (Requirement SC2 of [RFC3384], [InfoMod]) it is possible to=20
replicate the replication agreement.=20
=20
If a replication agreement includes replication credentials, the=20
agreement should be read and write protected in the directory, and=20
transport of the replication agreement should be encrypted.=20
=20
When replication agreements are themselves distributed via=20
replication, they are subject to same "loose consistency" issues (due=20
to replication delay and deferred conflict resolution) as other data. =20
Even a temporary inconsistency among replication agreements may cause=20
unbalanced replication and further inconsistency. As "multi-
mastering" complicates "loose consistency" issues, avoidance of these=20
issues by making all replication agreement changes through the same=20
master (see Sections 4 and 5) is strongly advised. =20
=20
2.2 Access Control=20
=20
The following considerations complicate replication of Access Control=20
Information:=20
=20
- Access Control Information (ACI) is treated as though it were=20
stored as attributes in the directory [RFC2820]=20
- LDAP [RFC2251] declares that changes resulting from a single LDAP=20
MODIFY are atomic (but see caveats for multi-master replication=20
in Sections 3 and 4)=20
- The ACI affecting a given entry may not be part of that entry (it=20
could be part of a group entry or part of an ancestor of the=20
entry in question) =20
- The ACI cannot always be changed atomically with associated data=20
changes=20
- The interaction of replication and partitioning is still unclear=20
(i.e. what happens when access control policy is inherited from=20
an area of replication that is not held locally) =20
=20
Do not leave windows where data is unprotected.=20
=20
To reduce risk:=20
=20
- In all environments, access control changes should be made before=20
adds and after deletes=20
- In multi-master environments, access control changes and the=20
associated data changes should be made on same system.=20
Huber, et al Expires December 2003 [Page 5] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
=20
Even when ACI is faithfully replicated (with the same transfer format)=20
among heterogeneous members of a replica group, there is no guarantee=20
that an ACI change is expressed similarly everywhere in the group. =20
This caveat is partly due to the open issues with respect to=20
partitioning mentioned above, and partly due to vendor differences=20
with regard to the expression of security policy. =20
=20
2.3 Change Logs=20
=20
Requirement G4 of [RFC3384] states that meta-data must not grow=20
without bound. Since it is unrealistic to assume that meta-data won't=20
be needed during replication, designers must consider how and when=20
meta-data can be purged.=20
=20
Replicas that use connections with intermittent quality should use=20
explicit replica cycle scheduling. Since the systems know when=20
replication should have occurred, delayed replication can be detected=20
and manual intervention initiated before the meta-data grows without=20
bound. In extreme cases, it may be necessary to remove a replica from=20
the replication group and restore it once better connectivity is=20
available.=20
=20
In a multi-master system, it is possible for a consumer to receive=20
changes that cannot be applied. For example, a modify request for an=20
entry may arrive before the add request that creates that entry. The=20
replication system will typically queue this change and wait for=20
additional changes (see Section 3.3). =20
=20
3 Naming Considerations=20
=20
A number of naming models have been proposed for directories=20
([RFC1255], [RFC2377]), and many others have been implemented on an ad=20
hoc basis. Each of these models specifies the naming attributes to be=20
used and provides rules for using them which may also include=20
containment rules. =20
=20
The naming plan applies to the directory as a whole, not the=20
individual servers holding replicas. Therefore, in a heterogeneous=20
replicated environment, all of the replicating servers must be capable=20
of supporting all of the rules for the naming plan in use for that=20
directory.=20
=20
Some directory implementations have naming constraints (e.g.=20
containment rules, restrictions on attributes that can be used for=20
naming). If such an implementation is part of a replicated directory,=20
those constraints will have to be observed by all participating=20
directories. If the environment contains implementations with=20
incompatible constraints there is a major problem. This should be=20
checked as early in the design phase as possible. =20
=20
Huber, et al Expires December 2003 [Page 6] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
Applications often have their own requirements on naming; if a=20
directory supports multiple applications it may have to support=20
multiple naming schemes. Thus, if two independent applications start=20
sharing previously separate directory information, care should be=20
taken that the naming is consistent across the applications. A=20
difference in name form may be accepted through LDUP without=20
constraint violation, but nevertheless result in unexpected behavior=20
from a cross-application perspective. Consistent naming is not only=20
important to the directory, but to the applications that consume=20
directory information as well. =20
=20
4 Conflict Resolution Considerations=20
=20
4.1 Consistent Access after Changes=20
=20
Many operations on a directory are done as a set of steps. For=20
example, a new object may be created by one operation, and its values=20
may be filled in as part of a separate LDAP operation. An=20
administrator may add a user to a directory, and that user may then=20
try to log in using the new entry.=20
=20
Replicated LDAP directories provide loose consistency [RFC3384]. A=20
new entry or a change to an existing entry will not reach all replicas=20
immediately; there will be some delay before changes are available on=20
all replicas. Changes made (e.g. adding a new user) on one physical=20
system may appear to be "lost" if checked on another physical system=20
before replication is complete.=20
=20
In general, LDAP applications should be prepared to operate correctly=20
in the face of replication delays. In some cases, this means=20
designing to allow for delay. In the case of the newly created user,=20
it should be standard practice to ask the user to wait a while before=20
trying to use the entry. In the case where the new object must be=20
filled in, the application should make appropriate use of LDAP=20
sessions to make sure that the same server is reached for both=20
operations.=20
=20
As a general rule, an LDAP application should bind once and not unbind=20
until a complete set of related operations have been performed. To=20
achieve load balancing of write operations in a multi-master=20
environment, balancing the write-enabled connections is recommended=20
over balancing the individual LDAP write operations.=20
=20
In the single-master case, all write requests go to one server. If a=20
set of related reads and writes are done, they should all be done on=20
the master if possible. =20
=20
In some cases, related requests will deal with data in different=20
partitions that are not all available on a single server. In this=20
case, it is safer to keep sessions open to all servers rather than=20
Huber, et al Expires December 2003 [Page 7] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
closing the session with one server and opening one with another=20
server.=20
=20
It may not always be obvious to clients that they are using different=20
servers. If a load distribution system is used between the client and=20
the server, the client may find that a change request and a subsequent=20
lookup are directed to different physical servers even though the=20
original requests were sent to the same server name and/or address.=20
=20
Since LDAP is session oriented, any load distribution system used=20
should take sessions into account. Thus, keeping all related read and=20
write requests within a single bind/unbind session should be the goal=20
in this situation as well.=20
=20
4.2 Conflict Resolution in Single-Master Systems=20
=20
It is possible that resolution conflicts could occur in a single=20
master replication system. Because requirement SM2 of [RFC3384] is a=20
"SHOULD" and not a "MUST", it is possible for implementers to reorder=20
changes. If changes are reordered, it is quite possible for a=20
conflict to occur. Consider a case where schema changes are declared=20
critical and must be moved to the front of the replication queue. =20
Then the consumer servers might have to delete an attribute that still=20
has values, and later process requests to delete the values of that=20
now undefined attribute.=20
=20
However, directory administrators may have scenarios where re-ordering=20
of replication information is desirable. On a case-by-case basis, the=20
directory administrator should make such decisions.=20
=20
Many vendors may not implement conflict resolution for single-master=20
replication. If such a system receives out-of-order changes from a=20
system that does support them, replication errors will almost=20
certainly occur. Designers should be aware that mismatches in the=20
capabilities of replicating single-master directories could cause=20
problems. Designs should not permit the master to re-order changes=20
unless all slave copies are known to handle the situation correctly.=20
=20
4.3 Problem Cases=20
=20
4.3.1 Atomicity=20
=20
The fact that replication does not guarantee the time order arrival of=20
changes at a consumer allows situations where changes that were=20
applied successfully at the supplier may fail in part when an attempt=20
is made to apply the same change at the consumer. Some examples=20
appear below; additional examples are given in Appendix B.5 of=20
[RFC3384].=20
=20
4.3.1.1 Locking=20
=20
Huber, et al Expires December 2003 [Page 8] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
There is an entry with distinguished name "DN" that contains=20
attributes X, Y, and Z. The value of X is 1. On replica A, a=20
ModifyRequest is processed which includes modifications to change that=20
value of X from 1 to 0 and to set the value of Y to "USER1". At the=20
same time, replica B processes a ModifyRequest which includes=20
modifications to change the value of X from 1 to 0 and to set the=20
value of Y to "USER2" and the value of Z to 42. The application in=20
this case is using X as a lock and is depending on the atomic nature=20
of ModifyRequests to provide mutual exclusion for lock access.=20
=20
In the single-server case, the two operations would have occurred=20
sequentially. Since a ModifyRequest is atomic, the entire first=20
operation would succeed. The second ModifyRequest would fail, since=20
the value of X would be 0 when it was attempted, and the modification=20
changing X from 1 to 0 would thus fail. The atomicity rule would=20
cause all other modifications in the ModifyRequest to fail as well.=20
=20
In the multi-master case, it is inevitable that at least some of the=20
changes will be reversed despite the use of the lock. Assuming the=20
changes from A have priority per the conflict resolution algorithm,=20
the value of X should be 0 and the value of Y should be "USER1" But=20
what is the value of Z at the end of the replication cycle? If it is=20
42, then the atomicity constraint on the change from B has been=20
violated. But for it to revert to its previous value, grouping=20
information must be retained. Therefore, it is not clear when such=20
information may be safely discarded. Thus, requirement G6 in=20
[RFC3384] may be violated.=20
=20
The utility of locking mechanisms cannot be guaranteed with multi-
master replication, and therefore results are likely to be misleading. =20
As discussed further in section 6.1 below, its use in multi-master=20
environments should be deprecated.=20
=20
4.3.1.2 Partitioning=20
=20
Partitioning (design of replica groups) also adds complexity. For=20
example, suppose two servers, A and B, are members of a replica-group=20
for area of replication X while servers B and C are members of=20
replica-group for area Y. It is possible to issue a ModifyRDN=20
operation on server B that moves an entry from area X to area Y. =20
Replication in area X would delete the entry on server A while=20
replication in area Y would add the entry to server C. However, if=20
another change on server C prevented the add operation from working=20
(e.g. an entry with the same RDN but a different GUID exists there=20
already), then the change on server A is inconsistent and will need to=20
be reversed. Other examples of cases of this class include group=20
membership modification and access control scope. =20
=20
4.4 General Principles=20
=20
Huber, et al Expires December 2003 [Page 9] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
The examples above discuss some of the most difficult problems that=20
can arise in multi-master replication. Dealing with them is difficult=20
and can lead to situations that are quite confusing to the application=20
and to users.=20
=20
The common characteristics of the examples [RFC3384] are:=20
=20
1. Several directory users/applications are changing the same data=20
2. They are changing the data at the same time=20
3. They are using different directory servers to make these changes=20
4. They are changing data that are parts of a distinguished name or=20
they are using ModifyRequest to both read and write a given=20
attribute value in a single atomic request.=20
=20
If any one of these conditions is reversed, the types of problems=20
described above will not occur. There are many useful applications of=20
multi-master directories where at least one of the above conditions=20
does not occur or where careful design can reverse one of the=20
conditions. If, for example, all atomic read/modify requests for a=20
given object can be directed to the same server, condition 3 will not=20
occur. For cases where all four conditions do occur, application=20
designers should be aware of the possible consequences.=20
=20
5 Failover Considerations=20
=20
One of the major reasons to use directory replication is to improve=20
reliability of the directory system as a whole. Replication permits=20
hot- and warm-standby configurations to be built easily.=20
=20
But there are some issues that must be considered during design. In=20
this situation, single-master systems actually raise more concerns=20
than multi-master. Both are addressed below.=20
=20
5.1 Common Issues=20
=20
In both the single- and multi-master cases, clients must be able to=20
find an alternate quickly when a server fails. Some possible ways to=20
do this are detailed in [FindingLDAP] and [LDAPinDNS]. If all else=20
fails, a list of possible servers can be built into client=20
applications. Designers should consider how clients are notified that=20
the server is again available.=20
=20
When the failed server comes back up, it is brought back into=20
synchronization with the other servers and is ready to take requests. =20
It is always possible that the failed server, if it was acting as a=20
supplier, was unable to completely distribute its pending changes=20
before removal from service, leaving its consumers in an inconsistent=20
state. During the period between its removal from service and its=20
eventual return, the inconsistency may have been compounded by further=20
application activity. At the time of publication there is no standard=20
automatic mechanism to rectify the problem, so the administrator must=20
Huber, et al Expires December 2003 [Page 10] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
use whatever mechanism is available to compare the replicas for=20
consistency as soon after the event as is reasonable.=20
=20
Note that the process used to bring a failed server back into=20
replication can also be used to add a server to a set of replicating=20
servers. In this case, the new server might be initialized from a=20
backed-up copy of the directory or it may acquire the entire DIB via=20
replication. The former method is usually preferable when the=20
directory is large. =20
5.2 Single Master Issues=20
=20
In a single-master system, the master is a single point of failure, as=20
all modification has to originate at the master server. When high=20
availability is a requirement, a quick, automated failover process for=20
converting a slave replica to a new master is desirable, as the=20
failover time becomes a major factor in determining system=20
availability. The considerations in section 5.1 apply here; clients=20
must know how to find the new master or a new slave in case of=20
failure.=20
=20
To aid in promotion of a slave replica, the master could replicate=20
control information and meta-data (including replication credentials)=20
so that this information is available during failover promotion. This=20
data may either be replicated on a single "failover designate" slave=20
(which would become the master during failover) or it could be=20
replicated to all slaves. The first possibility has the advantage of=20
minimizing the amount of extra replication while the second more=20
robustly handles multiple failovers (i.e. failover of the newly=20
promoted master to another slave before the original master has been=20
restored). If this method is followed, data privacy mechanisms should=20
be used to protect the replication session.=20
=20
If data privacy mechanisms (e.g. encryption) are used to protect the=20
replication session, the new master must have the necessary key=20
information. Further this key information should be independent of=20
the master that is using it (i.e. not tied to the IP address of the=20
master server). If it is not independent, slave replicas could be=20
pre-configured with the keys for all possible masters to reduce=20
failover time. =20
=20
Restoration of the failed or broken master can be handled in one of=20
two ways:=20
=20
- It could join the replica group and function as a slave.=20
- It could join the replica group and negotiate with the new master=20
to synchronize and then take over as master.=20
=20
In either case, clients need a way to know that a new server is=20
available. If the broken master is returned to service as a slave,=20
then the administrator must, external to LDUP, distribute and resolve=20
whatever pending changes remained undistributed and unresolved from=20
Huber, et al Expires December 2003 [Page 11] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
the time immediately before it was removed from service. If the broken=20
master is returned as a new master, then care must be taken with its=20
replacement master to ensure that all of its pending changes are=20
distributed and resolved before it is returned to duty as a slave.=20
=20
The slave replicas may also use the replication agreement to filter=20
which master is allowed to submit changes. Such a model allows the=20
slave servers to function correctly when the master server is "broken"=20
and sending out incorrect updates. However, then it is necessary to=20
update the replication agreement during the fail over process so that=20
the slaves will accept updates from the new master. This is the case=20
for both the original failure and the restoration of the restored=20
master if that is how the restored master rejoins the replica group.=20
=20
5.3 Multi-Master Issues=20
=20
Typically, a multi-master configuration is used when high availability=20
is required for writes as well as reads in the directory. Because=20
there are multiple active servers prepared to take write requests,=20
there is no "switchover" time in this case. But clients still need to=20
be able to find an alternate server, so the considerations of Section=20
5.1 apply here.=20
=20
6 Other Issues=20
=20
6.1 Locking=20
=20
Section 4.3.1.1 discussed the problems that can arise when the=20
"modify" command in LDAP is used for locking in a multi-master=20
environment. There are more general principles at work there. LDAP=20
is a distributed and replicated directory service that is typically=20
described as "loosely consistent". =20
=20
In loose consistency, the data should eventually converge among the=20
replicas, but at any given instant, replicas may be in disagreement. =20
This stipulation is the general result of:=20
=20
1. Delay due to replication intervals =20
2. Out of natural time order arrival of data at a replica=20
3. Temporary isolation of distributed systems from one another=20
4. Failure to accept a change due to conflict resolution failure on=20
a replica=20
=20
Because of loose consistency, data encountered by an LDAP operation=20
may differ among replicas. Multi-mastering may exacerbate loose=20
consistency, but single-mastering will not totally eliminate it if=20
out-of-order replication is allowed (see Section 4.2). One must=20
carefully assess the effect of loose consistency when considering the=20
use of distributed LDAP servers as a data store. Applications which=20
depend on synchronous consistency may be better suited for=20
transactional models and/or non-distributed data.=20
Huber, et al Expires December 2003 [Page 12] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
=20
=20
6.2 Backup and Restore=20
=20
Backup of a directory server should have the following goals:=20
=20
1. The directory (or the replica) can be unambiguously and=20
faithfully restored from the backup.=20
2. The backup is an internally consistent snapshot of an entire=20
replica during the time interval it took to make it. =20
3. Replication can resume on a machine restored from that backup=20
without information loss.=20
=20
Backup and restore of a single, operating directory server (rather=20
than the entire directory system) presents its own challenges. "Loose=20
consistency" works against the probability of achieving a loss-free=20
copy of all the data in the directory, except under ideal conditions. =20
Backup and restore of distributed directories is a decidedly easier=20
task when the constraint of continuous availability is removed. In=20
most cases, the removal of entire directory systems from write service=20
is impossible, even for small periods of time. It is more practical=20
to remove a single replica from service to achieve a condition of=20
quiescence. Once all write load is removed, including write load due=20
to replication, an internally consistent copy of the data may be=20
obtained.=20
=20
Replicas that have suffered catastrophic data loss may be restored=20
from backups of working ones temporarily removed from service=20
specifically to make a copy. This scenario illustrates the benefit of=20
having three or more master replicas in the system: no single point of=20
write failure in the event that one of the replicas must be restored=20
from a copy of another.=20
=20
The M11 requirement from [RFC3384] allows an empty replica to be=20
brought up to date through replication. This feature duplicates, but=20
does not make entirely unnecessary, backup procedures on directory=20
servers. Backups are still needed to recover data that has been lost=20
to all replicas, either through normal LDAP updates or through some=20
catastrophic event. =20
=20
7 Impact of Non-LDAP Changes/Constraints=20
=20
7.1 Changes Outside of LDAP=20
=20
LDAP directories are typically built on top of some database or file=20
system. Thus there are ways to change the data that do not go through=20
the normal LDAP change mechanisms (e.g. ModifyRequest). If the data=20
is modified outside of LDAP, the changes will not be checked for=20
schema conformance nor will access controls be checked as the changes=20
are made. Since both integrity and security checks are omitted,=20
security can be adversely affected.=20
Huber, et al Expires December 2003 [Page 13] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
=20
Also, many systems use the normal LDAP modification mechanisms to=20
trigger replication. Changes made using non-LDAP mechanisms may not=20
be replicated at all, leading to inconsistencies between replica=20
copies.=20
=20
7.2 Application Triggers=20
=20
Directory servers commonly integrate one or more specific=20
applications. To achieve this integration the directory server may=20
intercept updates and run application-specific "trigger" code. Such=20
triggers enforce directory invariants that cannot be expressed by the=20
LDAP schema.=20
=20
A simple trigger example is password policy enforcement. A directory=20
server might interpret a request to replace the current value of the=20
userPassword attribute with some new value as a request to first check=20
that the new value conforms to the server's password policy (e.g. the=20
value is sufficiently long and complex) before storing the new value.=20
Using this trigger the directory server voids the security risk=20
associated with passwords that are easy to attack.=20
=20
A more complex trigger example is password hashing. A directory=20
server might interpret a request to replace the current value of the=20
userPassword attribute with some new value as a request to compute one=20
or more secure hashes of the new value and store these hashes in one=20
or more attributes, storing no value in the userPassword attribute. =20
Using this trigger the directory server avoids the security exposure=20
of storing the plaintext password.=20
=20
Replication between directory servers with different application=20
triggers will compromise directory integrity.=20
=20
Similarly, one cannot extend the directory with stored procedures that=20
execute on access - such as scripts, programs or controls which change=20
the data - because the expression of such mechanisms may not be=20
guaranteed to be consistent among heterogeneous servers.=20
=20
7.3 Policy Conflicts Across Servers=20
=20
In addition to the discussions of ACI in Section 2.3 and triggering in=20
section 7.2, LDUP replication can not (by its definition) handle=20
replication of information that makes use of policy not expressible in=20
the LDAP protocol. A prime example of this is security encoding of=20
attributes (e.g. userPassword). This encoding is typically=20
implementation specific and is not easily expressible via the LDAP=20
protocol. Therefore replication of userPassword attributes between=20
directory servers that use different encoding schemes will impede=20
replication in a way that is not describable as schema or syntax=20
mismatch. This is because of the bind-time policy semantics that are=20
the true point of conflict.=20
Huber, et al Expires December 2003 [Page 14] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
=20
In general, any attribute with semantics that are outside the scope of=20
what is expressible by the LDAP protocol could result in strange=20
replication errors. Therefore, distributed directory implementers=20
should (in the absence of a way to express such semantics) either=20
strive for a homogeneous set of servers or ensure during acceptance=20
testing that a new server can support the existing semantics of their=20
directory.=20
=20
8 Security Considerations=20
=20
This document discusses issues that arise in replication. Some of=20
these issues are security related (e.g. replication of access control=20
information) and the security implications are discussed in the=20
relevant sections.=20
=20
9 Acknowledgements=20
=20
This document owes a lot to discussions on the LDUP mailing list. In=20
particular, the authors would like to thank Ed Reed, whose email to=20
the mailing list drove much of section 6.1, and Mark Brown for=20
identifying and generating text on the issues discussed in section 7.=20
=20
10 References=20
=20
[FindingLDAP] R. Moats, R. Hedberg, "A Taxonomy of Methods for LDAP=20
Clients Finding Servers", Internet Draft, draft-ietf-ldapext-ldap-
taxonomy-05.txt, July 2001.=20
=20
[InfoMod] R. Moats, R. Huber, J. McMeeking, "LDUP Replication=20
Information Model", Internet Draft, draft-ietf-ldup-infomod-07.txt,=20
June 2003.=20
=20
[LDAPinDNS] M. Armijo, L. Esibov, P. Leach, R. L. Morgan,=20
"Discovering LDAP Services with DNS", Internet Draft, draft-ietf-
ldapext-locate-05.txt, March 2001.=20
=20
[RFC1255] The North American Directory Forum, "A Naming Scheme for=20
c=3DUS", RFC 1255, September 1991.=20
=20
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access=20
Protocol", RFC 2251, December 1997.=20
=20
[RFC2377] A. Grimstad, R. Huber, S. Sataluri, M. Wahl, "Naming Plan=20
for Internet Directory-Enabled Applications", RFC 2377, September=20
1998. =20
=20
[RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behara, =93Access Control=
=20
Requirements for LDAP=94, RFC2820. May 2000.=20
=20
Huber, et al Expires December 2003 [Page 15] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
[RFC3384] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3=20
Replication Requirements", RFC 3384, October 2002.=20
=20
Authors' Addresses=20
=20
Richard V. Huber=20
Room C3-3B30=20
AT&T Laboratories=20
200 Laurel Avenue South=20
Middletown, NJ 07748=20
USA=20
E-Mail: [email protected]=20
Telephone: +1 732 420 2632=20
Fax: +1 732 368 1690=20
=20
Gerald F. Maziarski=20
Room C3-3Z01=20
AT&T Laboratories=20
200 Laurel Avenue South=20
Middletown, NJ 07748=20
USA=20
E-Mail: [email protected]=20
Telephone: +1 732 420 2162=20
Fax: +1 732 368 1690=20
=20
Ryan D. Moats=20
Lemur Networks=20
15621 Drexel Circle=20
Omaha, NE 68135=20
USA=20
E-Mail: [email protected]=20
Telephone: +1 402 894 9456=20
=20
Full Copyright Statement=20
=20
Copyright (C) The Internet Society (2000). All Rights Reserved.=20
=20
This document and translations of it may be copied and furnished to=20
others, and derivative works that comment on or otherwise explain it=20
or assist in its implementation may be prepared, copied, published and=20
distributed, in whole or in part, without restriction of any kind,=20
provided that the above copyright notice and this paragraph are=20
included on all such copies and derivative works. However, this=20
document itself may not be modified in any way, such as by removing=20
the copyright notice or references to the Internet Society or other=20
Internet organizations, except as needed for the purpose of developing=20
Internet standards in which case the procedures for copyrights defined=20
in the Internet Standards process must be followed, or as required to=20
translate it into languages other than English.=20
=20
Huber, et al Expires December 2003 [Page 16] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication September 2003=20
=20
The limited permissions granted above are perpetual and will not be=20
revoked by the Internet Society or its successors or assigns.=20
=20
This document and the information contained herein is provided on an=20
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT=20
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN=20
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20
=20
Acknowledgement=20
=20
Funding for the RFC Editor function is currently provided by the=20
Internet Society.=20
Huber, et al Expires December 2003 [Page 17] =0C
--------------B91BA20B2C46E9D224D677FE--