Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

[Aldo Basile <[e-mail]>]

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 goodip


If 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:[e-mail]] On Behalf Of Aldo Basile
> Sent: Thursday, June 09, 2016 1:29 PM
> To: DIEGO LOPEZ GARCIA; Susan Hares
> Cc: [e-mail]; [e-mail]; 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 <[e-mail]
>>> <mailto:[e-mail]>> 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
>>> [e-mail] <mailto:[e-mail]>
>>> 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: [e-mail]
>> Tel:    [phone]
>> Mobile: [phone]
>> ----------------------------------
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>