One document matched: draft-moats-ldap-dereference-match-02.txt

Differences from draft-moats-ldap-dereference-match-01.txt

Internet-Draft                                                Ryan Moats
draft-moats-ldap-dereference-match-02.txt                Jerry Maziarski
Expires in six months                                               AT&T
Category: Experimental Track                              John Strassner
                                                           cisco Systems
                                                           December 1999


             Extensible Match Rule to Dereference Pointers
          Filename: draft-moats-ldap-dereference-match-02.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document defines a LDAPv3 extensible matching rule that allows a
   server to dereference pointers stored in an object's attribute and
   apply a LDAPv3 search filter to the resulting objects.  This rule
   allows schema definitions to capture richer association models
   without requiring extra protocol exchanges or special client code.

1. Introduction

   When mapping rich information models, it sometimes becomes necessary
   to use DN pointers to show relationships between objects in the
   schema.  An example is the information model and resulting core
   schema that is currently being proposed by the policy working group
   (see [1]).

   To maintain client efficiency, it is desirable to define an



Expires 6/30/2000                                               [Page 1]





INTERNET DRAFTExtensible Match Rule to Dereference PointersDecember 1999


   extensible match rule that follows DN pointers as part of a query.

2. dereferencingMatch

   A server will advertise support for this matching rule by having the
   following rule definition present in its root subschema subentry.
   ( <oid-m1> NAME "dereferencingMatch"
     DESC "Extended match that dereferences before searching"
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   )
   This extensibleMatch filter is used by a client presenting <oid-m1>
   as the matchingRule, any attribute with DN syntax as the type and a
   string representation of a LDAP search filter as the value.  The
   server first collects the objects that the attribute points to and
   the client has permission to read and then applies the specified LDAP
   filter to them, returning the objects that were matched.

   For example, a client that presented the following filter:

   (targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)(trafficType=2)))

   The server would apply the filter specified to all objects referenced
   to by the values of the targetDN attribute of the current object.  It
   would then return the requested attributes of the objects that
   matched the specified filter.

   If the LDAP filter itself contains a dereferencingMatch rule, it is
   possible to do double dereferencing. The following filter causes the
   server to first apply the embedded filter (trafficType=2) to objects
   pointed to by the cimActiveConnectionRefs attribute of the base
   object.  Requested attributes of all objects pointed to by the
   cimProtocolEndpointsRef attribute of objects that passed the first
   filter are then returned to the client.

   (cimProtocolEndpointsRef:<oid-m1>:=
    (cimActiveConnectionRefs:<oid-m1>:=(trafficType=2)))

   In cases where a client does not have permission to access an object
   pointed to by a reference, that object is not placed on the list.

3. Considerations

3.1 Advertisement

A server implementing this extended match rule MUST include the OID of
this matching rule in the subschema entry of the root DSE, per RFCs 2251
[2].




Expires 6/30/2000                                               [Page 2]





INTERNET DRAFTExtensible Match Rule to Dereference PointersDecember 1999


3.2 Non-supporting Server Reply

Servers that do not support this extension MUST follow section 7.8 of
X.511 [3]. This is consistent with RFC 2251.

3.3 Interaction with sizelimit

During the application of this search filter, intermediate collections
of entries will result.  If the number of entries in these intermediate
collections exceed the server's size limit, the server MUST respond with
size limit exceeded error.

3.4 Search scoping considerations

   Because of the possibility of size limit overload and the loss of
   relationship between the returned objects and the source object
   during one-level or subtree searches, it is strongly recommended that
   this match rule only be used with base level searches.

3.5 Combining with other search filters

   Because this extensible matching rule is intended to result in
   objects and not a true/false value, rules for combination with other
   filters are necessary.  When combining filters, all non-dereferencing
   match filters at the level of the dereferencing-match are applied to
   the current object first. Then, any remaining objects have the
   dereferencing match applied to it.

   This rule means that it is illegal to have two dereferencing match
   filters at the same level.  The only legal combination is for a
   dereferencing match filter to "include" another dereferencing match
   filter.  This would allow a multi-step pointer dereferencing.

   Also, it is illegal for a boolean filter to be at a level "above" the
   dereferencing match, because of scope conflicts.

   To help clarify this rule, the following examples are provided:
     &(targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
                             (trafficType=2)))
      (sourceDN:<oid-m1>:=(objectClass=foobar)

   This filter is illegal because it specifies two dereferencing match
   rules at the same level.

     (targetDN:<oid-m1>:=(sourceDN:<oid-m1>:=(objectClass=*)))

   This filter is legal and returns all objects pointed to by the
   sourceDN attribute of all objects pointed to by the targetDN



Expires 6/30/2000                                               [Page 3]





INTERNET DRAFTExtensible Match Rule to Dereference PointersDecember 1999


   attribute of all objects in the search scope.

     &(objectClass=fancyconnectiontype)
      (targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
                             (trafficType=2)))

   This filter is legal, and would return all objects pointed to by the
   targetDN attribute of objects whose objectClass attribute was equal
   to fancyconnectiontype that had their objectClass attribute equal to
   cimActiveConnection and their trafficType attribute equal to 2.

     |(foo=bar)
      (foo=barshelf)
      (&(objectClass=fancyconnectiontype)
        (targetDN:<oid-m1>:=(&(objectClass=cimActiveConnection)
                               (trafficType=2))))

   This filter is illegal because the first two filters are at a
   "higher" level than the dereferencing match filter.

3.6 How to handle referrals

   For a query that encounters referrals, the solution set returns
   answers based on the local data set only.  Referrals should be
   returned using a rewritten query contained in a LDAP URL so that the
   client may submit the rewritten query to the referred machine.
   Without query rewriting, it would be impossible for the client to
   know at what stage of pointer dereferencing the referral occurred.

4. Examples of Use

   We present two (admittedly simple) examples for how this rule could
   be used.

4.1 White Pages Example

   In our first example, a directory holds white pages information,
   including building managers for buildings.  In their schema,
   buildings have their own object class (objectClass: building), which
   contains an attribute manager that has multi-valued DN syntax.  These
   DNs point to objects of object class person (objectClass: person) and
   include attributes phoneNumber and building.

   To find the phone number and building of all managers of any building
   the following query could be used:

      query type: subtree
      filter: (manager:<oid-m1>:(objectClass=person))



Expires 6/30/2000                                               [Page 4]





INTERNET DRAFTExtensible Match Rule to Dereference PointersDecember 1999


      returned attributes: (phoneNumber, building)

   To find the phone numbers of managers of building 12, the following
   query could be used:

      query type: subtree
      filter: (manager:<oid-m1>:((objectClass=person)&(building=12)))
      returned attributes: phoneNumber

4.2 Policy Example

   As a more complex example, we consider the case of managing QoS
   policy rule at a router.  We assume that the routers are modeled in
   the schema as objects with their own object class (objectClass:
   router) that include the attributes ipAddress and qosPolicyRules (a
   multi-valued DN attribute).  The attribute qosPolicyRules points to
   objects with objectClass set to qosPolicyRule and include attributes
   QosPolicyDirection (integer) and policyRulesAuxContainedSet (multi-
   valued DN).  This latter attribute points, in turn, to policy rules
   (objectClass: policyRule) with multiple attributes.

   To find policy rules for outbound traffic (QosPolicyDirection = 2)
   for routers with IP address 192.128.170.x, the following search could
   be used

      query type: subtree
      filter: (policyRulesAuxContainedSet:<oid-m1>:
               &(ipAddress="192.128.170.*")
                (qosPolicyRules:<oid-m1>:(QosPolicyDirection=2)))
      returned attributes: all

4.3 Referral Example

   As an example of how query-rewriting occurs during a referral, let us
   consider the example from section 4.2 above. It could be possible
   that policy rules for the routers are stored under a different
   portion of the directory tree that is contained in a different server
   (for example referral.foo.bar on port 389).  In that case, the
   referral would point to object <dn> and the following URL would be
   returned:

      ldap://referral.foo.bar/<dn>?sub?(qosPolicyRules:<oid-m1>
          :(QosPolicyDirection=2))

   The client could then follow this URL to continue the search.






Expires 6/30/2000                                               [Page 5]





INTERNET DRAFTExtensible Match Rule to Dereference PointersDecember 1999


5. Why use an extensible matching rule rather than a control?

   An alternative implementation of this procedure would be to use a new
   control, rather than an extensible matching rule.  We have considered
   this, but have failed to find a method for supporting multiple levels
   of dereferencing, which can be supported when using an extensible
   matching rule.

6. Security considerations

   An improperly formed query can create a denial of service attack by
   using up excessive resources.  Therefore, servers that support
   queries of this type should implement specific time limits that
   cannot be overriddent  to ensure that other clients can continue to
   make use of the directory.

   Although this type of query allows a client to request that the
   server collect objects before applying the search filter, it creates
   no additional security issues above what needs to be considered when
   allowing a subtree search.

7. References

   Request For Comments (RFC) and Internet Draft documents are available
   from numerous mirror sites.

         [1]         J. Strassner, E. Ellesson, B. Moore, R. Moats,
                     "Policy Framework Core Information Model," Internet
                     Draft (work in progress), November 1999.

         [2]         M. Wahl, T. Howes, S. Kille, "Lightweight Directory
                     Access Protocol (v3)," RFC 2251, December 1997.

         [3]         ITU-T Rec. X.511, "The Directory: Abstract Service
                     Definition," 1993.

7. Author's Addresses

   Ryan Moats               Jerry Maziarski           John Strassner
   15621 Drexel Circle      Room C3-3Z01              Cisco Systems, Bldg 1
   Omaha, NE 68135          200 S. Laurel Ave.        170 West Tasman Drive
   USA                      Middletown, NJ 07748      San Jose, CA 95134
   E-mail: jayhawk@att.com  USA                       E-mail:
johns@cisco.com
                            E-mail: gfm@qsun.att.com







Expires 6/30/2000                                               [Page 6]