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

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

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. 

On 2) My packet filters can be expanded to include application filters or we
can create a another grouping of filters. 

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

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? 

Sue 


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