Re: [I2nsf] 答复: Service Layer Policies - Post 1: Background Information on PCIM

[John Strassner <[e-mail]>]

Hi Frank,

Since current design principle for the policy model of capability interface
is to abstract from most common existing NSF security policy
implementations and consolidate them into a general and extensive model, I
think imperative logic is more suitable for this goal.


<jcs>
I agree. For example, declarative policies will require a much more complex
translation to a form that security devices can ingest than imperative
policies do.
</jcs>

I am very interested in whether “event” can be used in I2NSF capability
interface. Do you have some suggestions?


<jcs>
Why not? :-)
There are a lot of advantages to using Events. For example, events can be
used to debug the system by providing a real-time trace of which policies
executed. Logs like this are also crucial for accounting and auditing.
I think that we should at least make Events (and hence,
event-condition-action policies) optional in our policy structure.
</jcs>

Are the “subject” and “target” two different classes in PCIMe? Do you
suggest to include them in I2NSF policy model of capability interface for
the goal of authorizing the policy?


<jcs>
Subject and Target are NOT part of PCIM or PCIMe (see Post 2a or 2b).
IFF I2NSF needs to represent authorization policies (and I don't see why we
wouldn't), then SUBJECT is MANDATORY; it is also mandatory for performing
deontic and/or alethic logic.
Target (especially if modeled as a set of roles) is a much more scalable
and robust way of defining what entities policy will be applied to.
</jcs>



regards,
John


On Sun, Dec 13, 2015 at 6:45 PM, Xialiang (Frank) <[e-mail]
> wrote:

> Hi John,
>
> Since current design principle for the policy model of capability
> interface is to abstract from most common existing NSF security policy
> implementations and consolidate them into a general and extensive model, I
> think imperative logic is more suitable for this goal.
>
>
>
> I am very interested in whether “event” can be used in I2NSF capability
> interface. Do you have some suggestions?
>
>
>
> Are the “subject” and “target” two different classes in PCIMe? Do you
> suggest to include them in I2NSF policy model of capability interface for
> the goal of authorizing the policy?
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人:* I2nsf [mailto:[e-mail]] *代表 *John Strassner
> *发送时间:* 2015年12月12日 7:32
> *收件人:* Linda Dunbar
> *抄送:* [e-mail]
> *主题:* Re: [I2nsf] Service Layer Policies - Post 1: Background Information
> on PCIM
>
>
>
> Hi Linda,
>
>
>
> thank you for your kind words. My replies are inline:
>
>
>
> Thank you very much for the in-depth analysis of PCIM and its suitability
> as something that I2NSF should be based on. What you write is very
> valuable. I think the analysis should be added to the I2NSF gap analysis,
> (or be a standalone Policy Analysis ID).
>
>
>
> <jcs>
>
> If desired, I could summarize the key points for the gap analysis. I would
> be willing to do a Policy Analysis I-D, but I think that this probably
> belongs in SUPA. However, feedback from I2NSF is invaluable for such a
> document.
>
> </jcs>
>
>
>
>
>
> Note: It is possible to define limited constraints in PCIM as conditions.
> For example, the VendorPolicyCondition class has two attributes, Constraint
> and ConstraintEncoding, that do this. This will be discussed more in Post 4.
>
>
>
> Note: Context is NOT defined in the PCIM.
>
>
>
> [Linda]  Do you agree that “Condition of the PCIM” == “I2NSF subject” &
> “the Contextual states (or the I2NSF object)”?
>
>
>
> <jcs>
>
> PCIM/PCIMe conditions are clearly similar to what is now called "I2NSF
> Subject". However, the contextual state is trickier. Part of the problem is
> how we want to define Context. I'll save the bulk for Post 4 (as outlined
> in my Post 0 note). However, looking at page 6 of
> draft-merged-i2nsf-framework-04:
>
> "Object-Match values, based on context (e.g., state, direction of the
> traffic, time, geo-location, etc.)", in which case:
>
>    - state:  likely NOT part of the condition; rather, it applies to the
> entire PolicyRule as a whole
>
>    - traffic direction:  part of the condition
>
>    - time:  part of the condition
>
>    - geo-location:  part of the condition
>
> </jcs>
>
>
>
> ...
>
>
>
> Critical Problems:
>
>
>
> There is no unique ID that can be used to distinguish different
> instances of the same PolicyRule, PolicyGroup, PolicyCondition,
> or PolicyAction.
>
> [Linda] Can we simply create an ID (string or numeric) for instances of
> the same PolicyRule? Or it is more complicated?
>
>
>
> <jcs>
>
> SUPA and DEN-ng use two attributes to do this:
>
>
>
>    - a string that contains the content of the identifier
>
>    - a string that is an enum, which defines how to interpret the content
>
>
>
> This allows different IDs to be mixed (e.g., URIs, GUIDs, keys, FQDNs,
> etc.)
>
>
>
> That being said, it is certainly easier to pick one and go with it, but
> since I2NSF SHOULD interoperate with other models easily, I would recommend
> a scheme similar to the one I used (or the above, of course).
>
> </jcs>
>
>
>
>
>
> Relationships are implemented by defining an abstract class
> with keys, and then overriding the keys in the subclasses of the
> relationship. This is broken. Would you override keys in an RDBMS?
>
> [Linda] Is the “Key” to differentiating different “PolicyRule”?   Can you
> give an example of “subclasses of the relationship”?
>
> What events can cause “overriding the keys in the subclasses of the
> relationship”?
>
>
>
> <jcs>
> No, the key (as in primary and foreign keys, just to be clear) is used as
> part of how CIM data models are built. I believe that this strategy is
> fundamentally incorrect (as in, would you override keys in an RDBMS). It
> also violates a host of object-oriented principles (see Post 2b).
>
>
>
> Remember, PCIM and PCIMe do NOT define events. This is a design
> (compile-time) definition of how you build CIM classes.
> </jcs>
>
>
>
>
>
> ·  Most of the classes that are used to implement the relationships
> do NOT have attributes, so it is impossible to restrict which
> classes are related to which other classes (e.g., by context).
> Put another way, the same relationship must always be used
> between two types, even if the semantics varies. (The two
> exceptions are PolicyConditionInPolicyRule and
> PolicyActionInPolicyRule).
>
> [Linda] Does “classes” == “PolicyRule”?
>
>
>
> <jcs>
>
> No, "classes" == {association | aggregation | composition}.
>
>
>
> This is another artifact of CIM. They implement ALL relationships as
> classes. In UML, there is a difference between these three relationships
> and realizing them as a class; the CIM approach eliminates this distinction.
>
> </jcs>
>
>
>
>
>
>    - The "ignore this unless you need this" philosophy does not
>    work. How do you know if other implementations that you are
>    supposed to interoperate with are using them?
>
> [Linda] Is “Ignore this unless you need this” an new type of “PolicyRule”?
>
>
>
> <jcs>
>
> No, sorry, this is one of the key points underlying the design philosophy
> of CIM, and carried into PCIM and PCIMe. Basically, it means that it is OK
> to define model elements on another model element if they are optional.
> Examples:
>
>
>
>    - defining an optional attribute, method, or relationship on a class
>    - defining an optional constraint
>
>
>
> This violates all of the 4 design principles in Post 2b (references
> section)
>
> </jcs>
>
>
>
>
>
> There is no concept of the subject or the target of a policy
>
> [Linda] Does your “subject” have the same meaning as the “I2NSF subject”
> which means bits&bytes extracted from packets?
>
>
>
> <jcs>
>
> No. A PolicySubject is the author of a policy. One could also
> differentiate between author, owner, and executor, but that is more
> complex. It is vital for deontic logic (i.e., the logic of obligations and
> permissions, as in MUST, MUST NOT, SHOULD, MAY, etc.). This is one of my
> concerns with the Sbbject-Object-Action-Function model - one cannot build
> authorization policies that can be logically proven to be correct or not
> without a PolicySubject.
>
> </jcs>
>
>
>
>
>
> Adding a new type of policy (e.g., declarative or functional)
> will cause a major rewrite of the entire model
>
>
>
> [Linda] Can we say that  I2NSF policies have one type
> “Subject-ContextualStates- action- function? So in I2NSF environment, there
> is only the notion of adding a new “PolicyRule”, but no adding a new policy
> type. Is this correct statement?
>
>
>
> <jcs>
>
> No. The meaning of what I wrote above is much broader. If you think of ECA
> policies as imperative in nature, then the analogy is that PCIM/PCIMe are
> hard-wired to imperative policies. The schema cannot be used for other
> forms (declarative, functional, etc.) of policies.
>
>
>
> Put another way, ECA (or CA, which is all that the PCIM/PCIMe can do) is
> imperative - it specifies that, given this particular state, the ONLY state
> that you are allowed to transition to is this other state. Rationality MUST
> be compiled into the policy. In contrast, for declarative logic, given a
> particular state, there are a SET of states that either satisfy the goal,
> or take you closer to the goal. Hence, rationality is GENERATED by a logic
> planner/optimizer.
>
> </jcs>
>
>
>
>
>
> There is no approach to detecting and solving policy conflicts;
> this is due to the simplistic notion of just using a PDP and a
> PEP for applying policies.
>
>
>
> [Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>
> 1.       Virtual Network X can’t access “YouTube”,
>
> 2.      10.1.1.1 can access “YouTube” (where 10.1.1.1 is a host within
> the Virtual Network X).
>
> Do you call the 2 rules above conflict?
>
> <jcs>
>
> Bob already answered this in
> http://www.ietf.org/mail-archive/web/i2nsf/current/msg00729.html
>
> +1 to his answer (or see my reply)
>
> </jcs>
>
>
>
>
>
> Given the large amount of problems, I recommend that we not consider PCIM
> further.
>
> [Linda] should I2NSF reference PCIM?
>
>
>
> <jcs>
>
> I don't see any harm in **referencing** PCIM or PCIMe; I just don't want
> to **use** either to construct our policies.
>
> </jcs>
>
>
>
>
>
> best regards,
>
> John
>
>
>
>
>
>
>
> On Tue, Dec 8, 2015 at 1:10 PM, Linda Dunbar <[e-mail]>
> wrote:
>
> John,
>
>
>
> Thank you very much for the in-depth analysis of PCIM and its suitability
> as something that I2NSF should be based on. What you write is very
> valuable. I think the analysis should be added to the I2NSF gap analysis,
> (or be a standalone Policy Analysis ID).
>
>
>
> I have some questions inserted below:
>
>
>
> *From:* I2nsf [mailto:[e-mail]] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, December 06, 2015 7:01 PM
> *To:* [e-mail]
> *Subject:* [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> <Snipped>
>
>
>
> 2.  Brief description of PCIM
>
>
>
> The PCIM Class Hierarchy is very simple, as this is a CA
> (condition-action) model. Events are NOT represented. PCIM defines a
> PolicyRule, a PolicyGroup (group of PolicyRules), PolicyCondition, and
> PolicyAction. These are all siblings; their common superclass is called
> Policy, as shown below:
>
>
>
> ManagedElement (abstract)
>   |
>   +---Policy (abstract)
>   |     |
>   |     +---PolicyGroup
>   |     |
>   |     +---PolicyRule
>   |     |
>   |     +---PolicyCondition (abstract)
>   |     |      |
>   |     |      +---PolicyTimePeriodCondition
>   |     |      |
>   |     |      +---VendorPolicyCondition
>   |     |
>   |     +---PolicyAction (abstract)
>   |            |
>   |            +---VendorPolicyAction
>
>
>
> Note: PCIM does have a simple notion of Roles, but implements them as
> attributes, instead of objects. This is not scalable, and does not fully
> realize the power of using roles. This will be discussed more in Post 3.
>
>
>
> Note: It is possible to define limited constraints in PCIM as conditions.
> For example, the VendorPolicyCondition class has two attributes, Constraint
> and ConstraintEncoding, that do this. This will be discussed more in Post 4.
>
>
>
> Note: Context is NOT defined in the PCIM.
>
>
>
> [Linda]  Do you agree that “Condition of the PCIM” == “I2NSF subject” &
> “the Contextual states (or the I2NSF object)”?
>
>
>
>
>
> 3.  Summary: main drawbacks of using PCIM
>
>
>
> Note that the current CIM Policy Model (2.44.1) is significantly different
> than either PCIM or PCIMe. PCIM is based on CIM 2.4; PCIMe is based on CIM
> 2.5. PCIMe is NOT backwards compatible with PCIM in all areas.
>
>
>
> Critical Problems:
>
>    - There is no unique ID that can be used to distinguish different
>    instances of the same PolicyRule, PolicyGroup, PolicyCondition,
>    or PolicyAction.
>
> [Linda] Can we simply create an ID (string or numeric) for instances of
> the same PolicyRule? Or it is more complicated?
>
>    - Relationships are implemented by defining an abstract class
>    with keys, and then overriding the keys in the subclasses of the
>    relationship. This is broken. Would you override keys in an RDBMS?
>
> [Linda] Is the “Key” to differentiating different “PolicyRule”?   Can you
> give an example of “subclasses of the relationship”?
>
> What events can cause “overriding the keys in the subclasses of the
> relationship”?
>
>    - Most of the classes that are used to implement the relationships
>    do NOT have attributes, so it is impossible to restrict which
>    classes are related to which other classes (e.g., by context).
>    Put another way, the same relationship must always be used
>    between two types, even if the semantics varies. (The two
>    exceptions are PolicyConditionInPolicyRule and
>    PolicyActionInPolicyRule).
>
> [Linda] Does “classes” == “PolicyRule”?
>
>    - The "ignore this unless you need this" philosophy does not
>    work. How do you know if other implementations that you are
>    supposed to interoperate with are using them?
>
> [Linda] Is “Ignore this unless you need this” an new type of “PolicyRule”?
>
>    - There is no concept of error or exception handling
>    - There is no concept of the subject or the target of a policy
>
> [Linda] Does your “subject” have the same meaning as the “I2NSF subject”
> which means bits&bytes extracted from packets?
>
>    - Adding a new type of policy (e.g., declarative or functional)
>    will cause a major rewrite of the entire model
>
>
>
> [Linda] Can we say that  I2NSF policies have one type
> “Subject-ContextualStates- action- function? So in I2NSF environment, there
> is only the notion of adding a new “PolicyRule”, but no adding a new policy
> type. Is this correct statement?
>
>    - There is no approach to detecting and solving policy conflicts;
>    this is due to the simplistic notion of just using a PDP and a
>    PEP for applying policies.
>
>
>
> [Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>
> 1.       Virtual Network X can’t access “YouTube”,
>
> 2.      10.1.1.1 can access “YouTube” (where 10.1.1.1 is a host within
> the Virtual Network X).
>
> Do you call the 2 rules above conflict?
>
>
>
>
>
> 4. Recommendations
>
>
>
> Given the large amount of problems, I recommend that we not consider PCIM
> further.
>
> [Linda] should I2NSF reference PCIM?
>
>
>
> Thank you very much. Linda
>
>
>
> 5. Origin of PCIM/PCIMe
>
>
>
> This is a **theory** section; please skip unless you want to understand
> the model in more detail.
>
>
>
> The PCIM is based on the DMTF CIM, which is actually a **data model**
> (despite its name) because it uses relational technologies (e.g., keys and
> weak references) to create its model. PCIM is based on an early version of
> the CIM (2.4); the current version of the CIM is 2.44.1 as of this writing.
> Since this is tied to the CIM, this means that:
>
>
>
>    1) Policy is subclassed from a more generic class (ManagedElement)
>
>    2) ALL relationships (associations, aggregations, and compositions)
>
>        are realized as **classes**
>
>    3) As a result of 2), relationships are subclassed
>
>    4) Both attributes and associations are **inherited**
>
>    5) The same design approach (as much as possible) was used in
>
>         PCIM/PCIMe as was in CIM. Specifically, it was thought better
>
>         to define a generic, but optional, relationship instead of not
>
>         defining the relationship.
>
>    6) The CIM does NOT have a single rooted hierarchy; this makes
>
>         code generation more complex
>
>    7) The CIM uses a proprietary language and is not strictly UML
>
>         compliant, even though it looks like UML (unfortunately, this
>
>         language is also called MOF)
>
>
>
> Depending on the complexity of the implementation, the above have been
> shown to produce problems in large environments. For example, the spirit of
> "let's define an attribute or association in case it is useful, and make it
> optional so you don't have to worry about it" not only violates some
> well-known software architectural guidelines (e.g., Single Responsibility
> Principle and the Liskov Substitution Principle), but it makes things
> difficult to interoperate with (since you never really know if an attribute
> or relationship should be instantiated or not).
>
>
>
>
>
> regards,
>
> John
>
>
>
>
> --
>
> regards,
>
> John
>



-- 
regards,
John