Problems in RFC3060 et al

[Jeff Hodges <jhodges@oblix.com>]

This is the information wrt RFC 3060 et al that I'd mentioned and subsequently
signed-up to obtain. There's lessons in there that'll be relevant no matter
which model we use and/or develop.  

JeffH

-------------------------------------------------------------------------
Here's the set of issues perceived, by John Strassner (a PCIM [1] coauthor, in
the models specified by these inter-related documents..


[1] Policy Core Information Model (PCIM)
    http://www.rfc-editor.org/rfc/rfc3060.txt

[2] Policy Core LDAP Schema
    http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-11.txt

[3] Common Information Model (CIM)
    Distributed Management Task Force (DMTF)
    http://www.dmtf.org/standards/standard_cim.php


Here are some additional useful references supplied by John -- with the 
suggestion of reviewing them BEFORE reading the commentary below..

[4] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling,
    B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry,
    S. Waldbusser, Terminology for Policy-Based Management,
    <draft-ietf-policy-terminology-04.txt>

[5] J. Strassner, Directory Enabled Networks, Macmillan Technical
    Publishing, 1999, ISBN 1-57870-140-6 (especially Chapter 10 & 11)

[6] J. Strassner, =93Using an Information Model to Achieve Better
    Network and System Management=94, Proceedings of ICT2001, 2001

[7] J. Strassner, The IETF Policy Framework, Policy Workshop 1999
     Conference Proceedings


Below's John's comments on RFC3060 (lines begin with "> "), with
my (JeffH's) comments interspersed..


> First, please turn to page 11, of RFC 3060, which shows a rough ASCII
> block diagram of the model.
>
> Problem #1
>
> Note relationship b, PolicyGroupInSystem, and relationship c,
> PolicyRuleInSystem. While the goals of these relationships are noble,
> they just don't work. The definitions of these relationships are
> something like: "This association links a PolicyGroup (PolicyRule) to
> the System in whose scope the PolicyGroup (PolicyRule) is defined".
>
> This simply can't work for the networking case (though it may work for
> the general case). Problem is, a router or switch is represented in
> CIM as a particular type of ComputerSystem. Fine (not really, but
> let's not go there for this argument) except for one crucial point:
> the *intelligence* in networking devices is usually *not* in the
> chassis, but in the various cards that fit into a chassis. Each card
> has a set of interfaces, and very likely each (physical) interface has
> a set of logical subinterfaces that map onto it. So what this
> relationship does is point at a nebulous concept of a "System". The 
> "System" in this case is ill-defined, in that it is too
> general-purpose in nature (see description of a CIM "System" in note
> 1 at the end), and certainly does NOT capture the richness of a
> router. It should really be "ComputerSystem", since this is the CIM
> class that represents a router. At the very least, what one would
> have to do is to follow a myriad of associations and aggregations
> emanating from the (Computer)System to the respective components
> that contain the intelligence that is the target of the policy. This
> can lead to implementation nightmares (as in the case of a
> directory). So, this is exactly the wrong
> place to point. Furthermore, it can actually screw things up, because
> you may have two different policies pointing at the same system, when
> in fact they really map onto different interfaces (or worse, different
> subinterfaces of the same physical interface). 
>
> End result: these two associations do NOT properly scope their targets.

The lesson here is that problems will arise if one's (generically 
speaking) "policy information model" doesn't properly model it's world (or 
"scope it's targets" as put above). One would have to carefully check for this 
when applying RFC3060 (or any other policy information model) to a particular 
application domain (e.g. XACML's).


> Problem #2
>
> System is tied to the DMTF concept of System.

Here, he's pointing at CIM [3] and it's schemas, see..

[8] http://www.dmtf.org/standards/cim_schema_v26.php (in general)
    see this link for graphical model of CIM core schema..
    http://www.dmtf.org/var/release/CIM_Schema26/Visio-CIM_Core26.pdf


> This means if you want
> to try and fix problem #1 above, you first have to fix various
> problems in the  DMTF classes representing System and it's subclasses.
>
> Now, someone in the DMTF is bound to argue that gee, you can find the
> interface of a card of a device. They'll say:
>
>  a. Subclass System to get ComputerSystem (which is OK,
>     since subclasses inherit relationships) - this will
>     serve as the base class for a router
>  b. Locate the IPProtocolEndpoint (which is the subclass
>     of ProtocolEndpoint, which is the subclass of
>     ServiceAccessPoint) via the HostedSAP association
>
> But wait a minute! How do you know that this is the correct
> IPProtocolEndpoint? Well, IPProtocolEndpoint does have an IP address
> as a set of attributes (address and mask), but what if you are
> trapping on a range of IP addresses? There is an IPAddressRange class,
> which has a StartAddress and an EndAddress. But its superclass is
> CollectionOfMSEs, *which does not participate in the HostedSAP
> association*. Oops.
>
> In fact, the only way that you can bring IPAddressRange into the
> picture is through the MemberOfCollection aggregation, which is way
> above ProtocolEndpoint. And it doesn't give you the granularity to do
> what you want easily.
>
> (And since there isn't the concept of a logical subinterface, you
> simply can't do the other, period).
>
> What they all like to gloss over is that, in a real system, if you
> wanted to correlate this to the PhysicalInterface, then you have to do
> the following:
>
>  a. Change from the Network Model to the Physical Model
>  b. Oops, you're stuck, because there's no way to get
>     directly from ComputerSystem (a logical concept) to
>     the physical model except thru the Realizes association,
>     which is to LogicalDevice, not ComputerSystem). Sure,
>     there is an aggregation (SystemDevice) to go from
>     ComputerSystem to LogicalDevice, but the point is that
>     in this example, *we don't have a LogicalDevice*!
>  c. If you choose to ignore this, then assume you can get
>     to the (Physical) Chassis class. You then:
>     1. Get to a Slot via the Container aggregation
>     2. Get to a Card via the CardInSlot association
>     3. Get to the PhysicalLink via the ElementsLinked assocation
>     4. Oops, no way to get back to the logical interface

The lesson here is yet more of the same flavor-of-lesson as in Problem #1.


With Problem #3, he's again referring to RFC 3060 [1]...

> Problem #3
>
> The duality of PolicyCondition(Action)InPolicyRule and
> PolicyCondition(Action)InPolicyRepository. Simply stated, the model is
> broken because it doesn't prevent the same condition(action) from
> being both a rule-specific and a resuable condition(action) at the
> same time. This semantic is crucial, and is explicitly broken in  RFC
> 3060.

The above appears to be an item that'd be of concern if one attempted to 
generally apply PCIM [1], and thus is of concern to the XACML group.

>
> Problem #4
>
> Mismatches between CIM attributes [3,4] and Policy attributes [2].
> In an effort to minimize changes on CIM, some of the co-authors
> insisted that we redefine X.500 attributes. For example, cn is
> defined as a single-valued attribute in CIM, but is in reality a
> multi-valued attribute in X.500. Sigh.

The lesson in #4 being that one will encounter difficulties when mapping 
from an abstract model to a physical one, depending upon the repository's 
inf model. Redefining the repository's model, esp. when it's standardized, 
to overcome the difficulties may not be a good idea in practice.

>
> Problem #5
>
> Naming (we're now into the Policy Core LDAP Schema [2], which is in
> front of the IESG as we speak) is a mess. The only
> thing that made everyone happy was to have not one, not two, but three
> (yes, THREE) naming attributes that you could choose from:
>
>   1) cn
>   2) class-specific attribute (PolicyRuleName)
>   3) orderedCIMKeys
>
> This last was a critical mistake, and attempts to reproduce the CIM
> hierarchy in DN-like form as a string attribute. This is especially
> troublesome because CIM doesn't map consistently and coherently to
> LDAP (e.g., there is no one single semantic for expressing the concept
> of DIT containment in CIM - gee, there isn't a real semantic for
> containment - they jumble that in with aggregations, which is
> incorrect from a UML modeling point-of-view).
>
> Problem #6
>
> DN Pointers in PolicyRule and PolicyGroup [2]. Because the semantics
> (problem #3) are incorrect between rule-specific and reusable
> conditions and actions, we were unable to make policyRuleConditionList
> (the set of DNs that bind a condition to a rule) a MUST (i.e. thou
> MUST implement this).
>
> This means that an implementor might not ensure instantiation of this
> attribute, and then of course the implementation would not be able to
> attach a condition to the instance.

Problems #5 & #6 appear to be yet more examples of the pitfalls 
encounters when mapping an abstract info model [1] to a concrete schema [2], 
and as such aren't directly applicable to the question of whether [1] is a 
suitable applicable abstract model for XACML's domain.


Postscript added by John after reading my above comments: 

The real problem is that there isn't a well-defined standard that CIM 
uses to map from an information model (which is defined as INDEPENDENT 
of any particular repository and access protocol) to a particular data
model (which is defined as tightly bound to a particular repository that
uses a specific access protocol). Note that in generality there are a
plurality of such mappings, as the way data are organized and stored in
an RDBMS is significantly different than in a directory (same goes for
the power of SQL vs. the power of LDAP).

-------------------------------------------------------------------------