Subject: Policy Containment

From: [email-masked]
Date: Mon, 5 Apr 1999 13:56:59 -0400

Bob & I wrote-up some proposed text for describing the mechanisms for
finding policy-related object instances.

--------

SECTION:  Policy Containers

When a PDP goes to an LDAP directory to retrieve the policy object
instances relevant to the PEPs it serves, it is faced with two related
problems.

-- How does it locate and retrieve the directory entries that apply to its
PEPs.  These entries may include instances of all the Core Schema classes,
instances of domain-specific subclasses of these classes, and instances of
other classes modeling such resources as user groups, interfaces, and
address ranges.

-- How does it retrieve the directory entries it needs in an efficient
manner, so that retrieval of policy information from the directory does not
become a roadblock to scalability.  There are two facets to this
efficiency:  retrieving only the relevant directory entries, and retrieving
these entries using as few LDAP calls as possible.

We will assume that the PDP is configured sufficient information to find an
LDAP server to which it can direct its queries.  There are two basic
approaches the PDP can take.

1. If the PDP is configured with a high-level directory suffix under which
it can begin its search for policy-related entries, the PDP can request all
entries from the subtree beneath its starting suffix that match specified
value(s) in such search-assisting attributes as policyGroupKeywords,
policyRuleKeywords, and policyRuleUsage.  Once the relevant policy groups
and policy rules have been retrieved, it would then follow the (structured)
DN pointers to locate the relevant policy conditions and policy actions.

A PDP that goes exclusively with this first approach will be able to find
all the policy entries that apply to it, but this may require a large
number of LDAP calls as it follows the DN pointers from policy groups to
nested policy groups, from base-level policy groups to policy rules, and
from policy rules to policy conditions and actions.  In some limited cases,
simple policy rules can help by eliminating the DN pointers from the rules
to the conditions and actions.  But these simple policy rules do not
generalize and these simple policy rules do not remove the need for more
optimal retrieval of policy-related object entries.

2. The PDP may have a configured way of getting to a specific entry to
serve as a starting place for policy retrieval.  The PDP may be initialized
with the name of a policyContainer object entry for its policies.  That
policyContainer entry, then, may contain--in the directory name space
hierarchy sense of containment--policy-related object entries and it might
also have DNs that point to other related object entries.

Using this second approach and the LDAP bulk retrieval capability, the PDP
may issue an LDAP call specifying the DN of a configured policyContainer
entry requesting that all entries in its subtree must also be evaluated
against the selection criteria specified in the request.  The LDAP-enabled
directory, then, returns all entries in that subtree that satisfy the
specified criteria.  Using this technique, it would be possible to place
all related policy group object entries and all of their policy rule
entries as well as related condition and action class entries in a single
policyContainer subtree.

                   +-----+
  ---------------->|  A  | DN pointers to other subtrees +---+
  DN pointer to    |     | || +------------------------->| C |
  policy container |  ---+-V|-+         +---+            +---+
                   |  ---+--V---------->| B |           /     \
                   +-----+              +---+          /       \
                  /       \            /     \        /   ...   \
                 /         \          /       \
                /    ...    \        /   ...   \

  Figure N. Using a policyContainer Object to Scope Policies

Figure N shows the policyContainer class.  It is central to the semantics
of this class that an instance of the class (1) itself anchors a subtree of
entries related to the policies associated with the container, and (2) may
contain DN pointers to other object entries perhaps including other
policyContainer instances that anchor other subtrees that also contain
entries related to these policies.  The idea is that a PDP whose starting
place is a policyContainer will first retrieve all of the related subtrees
associated with the container, and then, in local memory, follow the DN
pointers between groups and rules, rules and conditions, and rules and
actions.

With policy containers, the policy administrator has the freedom to
organize policy entries in the DIT in a number of ways.  In Figure N, for
example, the subtree under A might contain departmental policies, under B
divisional policies, and under C corporate policies.  Alternatively, A's
subtree might contain policy groups and policy rules, B's subtree policy
conditions, and C's subtree policy actions.  In both cases the PDP's action
is the same.  First it retrieves all the policy entries, using one LDAP
call to get A and the subtree under it, followed by two more calls to get B
and C and their respective subtrees.  Then the PDP uses local calls to
traverse the various DN pointers among the entries it has just retrieved.

Similarly, a policyContainer instance may have a DN pointer to another
policyContainer instance that, in turn, has pointers to other
policyContainer instances.  This recursion permits a structured approach to
identifying related policies so, in the example above, the division
policies might include references to Corporate policies without the
departmental administrator needing to explicitly do so.

The DN list in the policyContainer class may also be used to point to
object entries that are not other policyContainers.  For example,
domain-specific policies may be specified to use other object classes such
as addressRange and they may be contained by an ipSubnet class instance.

Since a PDP has no guarantee that the entity that populates the directory
won't use policy containers, a PDP MUST understand the policyContainer
class, MUST be capable of retrieving and processing the entries in the
subtree anchored by the container, and MUST be capable of following the DN
pointers from the container to other subtrees of policy entries.  The same
requirements apply to any other entity needing to retrieve policy
information from the directory.  Thus a Policy Management Tool that
retrieves policy entries from the directory in order to perform validation
and conflict detection MUST also understand and be capable of using policy
containers.

When it is serving as a tool for creating policy entries in the directory,
a Policy Management Tool SHOULD support creation of policyCondition entries
and their DN pointers.

SECTION:  Aliases

                   +-----+
  ---------------->|  A  | DN pointers to other subtrees +---+
  DN pointer to    |     | || +------------------------->| C |
  policy container |  ---+-V|-+         +---+            +---+
                   |  ---+--V---------->| B |           /     \
                   +-----+              +---+          /       \
                  /       \            /     \        /   ...   \
                 /         \          /       \
    +---+       / +------+  \        /   ...   \
    | X |<********|aliasX|
    +---+         +------+

  Figure N+1.  Addition of an Alias Object

Figure N+1 shows an additional capability available to the policy
administrator:  LDAP aliasing.  Even if it is necessary to store a policy
entry X in a directory location separate from the other policy entries,
batch retrieval using policy containers can still be done.  The
administrator simply inserts into one of the subtrees identified by the
container an alias entry aliasX pointing to the outlying entry X.  When the
PDP requests all entries in the subtree under A, a response will be
returned for entry X, just as responses are returned for all the
(non-alias) entries that actually are in the subtree.

Since resolution of an alias to its true entry is handled entirely by the
LDAP directory, and is invisible to directory clients, PDPs need not do
anything extra to support aliases.  A Policy Management Tool MAY make
available to a policy administrator the ability to create alias entries
like the one in Figure N+1.

Lee M. Rafalow
Voice: 1-919-254-4455 (8-444-4455); Fax: 1-919-254-6243 (8-444-6243)
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, JDGA/501
RTP, NC 27709 USA
Work email: [email-masked]
Intranet: http://rafalow.raleigh.ibm.com/
Home email: [email-masked]