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
> 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.
>
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
> 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.
>
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>
...
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.
>
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
> 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.
>
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 <cataldo.bas...@polito.it>
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.
>
>
> On 03/01/2018 16:11, John Strassner wrote:
>
>> 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.
>>
>
>
> 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.
>
>
>
>> 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.
>>
>
> Agreed.
>
> [omissis]
>
>
>> 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.
>>
>
> I see packets mainly as aggregations of PolicyTargets, for our
> policy-based management purposes.
>
>
>> 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.
>>
>
>
> 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.
>
>
>
>> 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.
>>
>>
>
> Got it. I should have known the PolicyTarget concepts as I started my
> experience about PBNM exactly with that works...
>
>
> 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.
>>
>
> 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]
>
>
>> 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.
>>
>
> Agreed. We should check how to generalize the PolicyTerm to every
> PolicyComponent it may need evaluation.
>
>
>> 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.
>>
>
> 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.
>
>
>> ClauseEvaluation
>>
>> 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.
>
>
>> 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.
>>
>
> agreed.
>
> Regards,
> Aldo
>
>
>
> *From:*John Strassner [mailto:straz...@gmail.com]
>> *Sent:* Tuesday, January 02, 2018 10:11 AM
>> *To:* John Strassner <john.sc.strass...@huawei.com>
>> *Subject:* Fwd: [I2nsf] updates on the capability models
>>
>> ---------- Forwarded message ----------
>> From: *Cataldo Basile* <cataldo.bas...@polito.it <mailto:
>> cataldo.bas...@polito.it>>
>> Date: Mon, Dec 4, 2017 at 1:50 AM
>> Subject: Re: [I2nsf] updates on the capability models
>> To: Linda Dunbar <linda.dun...@huawei.com <mailto:linda.dun...@huawei.com
>> >>
>> Cc: "i2nsf@ietf.org <mailto:i2nsf@ietf.org>" <i2nsf@ietf.org <mailto:
>> i2nsf@ietf.org>>
>>
>>
>> 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:cataldo.bas...@polito.it
>> <mailto:cataldo.bas...@polito.it>]
>> Sent: Thursday, November 30, 2017 4:12 AM
>> To: Linda Dunbar <linda.dun...@huawei.com
>> <mailto:linda.dun...@huawei.com>>
>> Cc: i2nsf@ietf.org <mailto:i2nsf@ietf.org>
>> 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
>> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>>
>>
>> _______________________________________________
>> I2nsf mailing list
>> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>>
>>
>> --
>>
>> regards,
>>
>> John
>>
>>
>>
>> _______________________________________________
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>
>
--
regards,
John
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
