Re: [I2nsf] ECA umbrella - with "Condition" being the I2NSF's Subject-Object : 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

[Robert Moskowitz <[e-mail]>]

On 01/27/2016 07:02 PM, John Strassner wrote:
> Hi Linda,
>
> logon and logoff were simply examples, and certainly were not 
> exclusive. Though personally, I am not sure why security functions 
> wouldn't care about logon and logoff events.

I see logon/logoff events reported in my logwatch emails all the time.  
I consider them security events.

>
> I dislike the notion of a threshold crossing as an event, because 
> threshold values are typically test in the condition part of the rule. 
> This would "double count" the threshold event.
>
> regards,
> John
>
> On Wed, Jan 27, 2016 at 1:53 PM, Linda Dunbar <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     John,
>
>     For the Interface to Flow based Network Security Functions, we
>     would assume that the NSF has a ON session with the Controller.
>     Therefore,  the relevant events for I2NSF should be more limited,
>     shouldn’t include “logon or off”, should it?
>
>     I can see “Alarms” or “Threshold crossing” can relevant events for
>     I2NSF. What do you think?
>
>     Linda
>
>     *From:*John Strassner [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Saturday, January 16, 2016 4:52 PM
>     *To:* Linda Dunbar; John Strassner
>     *Cc:* Xialiang (Frank); [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: ECA umbrella - with "Condition" being the I2NSF's
>     Subject-Object : [I2nsf] 答复: Service Level Policies - Post 4:
>     differentiating between context, conditions, and Constraints
>
>     Hi Linda,
>
>     sorry for the delay, I missed this email. For me, I don't think of
>     packet reception as an event. This is because semantically, you
>     would be using both the event and the condition clause to say that
>     something is happening in the packet. I realize I am possibly
>     being nit-picky here.
>
>     For me, events are occurrences that are significant to the
>     management system, such as logon and logoff events, and the
>     receipt of alarms.
>
>     regards,
>
>     John
>
>     On Tue, Jan 12, 2016 at 9:53 AM, Linda Dunbar
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>     John, ,
>
>     I always think that ECA (Event- Condition-Action) is a big
>     Umbrella, with
>
>     -Event == Packet reception
>
>     -Condition == “subject”  (which are the bits & bytes in the
>     incoming packets)  & “object” (which is not from the incoming
>     packets, i.e. timer, states, buffer value, threshold, constraints,
>     etc).
>
>     -Action == “simple actions” || “function calls” || etc.
>
>     What do you think?
>
>     Linda
>
>     *From:*Xialiang (Frank)
>     *Sent:* Tuesday, January 12, 2016 12:00 AM
>     *To:* John Strassner
>     *Cc:* [e-mail] <mailto:[e-mail]>; Linda Dunbar
>     *Subject:* 答复: [I2nsf] 答复: Service Level Policies - Post 4:
>     differentiating between context, conditions, and Constraints
>
>     Hi John,
>
>     Maybe both. Right now I am not sure~~
>
>     But I hope the latter case is enough to address the whole problems.
>
>     BTW, I want to note that your ECA model is not essentially
>     different from current “subject-object-action-function” model. Of
>     course, ECA is more mature and widely used.
>
>     B.R.
>
>     Frank
>
>     *发件人**:*I2nsf [mailto:[e-mail]] *代表***John
>     Strassner
>     *发送时间**:*2016年1月12日11:40
>     *收件人**:*Xialiang (Frank); John Strassner
>     *抄送**:*[e-mail] <mailto:[e-mail]>; Linda Dunbar
>     *主题**:*Re: [I2nsf] 答复: Service Level Policies - Post 4:
>     differentiating between context, conditions, and Constraints
>
>     Hi Frank,
>
>     by "extended ECA model which incorporate necessary security
>     characteristic", do you mean adding a new clause to the ECA model,
>     or can these extensions be handled by extending the individual
>     event, condition, and action clauses with metadata (applied to the
>     container and/or the clauses)?
>
>     regards,
>
>     John
>
>     On Mon, Jan 11, 2016 at 6:29 PM, Xialiang (Frank)
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi all,
>
>     John, thanks a lot for the clarification of “context, condition,
>     constraint”.
>
>     And I think your understanding about current I2NSF capability
>     interface IM design below is correct. So, I am not against to use
>     ECA model instead of current “subject-object-action-function” model.
>
>     My concern is even we agree ECA is a more complete and standard
>     model for I2NSF, we still need to specify an extended ECA model
>     which incorporate necessary security characteristic, which is our
>     next step work.
>
>     B.R.
>
>     Frank
>
>     *发件人**:*I2nsf [mailto:[e-mail]
>     <mailto:[e-mail]>] *代表***John Strassner
>     *发送时间**:*2016年1月12日4:19
>     *收件人**:*Linda Dunbar; John Strassner
>     *抄送**:*[e-mail] <mailto:[e-mail]>
>     *主题**:*Re: [I2nsf] Service Level Policies - Post 4:
>     differentiating between context, conditions, and Constraints
>
>     Hi Linda,
>
>     The answer depends if I2NSF wants to pursue authorization policies
>     and/or deontic or alethic logic.
>
>     If any of the above three are true, then "Subject" must change.
>
>     If we step back for a moment and think about the definition of an
>     ECA policy rule (event-condition-action), then I remain
>     unconvinced why this is not sufficient for us at the moment. More
>     specifically:
>
>        1) Subject-Object-Action-Function does not have a facility for
>     representing Events, which start policy processing
>
>        2) Subject, as currently defined, is just part of a condition
>
>        3) Object, as currently defined, is also just part of a
>     condition (more specifically, object constraints do NOT apply to
>     anything else)
>
>        4) Function(al profile) needs more specificity, but appears to
>     be able to be covered by metadata (see below).
>
>     So, if we view a policy rule as a **container**, then the
>     container aggregates both metadata and content. Metadata can be
>     prescriptive and/or descriptive; content is the type of policy (or
>     set of policies) contained in the container.
>
>     This is the subject of my last 2 remaining posts, but in a
>     nutshell, I do not see a need for using
>     Subject-Object-Action-Function, since this introduces non-standard
>     terminology, and the terms are unclear. If the objective is
>     **just** to categorize what type of processing can be done by an
>     NSF, **and if** it is desired to link I2NSF to policy, then I
>     don't see why we can't use a standard ECA policy, augmented with
>     metadata, to do this.
>
>     regards,
>
>     John
>
>     On Fri, Jan 8, 2016 at 9:51 AM, Linda Dunbar
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>     John,
>
>     Thank you very much for clarifying the differences among
>
>     The term “Object” in I2NSF was intended for describing all three
>     “Context, Conditions and Constraints”.
>
>     I agree it is not very straight forward definition.
>
>     Do you Suggest I2NSF should have something like:
>
>     Within the frame of “Subject - <xxx> - Action –Function”, <xxx> is
>     the combination of “Context, Conditions and Constraints”.
>
>     Should we call it “CCC”?  Or do you have a better term?
>
>     Linda
>
>     *From:*I2nsf [mailto:[e-mail]
>     <mailto:[e-mail]>] *On Behalf Of *John Strassner
>     *Sent:* Thursday, January 07, 2016 4:09 AM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* [I2nsf] Service Level Policies - Post 4:
>     differentiating between context, conditions, and Constraints
>
>     During IETF94, I expressed discomfort with the
>     "Subject-Object-Action-Function" paradigm. This note defines and
>     differentiates between the concepts of context, constraints, and
>     conditions.
>
>     1. Context
>
>     There are many definitions of context. One of the most popular [1] is:
>
>     ‘‘Context is any information that can be used to characterize the
>     situation
>           of an entity. An entity is a person, place, or object that
>     is considered
>           relevant to the interaction between a user and an
>     application, including
>           the user and application themselves’’.
>
>     As stated in [2], the above definition has a number of problems.
>     Instead, [2] proposes the following definition:
>
>        "The Context of an Entity is a collection of measured and/or
>     inferred
>
>     knowledge that describe the state and the environment in which an
>          Entity exists or has existed."
>
>     The above definition enables human and or machine inference to be
>     used to more fully characterize the context of an Entity.
>
>     2. Conditions
>
>     An event-condition-action (ECA) policy rule consists of three
>     Boolean clauses, and has the following conceptual behavior:
>
>        IF the event_clause evaluates to TRUE
>
>     IF the condition_clause evaluates to TRUE
>
>     THEN execute the actions in the action_clause
>
>     ENDIF
>
>     ENDIF
>
>     Each of the above clauses may consist of one or more statements.
>     For example, a condition clause could be:
>
>        if userLogin = Error AND numLoginTries > 3
>
>     3. Constraints
>
>     A constraint is a limitation or restriction. Constraints have been
>     used in programming and in modeling for a long time. Constraint
>     programming refers to the embedding of constraints in a language;
>     for example, most Prolog languages include good support for
>     constraint programming. OCL (the Object Constraint Language) is
>     used to specify constraints in UML.
>
>     4. Putting Context, Conditions, and Constraints Together
>
>     Given a condition, a constraint can be used to further restrict
>     how to satisfy the condition. Then, if a context is specified, the
>     condition and its constraint are bound to that context. In an ECA
>     policy rule, the effect of this is typically to more fully specify
>     the condition clause.
>
>     Note, however, that constraints do not have to be used solely with
>     Conditions. For example, a constraint can be used to specify when
>     it is safe to transition to a new state. As another, more
>     powerful, example, the concept of a software contract [3] uses
>     constraints to extend the definition of Abstract Data Types to
>     formally define the behavior of software components. Simplifying
>     the theory, this says the following:
>
>       In order for a method to execute,
>           a set of pre-conditions must be satisfied before the method
>     can execute
>           a set of post-conditions must be satisfied when the method
>     is finished
>           a set of invariants must not change their value during the
>     execution
>
>     · The set of pre- and post-conditions, along with invariants, are
>     all constraints.
>
>     5. Proposal
>
>     Context, conditions, and constraints are separate concepts, but
>     they fit together naturally.
>
>     With respect to policies, if a policy is viewed as a (software)
>     container, then context is applied to the container (and hence, to
>     the components of the container).
>
>     Constraints can be applied to terms in each of the event,
>     condition, and action clauses of an ECA policy rule to restrict
>     their behavior, data type, domain and range, and so forth. The
>     most common examples are applying constraints to conditions or to
>     govern the behavior of actions.
>
>     · [1] Dey, A., "Providing Architectural Support for Building
>     Context-Aware
>          Applications, Ph.D. Thesis, 2000
>
>     [2] Strassner, J., et al., "The Use of Context-Aware Policies and
>          Ontologies to Facilitate Business-Aware Network Management",
>          Journal of Network and Systems Management (17), pg 255-284, 2009
>
>     · [3] Meyer, B., "Object-Oriented Software Construction, 2nd edition,
>          Prentice-Hall, ISBN: 0-13-629155-4
>
>
>     -- 
>
>     regards,
>
>     John
>
>
>
>
>     -- 
>
>     regards,
>
>     John
>
>
>
>
>     -- 
>
>     regards,
>
>     John
>
>
>
>
>     -- 
>
>     regards,
>
>     John
>
>
>
>
> -- 
> regards,
> John
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf