RE: Comments on draft-ietf-ldapext-trigger-01.txt

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Thanks for the response - I know one has to protect system resources -
we have quite a few features in our LDAP/X.500 distributed servers that
do just that and these features work consistently over a domain of them.

I just wonder if there is anyone on this list that has any concern re
the  rate at which these new LDAP features are being invented -
particularly when those features do not resolve LDAP server
scaling/distribution issues or infact just compound the problem by
introducing "resource locking" and/or limit less state machines. ie. the
more optional features added, the worse the interoperability becomes - 


It seems so obvious that the more one adds to LDAP the less "L" it
becomes and the worse it gets. Its just like baking a cake 7 times over.
One gets to the point where one has to throw it away.

But as an optimist some of these new LDAP options make LDAP V2/3 "basic
access" and/or DAP access to X.500 distributed directories a much more
pragmatic, workable and cost effective solution.

regards alan



----------
From: Tim Howes
To: Alan Lloyd
Cc: 'ietf-ldapext@netscape.com '
Sent: 8/14/98 8:33:30 AM
Subject: Re: Comments on draft-ietf-ldapext-trigger-01.txt

There's nothing in either the persistent search
or triggered search protocol elements that prevent
this, just like there's nothing in the basic LDAP
(or X.500 for that matter) protocol elements that
prevent 10-100 clients from making connections to
your server and beating the hell out of it in a
denial of service attack. Such things are handled
by administrative limits, sensible engineering and
configuration, audit trails, etc. Just as with any
operation that uses server resources, servers must
protect themsleves from having too many resources
consumed by malicious or careless users.
        -- Tim

Alan Lloyd wrote:
> 
>  Just a quick one - (thats not like me eh!) :-)
> Is it possible with this feature say, for 10 -100 users to plant a
> triggered search on every entry, say in a 100k entry DIB LDAP server
and
> for every entry update, the server has to check all 100 Users trigger
> requirements which include their ACLs and filters.
> 
> Sorry to be negative - but such features should be seen as totally
open
> to abuse and a massive performance slug on low end LDAP servers.
> 
> regards alan
> --