Dear Susan,I'm currently working on a model of security control capabilities based on the work within the SECURED project. The SECURED project also aims at performing policy refinement, thus we probably need a more detailed model than the one that may suffice for management purposes.
I also started from the draft "Capability model for South Bound interface (I2NSF manager to NSF device)" https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/). The other two documents are too related to DDoS and monitoring. I think there are (minor) issues in that information model that will make impossible to represent iptables rules and policies, and more in general, for an unambiguous description of the functions performed by a NSF. Thus much before the actual deployment of the configurations. Our model is not ready (it will be ready soon). So I'll add a few notes here related to the creation of Data models.
As a first general comment, I like the approach in the Capability document. It is not far from what we are doing and the positions are easily reconcilable. However, I have a few comments on specific topics.
1) The policy rule evaluation algorithm at page 13 is too simple to model the behaviour of several existing security controls, including iptables. It does not take care of cases where more than a rule matches a flow/packet/PDU, that is, the model does not consider the resolution strategies. That is, the match part is rule-specific (i.e., conditions are evaluated for each rule), the action to enforce is decided at policy level by considering all the matching rules.
Moreover, there are devices/security controls that stop when the first rule matches (like iptables, resolution = First Matching Rule) other security controls where the decision to stop the evaluation of other rules at lower priorities is written in the rule itself (like ModSecurity that includes some "actions" for rules order processing / rules control flow management).
Therefore, the part that needs to be refined is:
THEN execute <action-clause>
maybe into
action_to_enforce <-- Resolution{Rx,Ry,Rt,...}
where Rx,Ry,Rt,... are the matching rules, i.e., the rules whose
conditions are all satisfied.
Finally, the model must consider that if no rules match, then the security control must apply the default action (However, this is easier to add into the model and can be described with a normal rule.) To precisely cover all these cases, in our work, we are relying to a more sophisticated policy model.
2) security controls in the same category (e.g., network security control) may 'expose' different conditions and actions, thus they need to be described with more granularity in order to guarantee inter-operability and management correctness.
This is evident as the draft considers in the same category packet filters and application layer filters. Even in the same sub-category, e.g., application layer filters, they have very different set of conditions (and underlying policy models).
That is, attributes (=conditions) in the reported tables and in the EBNF syntax description do not apply to all the elmements in each category and need to be associated to each control individually. There are not so many of these security controls/products thus the problem is manageable. Moreover, if this becomes a standard, the security control vendors/developers would provide these data.
This consideration should affect your Yang model. 3) The 'Other security capabilities' (see Figure 2) as subclass of Actions.In my opinion, in the great majority of the cases listed, the 'other security capabilities' classes are conditions (for instance the 'URL filtering' is a condition = the action is deny/allow based on a string match/regex match condition on the URL field). In same cases, e.g., anti-virus and IPS signature recognition may be probably split in a condition part and some additional actions to add in the model (to be thus modelled separately), even if in my opinion they are again additional conditions whose domain is not a specific field. In these cases, the type of match is not based on simple operations (like =, !=, <, regex match) but on ad hoc, possibly sophisticated algorithms. In the end, they return a Boolean value that says whether the flow/packet/PDU matches or not.
Maybe, it can be reconciled with our current work by just 'appending' these features in another class that originates from Rule (is it a composition?), or better, as a subclass of the Condition class (e.g., Ingress, Egress, OtherConditionType).
4) Finally, I personally don't like ECA models because they mix PEP concepts with PDP/policy model concepts. Events are useful, no discussion. But for me, event information is just another kind of stateful info (or Context, as named in this document) collected by the PEP and passed to the PDP as any other Context info. The Policy model must then have a corresponding context/stateful condition type in the Policy model, to decide how to react, also on a per-rule basis. [you can see that events are exactly another kind of condition from the rule evaluation algorithm I mentioned before]
But I know this topic has been already discussed in this WG. Regards, Aldo On 08/06/2016 23:40, DIEGO LOPEZ GARCIA wrote:
Hi, Just a quick reply from a not too deep reading and a few minutes of thinking about it. I see this approach promising, and better structured than previous proposals on how to work at the Capability interface. It is my impression that this is well aligned with the model we have been applying in the SECURED project. Be goode,On 8 Jun 2016, at 19:23 , Susan Hares <[email protected] <mailto:[email protected]>> wrote: I’m working on some data models for I2NSF that intersect with I2RS Filter-Based RIB Models and BGP Flow Specification Data models. I could use some advice from the authors of the following information models. My focus is to be able to drive the use the flow filter Yang models (I2NSF packet-filters, Filter-Based RIB (config, I2RS, BGP input), and BGP Flow Specification transmission of filters) to drive the simple firewall rules found in the Linux iptables user program (netfilter kernel module). I am trying to get a set of Yang data models that can interact with a process (e.g. iptable++ user program named flow-filters) that communicates with a confd (cisco netconf deamon set) that handles NETCONF/RESTCONF and uses Yang to create the data base. I am creating prototype Data models that mirror the following drafts: · Capability model for South Bound interface (I2NSF manager to NSF device) https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/ · Inter-Cloud DDoS Mitigation API – https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ · *An Information Model for the Monitoring of Network Security Functions - https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-00* My understanding is the I2NSF capability interface focus on the south-bound interface to the NSF. To start out a Yang data model, I have created high-level Yang structures for these three models. I’ll be asking questions about each model in a separate email thread, but answer me in any email thread. First on the capability model, network security control is a list of ECA policies, network security content capability is a list of security content capabilities, and attack mitigation is a list of attack mitigation capabilities. A suggested Yang High-level model structure is below. My question is how does an I2NSF manager engage the packet security policies? Does putting a policy in the network security control means it gets transmitted to the NSF device, and installed? Does the capability model provide both the way to list the functions (security content and mitigation) and a way to engage these functions? Sue Hares Initial Yang models ---------- ietf-i2nsf-capability-SBI +--rw i2nsf-policy-list +--rw policy-list-name string - name of policy list +--rw i2nsf-policy-rule* [name] +--rw name string - name of policy rule +--rw net-sec-ctl-rules uses ietf-pkt-eca-sec-policy // packet ECA security policy +--rw net-sec-content // list of content security capabilities uses i2nsf-sec-content // grouping of security capabilities +--rw net-attack-mitigate // list of mitigation capabilities / uses i2nsf-mitigate-rules //grouping of mitigation capabilities Is this a good way to start the capabilities structure? I have definitions for each of the “uses” statements in different models, but I need help understanding if this structure is correct. ietf-pkt-eca-sec-policy can be an extension of the I2RS/Configuration filters for packet Filter-Based RIBS. For the i2nsf-sec-content-capbility, does this form make sense: +--i2nsf-sec-content +--rw i2nsf-sec-content-cap* [order-id function-set-name] +--rw order-id // order # if in ordered list +--rw function-set-name string // name for function +--rw anti-virus // basic security content action | +--rw public-anti-virus [name] // anti-virus capability from public sources | … // (yang structure details) | +--rw vendor-anti-virus [vendor] // anti-virus capability from vendor | | …. The mitigation has a similar structure to the i2nsf-sec-content. +--i2nsf-attack-mitigation +--rw i2nsf-attack-mitigate-fcn* [order-id, fcn-name] +--rw order-id +--rw fcn-name +--rw syn-flood | +--rw public-syn-flood* [name] | | ... | +--rw vendor-syn-flood* [vendor] | | ... +--rw UDP flood _______________________________________________ I2nsf mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf-- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ------------------------------------------------------------------------ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________ 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
