New version of Usage Profiles draft
Richard Huber <[email protected]> Fri, 27 Jun 2003 11:16:56 -0400
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------B7C14604984AFA48B1E12206
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Internet Drafts Editor -
Please publish the attached as draft-ietf-ldup-usage-profile-05.txt.
LDUP -
Most changes in the attached draft are to bring the references up to
date. A few other editorial changes.
Rick Huber
--------------B7C14604984AFA48B1E12206
Content-Type: text/plain; charset=iso-8859-1;
name="draft-ietf-ldup-usage-profile-05.txt"
Content-Disposition: inline;
filename="draft-ietf-ldup-usage-profile-05.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h5RFJIrb047811
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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: December 2003 Lemur Networks
June 2003
=20
=20
=20
General Usage Profile for LDAPv3 Replication=20
draft-ietf-ldup-usage-profile-05.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.=20
Huber, et al Expires December 2003 [Page 1] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=20
Table of Contents
1 Introduction........................................................2=20
2 Meta-data Considerations............................................3=20
2.1 Schema Considerations...........................................3=20
2.2 Replication Agreements..........................................4=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...................................................9=20
4.3.1 Atomicity....................................................9=20
4.3.1.1 Locking..................................................9=20
4.3.1.2 Partitioning............................................10=20
4.4 General Principles.............................................10=20
5 Failover Considerations............................................10=20
5.1 Common Issues..................................................11=20
5.2 Single Master Issues...........................................11=20
5.3 Multi-Master Issues............................................13=20
6 Other Issues.......................................................13=20
6.1 Locking........................................................13=20
6.2 Backup and Restore.............................................14=20
7 Impact of Non-LDAP Changes/Constraints.............................14=20
7.1 Changes Outside of LDAP........................................14=20
7.2 Application Triggers...........................................15=20
7.3 Policy Conflicts Across Servers................................15=20
8 Security Considerations............................................16=20
9 Acknowledgements...................................................16=20
10 References........................................................16=20
Authors' Addresses...................................................17=20
Full Copyright Statement.............................................18=20
=20
=20
1 Introduction=20
=20
As LDAP directories become part of the critical infrastructure for=20
applications maintaining high reliability and availability is=20
significant. =20
=20
Distributed, replicated directories can reduce reliability and=20
capacity problems. However, applications that work well with a=20
single, standalone directory can develop problems in a distributed=20
environment unless both the applications and the environment are=20
carefully designed. =20
=20
Huber, et al Expires December 2003 [Page 2] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=20
While particular areas of concern depend partly on whether the=20
distributed directory is a single-master or multi-master system most=20
concerns that are common to both. This document flags some issues as=20
being specific to either single-master or multi-master directories. =20
Unflagged issues pertain to both.=20
=20
The current replication framework provides no easily separable subset=20
of functions for single-master and multi-master replication, therefor=20
this addresses general issues regarding the deployment of single-
master and multi-master directory systems. There may be additional=20
drafts in the future that address specific applications.=20
=20
=20
2 Meta-data Considerations=20
=20
Any LDAP directory contains meta-data as well as the user data in the=20
directory. Examples of this meta-data include descriptions of the=20
data in the directory (e.g. schema), policies for use of the data=20
(e.g. access controls), and configuration/status information (e.g.=20
replication agreements); this is not an exhaustive list. =20
=20
This meta-data is stored in the directory itself, frequently=20
accessible as regular data or as operational attributes. Issues arise=20
when meta-data stored in the directory is replicated. However, not=20
replicating meta-data also causes issues to arise.=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
homogeneous schema because of directory vendors' built-in extensions.=20
A given directory may not utilize all of the elements of its schema,=20
so 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=20
distribute schema changes through that mechanism. Currently there is=20
no standard for LDAP schema representation within the=20
subschemaSubentry. In the absence of such a standard, full schema=20
interoperability is not possible in the IETF sense. Directory=20
Huber, et al Expires December 2003 [Page 3] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=20
designers should establish common schema on all servers holding a=20
replica. =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]. However, not all schema=20
differences 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 may result in data corruption due to a schema mismatch. =20
=20
Here are some options for dealing with such potential mismatches:=20
=20
- Use fractional replication to replicate only those attributes=20
that do not have differences=20
- Removal of 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
2.2 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
Huber, et al Expires December 2003 [Page 4] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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 protected in the directory and transport of=20
the replication agreement should be encrypted.=20
=20
When replication agreements are themselves distributed via=20
replication, they are subject to same "loose consistency" problems=20
(due to replication delay and deferred conflict resolution) as other=20
data. Even a temporary inconsistency among replication agreements may=20
cause 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
2.3 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
- Thus, if you aren't careful, you can leave windows where data is=20
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
=20
Huber, et al Expires December 2003 [Page 5] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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.4 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], [CIMNames]), and many others have been=20
implemented on an ad hoc basis. Each of these models specifies the=20
naming attributes to be used and provides rules for using them which=20
may also include 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
Huber, et al Expires December 2003 [Page 6] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
Applications often have their own requirements on naming; in this case=20
the directory will have to support multiple naming schemes. Thus, if=20
two independent applications start sharing previously separate=20
directory information, care should be taken that the naming is=20
consistent across the applications. A difference in name form may be=20
accepted through LDUP without constraint violation, but nevertheless=20
result in unexpected behavior from a cross-application perspective. =20
Consistent naming is not only important to the directory, but to the=20
applications that consume directory information as well. =20
=20
4 Conflict Resolution Considerations=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 LDAP write operations.=20
Huber, et al Expires December 2003 [Page 7] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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. Ideally, only sets of related operations that=20
cannot include a write should go to one of the slave servers. But=20
load balancing concerns may make this impractical. =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
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
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
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
Huber, et al Expires December 2003 [Page 8] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
4.3 Problem Cases=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
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
Huber, et al Expires December 2003 [Page 9] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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 scoping. =20
4.4 General Principles=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 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
Huber, et al Expires December 2003 [Page 10] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
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. As there is no current automatic mechanism to=20
rectify the problem, the administrator should use whatever mechanism=20
is available to compare the replicas for consistency as soon after the=20
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
Huber, et al Expires December 2003 [Page 11] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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 in 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
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
Huber, et al Expires December 2003 [Page 12] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
6 Other Issues=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. The delay due to replication or extended replication intervals =20
2. The out of natural time order arrival of data at a replica=20
3. The 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 preconditions to an LDAP operation=20
may differ among replicas. Multi-mastering may exacerbate this=20
situation, but single-mastering will not totally eliminate it if out-
of-order replication is allowed (see Section 4.2). One must carefully=20
assess the effect of loose consistency when evaluating operations that=20
place specific preconditions on data to work correctly. Applications=20
which depend on such operations may be better suited for transactional=20
models and/or non-distributed data.=20
=20
Distributed locking is one operation that depends on strict data=20
preconditions. When data preconditions cannot be guaranteed, the lock=20
is moot. The same principles hold for "atomic operations", defined=20
here as any mix of allowable operations contained within the same LDAP=20
PDU. RFC2251 requires that they either all fail or are applied as a=20
unit. If strict data preconditions cannot be guaranteed, then the=20
atomic operation may itself result in a further inconsistency=20
requiring human intervention at one of the consumers.=20
Huber, et al Expires December 2003 [Page 13] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=20
6.2 Backup and Restore=20
=20
Backup of a directory server should have the following goals:=20
=20
1. It can be unambiguously and faithfully restored.=20
2. It is an internally consistent snapshot of an entire replica=20
during the time interval it took to make it. This can only be=20
achieved if the server is quiescent. =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 directory server from service to achieve a=20
condition of quiescence. Once all write load is removed, including=20
write load due to replication, an internally consistent copy of the=20
data may be obtained.=20
=20
Replicas that have suffered catastrophic data loss may be restored=20
from backups of working servers temporarily removed from service=20
specifically to make a copy. This scenario illustrates the benefit of=20
having three or more replicas in the system: no single point of write=20
failure in the event that one of the replicas must be restored from a=20
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
Huber, et al Expires December 2003 [Page 14] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
=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
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
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
Huber, et al Expires December 2003 [Page 15] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
=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
=20
[CIMNames] Desktop Management Task Force, "Guidelines for CIM-to-LDAP=20
Directory Mappings", DMTF Specification DSP0100, May 2000 (available=20
online at http://www.dmtf.org/spec/DEN/DSP0100.htm).=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
Huber, et al Expires December 2003 [Page 16] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=20
[RFC3384] E. Stokes, R. Weiser, R. Moats, R. Huber, "LDAPv3=20
Replication Requirements", RFC 3384, October 2002.=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
[RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behara, =93Access Control=
=20
Requirements for LDAP=94, RFC2820. May 2000.=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
=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
Huber, et al Expires December 2003 [Page 17] =0C
INTERNET DRAFT Gen'l Usage Profile for LDAP Replication June 2003=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
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 18] =0C
--------------B7C14604984AFA48B1E12206--