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/28/2016 03:45 PM, Linda Dunbar wrote:
>
> John,
>
> Are you saying a  Controller  “logging on/off”  to the NSFs?  In order 
> for NSFs to get dynamic rules (policies) from a Controller, the 
> controller has to be logged on to the NSFs.
>

Any system that is important to network security should have its 
logon/off monitored.  I might expect that any Controller interaction 
will be over long running sessions, so there logging of rekeying of said 
sessions.

> Or do you mean a specific Virtual Network controller “logging on/off” 
> to the NSFs?
>
> Would you think that “Starting Time” can be  classified as an event 
> for rules to NSFs?
>
> Thanks, Linda
>
> *From:*John Strassner [mailto:[e-mail]]
> *Sent:* Wednesday, January 27, 2016 6:03 PM
> *To:* Linda Dunbar
> *Cc:* Xialiang (Frank); [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,
>
> 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 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