Subject: New submission: draft-moats-ldap-dereference-match-01 and AGENDA request

From: "Ryan Moats" <[email-masked]>
Date: Wed, 13 Oct 1999 11:19:21 -0500

The following has been submitted to the I-D editor.  It makes the changes
suggested by readers of -00.  We'd like 10-15 minutes of time in Washington
to discuss it (we were bumped from the Oslo agenda due to time constraints)

Ryan Moats (for the authors)

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

             Extensible Match Rule to Dereference Pointers
          Filename: draft-moats-ldap-dereference-match-01.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 12/31/99                                                [Page 1]

INTERNET DRAFTExtensible Match Rule to Dereference Pointers    June 1999

   extensible match rule that allows a LDAP search filter not to an
   object, but to the objects that are pointed to by DN pointers
   contained in a particular attribute of the base object of the search.

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.12
   )
   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=dmtfActiveConnection)(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 dmtfActiveConnectionRefs attribute of the base
   object.  Requested attributes of all objects pointed to by the
   destinationDmtfProtocolEndpointsRef attribute of objects that passed
   the first filter are then returned to the client.

   (destinationDmtfProtocolEndpointsRef:<oid-m1>:=
    (dmtfActiveConnectionRefs:<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

Expires 12/31/99                                                [Page 2]

INTERNET DRAFTExtensible Match Rule to Dereference Pointers    June 1999

[2].

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

If the number of objects that result from the application of the search
filter exceed the size limit, the server MUST respond with a 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 is 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 two 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=dmtfActiveConnection)
                    (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

Expires 12/31/99                                                [Page 3]

INTERNET DRAFTExtensible Match Rule to Dereference Pointers    June 1999

   sourceDN attribute of all objects pointed to by the targetDN
   attribute of all objects in the search scope.

     &(objectClass=fancyconnectiontype)
      (targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)
                    (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
   dmtfActiveConnection and their trafficType attribute equal to 2.

     |(foo=bar)
      (foo=barshelf)
      (&(objectClass=fancyconnectiontype)
        (targetDN:<oid-m1>:=(&(objectClass=dmtfActiveConnection)
                      (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

   In the case of a query that encounters referrals, the solution set
   returns answers based on the local data set only.  Referrals should
   be returned so that the client may submit the query to the referred
   machine.

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))
      returned attributes: (phoneNumber, building)

Expires 12/31/99                                                [Page 4]

INTERNET DRAFTExtensible Match Rule to Dereference Pointers    June 1999

   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>:(QosPolicyDirection=2)))
      returned attributes: all

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, queries of this type should
   also specify a specific time limit to ensure that other clients can
   continue to make use of the directory.

   In addition, by allowing a client to request that the server collect
   objects before applying the search filter, a client may be able to
   determine information about what objects they have rights to search
   on.  This is no different from what is possible using a subtree

Expires 12/31/99                                                [Page 5]

INTERNET DRAFTExtensible Match Rule to Dereference Pointers    June 1999

   search.

7. References

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

[1]         J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
            Information Model," Internet Draft (work in progress), May
            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 Defini-
            tion," 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: [email-masked]  USA                       E-mail:
[email-masked]
                            E-mail: [email-masked]

Expires 12/31/99                                                [Page 6]