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 adifferent class (say, metadata, an equally bad choice), now you have differentsemantics 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 begsthe 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. Ofcourse, MAC addresses are different from both, so as a simple example, insteadof listing a set of attributes that partially describe any one of these 3 typesof addresses, why not have a NetworkAddress class, with 3 subclasses? Thisenables 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 somethingthe 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:[email protected]] *Sent:* Tuesday, January 02, 2018 10:11 AM *To:* John Strassner <[email protected]> *Subject:* Fwd: [I2nsf] updates on the capability models ---------- Forwarded message ----------From: *Cataldo Basile* <[email protected] <mailto:[email protected]>>Date: Mon, Dec 4, 2017 at 1:50 AM Subject: Re: [I2nsf] updates on the capability models To: Linda Dunbar <[email protected] <mailto:[email protected]>>Cc: "[email protected] <mailto:[email protected]>" <[email protected] <mailto:[email protected]>>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 protected] <mailto:[email protected]>] Sent: Thursday, November 30, 2017 4:12 AM To: Linda Dunbar <[email protected] <mailto:[email protected]>> Cc: [email protected] <mailto:[email protected]> 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 protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- regards, John _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
