Network Working Group Johansson Internet-Draft Stockholm University Expires: November 8, 2001 Hedberg Catalogix May 10, 2001 Lightweight Directory Access Protocol over UDP/IP draft-ietf-ldapext-ldapudp-00 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." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 8, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes modifications to LDAP version 3[1] to allow transport of a subset of the LDAP protocol over UDP/IP. Johansson & Hedberg Expires November 8, 2001 [Page 1] Internet-Draft LDAPv3/UDP May 2001 Table of Contents 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Elements and Result Codes . . . . . . . . . . . . . . . 4 3. Description of the protocol . . . . . . . . . . . . . . . . . . 5 4. Dealing with lost result PDUs: reuse of messageIDs . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 Johansson & Hedberg Expires November 8, 2001 [Page 2] Internet-Draft LDAPv3/UDP May 2001 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 the number of round-trips 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[6] 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[5] 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 very large. Johansson & Hedberg Expires November 8, 2001 [Page 3] Internet-Draft LDAPv3/UDP May 2001 2. Protocol Elements and Result Codes The protocol messages of LDAPv3/UDP are identical with those of LDAPv3 and each LDAPMessage is encoded and transmitted in a single UDP datagram. In addition a new result code is defined: connectionRequired (70??) The semantics of this result code is as follows: * Whenever a server implementing the protocol described in this draft or any protocol derived from this protocol receives a request it for some reason is unwilling or unable to perform over connection-less transport the server must return this result code. Typical examples for this are when the resultset is to large to fit into the biggest packet the network in use can support or when a client tries to do a bind but does not provide enough information for it to succeed * Whenever a client implementing the protocol described in this draft or any protocol derived from this protocol receives this result code the client must not retry the request using connection-less transport. Johansson & Hedberg Expires November 8, 2001 [Page 4] Internet-Draft LDAPv3/UDP May 2001 3. Description of the protocol Use of the LDAPv3 protocol over UDP means that protocol elements can become dropped, delayed or even duplicated by the transport layer. In order to deal with these situations clients and servers implementing this protocol must employ some means for detecting and/or retrying failed requests. Note that the search operation is slightly different in this respect. A SearchResultEntry or a SearchResultReference can become lost or duplicated withouth affecting the flow of requests and responses between the client and the server as long as the SearchResultDone packet is not lost. The loss of this packet would be indistinguishable from the situation where the search is still underway. Thus the delivery of the resultcode packets (including the ExtendedResponse) is different from the delivery of search result packets. Since the application may or may not care about actually receiving SearchResultEntry and SearchResultReference packets some method for ensuring the delivery of these may or may not be needed. The reason why the safe delivery of the result-code pdu is important can be illustrated with a simple example. Assume that a client issues an add operation for a new entry. This request is received by the server and the add operation is performed but the resultcode (SUCCESS) gets lost on its way to the client. If the client were to retry the operation by issuing the same add request under a new message id the result code would indicate a failure since the object already exists in the server. There are several possible mechanisms for solving the problems described above and a particular choice must be agreed upon by the client and server before using ldap over connection-less transports. The method by which a mechanism is selected is not covered by this document but may involve the client connecting to the server over tcp to read the root-DSE entry before using connection-less transport. This standard may be extended by specifying other mechanisms for safe delivery of protocol messages. Servers implementing this protocol SHOULD provide a protocol listener on port 389. How the existence of other protocol listeners are communicated to clients (server location) is not covered in this document. To be used over LDAPv3/UDP other extensions defined for LDAPv3 must be amended by text which explains how the controls and/or exops defined in the extension interact with LDAPv3/UDP. In particular, for each control that is marked critical by the extension the standard must explain how safe delivery of the pdu containing the control is ensured. Johansson & Hedberg Expires November 8, 2001 [Page 5] Internet-Draft LDAPv3/UDP May 2001 4. Dealing with lost result PDUs: reuse of messageIDs A simple method for sending and receiving protocol messages over lossy connection-less transport is reuse of messageIDs. Whenever a client times out before receiving a result PDU it is waiting for it may, using this mechanism, retry the same request using the same messageID as before. A server implementing reuse of messageIDs is required to maintain a cache (the size of which should be annonced in the rootDSE-object; see below) of recent result-codes for each source port and address. Consequently a client using this mechanism must bind to the local port before issuing requests so that a particular client process can be identified by the server. The client must not issue more operations at a time than the cachesize. A server implementing this mechanism must announce it by providing a value for the size of the result code cache in the root-DSE attribute LDAPResultCacheSize: ( NAME 'LDAPResultCacheSize' DESC 'The size of the per-client cache of resultcodes SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY 'integerMatch' NO-USER-MODIFICATION USAGE dSAOperation ) Note that this mechanism does not protect agains a third party inserting protocol messages. See the section on security considerations. Johansson & Hedberg Expires November 8, 2001 [Page 6] Internet-Draft LDAPv3/UDP May 2001 5. Security considerations Since SASL[3] is only defined for connection-oriented operation it is not possible to use SASL authentication with LDAPv3/UDP and a server must respond with an result code of connectionRequired (??) if a bind requesting SASL authentication is received. Mechanisms for safe delivery of protocol messages which do not protect against third-party attacks (inserting messages into the protocol stream) should not be used for update operations unless the underlying transport provides protection against such attacks. Johansson & Hedberg Expires November 8, 2001 [Page 7] Internet-Draft LDAPv3/UDP May 2001 References [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [2] Kent, S and R Atkinson, "Security Architecture for the Internet Protocol", November 1998. [3] Myers, J, "Simple Authentication and Security Layer (SASL)", October 1997. [4] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP Services with DNS", Internet-Draft draft-ietf-ldapext-locate-02, April 2000. [5] Hedberg, R and L Daigle, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)", January 2000. [6] 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 Jegerveien 25 Oslo 0777 Norway Phone: +47 23082996 EMail: roland@catalogix.se Johansson & Hedberg Expires November 8, 2001 [Page 8] Internet-Draft LDAPv3/UDP May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 November 8, 2001 [Page 9]