Subject: Re: [Ldap-dir] DLAP Directorate review request for draft-dawkins-ldapext-subnot

From: Alexey Melnikov <[email-masked]>
Date: Wed, 14 Oct 2009 21:07:21 +0100

Spencer Dawkins wrote:

> Hi, LDAP Directorate,

Hi Spencer,

> Some of you may be aware of a 3GPP CT4 proposal to add a 
> subscribe/notify capability to LDAP.
>
> I've been helping Xun Peng with a draft describing this extension, 
> which I've just posted as 
> http://www.ietf.org/id/draft-dawkins-ldapext-subnot-00.txt.
>
> Alexey told me that the next step was to request a review from the 
> LDAP Directorate, asking for your opinion on AD-sponsoring this work, 
> so I'm requesting your review.
>
> I will be present in Hiroshima for any face-to-face discussions that 
> would be helpful.

Do you want some time at the Apps Area meeting in Hiroshima (Monday 9:00am)?

> A note on timing - 3GPP CT4 is meeting the same week as IETF 76, and 
> will be making a decision during that meeting on whether to use the 
> approach described in this draft (and processed in the IETF) or to use 
> an XML/SOAP alternative (not processed in the IETF). It would be 
> extremely helpful to have your feedback before November 13 (when both 
> IETF 76 and the CT4 meeting end).
>
> Thanks,
>
> Spencer

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 14 Oct 2009 13:56:03 -0700

The immediate question I have is "but why?"  That is, I'd like to  
understand better what the application requirements are so that I can  
analysis whether or not this mechanism mets those requirements.  I'd  
also like to understand better why none of the existing extensions in  
this area were (presumedly) found to do not address the application  
requirements.

I am curious as to why firewalls and NATs are mentioned in the  
applicability of the specification.  Does this extension not have the  
same basic issues with firewalls and NATs that simple LDAP has?  That  
is, LDAP generally works just fine (*) through firewalls and NATs so  
long as they are configured to allow traversal, as most TCP-based  
client/server protocols do.  (* expecting issues with reverse NAT and  
knowledge references, and the like).

I didn't dig into the particulars of the extension protocol yet.  I  
defer comments here until I better understand the "why?".  But on  
first glance, I suspect it suffers from many of the problems folks  
have found in triggered searches and like extensions.

On security considerations, I suspect there are many considerations  
that this extension, by itself, raises.  Just referencing general LDAP  
security considerations seems quite inadequate to me.

-- Kurt

On Oct 14, 2009, at 1:07 PM, Alexey Melnikov wrote:

> Spencer Dawkins wrote:
>
>> Hi, LDAP Directorate,
>
> Hi Spencer,
>
>> Some of you may be aware of a 3GPP CT4 proposal to add a subscribe/ 
>> notify capability to LDAP.
>>
>> which I've just posted as http://www.ietf.org/id/draft-dawkins-ldapext-subnot-00.txt 
>> .
>>
>> LDAP Directorate, asking for your opinion on AD-sponsoring this  
>> work, so I'm requesting your review.
>>
>> I will be present in Hiroshima for any face-to-face discussions  
>> that would be helpful.
>
>> A note on timing - 3GPP CT4 is meeting the same week as IETF 76,  
>> and will be making a decision during that meeting on whether to use  
>> the approach described in this draft (and processed in the IETF) or  
>> to use an XML/SOAP alternative (not processed in the IETF). It  
>> would be extremely helpful to have your feedback before November 13  
>> (when both IETF 76 and the CT4 meeting end).
>>
>> Thanks,
>>
>> Spencer
>
>
> _______________________________________________
> Ldap-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldap-dir

---

From: Steven Legg <[email-masked]>
Date: Thu, 15 Oct 2009 11:41:19 +1100

Hi Spencer,

> this area were (presumedly) found to do not address the application 

Ditto from me on the "but why". One thing the draft doesn't make clear
is whether a subscription persists beyond the LDAP session that
establishes it. That is, can an LDAP client create a subscription,
end the session, and come back later with a new session and pick up
the notifications for events that occurred in the meantime and occur
subsequently ? If not, then this appears to be just another (though
perhaps cleaner) way to do persistent search, for which there are
already implementations.

Have any LDAP server vendors expressed an interest in implementing this
subscription mechanism ?

Regards,
Steven

> defer comments here until I better understand the "why?".  But on first 
> glance, I suspect it suffers from many of the problems folks have found 
> in triggered searches and like extensions.
> 
> On security considerations, I suspect there are many considerations that 
> this extension, by itself, raises.  Just referencing general LDAP 
>>> approach described in this draft (and processed in the IETF) or to 
>>> use an XML/SOAP alternative (not processed in the IETF). It would be

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 15 Oct 2009 13:53:50 +0200

On Oct 15, 2009, at 2:41 AM, Steven Legg wrote:

>> understand better what the application requirements are so that I  
>> can analysis whether or not this mechanism mets those  
>> requirements.  I'd also like to understand better why none of the  
>> existing extensions in this area were (presumedly) found to do not  
>> address the application requirements.
>
> establishes it.

Ditto.

> That is, can an LDAP client create a subscription,

We've had discussions with one of our customer who was interested in  
similar subscription / notification model, with the ability to end  
session, come back and retrieve notifications for all events since the  
end of the last session.

If this I-D is along the same line, we may implement such  
functionality in our server. There are definitely things to tidy up  
first.

Regards,

Ludovic.

>> applicability of the specification.  Does this extension not have  
>> the same basic issues with firewalls and NATs that simple LDAP  
>> has?  That is, LDAP generally works just fine (*) through firewalls  
>> and NATs so long as they are configured to allow traversal, as most  
>> TCP-based client/server protocols do.  (* expecting issues with  
>> reverse NAT and knowledge references, and the like).
>> that this extension, by itself, raises.  Just referencing general  
>> LDAP security considerations seems quite inadequate to me.
>> -- Kurt
>>>> I've been helping Xun Peng with a draft describing this  
>>>> extension, which I've just posted as http://www.ietf.org/id/draft-dawkins-ldapext-subnot-00.txt 
>>>> .
>>>>
>>>> Alexey told me that the next step was to request a review from  
>>>> the LDAP Directorate, asking for your opinion on AD-sponsoring  
>>>> this work, so I'm requesting your review.
>>>>
>>>> and will be making a decision during that meeting on whether to  
>>>> use the approach described in this draft (and processed in the  
>>>> IETF) or to use an XML/SOAP alternative (not processed in the  
>>>> IETF). It would be extremely helpful to have your feedback before  
>>>> November 13 (when both IETF 76 and the CT4 meeting end).
>>>>
>>>> Thanks,
>>>>
>>>> Spencer
>>>
>>>

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Oct 2009 13:59:07 -0500

Hi, LDAP Directorate,

Some of you may be aware of a 3GPP CT4 proposal to add a subscribe/notify 
capability to LDAP.

I've been helping Xun Peng with a draft describing this extension, which 
I've just posted as 
http://www.ietf.org/id/draft-dawkins-ldapext-subnot-00.txt.

Alexey told me that the next step was to request a review from the LDAP 
Directorate, asking for your opinion on AD-sponsoring this work, so I'm 
requesting your review.

I will be present in Hiroshima for any face-to-face discussions that would 
be helpful.

A note on timing - 3GPP CT4 is meeting the same week as IETF 76, and will be 
making a decision during that meeting on whether to use the approach 
described in this draft (and processed in the IETF) or to use an XML/SOAP 
alternative (not processed in the IETF). It would be extremely helpful to 
have your feedback before November 13 (when both IETF 76 and the CT4 meeting 
end).

Thanks,

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Oct 2009 15:53:31 -0500

Hi, Alexey,

That would probably be an excellent thing to do. Are you thinking 10-15 
minutes?

Thanks,

Spencer

>> A note on timing - 3GPP CT4 is meeting the same week as IETF 76, and will 
>> be making a decision during that meeting on whether to use the approach 
>> have your feedback before November 13 (when both IETF 76 and the CT4 
>> meeting end).
>>
>> Thanks,
>>
>> Spencer
>
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 16 Oct 2009 07:23:20 -0500

Hi, Kurt,

I'm replying to a question you asked, but my reply is probably also relevant 
to Steven Legg's question about subscription lifetimes.

> same basic issues with firewalls and NATs that simple LDAP has?  That  is, 
> LDAP generally works just fine (*) through firewalls and NATs so  long as 
> they are configured to allow traversal, as most TCP-based  client/server 
> protocols do.  (* expecting issues with reverse NAT and  knowledge 
> references, and the like).

My understanding of this proposal (Peng is the expert on the proposal, I'm 
the guy who understands the IETF) is that the LDAP client would not close 
the TCP connection to the LDAP server, but would leave the TCP connection 
open, so that the LDAP server can send notifications in a timely manner.

This isn't normal LDAP-style TCP connection handling, as I understand it 
(please correct me if I am confused).

The alternatives would be

o having the LDAP client poll periodically to pick up notifications (as you 
visualized) - this wasn't chosen, because the goal is that notifications be 
delivered in a timely manner, or

o having the LDAP server open a TCP connection to the LDAP client - this 
wasn't chosen, because it trips over one-way firewall policies.

So I was imagining that we would have problems with firewall and NAT binding 
timeouts, etc. in ways that other LDAP operations would not. That's what I 
was thinking about when I added this section, just before we submitted.

Does this make sense? (And, if so, should this model of operation be stated 
more clearly in the draft? :-)

As for Steven's question - I believe that the LDAP server would remove the 
subscription if the TCP connection is closed, or reset due to unreachability 
of the client. Does this make sense, or would you prefer to see an 
LDAP-level unsubscribe operation?

I'd also like to thank you guys for the near-instantaneous feedback.

Spencer

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 16 Oct 2009 13:54:01 -0700

If I understand all that you and Xun have said, this specification is  
attempting to mechanism that allows an LDAP client to maintain a copy  
of select directory content, presumedly with a requirement of eventual  
(but timely) convergence of the copy with the directory content.

Is that correct?  If so, then I think the question many of then have  
is, how does LDAP Content Sync [RFC 4533], or LCUP [RFC 3928], or  
various other mechanisms that have been suggested in the past fail to  
met the application requirements?  That is, we understand you don't  
want to poll for changes, but why aren't any of the existing  
mechanisms we already have to avoid polling for changes not suitable?

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 16 Oct 2009 13:55:19 -0700

On Oct 16, 2009, at 1:54 PM, Kurt Zeilenga wrote:

> If I understand all that you and Xun have said, this specification  
> is attempting to mechanism that allows an LDAP client to maintain a  
> copy of select directory content, presumedly with a requirement of  
> eventual (but timely) convergence of the copy with the directory  
> content.

s/attempting to mechanism/attempting to provide a mechanism/

> various other mechanisms that have been suggested in the past fail  
> to met the application requirements?  That is, we understand you  
> don't want to poll for changes, but why aren't any of the existing