Connectionless LDAP: Connection-less Lightweight X.500 Directory Access Protocol
A faster way to query the directory using single datagrams instead of multiple connection-oriented exchanges.
Young, A., "Connection-less Lightweight X.500 Directory Access Protocol", RFC 1798, DOI 10.17487/RFC1798, June 1995, <https://www.rfc-editor.org/info/rfc1798>.
@misc{rfc1798,
series = {Request for Comments},
number = 1798,
howpublished = {RFC 1798},
publisher = {RFC Editor},
doi = {10.17487/RFC1798},
url = {https://www.rfc-editor.org/info/rfc1798},
author = {A. Young},
title = {{Connection-less Lightweight X.500 Directory Access Protocol}},
pagetotal = 9,
year = 1995,
month = jun,
} RFC text
Contents
Network Working Group A. Young
Request for Comments: 1798 ISODE Consortium
Category: Standards Track June 1995
Connection-less Lightweight X.500 Directory Access Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
X.500
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP) [3]. In particular, it is aimed at
avoiding the elapsed time that is associated with connection-oriented
communication and it facilitates use of the Directory in a manner
analagous to the DNS [5,6]. It is specifically targeted at simple
lookup applications that require to read a small number of attribute
values from a single entry. It is intended to be a complement to DAP
and LDAP [4]. The protocol specification draws heavily on that of
LDAP.
1. Background
The Directory can be used as a repository for many kinds of
information. The full power of DAP is unnecessary for applications
that require simple read access to a few attribute values.
Applications addressing is a good example of this type of use where
an application entity needs to determine the Presentation Address
(PA) of a peer entity given that peer's Application Entity Title
(AET). If the AET is a Directory Name (DN) then the required result
can be obtained from the PA attribute of the Directory entry
identified by the AET. This is very similar to DNS.
Use of DAP to achieve this functionality involves a significant
number of network exchanges:
___________________________________________________________
|_#_|______Client_(DUA)________DAP________Server_(DSA)_____|
| 1| N-Connect.request -> |
| 2| <- N-Connect.response |
| 3| T-Connect.request -> |
| 4| <- T-Connect.response |
| | S-Connect.request, |
| | P-Connect.request, |
| | A-Associate.request, |
| 5| DAP-Bind.request -> |
| | S-Connect.response, |
| | P-Connect.response, |
| | A-Associate.response, |
| 6| <- DAP-Bind.response |
| 7| DAP-Read.request -> |
| 8| <- DAP-Read.response |
| | S-Release.request, |
| | P-Release.request, |
| | A-Release.request, |
| 9| DAP-Unbind.request -> |
| | S-Release.response, |
| | P-Release.response, |
| | A-Release.response, |
| 10| <- DAP-Unbind.response |
| | T-Disconnect.request, |
| 11| N-Disconnect.request -> |
| | T-Disconnect.response,|
| 12| <- N-Disconnect.response |
|___|______________________________________________________|
This is 10 packets before the application can continue, given that it
can probably do so after issuing the T-Disconnect.request. (Some
minor variations arise depending upon the class of Network and
Transport service that is being used; for example use of TP4 over
CLNS reduces the packet count by two.) LDAP is no better in the case
where the LDAP server uses full DAP to communicate with the
Directory:
____________________________________________________________________
|__#_|___Client_____LDAP_____LDAP_server______DAP_________DSA_______|
| 1 | TCP SYN -> |
| 2 | <- TCP SYN ACK |
| 3 | BindReq -> |
| 4 | N-Connect.req -> |
| 5 | <- N-Connect.res |
| 6 | T-Connect.req -> |
| 7 | <- T-Connect.res |
| 8 | DAP-Bind.req -> |
| 9 | <- DAP-Bind.res |
| 10 | <- BindRes |
| 11 | SearchReq -> |
| 12 | DAP-Search.req -> |
| 13 | <- DAP-Search.res |
| 14 | <- SearchRes |
| 15 | TCP FIN -> |
| 16 | DAP-Unbind.req -> |
| 17 | <- DAP-Unbind.res |
| 18 | N-Disconnect.req -> |
| 19 | <- N-Disconnect.res|
|____|______________________________________________________________|
Here there are 14 packets before the application can continue. Even
if the LDAP server is on the same host as the DSA (so packet delay is
negligible), or if the DSA supports LDAP directly, then there are
still 6 packets.
____________________________________
| #| Client LDAP LDAP server|
|__|________________________________|
| 1| TCP SYN -> |
| 2| <- TCP SYN ACK|
| 3| BindReq -> |
| 4| <- BindRes |
| 5| SearchReq -> |
|_6|_______________<-____SearchRes__|
This protocol provides for simple access to the Directory where the
delays inherent in the above exchanges are unacceptable and where the
additional functionality provided by connection-mode operation is not
required.
2. Protocol Model
CLDAP is based directly on LDAP [4] and inherits many of the key
aspects of the LDAP protocol:
- - Many protocol data elements are encoding as ordinary strings
(e.g., Distinguished Names).
- - A lightweight BER encoding is used to encode all protocol
elements.
It is different to LDAP in that:
- - Protocol elements are carried directly over UDP or other
connection-less transport, bypassing much of the
session/presentation overhead and that of connections (LDAP uses
a connection-mode transport service).
- - A restricted set of operations is available.
The definitions of most protocol elements are inherited from LDAP.
The general model adopted by this protocol is one of clients
performing protocol operations against servers. In this model, this
is accomplished by a client transmitting a protocol request
describing the operation to be performed to a server, which is then
responsible for performing the necessary operations on the Directory.
Upon completion of the necessary operations, the server returns a
response containing any results or errors to the requesting client.
Note that, although servers are required to return responses whenever
such responses are defined in the protocol, there is no requirement
for synchronous behaviour on the part of either client or server
implementations: requests and responses for multiple operations may
be exchanged by client and servers in any order, as long as servers
eventually send a response for every request that requires one.
Also, because the protocol is implemented over a connection-less
transport service clients must be prepared for either requests or
responses to be lost. Clients should use a retry mechanism with
timeouts in order to achieve the desired level of reliability. For
example, a client might send off a request and wait for two seconds.
If no reply is forthcoming, the request is sent again and the client
waits four seconds. If there is still no reply, the client sends it
again and waits eight seconds, and so on, until some maximun time.
Such algorithms are widely used in other datagram-based protocol
implementations, such as the DNS. It is not appropriate to mandate a
specific algorithm as this will depend upon the requirments and
operational environment of individual CLDAP client implementations.
It is not required that a client abandon any requests to which no
response has been received and for which a reply is no longer
required (because the request has been timed out), but they may do
so.
Consistent with the model of servers performing protocol operations
on behalf of clients, it is also to be noted that protocol servers
are expected to handle referrals without resorting to the return of
such referrals to the client. This protocol makes no provisions for
the return of referrals to clients, as the model is one of servers
ensuring the performance of all necessary operations in the
Directory, with only final results or errors being returned by
servers to clients.
Note that this protocol can be mapped to a strict subset of the
Directory abstract service, so it can be cleanly provided by the DAP.
3. Mapping Onto Transport Services
This protocol is designed to run over connection-less transports,
with all 8 bits in an octet being significant in the data stream.
Specifications for two underlying services are defined here, though
others are also possible.
3.1. User Datagram Protocol (UDP)
The CLDAPMessage PDUs are mapped directly onto UDP datagrams. Only
one request may be sent in a single datagram. Only one response may
be sent in a single datagram. Server implementations running over
the UDP should provide a protocol listener on port 389.
3.2. Connection-less Transport Service (CLTS)
Each LDAPMessage PDU is mapped directly onto T-Unit-Data.
4. Elements of Protocol
CLDAP messages are defined by the following ASN.1:
CLDAPMessage ::= SEQUENCE {
messageID MessageID,
user LDAPDN, -- on request only --
protocolOp CHOICE {
searchRequest SearchRequest,
searchResponse SEQUENCE OF
SearchResponse,
abandonRequest AbandonRequest
}
}
where MessageID, LDAPDN, SearchRequest, SearchResponse and
AbandonRequest are defined in the LDAP protocol.
The 'user' element is supplied only on requests (it should be zero
length and is ignored in responses). It may be used for logging
purposes but it is not required that a CLDAP server implementation
apply any particular semantics to this field.
Editorial note:
There has been some discussion about the desirability of
authentication with CLDAP requests and the addition of the fields
necessary to support this. This might take the form of a clear
text password (which would go against the current IAB drive to
remove such things from protocols) or some arbitrary credentials.
Such a field is not included. It is felt that, in general,
authentication would incur sufficient overhead to negate the
advantages of the connectionless basis of CLDAP. If an
application requires authenticated access to the Directory then
CLDAP is not an appropriate protocol.
Within a searchResponse all but the last SearchResponse has choice
'entry' and the last SearchResponse has choice 'resultCode'. Within
a searchResponse, as an encoding optimisation, the value of the
objectName LDAP DN may use a trailing '*' character to refer to the
baseObject of the corresponding searchRequest. For example, if the
baseObject is specified as "o=UofM, c=US", then the following
objectName LDAPDNs in a response would have the indicated meanings
objectName returned actual LDAPDN denoted
____________________________________________________
"*" "o=UofM, c=US"
"cn=Babs Jensen, *" "cn=Babs Jensen, o=UofM, c=US"
4.1. Errors
The following error code is added to the LDAPResult.resultCode
enumeration of [4]:
resultsTooLarge (70),
This error is returned when the LDAPMessage PDU containing the
results of an operation are too large to be sent in a single
datagram.
4.2. Example
A simple lookup can be performed in 4 packets. This is reduced to 2
if either the DSA implements the CLDAP protocol, the CLDAP server has
a cache of the desired results, or the CLDAP server and DSA are co-
located such that there is insignificant delay between them.
_______________________________________________________________
|_#|___Client_____CLDAP____CLDAP_server____DAP________DSA______|
| 1| SearchReq -> |
| 2| DAP-Search.req -> |
| 3| <- DAP-Search.res|
| 4| <- SearchRes |
|__|___________________________________________________________|
5. Implementation Considerations
The following subsections provide guidance on the implementation of
clients and servers using the CLDAP protocol.
5.1. Server Implementations
Given that the goal of this protocol is to minimise the elapsed time
between making a Directory request and receiving the response, a
server which uses DAP to access the directory should use techniques
that assist in this.
- - A server should remain bound to the Directory during reasonably
long idle periods or should remain bound permanently.
- - Cacheing of results is highly desirable but this must be
tempered by the need to provide up-to-date results given the
lack of a cache invalidation protocol in DAP (either implicit
via timers or explicit) and the lack of a dontUseCopy service
control in the protocol.
Of course these issues are irrelevant if the CLDAP protocol is
directly supported by a DSA.
5.2. Client Implementations
For simple lookup applications, use of a retry algorithm with
multiple servers similar to that commonly used in DNS stub resolver
implementations is recommended. The location of a CLDAP server or
servers may be better specified using IP addresses (simple or
broadcast) rather than names that must first be looked up in another
directory such as DNS.
6. Security Considerations
This protocol provides no facilities for authentication. It is
expected that servers will bind to the Directory either anonymously
or using simple authentication without a password.
7. Bibliography
[1] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[2] The Directory: Models. CCITT Recommendation X.501 ISO/IEC JTC
1/SC21; International Standard 9594-2, 1988.
[3] The Directory: Abstract Service Definition. CCITT Recommendation
X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.
[4] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight Directory
Access Protocol", RFC 1487, Performance Systems International,
University of Michigan, ISODE Consortium, July 1993.
[5] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
8. Acknowledgements
Many thanks to Tim Howes and Steve Kille for their detailed comments
and to other members of the working group.
This work was initiated by the Union Bank of Switzerland.
9. Author's Address
Alan Young
ISODE Consortium
The Dome, The Square
RICHMOND
GB - TW9 1DT
Phone: +44 81 332 9091
EMail: A.Young@isode.com
X.400: i=A; s=Young; o=ISODE Consortium; p=ISODE; a=MAILNET; c=FI
AI ELI5
On this page
§1The Problem with Connection-Oriented Lookup
The full Directory Access Protocol (DAP) connects to the X.500 Directory by setting up multiple layers of session and presentation connections, binding to the directory, performing the lookup, unbinding, and disconnecting. For simple lookups—such as finding a peer's network address from its name—this takes about 10 network packets and can take several seconds.
CLDAP (Connectionless Lightweight Directory Access Protocol) eliminates this overhead. It sends requests and responses as single UDP datagrams, much like DNS. For a simple lookup, the total is just 4 packets, or 2 if the server caches results or co-locates with the directory.
Asking a phone operator for a number is slow; looking it up in a phonebook is fast. CLDAP is the phonebook method.
§2The CLDAP Design
CLDAP inherits most of its structure from LDAP but strips away connection overhead. It runs directly over UDP or other connectionless transport. A client sends a request describing what to look up (the search request), and the server returns one or more response datagrams with the results. Unlike LDAP, there is no login step, no persistent connection, and no explicit disconnect.
Clients must handle the unreliability of UDP by retrying requests with exponential backoff if no response arrives within a timeout. This is the same retry logic that DNS resolvers use.
You send a postcard asking a question and listen for the answer. If you don't hear back, you send it again and wait longer.
§3Messages and Errors
A CLDAP request is a single message with a message ID, the user's name, and a search request (which comes from LDAP). The response is one or more messages containing the entries found. An encoding optimisation lets a response refer to the base object's name with just a star character instead of the full name, saving bytes in typical cases.
CLDAP adds one new error code: resultsTooLarge (70), which the server returns when the response would not fit in a single UDP datagram. The client must then either try a simpler search, ask the server to continue the search, or use a more capable protocol like DAP.
The message is a postcard: a question number, your name, and what you want to know. The answer fits on another postcard, or the server says 'the answer is too long for a postcard.'
§4Deployment Guidance
Servers should stay bound to the Directory during idle periods or remain bound permanently to avoid reconnect delays when a CLDAP request arrives. Caching results is highly desirable but must be balanced against the lack of a cache invalidation protocol in DAP. If the CLDAP protocol is implemented directly in a directory server, these issues disappear.
Clients should use a retry algorithm similar to DNS stub resolvers, locating servers by IP address rather than domain name when possible to avoid recursive lookups. The specification does not mandate a specific retry timing, only that clients implement backoff to avoid network storms.
The server should remember recent answers and be ready to respond right away. The client should keep trying with longer pauses if the postcard doesn't come back.
§5Security Trade-Offs
CLDAP provides no authentication facilities. The design trades security for speed and simplicity. Servers are expected to bind to the Directory anonymously or with simple authentication. Applications that need authenticated access to the Directory should use the full Directory Access Protocol instead.
The lack of authentication means CLDAP is suited only for public directory data or within trusted networks. The single-datagram nature also rules out encryption during the exchange itself, though encryption of the transport layer (such as secure UDP) would be an addition outside this protocol.
Anyone can ask questions and get answers. If you need secrets, use a more secure protocol.