[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Circular referral (Was: (ITS#4055) back-ldap hangs)

Pierangelo Masarati wrote:
[moved to -devel for discussion]

On Fri, 2005-09-30 at 18:39 +0000, raphael.ouazana@linagora.com wrote:
Finally I think it is a configuration problem : a special case of
recursive referral.
I think you can close this ITS or change it in a feature request to detect
this special bad configuration :
Server 1 with back-ldap pointing to server 2.
Server 2 with back-bdb with a referral to server1.

I think we need to design some procedure to detect this type of issues. In fact, now that back-ldap is being used for a number of applications that may give rise to circular referral conditions (proxy, chain, ...), the referral mechanism appears somewhat inadequate. In fact, it doesn't allow a built-in and standardized way to keep track of its history and/or at least count. While this might be food for thought for the ldapbis list, the current implementation of the proxy and of the chain overlay would really need this. For example, the current implementation of the chain overlay violates draft-ietf-ldapbis-protocol where it states

   Clients that follow referrals MUST ensure that they do not loop
   between servers. They MUST NOT repeatedly contact the same server for
   the same request with the same parameters. Some clients use a counter
   that is incremented each time referral handling occurs for an
   operation, and these kinds of clients MUST be able to handle at least
   ten nested referrals while progressing the operation.

because in this case it is __not__ the client library that follows
referrals and counts the number of referrals that have been followed
(thus limiting recursion by limiting the maximal count of referrals
chased, instead of keeping track of the values that were chased).  With
back-ldap and with proxies in general, there is no way to determine if a
request comes as a consequence of a referral chasing.

Maybe we could add some sort of control that appends a cookie to
requests and instructs the server to propagate that cookie when chasing
referrals or proxying the request.  The appearance of the cookie in a
request to a server, when the cookie originated from that server for
that very request, would indicate a circular reference.  I think there
is more to think about this (servers that do not implement this control
would destroy its usefulness; we need a specific control to implement
something that should be granted anyway according to draft-ietf-ldapbis-
protocol; each sub-request performed to satisfy the initial one would
need to be appended to the cookie because the circular reference may
start at any level of nested request; ...).
Actually I don't see this as a problem for referral processing, though we have to change how we handle it. That is, the back-ldap proxy needs to check when it receives a referral, and see if the referral points to itself, before chasing it. In the case of chaining, where the remote server progresses the request itself, the chaining control would be used. Unfortunately the Sermersheim draft has expired, and anyway that control doesn't carry enough information to solve this problem. Someone needs to go back to the X.518 ChainingArguments and at least bring the traceInformation into the LDAP chaining control spec.

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/