idnits 2.17.1 draft-ietf-ldapext-cldap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 199, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 205, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-08) exists of draft-ietf-ldapext-locate-02 -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Experimental RFC: RFC 2657 (ref. '6') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Johansson 3 Internet-Draft Stockholm University 4 Expires: August 22, 2001 Hedberg 5 Catalogix 6 February 2001 8 Connection-less Lightweight Directory Access Protocol 9 draft-ietf-ldapext-cldap-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 22, 2001. 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract 40 This memo describes modifications to LDAP version 3[1] to allow 41 transport of a subset of the LDAP protocol over connection-less 42 transport. The case of UDP/IP is covered in detail in this memo but 43 other transports are possible. 45 Table of Contents 47 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . . 3 48 2. Protocol Elements and Result Codes . . . . . . . . . . . . . . . 4 49 3. Description of the protocol . . . . . . . . . . . . . . . . . . 5 50 4. Delivery of result PDUs: reuse of messageIDs . . . . . . . . . . 6 51 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 52 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 54 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 56 1. Overview and Rationale 58 Using LDAP version 3[1] involves normal TCP/IP connection setup 59 which for some applications may constitute undesirable overhead, 60 especially in situations where only unauthenticated requests are 61 performed. The typical use would be for fast light-weight read-only 62 clients where latency must be kept to a minimum or for clients which 63 makes large numbers of requests to multiple LDAP servers. An example 64 of the latter would be an LDAP server which maintains a CIP[6] index 65 and provides chaining of requests to servers indexed by the mesh. 66 Such a server will often have to maintain large numbers of tcp 67 connections. Experience from the TISDAG[5] project has shown that 68 even with relatively small indices and few concurrent clients to the 69 index server the number of outgoing tcp connections may be quite 70 large and even approaching limits imposed by popular operating 71 systems. 73 2. Protocol Elements and Result Codes 75 It is a requirement of CLDAPv3 that the underlying transport layer 76 uses 8 bits per octet and that all bits are used when encoding 77 messages. LDAP messages are encoded, one PDU per packet, as packets 78 of the underlying transport layer. 80 The protocol messages of CLDAPv3 are identical with those of LDAPv3 81 and each LDAPMessage is mapped to a single packet of the underlying 82 transport layer. In addition a result code is defined 84 connectionRequired (70??) 86 The semantics of this result code is as follows: 88 * Whenever a server implementing the protocol described in this 89 draft or any protocol derived from this protocol receives a 90 request it for some reason is unwilling or unable to perform over 91 connection-less transport the server must return this result 92 code. Typical examples for this are when the resultSet is to 93 large to fit into the biggest packet the network in use can 94 support or when a client tries to do a bind but does not provide 95 enough information for it to succeed 97 * Whenever a client implementing the protocol described in this 98 draft or any protocol derived from this protocol receives this 99 result code the client must not retry the request using 100 connection-less transport. 102 3. Description of the protocol 104 Use of the LDAP protocol over connection-less transports means that 105 protocol elements can become dropped, delayed or even duplicated by 106 the transport layer. In order to deal with these situations clients 107 and servers implementing this protocol must employ some means for 108 detecting and/or retrying failed requests. 110 Note that the search operation is slightly different in this 111 respect. A SearchResultEntry or a SearchResultReference can become 112 lost or duplicated withouth affecting the flow of requests and 113 responses between the client and the server as long as the 114 SearchResultDone packet is not lost. The loss of this packet would 115 be indistinguishable from the situation where the search is still 116 underway. Thus the delivery of the resultcode packets (including the 117 ExtendedResponse) is different from the delivery of search result 118 packets. Since the application may or may not care about actually 119 receiving SearchResultEntry and SearchResultReference packets some 120 method for ensuring the delivery of these may or may not be needed. 122 The reason why the safe delivery of the result-code pdu is important 123 can be illustrated with a simple example. Assume that a client 124 issues an add operation for a new entry. This request is received by 125 the server and the add operation is performed but the resultcode 126 (SUCCESS) gets lost on its way to the client. If the client were to 127 retry the operation by issuing the same add request under a new 128 message id the result code would indicate a failure since the object 129 already exists in the server. 131 There are several possible mechanisms for solving the problems 132 described above and a particular choice must be agreed upon by the 133 client and server before using ldap over connection-less transports. 134 The method by which a mechanism is selected is not covered by this 135 document but may involve the client connecting to the server over 136 tcp to read the root-DSE entry before using connection-less 137 transport. This standard may be extended by specifying other 138 mechanisms for safe delivery of protocol messages. 140 Servers implementing this protocol over UDP/IP should provide a 141 protocol listener on port 389. How the existence of other protocol 142 listeners are communicated to clients (server location) is not 143 covered in this document. 145 To be used over CLDAP other extensions defined for LDAPv3 must be 146 amended by text which explains how the controls and/or exops defined 147 in the extension interact with CLDAP. In particular, for each 148 control that is marked critical by the extension the standard must 149 explain how safe delivery of the pdu containing the control is 150 ensured. 152 4. Delivery of result PDUs: reuse of messageIDs 154 A simple method for sending and receiving protocol messages over 155 lossy connection-less transport is reuse of messageIDs. Whenever a 156 client times out before receiving a result PDU it is waiting for it 157 may, using this mechanism, retry the same request using the same 158 messageID as before. A server implementing reuse of messageIDs is 159 required to maintain a cache (the size of which should be annonced 160 in the rootDSE-object; see below) of recent result-codes for each 161 source port and address. Consequently a client using this mechanism 162 must bind to the local port before issuing requests so that a 163 particular client process can be identified by the server. The 164 client must not issue more operations at a time than the cachesize. 166 A server implementing this mechanism must announce it by providing a 167 value for the size of the result code cache in the root-DSE 168 attribute cLDAPResultCacheSize: 170 ( 171 NAME 'cLDAPResultCacheSize' 172 DESC 'The size of the per-client cache of resultcodes 173 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 174 EQUALITY 'integerMatch' 175 NO-USER-MODIFICATION 176 USAGE dSAOperation ) 178 Note that this mechanism does not protect agains a third party 179 inserting protocol messages. See the section on security 180 considerations. 182 5. Security considerations 184 Since SASL[3] is only defined for connection-oriented operation it 185 is not possible to use SASL authentication with CLDAPv3 and a server 186 must respond with an result code of connectionRequired (??) if a 187 bind requesting SASL authentication is received. 189 Mechanisms for safe delivery of protocol messages which do not 190 protect against third-party attacks (inserting messages into the 191 protocol stream) should not be used for update operations unless the 192 underlying transport provides protection against such attacks. 194 References 196 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 197 Protocol (v3)", RFC 2251, December 1997. 199 [2] Kent, S and R Atkinson, "Security Architecture for the Internet 200 Protocol", November 1998. 202 [3] Myers, J, "Simple Authentication and Security Layer (SASL)", 203 October 1997. 205 [4] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP 206 Services with DNS", draft-ietf-ldapext-locate-02 (work in 207 progress), April 2000. 209 [5] Hedberg, R and L Daigle, "Technical Infrastructure for Swedish 210 Directory Access Gateways (TISDAG)", January 2000. 212 [6] Hedberg, R, "LDAPv2 client vs. the Index Mesh", RFC 2657, 213 August 1999. 215 Authors' Addresses 217 Leif Johasson 218 Stockholm University 219 Stockholm SE-10691 220 Sweden 222 Phone: +46 8 164541 223 EMail: leifj@it.su.se 225 Roland Hedberg 226 Catalogix 227 Jegerveien 25 228 Oslo 0777 229 Norway 231 Phone: +47 23082996 232 EMail: roland@catalogix.se 234 Full Copyright Statement 236 Copyright (C) The Internet Society (2000). All Rights Reserved. 238 This document and translations of it may be copied and furnished to 239 others, and derivative works that comment on or otherwise explain it 240 or assist in its implementation may be prepared, copied, published 241 and distributed, in whole or in part, without restriction of any 242 kind, provided that the above copyright notice and this paragraph 243 are included on all such copies and derivative works. However, this 244 document itself may not be modified in any way, such as by removing 245 the copyright notice or references to the Internet Society or other 246 Internet organizations, except as needed for the purpose of 247 developing Internet standards in which case the procedures for 248 copyrights defined in the Internet Standards process must be 249 followed, or as required to translate it into languages other than 250 English. 252 The limited permissions granted above are perpetual and will not be 253 revoked by the Internet Society or its successors or assigns. 255 This document and the information contained herein is provided on an 256 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 257 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 258 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 259 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 260 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Acknowledgement 264 Funding for the RFC editor function is currently provided by the 265 Internet Society.