idnits 2.17.1 draft-ietf-ldapext-ldapudp-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...ng this protocol SHOULD provide a prot...' 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 (May 10, 2001) is 8386 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 187, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 193, 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: 9 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Johansson 2 Internet-Draft Stockholm University 3 Expires: November 8, 2001 Hedberg 4 Catalogix 5 May 10, 2001 7 Lightweight Directory Access Protocol over UDP/IP 8 draft-ietf-ldapext-ldapudp-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on November 8, 2001. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 This memo describes modifications to LDAP version 3[1] to allow 37 transport of a subset of the LDAP protocol over UDP/IP. 39 Table of Contents 41 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . . 3 42 2. Protocol Elements and Result Codes . . . . . . . . . . . . . . . 4 43 3. Description of the protocol . . . . . . . . . . . . . . . . . . 5 44 4. Dealing with lost result PDUs: reuse of messageIDs . . . . . . . 6 45 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 46 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 48 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 50 1. Overview and Rationale 52 Using LDAP version 3[1] involves normal TCP/IP connection setup 53 which for some applications may constitute undesirable overhead, 54 especially in situations where only unauthenticated requests are 55 performed. The typical use would be for fast light-weight read-only 56 clients where the number of round-trips must be kept to a minimum or 57 for clients which makes large numbers of requests to multiple LDAP 58 servers. An example of the latter would be an LDAP server which 59 maintains a CIP[6] index and provides chaining of requests to 60 servers indexed by the mesh. Such a server will often have to 61 maintain large numbers of tcp connections. Experience from the 62 TISDAG[5] project has shown that even with relatively small indices 63 and few concurrent clients to the index server the number of 64 outgoing tcp connections may be very large. 66 2. Protocol Elements and Result Codes 68 The protocol messages of LDAPv3/UDP are identical with those of 69 LDAPv3 and each LDAPMessage is encoded and transmitted in a single 70 UDP datagram. In addition a new result code is defined: 72 connectionRequired (70??) 74 The semantics of this result code is as follows: 76 * Whenever a server implementing the protocol described in this 77 draft or any protocol derived from this protocol receives a 78 request it for some reason is unwilling or unable to perform over 79 connection-less transport the server must return this result 80 code. Typical examples for this are when the resultset is to 81 large to fit into the biggest packet the network in use can 82 support or when a client tries to do a bind but does not provide 83 enough information for it to succeed 85 * Whenever a client implementing the protocol described in this 86 draft or any protocol derived from this protocol receives this 87 result code the client must not retry the request using 88 connection-less transport. 90 3. Description of the protocol 92 Use of the LDAPv3 protocol over UDP means that protocol elements can 93 become dropped, delayed or even duplicated by the transport layer. 94 In order to deal with these situations clients and servers 95 implementing this protocol must employ some means for detecting 96 and/or retrying failed requests. 98 Note that the search operation is slightly different in this 99 respect. A SearchResultEntry or a SearchResultReference can become 100 lost or duplicated withouth affecting the flow of requests and 101 responses between the client and the server as long as the 102 SearchResultDone packet is not lost. The loss of this packet would 103 be indistinguishable from the situation where the search is still 104 underway. Thus the delivery of the resultcode packets (including the 105 ExtendedResponse) is different from the delivery of search result 106 packets. Since the application may or may not care about actually 107 receiving SearchResultEntry and SearchResultReference packets some 108 method for ensuring the delivery of these may or may not be needed. 110 The reason why the safe delivery of the result-code pdu is important 111 can be illustrated with a simple example. Assume that a client 112 issues an add operation for a new entry. This request is received by 113 the server and the add operation is performed but the resultcode 114 (SUCCESS) gets lost on its way to the client. If the client were to 115 retry the operation by issuing the same add request under a new 116 message id the result code would indicate a failure since the object 117 already exists in the server. 119 There are several possible mechanisms for solving the problems 120 described above and a particular choice must be agreed upon by the 121 client and server before using ldap over connection-less transports. 122 The method by which a mechanism is selected is not covered by this 123 document but may involve the client connecting to the server over 124 tcp to read the root-DSE entry before using connection-less 125 transport. This standard may be extended by specifying other 126 mechanisms for safe delivery of protocol messages. 128 Servers implementing this protocol SHOULD provide a protocol 129 listener on port 389. How the existence of other protocol listeners 130 are communicated to clients (server location) is not covered in this 131 document. 133 To be used over LDAPv3/UDP other extensions defined for LDAPv3 must 134 be amended by text which explains how the controls and/or exops 135 defined in the extension interact with LDAPv3/UDP. In particular, 136 for each control that is marked critical by the extension the 137 standard must explain how safe delivery of the pdu containing the 138 control is ensured. 140 4. Dealing with lost result PDUs: reuse of messageIDs 142 A simple method for sending and receiving protocol messages over 143 lossy connection-less transport is reuse of messageIDs. Whenever a 144 client times out before receiving a result PDU it is waiting for it 145 may, using this mechanism, retry the same request using the same 146 messageID as before. A server implementing reuse of messageIDs is 147 required to maintain a cache (the size of which should be annonced 148 in the rootDSE-object; see below) of recent result-codes for each 149 source port and address. Consequently a client using this mechanism 150 must bind to the local port before issuing requests so that a 151 particular client process can be identified by the server. The 152 client must not issue more operations at a time than the cachesize. 154 A server implementing this mechanism must announce it by providing a 155 value for the size of the result code cache in the root-DSE 156 attribute LDAPResultCacheSize: 158 ( 159 NAME 'LDAPResultCacheSize' 160 DESC 'The size of the per-client cache of resultcodes 161 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 162 EQUALITY 'integerMatch' 163 NO-USER-MODIFICATION 164 USAGE dSAOperation ) 166 Note that this mechanism does not protect agains a third party 167 inserting protocol messages. See the section on security 168 considerations. 170 5. Security considerations 172 Since SASL[3] is only defined for connection-oriented operation it 173 is not possible to use SASL authentication with LDAPv3/UDP and a 174 server must respond with an result code of connectionRequired (??) 175 if a bind requesting SASL authentication is received. 177 Mechanisms for safe delivery of protocol messages which do not 178 protect against third-party attacks (inserting messages into the 179 protocol stream) should not be used for update operations unless the 180 underlying transport provides protection against such attacks. 182 References 184 [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 185 Protocol (v3)", RFC 2251, December 1997. 187 [2] Kent, S and R Atkinson, "Security Architecture for the Internet 188 Protocol", November 1998. 190 [3] Myers, J, "Simple Authentication and Security Layer (SASL)", 191 October 1997. 193 [4] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP 194 Services with DNS", Internet-Draft 195 draft-ietf-ldapext-locate-02, April 2000. 197 [5] Hedberg, R and L Daigle, "Technical Infrastructure for Swedish 198 Directory Access Gateways (TISDAG)", January 2000. 200 [6] Hedberg, R, "LDAPv2 client vs. the Index Mesh", RFC 2657, 201 August 1999. 203 Authors' Addresses 205 Leif Johasson 206 Stockholm University 207 Stockholm SE-10691 208 Sweden 210 Phone: +46 8 164541 211 EMail: leifj@it.su.se 213 Roland Hedberg 214 Catalogix 215 Jegerveien 25 216 Oslo 0777 217 Norway 219 Phone: +47 23082996 220 EMail: roland@catalogix.se 222 Full Copyright Statement 224 Copyright (C) The Internet Society (2001). All Rights Reserved. 226 This document and translations of it may be copied and furnished to 227 others, and derivative works that comment on or otherwise explain it 228 or assist in its implmentation may be prepared, copied, published 229 and distributed, in whole or in part, without restriction of any 230 kind, provided that the above copyright notice and this paragraph 231 are included on all such copies and derivative works. However, this 232 document itself may not be modified in any way, such as by removing 233 the copyright notice or references to the Internet Society or other 234 Internet organizations, except as needed for the purpose of 235 developing Internet standards in which case the procedures for 236 copyrights defined in the Internet Standards process must be 237 followed, or as required to translate it into languages other than 238 English. 240 The limited permissions granted above are perpetual and will not be 241 revoked by the Internet Society or its successors or assigns. 243 This document and the information contained herein is provided on an 244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 246 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 247 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 250 Acknowledgement 252 Funding for the RFC editor function is currently provided by the 253 Internet Society.