collective attributes appearing in collective attribute subentries.
4.4. Access and Other Administrative Controls
Entries are commonly subject to access and other administrative
Controls. While portions of the policy information governing a
particular entry may be held in the entry, policy information is
often held elsewhere (in superior entries, in subentries, in the root
DSE, in configuration files, etc.). Because of this, changes to
policy information make it difficult to ensure eventual convergence
during incremental synchronization.
Where it is impractical or infeasible to generate content changes
resulting from a change to policy information, servers may opt to
return e-syncRefreshRequired or to treat the Sync Operation as an
initial content request (e.g., ignore the cookie or the
synchronization state represented in the cookie).
5. Interaction with Other Controls
The Sync Operation may be used with:
- ManageDsaIT Control [RFC3296]
- Subentries Control [RFC3672]
as described below. The Sync Operation may be used with other LDAP
extensions as detailed in other documents.
5.1. ManageDsaIT Control
The ManageDsaIT Control [RFC3296] indicates that the operation acts
upon the DSA Information Tree and causes referral and other special
entries to be treated as object entries with respect to the
operation.
5.2. Subentries Control
The Subentries Control is used with the search operation "to control
the visibility of entries and subentries which are within scope"
[RFC3672]. When used with the Sync Operation, the subentries control
and other factors (search scope, filter, etc.) are used to determine
whether an entry or subentry appears in the content.
6. Shadowing Considerations
As noted in [RFC4511], some servers may hold shadow copies of entries
that can be used to answer search and comparison queries. Such
servers may also support content synchronization requests. This
section discusses considerations for implementors and deployers for
the implementation and deployment of the Sync operation in shadowed
directories.
While a client may know of multiple servers that are equally capable
of being used to obtain particular directory content from, a client
SHOULD NOT assume that each of these servers is equally capable of
continuing a content synchronization session. As stated in Section
3.1, the client SHOULD issue each Sync request of a Sync session to
the same server.
However, through domain naming or IP address redirection or other
techniques, multiple physical servers can be made to appear as one
logical server to a client. Only servers that are equally capable in
regards to their support for the Sync operation and that hold equally
complete copies of the entries should be made to appear as one
logical server. In particular, each physical server acting as one
logical server SHOULD be equally capable of continuing a content
synchronization based upon cookies provided by any of the other
physical servers without requiring a full reload. Because there is
no standard LDAP shadowing mechanism, the specification of how to
independently implement equally capable servers (as well as the
precise definition of "equally capable") is left to future documents.
Note that it may be difficult for the server to reliably determine
what content was provided to the client by another server, especially
in the shadowing environments that allow shadowing events to be
coalesced. For these servers, the use of the delete phase discussed
in Section 3.3.2 may not be applicable.
7. Security Considerations
In order to maintain a synchronized copy of the content, a client is
to delete information from its copy of the content as described
above. However, the client may maintain knowledge of information
disclosed to it by the server separate from its copy of the content
used for synchronization. Management of this knowledge is beyond the
scope of this document. Servers should be careful not to disclose
information for content the client is not authorized to have
knowledge of and/or about.
While the information provided by a series of refreshOnly Sync
Operations is similar to that provided by a series of Search
Operations, persist stage may disclose additional information. A
client may be able to discern information about the particular
sequence of update operations that caused content change.
Implementors should take precautions against malicious cookie
content, including malformed cookies or valid cookies used with
different security associations and/or protections in an attempt to
obtain unauthorized access to information. Servers may include a
digital signature in the cookie to detect tampering.
The operation may be the target of direct denial-of-service attacks.
Implementors should provide safeguards to ensure the operation is not
abused. Servers may place access control or other restrictions upon
the use of this operation.
Note that even small updates to the directory may cause a significant
amount of traffic to be generated to clients using this operation. A
user could abuse its update privileges to mount an indirect denial of
service to these clients, other clients, and/or portions of the
network. Servers should provide safeguards to ensure that update
operations are not abused.
Implementors of this (or any) LDAP extension should be familiar with
general LDAP security considerations [RFC4510].
8. IANA Considerations
Registration of the following values have been completed by the IANA
[RFC4520].
8.1. Object Identifier
The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
OpenLDAP Foundation, under its IANA-assigned private enterprise
allocation [PRIVATE], for use in this specification.
8.2. LDAP Protocol Mechanism
The IANA has registered the LDAP Protocol Mechanism described in this
document.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
Description: LDAP Content Synchronization Control
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
8.3. LDAP Result Codes
The IANA has registered the LDAP Result Code described in this
document.
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Result Code Name: e-syncRefreshRequired (4096)
Specification: RFC 4533
Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
Comments: none
9. Acknowledgements
This document borrows significantly from the LDAP Client Update
Protocol [RFC3928], a product of the IETF LDUP working group. This
document also benefited from Persistent Search [PSEARCH], Triggered
Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
This document also borrows from "Lightweight Directory Access
Protocol (v3)" [RFC2251].
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3296] Zeilenga, K., "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP)
Directories", RFC 3296, July 2002.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Cancel Operation", RFC 3909, October 2004.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) entryUUID Operational Attribute", RFC 4530, June
2006.
[UUID] International Organization for Standardization (ISO),
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996
[X.501] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory -- Models,"
X.501(1993) (also ISO/IEC 9594-2:1994).
[X.680] International Telecommunication Union - Telecommunication
Standardization Sector, "Abstract Syntax Notation One
(ASN.1) - Specification of Basic Notation", X.680(1997)
(also ISO/IEC 8824-1:1998).
[X.690] International Telecommunication Union - Telecommunication
Standardization Sector, "Specification of ASN.1 encoding
rules: Basic Encoding Rules (BER), Canonical Encoding
Rules (CER), and Distinguished Encoding Rules (DER)",
X.690(1997) (also ISO/IEC 8825-1:1998).
11. Informative References
[RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J.
Parham, "Lightweight Directory Access Protocol (LDAP)
Client Update Protocol (LCUP)", RFC 3928, October 2004.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[X.500] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory -- Overview of
concepts, models and services," X.500(1993) (also ISO/IEC
9594-1:1994).
[X.525] International Telecommunication Union - Telecommunication
Standardization Sector, "The Directory: Replication",
X.525(1993).
[DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
Synchronization", Work in Progress.
[PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP
Change Notification Mechanism", Work in Progress.
[TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in
Progress.
Appendix A. CSN-based Implementation Considerations
This appendix is provided for informational purposes only; it is not
a normative part of the LDAP Content Synchronization Operation’s
technical specification.
This appendix discusses LDAP Content Synchronization Operation server
implementation considerations associated with Change Sequence Number
based approaches.
Change Sequence Number based approaches are targeted for use in
servers that do not maintain history information (e.g., change logs,
state snapshots) about changes made to the Directory and hence, must
rely on current directory state and minimal synchronization state
information embedded in Sync Cookie. Servers that maintain history
information should consider other approaches that exploit the history
information.
A Change Sequence Number is effectively a time stamp that has
sufficient granularity to ensure that the precedence relationship in
time of two updates to the same object can be determined. Change
Sequence Numbers are not to be confused with Commit Sequence Numbers
or Commit Log Record Numbers. A Commit Sequence Number allows one to
determine how two commits (to the same object or different objects)
relate to each other in time. A Change Sequence Number associated
with different entries may be committed out of order. In the
remainder of this Appendix, the term CSN refers to a Change Sequence
Number.
In these approaches, the server not only maintains a CSN for each
directory entry (the entry CSN) but also maintains a value that we
will call the context CSN. The context CSN is the greatest committed
entry CSN that is not greater than any outstanding (uncommitted)
entry CSNs for all entries in a directory context. The values of
context CSN are used in syncCookie values as synchronization state
indicators.
As search operations are not isolated from individual directory
update operations and individual update operations cannot be assumed
to be serialized, one cannot assume that the returned content
incorporates each relevant change whose change sequence number is
less than or equal to the greatest entry CSN in the content. The
content incorporates all the relevant changes whose change sequence
numbers are less than or equal to context CSN before search
processing. The content may also incorporate any subset of the
changes whose change sequence number is greater than context CSN
before search processing but less than or equal to the context CSN
after search processing. The content does not incorporate any of the
changes whose CSN is greater than the context CSN after search
processing.
A simple server implementation could use the value of the context CSN
before search processing to indicate state. Such an implementation
would embed this value into each SyncCookie returned. We’ll call
this the cookie CSN. When a refresh was requested, the server would
simply generate "update" messages for all entries in the content
whose CSN is greater than the supplied cookie CSN and generate
"present" messages for all other entries in the content. However, if
the current context CSN is the same as the cookie CSN, the server
should instead generate zero "updates" and zero "delete" messages and
indicate a refreshDeletes of TRUE, as the directory has not changed.
The implementation should also consider the impact of changes to meta
information, such as access controls, that affect content
determination. One approach is for the server to maintain a
context-wide meta information CSN or meta CSN. This meta CSN would
be updated whenever meta information affecting content determination
was changed. If the value of the meta CSN is greater than the cookie
CSN, the server should ignore the cookie and treat the request as an
initial request for content.
Additionally, servers may want to consider maintaining some per-
session history information to reduce the number of messages needed
to be transferred during incremental refreshes. Specifically, a
server could record information about entries as they leave the scope
of a disconnected sync session and later use this information to
generate delete messages instead of present messages.
When the history information is truncated, the CSN of the latest
truncated history information entry may be recorded as the truncated
CSN of the history information. The truncated CSN may be used to
determine whether a client copy can be covered by the history
information by comparing it to the synchronization state contained in
the cookie supplied by the client.
When there is a large number of sessions, it may make sense to
maintain such history only for the selected clients. Also, servers
taking this approach need to consider resource consumption issues to
ensure reasonable server operation and to protect against abuse. It
may be appropriate to restrict this mode of operation by policy.
Authors’ Addresses
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Jong Hyuk Choi
IBM Corporation
EMail: jongchoi@us.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).