[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
New submission: draft-moats-ldap-dereference-match-01 and AGENDA request
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: jayhawk@att.com USA E-mail:
johns@cisco.com
E-mail: gfm@qsun.att.com
Expires 12/31/99 [Page 6]