Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)
RFC 4373
Document | Type |
RFC
- Informational
(January 2006)
Was
draft-rharrison-lburp
(individual in app area)
|
|
---|---|---|---|
Authors | Yulin Dong, Roger Harrison , Jim Sermersheim | ||
Last updated | 2018-12-20 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
IESG | Responsible AD | Ted Hardie | |
Send notices to | (None) |
RFC 4373
5.4.1. OperationResults When a response element is included in an LBURPUpdateResponse message, it contains the BER-encoding of the following ASN.1: OperationResults ::= SEQUENCE OF OperationResult OperationResult ::= SEQUENCE { operationNumber INTEGER, ldapResult LDAPResult } An OperationResult is included for each operation from the UpdateOperationList that failed during processing. 5.4.1.1. operationNumber The operationNumber identifies the LDAP update operation from the UpdateOperationList of the LBURPUpdateRequest that failed. Operations are numbered beginning at 1. 5.4.1.2. ldapResult The ldapResult included in the OperationResult is the same ldapResult that would be sent for the update operation that failed if it had failed while being processed as a normal LDAP update operation. LDAPResult is defined in [RFC2251], section 4.1.10. 5.5. EndLBURPRequest The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3. The requestValue contains the BER-encoding of the following ASN.1: EndLBURPRequestValue::= SEQUENCE { sequenceNumber INTEGER (1 .. maxInt) } 5.5.1. sequenceNumber The value in sequenceNumber is one greater than the last LBURPUpdateRequest.sequenceNumber in the update stream. It allows the server to know when it has received all outstanding asynchronous LBURPUpdateRequests. Harrison, et al. Informational [Page 10] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 5.6. EndLBURPResponse The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4. There is no response element in the EndLBURPResponse message. 6. Semantics of the Incremental Update Style The initial state of entries in the consumer's DIT plus the LBURPUpdateRequest messages in the update stream collectively represent the desired final state of the consumer's DIT. All LDAP update operations defined in [RFC2251]--Add, Modify, Delete, and Modify DN--are allowed in the incremental update stream. All of the semantics of those operations are in effect, so for instance, an attempt to add an entry that already exists will fail just as it would during a normal LDAP Add operation. 7. General LBURP Semantics The consumer server may take any action required to efficiently process the updates sent via LBURP, as long as the final state is equivalent to that which would have been achieved if the updates in the update stream had been applied to the DIT using normal LDAP update operations. The LBURPUpdateRequest messages that form the update stream MAY be sent asynchronously by the supplier to the consumer. This means that the supplier need not wait for an LBURPUpdateResponse message for one LBURPUpdateRequest message before sending the next LBURPUpdateRequest message. When the LBURP update stream contains a request that affects multiple Directory System Agents (DSAs), the consumer MAY choose to perform the request or return a resultCode value of affectsMultipleDSAs. As with any LDAP operation, a consumer MAY send a resultCode value of referral as part of the OperationResult element for any operation on an entry that it does not contain. If the consumer is configured to do so, it MAY chain on behalf of the supplier to complete the update operation instead. While a consumer server is processing an LBURP update stream, it may choose not to service LDAP requests on other connections. This provision is designed to allow implementers the freedom to implement highly-efficient methods of handling the update stream without being constrained by the need to maintain a live, working DIT database while doing so. Harrison, et al. Informational [Page 11] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 If a consumer chooses to refuse LDAP operation requests from other suppliers during LBURP update, it is RECOMMENDED that the consumer refer those requests to another server that has the appropriate data to complete the operation. Unless attribute values specifying timestamps are included as part of the update stream, updates made using LBURP are treated the same as other LDAP operations wherein they are deemed to occur at the present. Consumers MAY store timestamp values sent by suppliers but are not required to do so. Implementations may choose to perform the operations in the update stream with special permissions to improve performance. Consumer implementations should include functionality to detect and terminate connections on which an LBURP session has been initiated but information (such as the EndLBURPRequest) needed to complete the LBURP session is never received. A timeout is one mechanism that can be used to accomplish this. 8. Security Considerations Implementations should ensure that a supplier making an LBURP request is properly authenticated and authorized to make the updates requested. There is a potential for loss of data if updates are made to the DIT without proper authorization. If LBURP is used for replication, implementers should note that unlike other replication protocols, no existing replication agreement between supplier and consumer is required. These risks increase if the consumer server also processes the update stream with special permissions to improve performance. For these reasons, implementers should carefully consider which permissions should be required to perform LBURP operations and take steps to ensure that only connections with appropriate authorization are allowed to perform them. The data contained in the update stream may contain passwords and other sensitive data. Care should be taken to properly safeguard this information while in transit between supplier and consumer. The StartTLS [RFC2830] operation is one mechanism that can be used to provide data confidentiality and integrity services for this purpose. As with any asynchronous LDAP operation, it may be possible for an LBURP supplier to send asynchronous LBURPUpdateRequest messages to the consumer faster than the consumer can process them. Consumer implementers should take steps to prevent LBURP suppliers from interfering with the normal operation of a consumer server by issuing a rapid stream of asynchronous LBURPUpdateRequest messages. Harrison, et al. Informational [Page 12] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 9. IANA Considerations Registration of the following values has been made by the IANA [RFC3383]. 9.1. LDAP Object Identifier Registrations The IANA has registered LDAP Object Identifiers identifying the protocol elements defined in this technical specification. The following registration template was provided: Subject: Request for LDAP OID Registration Person & email address to contact for further information: Roger Harrison rharrison@novell.com Specification: RFC 4373 Author/Change Controller: IESG Comments: Seven delegations will be made under the assigned OID. The following 6 OIDs are Protocol Mechanism OIDs of type "E" (supportedExtension): 1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message The following 1 OID is a Protocol Mechanism OID of type "F" (supportedFeature): 1.3.6.1.1.17.7 LBURP Incremental Update style OID Harrison, et al. Informational [Page 13] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 10. Normative References [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation" [X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 2002. 11. Informative References [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. Harrison, et al. Informational [Page 14] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 Authors' Addresses Roger Harrison Novell, Inc. 1800 S. Novell Place Provo, UT 84606 Phone: +1 801 861 2642 EMail: rharrison@novell.com Jim Sermersheim Novell, Inc. 1800 S. Novell Place Provo, UT 84606 Phone: +1 801 861 3088 EMail: jimse@novell.com Yulin Dong EMail: yulindong@gmail.com Harrison, et al. Informational [Page 15] RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, 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). Harrison, et al. Informational [Page 16]