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

["Susan Hares" <[e-mail]>]

Aldo: 

I'm going to answer in summary, and then with "sue:" in the text below.  On,
hares-i2rs-pkt-eca-policy - I agree it is missing 

-----Original Message-----
From: I2nsf [mailto:[e-mail]] On Behalf Of Aldo Basile
Sent: Friday, June 10, 2016 6:46 AM
To: Susan Hares; 'DIEGO LOPEZ GARCIA'
Cc: [e-mail]; [e-mail]; 'Linda Dunbar'
Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

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.

Thank you. 

>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).

Sue: I agree.  I am waiting for the WG LC to be completed to release a
version with more matching conditions.  However, I'd be very interested in
yours.

>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.

Sue: You are correct this is missing.  My struggle was where to draw the
line for simple filtering (aka IPTable or netfiltesr) and the security
custom.
I was trying to create a base model for simple filtering and augment it.
Do you think I have a good base. 

>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.

Sue: Excellent! I would love to see this policy.  I tried to get work on the
node filters (I2RS and I2NSF).  Is this the user to I2NSF Manager? 

>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.

Sue: An interesting strategy for top-down (management).  Is that what you
were doing? 
  
> 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).

This MSTP - is often the default in routing. 

>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).

Yes - the resolution strategy does need to  indicate whether it is ordered
or "all rules match", or something else 

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

Could you send me a copy via email (outside the mail list) with this
documents. I cannot get access. 

>>
>> 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.

Thank you for your input. 

>
> 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?

Aldo's comments: 
>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.

Sue: Agreed

>>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.

This was  my assumption in my code.   The reason I had two places was to
allow the user a mount point for the public rules (e.g. snort filters from a
public site), and vendor developed (from IDS/IPS).  I am missing your point,
but I have not read your documents yet. 
>>
>> 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.

Yes I has clarified our work. 

>
> 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.

This is a lot of backhaul for a simple security device (iptables) for more
sophisticated devices, it may be the best way. 

>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.]

I understand the concept.  It is the original PDP/PEP work. 
Is there a benefit in this for security work that I am missing? 

>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).

Sue: This is a reasonable approach, the only problem is how much 
"backhaul" of data needs to be done.  In modern switches fabrics, 
You can get a lot of logic done on site.  (Age-old trade off: tunnel to
process or process on edge of network) 

>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...

Not cryptic and I really appreciate your long email.  I will do better once
I've seen the papers or your model. 

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
>