Subject: Second proposed mail on LCUP draft...

From: "Ryan Moats" <[email-masked]>
Date: Fri, 10 Mar 2000 12:49:29 -0600

Having read the LCUP draft, we're concerned that this doesn't
seem to address the issues that were identified with either
the old or new Persistent and Triggered searches drafts.  

A noticeable point is that the definition doesn't distinguish
(at the protocol message level) between the cases where 
a server shuts down a connection normally and where it
shuts down a connection because of resource exhaustion.
Further, the draft needs to provide some guidance/mandate
on client behavior in the second case.  Without it, what's
to stop a client from reconnecting and resubmitting the
control (and how does that help resource exhaustion)?

The LCUP draft might want to contain something along the lines of the
"Implementation Considerations" section of the new psearch draft.  The
intended use discussion raises some interesting scale issues that LCUP
should address.

LCUP draft should mention whether any other LDAP requests/responses can
be sent via the open connection while a keepConnection request is
active (The draft doesn't seem to say.  We hope the answer is
"none apart from the usual suspects like ABANDON").

Why MUST a stateUpdate message contain a valid entry?

If the client sends the server a bad cookie, the server sends back
unwillingToPerform.  Is there some problem in generating a more specific
error?  Using a really general error seems like it might lead to a lot
of customer service support time to track down the real problem.

Why SHOULD size and time limits be ignored for persistent operations?
Why not MUST?

The Security Considerations address the issue of limiting resources
that are accessed by a single client, but don't seem to address the
same issues if the "attacker" just uses several clients.

Ryan Moats
Rick Huber

---

From: "Ryan Moats" <[email-masked]>
Date: Fri, 10 Mar 2000 13:12:08 -0600

(That's what I get for not paying attention to
subject lines.  This is a resend with a correct
subject.  Sigh)

Ryan Moats
Rick Huber

---

From: [email-masked] (Olga Natkovich)
Date: Tue, 14 Mar 2000 14:57:04 -0800

Hi,

Thank you for your feedback. My comments are inline below.

> control (and how does that help resource exhaustion)?

Good point. The server should send an appropriate error code to the client.
I will  define a control that will be attached to the SearchResultDone
message and will contain the error code. I will also add the information on
client's behavior; I was thinking something along the lines of exponential
backoff.

> intended use discussion raises some interesting scale issues that LCUP

Ok, I will add that.

> "none apart from the usual suspects like ABANDON").

I am not sure why it would be beneficial to disallow other operations on the
same connection. Since each request/response pair carries a message id, no
ambiguity could arise. Also, allowing operations on the same connection
would allow to conserve server's resources.

> Why MUST a stateUpdate message contain a valid entry?

By valid entry I meant an entry that contained a valid DN to comply with
LDAP v3 definition of the
SearchResultEntry. I will clarify this in the draft.

> of customer service support time to track down the real problem.

The only problem was the need for a new control. However, this seems like
the right thing to do. So the control described above will be used.

> Why SHOULD size and time limits be ignored for persistent operations?

Right, this should be MUST.

> same issues if the "attacker" just uses several clients.

This problem is not specific to LCUP; the same problem exists in LDAP and a
lot of other client-server applications. Mark Smith suggested that we do the
following:  "... you can require authentication and restrict use of LCUP to
some clients, but if the attacker gets a hold of an identity that is allowed
to use LCUP life is hard.  We could suggest limiting how many different
simultaneous connections can be used for LCUP that are bound to the same
identity (e.g., "Bob Smith is allowed to use LCUP
but only on 2 connections at a time.")  Implementation of such a restriction
would be server-specific for now but could be rolled into the LDAPv3 access
control standard.

Olga