Subject: Re: [I2nsf] updates on the capability models

From: John Strassner <[email-masked]>
Date: Wed, 3 Jan 2018 15:11:05 +0000

Sorry for the delay in replying.

First, Aldo is correct – the decorator pattern is used to both increase
extensibility and to avoid object explosion (by having to enumerate each
different function as a separate object).

Second, I wouldn’t call the NSF-facing model a “superset” of the capability
model. Every concept that is in the NSF-facing model SHOULD be derived from
the Capability model (if that isn’t possible, then we need to extend the
Capability model). This is very important – if this is not true, then other
data models that are NOT YANG models will not be interoperable with our
YANG data model. Note that this doesn’t mean that a data model just selects
objects from the info model! Rather, it selects **concepts**, and then
refines those concepts. For example, if the info model defines the concept
of an operator, then a data model is free to define new types of operators.
In this example, if the operator was a class, the new operator types would
be subclasses of the operator class.

Now suppose that the info model did not define an operator class. Clearly,
imperative policy rules need operators. The data model would have to define
an operator class – but where would it define it from? Let’s say it chooses
to define it from I2NSFPolicy (an obviously bad choice). If another data
model (say, one using relational calculus) defines an operator from a
different class (say, metadata, an equally bad choice), now you have different
semantics attached to the notion of an operator, since they are subclassed
from different places. Say goodbye to interoperability.

The above simple example is one reason why the different data models need to
be properly derived from the info model.

Your third question (about the long list of attributes) is subject to opinion.
I personally dislike classes with long list of attributes. Such a design begs
the question, “is this attribute really **only** applicable to this one class?”
For example, take an address. It is common to have separate classes for IPv4
and IPv6, since the structure of the address is fundamentally different. Of
course, MAC addresses are different from both, so as a simple example, instead
of listing a set of attributes that partially describe any one of these 3 types
of addresses, why not have a NetworkAddress class, with 3 subclasses? This
enables us to properly describe the semantics of the components of an address,
as well as relate other entities (e.g., a DHCP server) to those types of
addresses that need it.

While on vacation and travel, I received some private notes about parts of
the model. The rest of this note will answer these and comment on the PDF
that was provided.

There seems to be some confusion about the structure of the information
model. This note will first clarify the structure of the information model,
and then elaborate on the questions raised below.

Refer to figure 2 in draft-xibassnez. This defines the inheritance
relationships between I2NSFPolicyRule and I2NSFPolicyComponent, and
is shown below in more complete detail (sorry for the confusion).

*******************************************************************
*                     ETERNAL INFO MODEL                          *
*                                                                 *
*  +------------+0..1                    1..n+------------------+ *
*  |            |/ \                        \|                  | *
*  | PolicyRule + A -------------------------+ PolicyComponent  | *
*  |            |\ /  HasPolicyComponent    /|                  | *
*  +------+-----+                            +--------+---------+ *
*        / \                                         / \          *
*         I                                           I           *
**********I*******************************************I************
           I                                           I
           I                                           I
 +--------+--------+                        +----------+-----------+
 | I2NSFPolicyRule |                        | I2NSFPolicyComponent |
 +--------+--------+                        +----------+-----------+
           I                                           I
           I                                           I
+----------+------------+  +---------------+-----------+-----+
|I2NSFSecurityPolicyRule|  I               I                 I
+-----------------------+  I               I                 I
                           I               I                 I
                     +-----+-----+   +-----+-----+     +-----+-----+
                     |I2NSFPolicy|   |I2NSFPolicy|     |I2NSFPolicy|
                     |   Event   |   | Condition |     |  Action   |
                     +-----------+   +-----------+     +-----------+

A new class, called I2NSFPolicy, is defined to separate the notion of
SecurityPolicyRules from other types of PolicyRules. This enables us to
define (for example) management policy rules as a sibling to
I2NSFSecurityPolicyRule in the future.

Similarly, a new class, called I2NSFPolicyComponent, is used to
separate events, conditions, and actions from other types of policy
components. This is important, since in imperative policies, events,
conditions, and actions act together.

The multiplicity of the HasPolicyComponent aggregation is 0..1 – 1..n.
This means that a PolicyRule MUST have at least one PolicyComponent,
and a PolicyComponent may be aggregated by 0 or 1 PolicyRules.

Note that there is also an aggregation between PolicyRule and Metadata
in the external info model, and that I2NSFPoliyMetadata inherits from
the Metadata class in the external info model.

Note especially that I2NSFPolicyEvent, I2NSFPolicyCondition, and
I2NSFPolicyAction are NOT subclassed from I2NSFPolicyMetadata. This
is because these objects are mandatory concepts that make up an I2NSF
Policy Rule. In contrast, I2NSF metadata is ALWAYS optional, and is
used to describe and/or prescribe an I2NSF object.

Given the above, let’s define some important concepts in the Capability
Information model.

Figure 3 in draft-xibassnez
The problem with Figure 3 is that it is fundamentally fragile. It uses
inheritance to define new types of SecurityPolicyRules. This approach
has two problems:

1)  It makes each subclass separate, and

2)  It is not extensible

The first problem is that each function is in effect a new subclass. If
you want to have authentication and authorization, you need two separate
policy rules.

The second problem is that each new function requires a new subclass.
It is impossible to think of all types of policy rules beforehand, and
even if this was feasible, this would mean that most applications would
not be using the majority of subclasses.

The decorator pattern solves both of these problems. The decorator pattern
enables a base object to be “wrapped” by zero or more decorator objects.
So an I2NSFSecurityPolicyRule could be the base object, and the 6
subclasses shown in Figure 3 could each be decorator classes. The point
is that the base object is not affected by new decorator subclasses; it
can choose to aggregate them or not. More importantly, the client of the
model is not affected, since all it sees is the base object’s class.

The class design is simple:  I2NSFPolicyRule is a subclass of the external
information model. I2NSFSecurityPolicyRule and I2NSFDecoratorRule are both
subclasses of I2NSFPolicyRule. There is an aggregation between
I2NSFSecurityPolicyRule and I2NSFPolicyRule. The 6 subclasses of
SecurityECAPolicyRule in Figure 3 are moved to subclass from
I2NSFDecoratorRule.

Figure 4 of draft-xibassnez
The top of this figure is shown in the first Figure on this page. That is,
the Event, Condition, and Action classes in Figure 4 become I2NSFEvent,
I2NSFCondition, and I2NSFAction, and all inherit from the I2NSFPolicyComponent
class. The reason for defining I2NSFPolicyComponent is to provide a common
control point for the different components of an I2NSF Policy Rule. For
example, we can now define a decorator pattern by adding a sibling class to
I2NSFEvent, I2NSFCondition, and I2NSFAction. This fourth class, called
I2NSFComponentDecorator, enables the **same** decorator pattern to be used
for events, conditions, and actions (this is the mark of a good design
pattern!). We do this by defining an aggregation between the
I2NSFComponentDecorator and I2NSFPolicyComponent classes. This now lets us
the 4 event subclasses from Figure 4 to inherit from I2NSFComponentDecorator.

Figures 5 and 6 of draft-xibassnez
Similarly, the 6 condition subclasses in Figure 5, and the 3 Action subclasses
In Figure 6, can also inherit from I2NSFComponentDecorator.

Figures 7-9 of draft-xibassnez
A Capability is a type of Metadata. We will insert a new class, called
I2NSFMetadata, as the superclass of the SecurityCapability class in Figure 7.
The superclass of I2NSFMetadata will be an appropriate class from the external
Info model.

We can again use the decorator pattern to enable different security capabilities
to decorate our base I2NSFMetadata class. This enables us to reuse the
aggregation between the external info model’s policy rule class and the
external info model’s metadata class. More importantly, we can now treat
security capabilities in a consistent manner with other types of metadata. All
that is needed is to once again define a decorator class (let’s call it
I2NSFMetadataDecorator), and define an aggregation between it and I2NSFMetadata.
Both the ContentSecurityCapability and AttackMitigationCapability class
hierarchies are moved under the I2NSFMetadataDecorator class (i.e., the
SecurityCapability class is the base class that is decorated).

New Concepts from the PDF File

Packets and Protocols
I don’t like Packets being defined as a type of metadata. The reasoning is
Similar as that for not subclassing events, conditions, and actions from
metadata. This also applies to Protocols.

StateInfo
This is harder. One could argue that state information describes (and
prescribes) the behavior of an object. One could also argue that state is
very important (note that state is handled separately in YANG), and as such,
should be its own distinct object. I typically model state as a separate
object, because it simplifies the understanding of behavioral specifications
(e.g., a state could be a set of attributes that need to be manipulated
Together). We should talk more about this before making a decision.

ConditionTarget
In the SUPA and MEF work, we defined a separate class called PolicyTarget.
The semantics of this date back to DEN-ng (defined in 2000), and build on
Sloman’s work in the late 90s, and are well established. It simplifies
understanding what a Policy Rule is working on and affecting – this is
especially true for imperative policies. I would recommend keeping
this approach and removing ConditionTarget.

If we do this, then PolicyTarget should inherit from the I2NSFPolicyRule
Class.

A possibly mitigating factor is the presence of the 2 associations (called
decidesBased and appliesOn in the PDF). I’m not sure what the purpose of
these associations are, so this may change the reasoning I gave.

Operation and OperationSet
The SUPA work defined a class called PolicyTerm (which is a type of
policy component decorator). PolicyTerm then defined three subclasses,
called PolicyVariable, PolicyOperator, and PolicyValue. The advantage
of this approach is that the information model can itself be used to
define a canonical type of expression in the form of a tuple:
  {variable, operator, value}

The disadvantage is more objects. However, in SUPA, as well as in the
MEF and DEN-ng efforts, the goal was model-driven engineering (i.e., the
model was both the design and the implementation). As such, reuse was
very important.

Since Events MUST have a type of operator (in order to form a Boolean
Clause), and since Actions MAY need operators, it seems appropriate to
generalize the notion of an operation, but make it accessible for events,
conditions, and actions. Hence, more discussion is needed here.

ResolutionStrategy
I agree that this is a class. However, I would subclass it from
I2NSFMetadata, not from SecurityCapability. This is because the
ResolutionStrategy is optional, and because it is used to prescribe
The behavior of the Policy Rule.

ClauseEvaluation
Sorry, I don’t understand what this is.

SecurityTemplate
This is a good idea!

SecurityCapability, DescribedBySecurityCapabilityDetail, NSF
I would change this design.

An NSF MAY be described by 0 or more SecurityCapabilities. Hence,
there should be an aggregation from NSF to SecurityCapability. Since
there can be many types of NSF that have many different types of
SecurityCapabilities, DescribedBySecurityCapabilityDetail should be
an association class. This yields the following design:

    +-----+0..n                      0..n+--------------------+
    |     |/ \  HasSecurityCapability    |                    |
| NSF | A ----------+----------------+ SecurityCapability |
|     |\ /          ^                |                    |
    +-----+             |                +--------------------+
                        |
          +-------------+---------------+
          | HasSecurityCapabilityDetail |
          + ----------------------------+

This enables the HasSecurityCapabilityDetail association class to either
be the target of a Policy Rule (to define which SecurityCapabilities of
this NSF are visible and can be used – in other words, the Policy pattern)
and/or be associated with a SecurityTemplate.

Best regards,
John

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, January 02, 2018 10:11 AM
To: John Strassner <[email-masked]>
Subject: Fwd: [I2nsf] updates on the capability models

---------- Forwarded message ----------
From: Cataldo Basile <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 4, 2017 at 1:50 AM
Subject: Re: [I2nsf] updates on the capability models
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Dear Linda,

I may be wrong, but I remember that we discussed a change in the capability model to avoid sub-classing as a way to obtain different types of conditions, action, events, etc.

The new model, now under John's review, implements the decorator pattern, thus avoid sub-classing as conditions, action, events become instances (that can be easily generated, and also used dynamically at run-time and many other advantages).

Then, the NSF facing data model will probably be a superset of the capability model, obtained by extending it with concepts that are specific of NSF facing interface.

After having restructured the capability model we can discuss how this impacts the NSF facing data model.

Regards,
Aldo

On 30/11/2017 23:30, Linda Dunbar wrote:
Aldo,
Thank you very much for the update. By the way, the version on data tracker is still 00, so your update should be 01.
During our side meeting in Singapore among IM/DM authors, you stated that you don't like explicit listing of the needed attributes for capability, e.g. the line by line list of all the IP addresses format and you volunteered to restructure the NSF facing data model so that it can be easily extended. Once you prepare the preliminary NSF facing data model structure, the NSF facing data model authors can regroup the attributes accordingly.
How does the tree structure in the *pdf file you sent last Friday eliminate explicit listing of all the needed attributes for "Condition" on IP addresses?
Thank you very much.
Linda
-----Original Message-----
From: Aldo Basile [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 30, 2017 4:12 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: updates on the capability models
Dear Linda, all,
short update on the capability information model (IM) and data model
(DM) task defined during the Wednesday meeting.
I have prepared a DM that derives from the capability IM model presented
by John that uses the policy and decorator patterns. This model really
improves on the one I circulated last Friday. Despite the patterns, the
model is not complicated.
In the meantime, John is validating it, both formally and semantically.
When it will pass John's validation I'll write the corresponding YANG
Data model.
I also prepared an informal instance of the model that I circulated in
the draft-xibassnez-i2nsf-capability-02 group. This will also be checked
after John's validation, aligned with YANG DM (and written in XML, I guess).
I'll also provide guidelines to expand the DM instance with all the data
that are currently part of the
draft-hares-i2nsf-capability-data-model-05 (IMO, it will be a minor
rearrangement).
When DM and instance will be ready, we'll ask the WG (in particular the
other authors of IMs and DMs) to verify if they agree on the proposed DM
and process the proposed modifications.
Furthermore, I just asked Arnaud Taddei from Symantec to share with us
the additional requirements from a multi-domain-of-administration
scenario he was mentioning during the I2NSF plenary. I'll process these
data and share with you my findings and potential improvements to the
I2NSF capability IM and DMs.
Finally, the new IM and DM implies changes to the capability IM in
draft-xibassnez-i2nsf-capability-02, we'll also align the document to
the changes.
Regards,
Aldo

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 3 Jan 2018 18:26:32 +0000

John,

Thank you very much for the detailed explanation. Took me awhile to carefully reading through your writing. Felt like reading a college class assignment. Are you going to update the capability draft accordingly?

You stated to have separate “I2NSFSecurityPolicyRule and I2NSFDecoratorRule”. Do users (e.g. Controller or Admin who issue the policy rules) have to be aware which one to use?

Are the “event”, “condition” and “action” part of I2NSFPolicyComponent? What are the examples of sibling class to I2NSFEvent, I2NSFCondition, and I2NSFAction?  Can you add the examples to the updated draft? To make it easier for people to comprehend.

Can you also add some examples of “I2NSFMetadata class” in the updated draft?

Thank you very much.

Linda

From: John Strassner
Sent: Wednesday, January 03, 2018 9:11 AM
To: Linda Dunbar <[email-masked]>; Aldo Basile <[email-masked]>; John Strassner <[email-masked]>; John Strassner <[email-masked]>
Cc: [email-masked]
Subject: RE: [I2nsf] updates on the capability models

2)  It is not extensible

Packets and Protocols

StateInfo

ConditionTarget

ResolutionStrategy

ClauseEvaluation

SecurityTemplate
This is a good idea!

Best regards,
John

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, January 02, 2018 10:11 AM
To: John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: Fwd: [I2nsf] updates on the capability models

---------- Forwarded message ----------
From: Cataldo Basile <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 4, 2017 at 1:50 AM
Subject: Re: [I2nsf] updates on the capability models
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Dear Linda,

Regards,
Aldo

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 30, 2017 4:12 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: updates on the capability models
Dear Linda, all,

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 4 Jan 2018 01:23:39 +0000

Hi Linda,

Please see inline.

Regards,
John

From: Linda Dunbar
Sent: Wednesday, January 03, 2018 10:27 AM
To: John Strassner <[email-masked]>; Aldo Basile <[email-masked]>; John Strassner <[email-masked]>
Cc: [email-masked]
Subject: RE: [I2nsf] updates on the capability models

John,

Thank you very much for the detailed explanation. Took me awhile to carefully reading through your writing. Felt like reading a college class assignment.
<jcs>
Sorry, I wrote this on the plane trip to Shenzhen. I am a tenured professor, but that was not my intent. ☺
</jcs>

Are you going to update the capability draft accordingly?
<jcs>
I will wait for feedback from at least the Capability draft co-authors, and then lead the editing of this draft.
</jcs>

You stated to have separate “I2NSFSecurityPolicyRule and I2NSFDecoratorRule”. Do users (e.g. Controller or Admin who issue the policy rules) have to be aware which one to use?
<jcs>
NO!
The power of the decorator pattern is to provide a single interface to the “base class” (in this case, I2NSFSecurityPolicyRule). The client is blissfully unaware of whether additional objects wrap the base class. :-)
</jcs>

Are the “event”, “condition” and “action” part of I2NSFPolicyComponent?
<jcs>
YES! Remember, an I2NSFPolicyRule aggregates an event clause, a condition clause, and an action clause. Conceptually, think of an I2NSFPolicyRule as aggregating one or more I2NSFPolicyComponents.
</jcs>

What are the examples of sibling class to I2NSFEvent, I2NSFCondition, and I2NSFAction?  Can you add the examples to the updated draft? To make it easier for people to comprehend.
<jcs>
Any object that is a part of an I2NSFPolicyRule (except for I2NSFMetadata) can be a PolicyComponent (i.e., a sibling class). For example, take a look at Figure 13 of the SUPA draft. Event, Condition, and Action are the fundamental components of an ECA policy rule, but each of these can be optionally constructed from other objects. For example, a Boolean clause takes the form of {variable, operator, value} (e.g., numAlarms > 5). One could either use an atomic Event (or Condition in this example), or use individual objects (e.g., a PolicyVariable, a PolicyOperator, and a PolicyValue) to make up the Boolean clause.

I will add examples to the draft.
</jcs>

<jcs>
Sure
</jcs>

Thank you very much.

Linda

From: John Strassner
Sent: Wednesday, January 03, 2018 9:11 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Aldo Basile <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [I2nsf] updates on the capability models

2)  It is not extensible

Packets and Protocols

StateInfo

ConditionTarget

ResolutionStrategy

ClauseEvaluation

SecurityTemplate
This is a good idea!

Best regards,
John

---------- Forwarded message ----------
From: Cataldo Basile <[email-masked]<mailto:[email-masked]>>
Date: Mon, Dec 4, 2017 at 1:50 AM
Subject: Re: [I2nsf] updates on the capability models
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Dear Linda,

Regards,
Aldo

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 30, 2017 4:12 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: updates on the capability models
Dear Linda, all,

--
regards,
John

---

From: Cataldo Basile <[email-masked]>
Date: Sat, 6 Jan 2018 11:39:56 +0100

Hi John,

answers in-line...

In short, I agree on all points, I have a concern on ResolutionStrategy 
to be metadata, and confirm we need further discussions to continue the 
design on the points that have been marked as open issues by John.

> be properly derived from the info model.

Insisting on deriving data models from info models in the proper way 
will never be enough, in my opinion.
I agree I used superset in the improper way. In all cases, I meant a 
correct data model instance of an information model.

> as well as relate other entities (e.g., a DHCP server) to those types of

Agreed.

[omissis]

> metadata. This also applies to Protocols.

I see packets mainly as aggregations of PolicyTargets, for our 
policy-based management purposes.

> Together). We should talk more about this before making a decision.

Agreed. I never had the time to deepen the analysis of the states. So I 
agree we should talk more about this.
Also because states may be protocol/network states, maintained by the 
security control (e.g., TCP states, bandwidth, packet count).
But there are also languages (e.g., ModSecurity) that allow the 
definition of 'internal states' (by means of statefull rules) that are 
used to evaluate applicability of next rules in the list.

> If we do this, then PolicyTarget should inherit from the I2NSFPolicyRule

Got it. I should have known the PolicyTarget concepts as I started my 
experience about PBNM exactly with that works...

> these associations are, so this may change the reasoning I gave.

The two associations serve to describe the case of proprietary 
algorithms that evaluate when a condition is satisfied (custom match 
conditions).

The decidesBased links the condition to the value that should be 
considered during the evaluation. It is the normal case, explicit 
condition, i.e., "IP source == 10.0.0.1" --> decidesBased on IP.source.

With appliesOn I wanted to describe the case of implicit conditions 
(because proprietary or because too complex to be explicitly written) .

For instance, an IDS/IPS deciding to perform a given action when DDoS is

if(DDoS is detected) do something

the condition 'DDoS is detected' (Boolean) summarizes a condition clause 
where different atomic conditions are used but they are not explicitly 
written. Nevertheless, for analysis purposes, I need to know that it 
uses information from IP source, IP destination, bandwidth data, etc.

Hope this clarifies the need for two associations.

[Justification:

I introduced this association because I need it for security analysis 
purposes.
In the past, I was also performing the distributed security analysis. 
When the NSFs have explicit policies I can compute explicitly the 
"anomalies", that is, if the order of processing of a flow by two 
chained NSFs can result in an unwanted/unexpected enforcement, à la 
Al-shaer]

If an NSF uses an implicit policy (e.g., a parental control system, an 
IPS) I cannot compute the anomalies explicitly, nevertheless, I still 
need to know if there could be "interference" among NSFs if they will be 
chained]

> conditions, and actions. Hence, more discussion is needed here.

Agreed. We should check how to generalize the PolicyTerm to every 
PolicyComponent it may need evaluation.

> The behavior of the Policy Rule.

I see your point, however, I'm not 100% convinced that 
ResolutionStrategy should be a I2NSFMetadata.
It is true that it is optional, but a NSF may support one or more 
strategies. And I need to know them when translating the policies for it.
For me, the fact that a NSF "supports something" is a good reason to 
consider "something" a SecurityCapability.
However, I'm open to discussion.

> Sorry, I don’t understand what this is.

ClauseEvaluation is the class I introduced to indicate the operations to 
evaluate all the conditions, e.g., DNF, CNF, general Boolean function.

I remember in PCIM DNF/CNF was an attribute in almost all the classes in 
the chain from Policy to PolicyCondition and subclasses.

> | NSF | A ----------+----------------+ SecurityCapability |

agreed.

Regards,
Aldo

> *From:*John Strassner [mailto:[email-masked]]
> *Sent:* Tuesday, January 02, 2018 10:11 AM
> *To:* John Strassner <[email-masked]>
> *Subject:* Fwd: [I2nsf] updates on the capability models
> 
> From: *Cataldo Basile* <[email-masked] 
> <mailto:[email-masked]>>
> To: Linda Dunbar <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> 
> 
> Dear Linda,
> 
> I may be wrong, but I remember that we discussed a change in the 
> capability model to avoid sub-classing as a way to obtain different 
> types of conditions, action, events, etc.
> 
> The new model, now under John's review, implements the decorator 
> pattern, thus avoid sub-classing as conditions, action, events become 
> instances (that can be easily generated, and also used dynamically at 
> run-time and many other advantages).
> 
> Then, the NSF facing data model will probably be a superset of the 
> capability model, obtained by extending it with concepts that are 
> specific of NSF facing interface.
> 
>     Thank you very much for the update. By the way, the version on data
>     tracker is still 00, so your update should be 01.
>     During our side meeting in Singapore among IM/DM authors, you stated
>     that you don't like explicit listing of the needed attributes for
>     capability, e.g. the line by line list of all the IP addresses
>     format and you volunteered to restructure the NSF facing data model
>     so that it can be easily extended. Once you prepare the preliminary
>     NSF facing data model structure, the NSF facing data model authors
>     can regroup the attributes accordingly.
>     How does the tree structure in the *pdf file you sent last Friday
>     eliminate explicit listing of all the needed attributes for
>     "Condition" on IP addresses?
>     Thank you very much.
>     Linda
>     Cc: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: John Strassner <[email-masked]>
Date: Wed, 17 Jan 2018 20:13:30 -0800

Hi Aldo,

I just realized that this email never made it out, my apologies. I'm
getting old. :-(

All, Aldo and I did chat, and are agreed. My action was to reply to the
list, but a combination of travel and old age prevented that... :-(

Eliminating things that were agreed upon, the following will clarify the
points
that may have been in doubt.

Aldo wrote:
Insisting on deriving data models from info models in the proper way will
never be enough, in my opinion.
I agree I used superset in the improper way. In all cases, I meant a
correct data model instance of an information model.
<jcs>
This is resolved - Aldo made a typo :-)
</jcs>

...

Packets and Protocols
> metadata. This also applies to Protocols.

I see packets mainly as aggregations of PolicyTargets, for our policy-based
management purposes.
<jcs>
Agreed. How about subclassing from ManagedEntity? In the MEF it is
LogicalResource, but that involves more classes.
I would also be happy with subclassing from LogicalResource.
</jcs>

...

StateInfo

Agreed. I never had the time to deepen the analysis of the states. So I
agree we should talk more about this.
Also because states may be protocol/network states, maintained by the
security control (e.g., TCP states, bandwidth, packet count).
But there are also languages (e.g., ModSecurity) that allow the definition
of 'internal states' (by means of statefull rules) that are used to
evaluate applicability of next rules in the list.
<jcs>
This one requires a more in-depth conversation. It will be addressed
before Singapore, but staged in back of the other easier ones.
</jcs>

...

> these associations are, so this may change the reasoning I gave.

The two associations serve to describe the case of proprietary algorithms
that evaluate when a condition is satisfied (custom match conditions).
The decidesBased links the condition to the value that should be considered
during the evaluation. It is the normal case, explicit condition, i.e., "IP
source == 10.0.0.1" --> decidesBased on IP.source.
With appliesOn I wanted to describe the case of implicit conditions
(because proprietary or because too complex to be explicitly written) .
For instance, an IDS/IPS deciding to perform a given action when DDoS is
if(DDoS is detected) do something

the condition 'DDoS is detected' (Boolean) summarizes a condition clause
where different atomic conditions are used but they are not explicitly
written. Nevertheless, for analysis purposes, I need to know that it uses
information from IP source, IP destination, bandwidth data, etc.

Hope this clarifies the need for two associations.
<jcs>
The problem with the two associations is that it makes the class
schizophrenic :-) (i.e., sometimes it does one thing, and sometimes
it does another thing). There are two fixes:
   1) use OCL to say "either one or the other"
   2) have two separate classes (one with normal condition,
        one with custom).
I'm happy with whichever one you want.
</jcs>

...

ResolutionStrategy
> The behavior of the Policy Rule.

I see your point, however, I'm not 100% convinced that ResolutionStrategy
should be a I2NSFMetadata.
It is true that it is optional, but a NSF may support one or more
strategies. And I need to know them when translating the policies for it.
For me, the fact that a NSF "supports something" is a good reason to
consider "something" a SecurityCapability.
However, I'm open to discussion.
<jcs>
This needs a bit more discussion. It is an attribute in the MEF and SUPA
designs.
</jcs>

ClauseEvaluation is the class I introduced to indicate the
operations to evaluate all the conditions, e.g., DNF, CNF,
general Boolean function.

I remember in PCIM DNF/CNF was an attribute in almost all the
classes in the chain from Policy to PolicyCondition and subclasses.
<jcs>
OK, we can introduce a similar attribute
</jcs>

best regards,
John

On Sat, Jan 6, 2018 at 2:39 AM, Cataldo Basile <[email-masked]>
wrote:

> Hi John,
>
> answers in-line...
>
> In short, I agree on all points, I have a concern on ResolutionStrategy to
> be metadata, and confirm we need further discussions to continue the design
> on the points that have been marked as open issues by John.
>
>
> Insisting on deriving data models from info models in the proper way will
> never be enough, in my opinion.
> But there are also languages (e.g., ModSecurity) that allow the definition
> of 'internal states' (by means of statefull rules) that are used to
> evaluate applicability of next rules in the list.
>
>
>
>> ConditionTarget
>>
> The two associations serve to describe the case of proprietary algorithms
> that evaluate when a condition is satisfied (custom match conditions).
>
> written. Nevertheless, for analysis purposes, I need to know that it uses
> information from IP source, IP destination, bandwidth data, etc.
>
> In the past, I was also performing the distributed security analysis. When
> the NSFs have explicit policies I can compute explicitly the "anomalies",
> that is, if the order of processing of a flow by two chained NSFs can
> result in an unwanted/unexpected enforcement, à la Al-shaer]
>
> IPS) I cannot compute the anomalies explicitly, nevertheless, I still need
> to know if there could be "interference" among NSFs if they will be chained]
>
>
> I see your point, however, I'm not 100% convinced that ResolutionStrategy
> should be a I2NSFMetadata.
>> From: *Cataldo Basile* <[email-masked] <mailto:
>> [email-masked]>>
>> To: Linda Dunbar <[email-masked] <mailto:[email-masked]
>> >>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>> Dear Linda,
>>
>> capability model to avoid sub-classing as a way to obtain different types
>> of conditions, action, events, etc.
>>
>> The new model, now under John's review, implements the decorator pattern,
>> thus avoid sub-classing as conditions, action, events become instances
>> (that can be easily generated, and also used dynamically at run-time and
>> many other advantages).
>>
>> capability model, obtained by extending it with concepts that are specific
>> of NSF facing interface.
>>

-- 
regards,
John