Dear Susan, more comments in-line...
On 09/06/2016 21:30, Susan Hares wrote:
Alod:
The minor changes to getting IPTable deployments are why I started this
thread.
On 1) I turned the packet matching into a ordered list where a match causes
the processing to stop. Your action_to_enforce <--
Resolution{Rx,Ry,Rt,...}. You can see some of the ideas in my I2RS draft
(draft-hares-i2rs-pkt-eca-policy), but it needed changes for I2RS and for
the policy. The draft-hares-i2rs-fb-rib-data-model shows how you can use
this policy on specific interfaces, and have a default RIB for things which
do not match. I am interested to discuss your ideas on the more complex
policy model.
I have checked your draft, I see that you can easily model iptables rules. I also noticed that you mapped an incredibly high number of conditions on the most important (if not all) protocols at the first four ISO layers. Excellent work that we may want to reuse.
Compared to our model, there is a missing information: the condition matching algorithm, i.e., the types of operations allowed when specifying a condition on a given field. That is, when you express conditions on IP Protocol Type field you specify a list of values and don't need to use ranges (= set based), for source or dest ports you may want to use inequalities or ranges (= range based) and for IP source and dest you may want to use prefixes (= prefix based ~ range based). For URLs and other upper protocol conditions on strings you may want to use string match (like squid dstdomain acl) or regex match (like squid url_regex acl). Finally, to describe cases like antivirus or malware detection conditions we have introduced the custom match conditions (i.e., we describe the list of fields that the condition match verifier will take into account when taking the decision without explicitly referring to the algorithm to map these inputs into a Boolean answer). 'Other capabilities' in the Capabilities draft will likely be Custom Match conditions.
Since our objective in SECURED was also to model policy specification needs at a higher level (and to perform refinement), we concentrated on the definition of resolution strategies that may be useful for administrators, regardless of the fact that they are actually implemented in some security controls. For instance we considered the Deny Take Precedence (DTP) resolution strategies, borrowed from the DB world, where if more a rule matches, the action to enforce will be Deny (drop in your model) if at least one of the matching rule enforce the Deny. This is a way to implement conservative policies. Moreover, there is also the Most Specific Take Precedence (MSTP) which applies the rule that more precisely matches the PDU (e.g., if there is a rule for a subnet and one specific for a given IP, the one for the single IP prevails).
Note that not all the device use prioritized rules (= list of rules) to make decisions. A simple example: the ipsec tools use the {Default, Use, Require, Unique} attributes that slightly change the ordered list behavious. Therefore, the concept of resolution strategy needs to be explicitly reported in a data model (in my opinion).
If you are interested in my policy model, a more detailed (and formal definition) description of resolution strategies and the policy model for our work on capabilities can be found here:
(for packet filters) http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6111329
(extension on application filters) http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6690252
On 2) My packet filters can be expanded to include application filters or we can create a another grouping of filters.
I agree it is a very easy step in your model.
On 3) security controls in network security control
I agree that the matching is complex or the actions are complex. In many
cases, these actions are specific to a vendor. However, let's start with
simple URL filtering as an example. I assumed that the URL Filtering was
point to a URL Filtering list. There could be public lists or vendor
generated lists. Therefore in high level yang, the first part of the i2NSF
Security content might be:
Module -i2nsf-sec-content
+--rw i2nsf-sec-content-cap* [order-id rule]
+--rw order-id
+--rw rule-name
+--rw anti-virus
| +--rw public-anti-virus* [name]
| ....
| +--rw vendor-anti-virus* [vendor]
| ....
+--rw IPS
| +--rw snort-rules* [date]
| | ...
| +--rw vendor-IPS-rule* [Vendor]
| | ...
+--rw URL Filtering
| +--rw public-url* [name]
| | ...
| +--rw vendor-url*[vendor]
| | ....
I think this matches your work. However, I think the results of the filter
process can be match or not. The question is once you match, what do you
do?
If I understand correctly, you implicitly assume an action when using URL filters.
For me, URL filtering is just a condition of regex/string based type.If (the URL in the PDU under examination matches some_URL_strings) then return TRUE.
some_URL_strings can be either manually written by the policy editor or obtained by some vendor or public source of URLs.
Then this condition on URLs can be mixed with other conditions to form other rules.
if (URLcondition) ^ (other conditions) Then ACTION You can see a simple example of what I'm describing in squid acl goodurl url_regex myurl1 myurl2 myurl3 acl goodip dst 1.1.1.1 http_access allow goodurl goodipIf the list {myurl1 myurl2 myurl3 } is downloaded from a site, the matching does not change, the way to retrieve the data of course changes.
---I follow the same approach (i.e., I model them as conditions) also for for snort rules, VendorIPS rules etc.
The
The packet eca actions can have many types | +--rw eca-actions | | +--rw eca-ingress-act* | | | ... (permit, deny, mirror) | + +--rw eca-fwd-actions* | | ... (invoke, tunnel encap, fwd, drop) | | +--rw eca-egress-act* | | | (rate limit output,..) | | +--rw eca-qos-actions* | | | .. (set bits in packet | + +--rw eca-security-actions* | | uses i2nsf-sec-content-cap I was starting to work on these complex set of actions when I felt I needed to make sure I was on the right track.
I agree on these action types, I have considered all of them in my model.To the URL filter example before, for me, the eca-fwd-actions drop is the one that it is actually applied for blacklists of URL and fwd (~allow/accept) is the one in case of white lists.
Hope this has clarified my idea on the complex actions that I saw in the Capabilities draft.
4) PDP and PEP is a valuable concept. I think that ordered lists of
packet-based ECA policy is simply a means for the PDP to send the PEP a
specific set of ordered filters. Similarly, the exchange of capabilities
is simply the I2NSF sending the NSF its capabilities as ordered rules.
+--rw i2nsf-policy-list
+--rw policy-list-name string
+--rw policy-rule [name]
+--rw name string
+--rw net-sec-ctl-rules*
uses ietf-pkt-eca-policy-cfg
+--rw net-sec-content
uses i2nsf-content-rules*
+--rw net-attack-mitigate*
uses i2nsf-mitigate-rules
Have I misunderstood previous conversations on this topic?
Yes, you interpreted correctly my idea of events. However, in our model we see in a slightly different way the PDP-PEP exchanges and capability interfaces.
The PEP sends the PDP the stateful info (i.e., the context) together with the flow/packet/PDU data to evaluate (note that some additional info can be obtained from a PIP, but this is a minor detail). This context info also contains the events that triggered the evaluation from the PEP. The PDP looks into the Policy in the PolicyDB, checks matching rules and decides actions (some of these rules will contain conditions on the events), then the PDP sends the PEP the action (+ provisional data). [maybe it is not 100% compliant with IETF but just for lack of room, it's already a long email.]
In a SECURED-equivalent approach, the I2NSF controller knows (from a repository) or asks the NSF its capabilities (through an API), capabilities that include the list the actions that can enforce, the conditions that allow to determine the traffic on which enforce actions, plus all the other info needed to build a valid configuration for that device.
Then the SECURED infrastructure uses this info to derive a configuration for the NSF (i.e., a policy composed of rules for the specific NSF), based on high-level policies (i.e., vendor- NSF-agnostic security requirements).
That is, the policy is built on the NSF capabilities (capabilities that describe what an NSF can do if the infrastructure wants to use it for enforcing security policies) but it is not a capability.
Hope I am not cryptic and boring with these long emails... Regards, Aldo
-----Original Message----- From: I2nsf [mailto:[email protected]] On Behalf Of Aldo Basile Sent: Thursday, June 09, 2016 1:29 PM To: DIEGO LOPEZ GARCIA; Susan Hares Cc: [email protected]; [email protected]; Linda Dunbar Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models 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-mitigatio n-api/· *An Information Model for the Monitoring of Network Security Functions - https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-0 0* 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_______________________________________________ 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
