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 <rgm-ietf@htt-consult.com> Fri, 29 January 2016 19:15 UTC

Return-Path: <rgm-ietf@htt-consult.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C717E1B3202 for <i2nsf@ietfa.amsl.com>; Fri, 29 Jan 2016 11:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level:
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAZImWf8jc5A for <i2nsf@ietfa.amsl.com>; Fri, 29 Jan 2016 11:15:50 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0520F1B3201 for <i2nsf@ietf.org>; Fri, 29 Jan 2016 11:15:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 9AB79621AF; Fri, 29 Jan 2016 14:15:48 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lyEr4qHtYD2j; Fri, 29 Jan 2016 14:15:18 -0500 (EST)
Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 35C6D62140; Fri, 29 Jan 2016 14:15:17 -0500 (EST)
To: Linda Dunbar <linda.dunbar@huawei.com>, John Strassner <strazpdj@gmail.com>
References: <CAJwYUrGdNiYf5fbVQ+9r0E7pMXE8-0uErrX-qxL9AFirz_8kEQ@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657DB9CCD@dfweml701-chm> <CAJwYUrGo_zQtcO6g_fs=p-kegStKpXz5sY0X0Ug+9=aNtYEQ8w@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F12AED6E7A@SZXEMA502-MBS.china.huawei.com> <CAJwYUrFV=yv5zFk1Qjyv000tLuPbW3snozS7nyjcKWh7gnwDzA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F12AED7EC5@SZXEMA502-MBS.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F657DD4226@dfweml701-chm> <CAJwYUrFc7Wus5aBH_6Hm8SeTSH3mG9Z=2bJB7SNUfftpFyF17Q@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657DE2751@dfweml701-chm> <CAJwYUrE=ymvGFG4BDnBEvq75iZZWdZu8tcsMN9KrJsvZJTn9Ag@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657DE411A@dfweml701-chm>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
Message-ID: <56ABBA44.2090401@htt-consult.com>
Date: Fri, 29 Jan 2016 14:15:16 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DE411A@dfweml701-chm>
Content-Type: multipart/alternative; boundary="------------080402010609030509020206"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/WiZ296doohByghM89o6Rzje0iGE>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, "Xialiang (Frank)" <frank.xialiang@huawei.com>
Subject: Re: [I2nsf] ECA umbrella - with "Condition" being the I2NSF's Subject-Object : 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 19:15:56 -0000


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:strazpdj@gmail.com]
> *Sent:* Wednesday, January 27, 2016 6:03 PM
> *To:* Linda Dunbar
> *Cc:* Xialiang (Frank); i2nsf@ietf.org
> *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 <linda.dunbar@huawei.com 
> <mailto:linda.dunbar@huawei.com>> 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:strazpdj@gmail.com 
> <mailto:strazpdj@gmail.com>]
> *Sent:* Saturday, January 16, 2016 4:52 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* Xialiang (Frank); i2nsf@ietf.org <mailto:i2nsf@ietf.org>
> *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 <linda.dunbar@huawei.com 
> <mailto:linda.dunbar@huawei.com>> 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:* i2nsf@ietf.org <mailto:i2nsf@ietf.org>; 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:i2nsf-bounces@ietf.org] *代表***John Strassner
> *发送时间**:*2016年1月12日11:40
> *收件人**:*Xialiang (Frank); John Strassner
> *抄送**:*i2nsf@ietf.org <mailto:i2nsf@ietf.org>; 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) 
> <frank.xialiang@huawei.com <mailto:frank.xialiang@huawei.com>> 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:i2nsf-bounces@ietf.org 
> <mailto:i2nsf-bounces@ietf.org>] *代表***John Strassner
> *发送时间**:*2016年1月12日4:19
> *收件人**:*Linda Dunbar; John Strassner
> *抄送**:*i2nsf@ietf.org <mailto:i2nsf@ietf.org>
> *主题**:*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 <linda.dunbar@huawei.com 
> <mailto:linda.dunbar@huawei.com>> 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:i2nsf-bounces@ietf.org 
> <mailto:i2nsf-bounces@ietf.org>] *On Behalf Of *John Strassner
> *Sent:* Thursday, January 07, 2016 4:09 AM
> *To:* i2nsf@ietf.org <mailto:i2nsf@ietf.org>
> *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
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf