One document matched: draft-ietf-ldapext-cldap-00.txt
Network Working Group Johansson
Internet-Draft Stockholm University
Expires: December 31, 2000 Hedberg
Catalogix
May 31, 2000
Connection-less Lightweight Directory Access Protocol
draft-ietf-ldapext-cldap-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at.
http://www.ietf.org/shadow.html..
This Internet-Draft will expire on December 31, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo describes modifications to LDAP version 3[1] to allow
transport of a subset of the LDAP protocol over connection-less
transport. The case of UDP/IP is covered in detail in this memo but
other transport layers are possible.
Johansson & Hedberg Expires December 31, 2000 [Page 1]
Internet-Draft CLDAP (v3) May 2000
Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 3
2. Mapping LDAP protocol operations . . . . . . . . . . . . . . . 4
3. Protocol Elements and Result Codes . . . . . . . . . . . . . . 5
4. Client and Server Operation . . . . . . . . . . . . . . . . . 6
5. Considerations for Server location . . . . . . . . . . . . . . 7
6. Security considerations . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
Johansson & Hedberg Expires December 31, 2000 [Page 2]
Internet-Draft CLDAP (v3) May 2000
1. Overview and Rationale
Using LDAP version 3[1] involves normal TCP/IP connection setup
which for some applications may constitute undesirable overhead,
especially in situations where only unauthenticated requests are
performed. The typical use would be for fast light-weight read-only
clients where latency must be kept to a minimum or for clients which
makes large numbers of requests to multiple LDAP servers. An example
of the latter would be an LDAP server which maintains a CIP[5] index
and provides chaining of requests to servers indexed by the mesh.
Such a server will often have to maintain large numbers of tcp
connections. Experience from the TISDAG[4] project has shown that
even with relatively small indices and few concurrent clients to the
index server the number of outgoing tcp connections may be quite
large and even approaching limits imposed by popular operating
systems.
Johansson & Hedberg Expires December 31, 2000 [Page 3]
Internet-Draft CLDAP (v3) May 2000
2. Mapping LDAP protocol operations
It is a requirement of CLDAPv3 that the underlying transport layer
uses 8 bits per octet and that all bits are used when encoding
messages.
LDAP messages are encoded, one PDU per packet, as packets of the
underlying transport layer. Encoded packets must be small enough to
fit inside a datagram no bigger than the size of the MTU of the
transport mechanism. For UDP/IP normally this means that an LDAP
message may be no larger than 512 bytes. Furthermore the MTU of the
transport mechanism must be at least big enough for a client
LDAPMessage request.
Johansson & Hedberg Expires December 31, 2000 [Page 4]
Internet-Draft CLDAP (v3) May 2000
3. Protocol Elements and Result Codes
The protocol messages of CLDAPv3 are identical with those of LDAPv3
and each LDAPMessage is mapped to a single packet of the underlying
transport layer. In addition the following error code added by CLDAP
version 2[3] is included:
resultsTooLarge (70),
The semantics of this error message in CLDAPv3 also remains the
same: If when encoding a reply to a client the LDAPMessage PDU
containing the message cannot be encoded in a single transport layer
datagram the server must send this error code to the client. The
action taken by a client when encountering this error message is not
specified in this document. The client may choose to open a tcp
connection to the server and retry the request. Note that it is
possible for a client to issue a modifying request (add, delete,
moddn, modify) together with a control or an extended request which
modifies the directory such that the response is too large to fit in
a datagram which would make it impossible for the client to know if
the requested operation was successful or not. For this reason
servers implementing this protocol must respond with an error of
unwillingToPerform(53) if such a request is received.
An alternative would be to include a control with the
resultsToLarge(70) response containing a cookie which when presented
to the server on a tcp connection would result in the server
returning the full response to the client. Such a scheme is beyond
the scope of this memo but may be addressed in a future draft.
Johansson & Hedberg Expires December 31, 2000 [Page 5]
Internet-Draft CLDAP (v3) May 2000
4. Client and Server Operation
In this section we describe the requirements on servers and clients
implementing CLDAPv3 as well as a description of the protocol
exchanges and the differences that exist between LDAPv3 and CLDAPv3.
The rest of this section will focus on CLDAPv3 over UDP/IP, other
connection-less transport layers may pose additional or completely
different requirements on servers and clients although it is
expected that the protocol itself would not need to changed.
Servers implementing this protocol over UDP/IP should provide a
protocol listener on port 389. They must also check the version
field of the LDAP PDU and return an error code of protocolError(2)
if a version 2 client issues any requests besides searchRequest.
Since the protocol described in this memo is not compatible with
CLDAPv2 it is worth noting that it is very easy for server
implementations to support both version 2 and 3 clients over UDP/IP
and other connection-less transports described in CLDAP version
2[3]. They only have to check the ASN.1 tag of the first ASN.1
object following the MessageID. In the case of CLDAPv3 this tag has
the CONTEXT tag bit set (being a CHOICE component) this is not the
case in CLDAPv2 (where the second ASN.1 object in the CLDAPMessage
SEQUENCE is an OCTET STRING). Servers wishing to support both
version 2 and version 3 clients must reply to version 2
searchRequests as per RFC1789[3].
Using UDP there is no guarantee that all packets sent from the
server will eventually arrive at the client. Therefore the
application using CLDAPv3 have to handle packet loss. One way of
aiding this would be to add something like a packet sequence number
in the PDUs sent from the server to the client, how this is to be
done is outside the scope of this document.
Johansson & Hedberg Expires December 31, 2000 [Page 6]
Internet-Draft CLDAP (v3) May 2000
5. Considerations for Server location
If a client uses DNS to locate LDAP servers as per RFCXXXX[2] and
finds a SRV record for _ldap._udp all referenced servers must
support the protocol described in this memo over UDP/IP-transport.
It is beyond the scope of this document to describe how a client may
find out what transport mechanisms are supported by a given server.
Johansson & Hedberg Expires December 31, 2000 [Page 7]
Internet-Draft CLDAP (v3) May 2000
6. Security considerations
Unlike CLDAP verison 2[3] it is possible for a CLDAPv3 client to
establish a secure association to a CLDAPv3 server by a SASL bind
which can establish an integrity or security layer. Note that
authentication alone is not enough to maintain a secure association
with a connection-less LDAP server since there is no connection with
which to associate the authenticated client. In order to establish a
secure association a security or integrity layer must be in place
through the usual method of embedding the LDAP messages in bind
requests. Also in order to make use of this method any APIs involved
must take care to protect the association between client and server
(including session credentials) from hijacking
If high reliability is needed clients must either employ some
external means of ensuring that messages get through (such as a
strict regimen of timeouts and resends) or use normal LDAP instead.
This is especially important during a sequence of bind requests and
responses.
Johansson & Hedberg Expires December 31, 2000 [Page 8]
Internet-Draft CLDAP (v3) May 2000
References
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[2] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP
Services with DNS", Internet-Draft
draft-ietf-ldapext-locate-02, April 2000.
[3] Young, A., "Connection-less Lightweight Directory Access
Protocol", RFC 1798, June 1995.
[4] Daigle, L. and Hedberg, R, "Technical Infrastructure for
Swedish Directory Access Gateways (TISDAG)", Internet-Draft
draft-daigle-tisdag-01.txt, January 2000.
[5] Hedberg, R, "LDAPv2 client vs. the Index Mesh", RFC 2657,
August 1999.
Authors' Addresses
Leif Johasson
Stockholm University
Stockholm SE-10691
Sweden
Phone: +46 8 164541
EMail: leifj@it.su.se
Roland Hedberg
Catalogix
Dalsveien 53
Oslo 0775
Norway
Phone: +47 23082996
EMail: roland@catalogix.ac.se
Johansson & Hedberg Expires December 31, 2000 [Page 9]
Internet-Draft CLDAP (v3) May 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Johansson & Hedberg Expires December 31, 2000 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:52 |