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

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jun 2016 13:23:04 -0400

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 8 Jun 2016 18:02:01 +0000

Sue,

Thank you very much for the detailed analysis, and linking with the relevant Flow Filter YANG models developed by I2RS and BGP flow spec.

To answer your questions, I think that we need to make the terminology less confusing.

The I2NSF framework specified two interfaces :

-        Service Layer Interface: between client and  controller

-        Capability layer interface: between Controller and NSF functions.

So the Capability layer is the south bound interface between Controller and NSF functions.

https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ introduces a requirement for one domain to query the Flow Security  Policy enforcement "capability" from another domain over the "I2NSF Service Layer Interface"".

Therefore, I think we need to differentiate the two.

For ease of discussion, Let's use the term "NSF Flow Policy" for the Flow Security Policies over the Controller <-> NSF interface (waiting for WG to finalize the terminology), and use the "Capability" as used by https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api/ for one domain to inquire the  "capability" of the other domain of enforcing the Flow Security Policy.

Your question: "how does an I2NSF manager engage the packet security policies?

Answer: I think  "I2NSF Controller" is a more accurate term. The I2NSF Controller converts the Flow Security Policies from the Service Layer Interface to implementable policies to the NSFs.

I2NSF charter says: " Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF."

Your question: Does putting a policy in the network security control means it gets transmitted to the NSF device,

Answer: Yes.

Your question: and installed?

Answer: the NSF needs to install the policies. But not the controller

Your question: Does the capability model provide both the way to list the functions (security content and mitigation) and a way to engage these functions?
Answer: if we use the new terms, the "Capability Model" specified by the https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/  is the Flow Security Polices that controller can pass down to NSF.   The "capability" inquiry is over the "I2NSF Service layer interface"

If my explanation is still not clear, please ask more questions.

Thank you very much.

Linda

From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, June 08, 2016 12:23 PM
To: [email-masked]
Cc: Linda Dunbar; [email-masked]
Subject: Help on turning I2NSF Information Models to Data Models

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

      +--rw net-sec-content               // list of content security capabilities
            uses i2nsf-sec-content       // grouping of security 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
     |  |
    ....

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 8 Jun 2016 21:40:43 +0000

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-masked]<mailto:[email-masked]>> 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.

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

Sue Hares

Initial Yang models
----------

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.

+--i2nsf-sec-content
     |   …                                                       //  (yang structure details)
    ….

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
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-masked]
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

---

From: Aldo Basile <[email-masked]>
Date: Thu, 9 Jun 2016 19:29:05 +0200

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,
>
>> 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 –
>> ·         *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
>> ----------
>> 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.
>>
>> filters for packet Filter-Based RIBS.   For the
>> i2nsf-sec-content-capbility, does this form make sense:
>>
>> +--i2nsf-sec-content
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> 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
>
>
> [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Jun 2016 14:59:45 -0400

Linda: 

Thank you for defining the service layer and the capability layer.   Let me
see if this picture is right for the simple Linux firewall 

           User level   

              |  (query on policies) 

    (NBI) V

   I2NSF Controller

    (SBI) |   per NSF policies (yang data Model)   

           NSF  

             |   (IP table policies on linux) 

            Kernel 

The Inter-Cloud interface is at the User level 

  Cloud 1 ------àI2NSF Controller(cloud 2) 

   Client                   agent/server 

Cloud 2 ß------- Cloud 2  

I2NSF                    client 

Controller 

Do I understand this correctly? 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 08, 2016 2:02 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Sue, 

Thank you very much for the detailed analysis, and linking with the relevant
Flow Filter YANG models developed by I2RS and BGP flow spec. 

To answer your questions, I think that we need to make the terminology less
confusing. 

 

So the Capability layer is the south bound interface between Controller and
NSF functions. 

https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigatio
n-api/ introduces a requirement for one domain to query the Flow Security
Policy enforcement “capability” from another domain over the “I2NSF Service
Layer Interface””. 

For ease of discussion, Let’s use the term “NSF Flow Policy” for the Flow
Security Policies over the Controller <-> NSF interface (waiting for WG to
finalize the terminology), and use the “Capability” as used by
https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mitigatio
n-api/ for one domain to inquire the  “capability” of the other domain of
enforcing the Flow Security Policy. 

Your question: “how does an I2NSF manager engage the packet security
policies?  

Answer: I think  “I2NSF Controller” is a more accurate term. The I2NSF
Controller converts the Flow Security Policies from the Service Layer
Interface to implementable policies to the NSFs. 

I2NSF charter says: ” Simple Service Layer policies can be directly
translated to capability layer rules with a direct mapping that might
include a customer ID to be translated to tags carried by packets, but might
not specify the NSF.”

Your question: Does putting a policy in the network security control means
it gets transmitted to the NSF device, 

Answer: Yes. 

 

Your question: Does the capability model provide both the way to list the
functions (security content and mitigation) and a way to engage these
functions? 

Answer: if we use the new terms, the “Capability Model” specified by the
https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/
is the Flow Security Polices that controller can pass down to NSF.   The
“capability” inquiry is over the “I2NSF Service layer interface”

Thank you very much. 

Linda 

·         Capability model for South Bound interface (I2NSF manager to NSF
device)
https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/

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

Sue Hares

Initial Yang models 

----------

+--rw i2nsf-policy-list

       +--rw net-sec-ctl-rules 

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. 

+--i2nsf-sec-content

     |   …                                                       //  (yang
structure details) 

     |  |

    …. 

     +--rw order-id

     +--rw fcn-name 

     +--rw syn-flood

     |  | ... 

     |  | ... 

     +--rw UDP flood

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 9 Jun 2016 15:30:55 -0400

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:[email-masked]] On Behalf Of Aldo Basile
Sent: Thursday, June 09, 2016 1:29 PM
To: DIEGO LOPEZ GARCIA; Susan Hares
Cc: [email-masked]; [email-masked]; 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).

maybe into

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.

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:
> 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,
>
>> - 
>> https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-0
>> 0*
>>
>> 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
>> ----------
>> definitions for each of the “uses” statements in different models, 
>> but I need help understanding if this structure is correct.
>>
> 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.
>
> 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.
>
> 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,

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 10 Jun 2016 10:01:25 +0000

Sue,

Yes. Your drawing is right. Should we update the I2NSF terminologies accordingly?

Thanks, Linda

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, June 09, 2016 2:00 PM
To: Linda Dunbar; [email-masked]
Cc: [email-masked]
Subject: RE: [I2nsf] Help on turning I2NSF Information Models to Data Models

Linda:

Thank you for defining the service layer and the capability layer.   Let me see if this picture is right for the simple Linux firewall

           User level
              |  (query on policies)
    (NBI) V
   I2NSF Controller

  Cloud 1 -------->I2NSF Controller(cloud 2)
   Client                   agent/server

Cloud 2 <--------- Cloud 2
I2NSF                    client
Controller

Sue

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 08, 2016 2:02 PM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Sue,

Answer: Yes.

Thank you very much.

Linda

From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, June 08, 2016 12:23 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: Help on turning I2NSF Information Models to Data Models

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

·        An Information Model for the Monitoring of Network Security Functions - https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-00

Sue Hares

Initial Yang models
----------

+--i2nsf-sec-content

---

From: Aldo Basile <[email-masked]>
Date: Fri, 10 Jun 2016 12:46:23 +0200

Dear Susan,

more comments in-line...

> do not match.  I am interested to discuss your ideas on the more complex

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

> can create a another grouping of filters.

I agree it is a very easy step in your model.

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

> 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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Jun 2016 16:24:44 -0400

Linda: 

That would be helpful.  Since I’m a co-author on the draft, I will note to
myself that I should update the text. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, June 10, 2016 6:01 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Sue, 

Yes. Your drawing is right. Should we update the I2NSF terminologies
accordingly? 

Thanks, Linda 

Linda: 

           User level   

              |  (query on policies) 

    (NBI) V

   I2NSF Controller

           NSF  

            Kernel 

   Client                   agent/server 

Cloud 2 ß------- Cloud 2  

I2NSF                    client 

Controller 

Sue 

Sue, 

 

 

Answer: Yes. 

 

Thank you very much. 

Linda 

 

Sue Hares

Initial Yang models 

----------

+--rw i2nsf-policy-list

       +--rw net-sec-ctl-rules 

+--i2nsf-sec-content

     |   …                                                       //  (yang
structure details) 

     |  |

    …. 

     +--rw order-id

     +--rw fcn-name 

     +--rw syn-flood

     |  | ... 

     |  | ... 

     +--rw UDP flood

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 16 Jun 2016 01:50:50 +0000

Hi all,
Firstly, I really like Sue’s design of I2NSF capability interface data model even it’s in the very beginning stage now. I think it’s very promising.
My Comments to Diego:

发件人: I2nsf [mailto:[email-masked]] 代表 DIEGO LOPEZ GARCIA
发送时间: 2016年6月9日 5:41
收件人: Susan Hares
抄送: [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

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.
[Frank]: Could you please remind me what is the “previous proposals”? Do you mean the current information model design? Any more details?

It is my impression that this is well aligned with the model we have been applying in the SECURED project.

Be goode,

Sue Hares

Initial Yang models
----------

+--i2nsf-sec-content

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Jun 2016 22:02:24 -0400

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:[email-masked]] On Behalf Of Aldo Basile
Sent: Friday, June 10, 2016 6:46 AM
To: Susan Hares; 'DIEGO LOPEZ GARCIA'
Cc: [email-masked]; [email-masked]; '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 <--
>> 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. 

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)

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

Sue: Agreed

other rules.
> acl goodurl url_regex myurl1 myurl2 myurl3 acl goodip dst 1.1.1.1
>
>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. 

>Hope this has clarified my idea on the complex actions that I saw in the 

Yes I has clarified our work. 

>This context info also contains the events that triggered the evaluation 

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

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

>based on high-level policies (i.e., vendor- NSF-agnostic security 

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) 

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

Regards,
Aldo

> Our model is not ready (it will be ready soon). So I'll add a few notes
here
> As a first general comment, I like the approach in the Capability
document.
> That is, the match part is rule-specific (i.e., conditions are evaluated
for
> Moreover, there are devices/security controls that stop when the first
rule
> where Rx,Ry,Rt,... are the matching rules, i.e., the rules whose
conditions
> probably split in a condition part and some additional actions to add in
the
> 4) Finally, I personally don't like ECA models because they mix PEP
concepts

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 15 Jun 2016 22:06:54 -0400

Aldo: 

I forgot to give a summary of my email.  I agree things are missing from
hares-pkt-eca-policy.   One question is whether we have a simple filter yang
model and a security filter model or how these are linked.  

I could not access your papers.  Would you send them (to me directly)?  I
think we have a lot of good work we can do togheter. 

Sue Hares

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2016 10:02 PM
To: 'Aldo Basile'; 'DIEGO LOPEZ GARCIA'
Cc: [email-masked]'; [email-masked]'; 'Linda Dunbar'
Subject: RE: [I2nsf] Help on turning I2NSF Information Models to Data Models

Aldo: 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Aldo Basile
Sent: Friday, June 10, 2016 6:46 AM
To: Susan Hares; 'DIEGO LOPEZ GARCIA'
Cc: [email-masked]; [email-masked]; '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:
>> which do not match.  I am interested to discuss your ideas on the 
>> more complex policy model.

>conditions on the

Thank you. 

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

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

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

(for packet filters)

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

filters.
return TRUE.

Sue: Agreed

other rules.
> if (URLcondition) ^ (other conditions) Then ACTION You can see a 
>simple example of what I'm describing in squid
>

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

>Hope this has clarified my idea on the complex actions that I saw in 
>the  Capabilities draft.

>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 

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

Regards,
Aldo

> 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.
>
> 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.
>
document.
iptables.
> 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.
>
> security control must apply the default action (However, this is 
> easier to add into the model and can be described with a normal rule.) 
> 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.
> 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
> 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.
>>> 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 
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> destinatario, puede contener información privilegiada o confidencial 
>> y es para uso exclusivo de la persona o entidad de destino. Si no es

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 16 Jun 2016 03:08:48 +0000

Hi Frank,

May be is my personal preference to avoid general classifications (what I was concerned the information model could fall into) or the fact that concrete approaches are easier to understand (and that’s why I tend to look for data models whenever I see an information model), but I saw this document as a clear step towards a precise understanding of what the capability layer is.

Be goode,

On 16 Jun 2016, at 10:50 , Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

发件人: I2nsf [mailto:[email-masked]] 代表 DIEGO LOPEZ GARCIA
发送时间: 2016年6月9日 5:41
收件人: Susan Hares
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Linda Dunbar
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Hi,

Be goode,

Sue Hares

Initial Yang models
----------

+--i2nsf-sec-content

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 16 Jun 2016 03:41:53 +0000

Ok, Diego. I get your point.
In general, I agree with you. More concrete approaches are always easier than the general classification.
The information model draft is going to and will continue this direction.

Thanks!

发件人: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
发送时间: 2016年6月16日 11:09
收件人: Xialiang (Frank)
抄送: [email-masked]; [email-masked]; Linda Dunbar; Susan Hares
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Hi Frank,

Be goode,

Hi all,

Hi,

Be goode,

Sue Hares

Initial Yang models
----------

+--i2nsf-sec-content

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Jun 2016 00:30:26 -0400

Frank: 

I just took your capability information model and made it concrete for a very simple firewall (IPTables/netfilters in linux).   As we iterate on these models, I’m sure we’ll learn from each other.   I just wanted to get it started so that we could give vendors an idea where the info-models would plug in vendor specific model.  It also helps me understand what in the I2RS FB-FIB can be reused and what must be changed. 

I suspect iteration will be helpful here on the list. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Xialiang (Frank)
Sent: Wednesday, June 15, 2016 11:42 PM
To: DIEGO LOPEZ GARCIA
Cc: [email-masked]; [email-masked]; Susan Hares; Linda Dunbar
Subject: [I2nsf] 答复: Help on turning I2NSF Information Models to Data Models

Thanks!

Hi Frank, 

Be goode,

On 16 Jun 2016, at 10:50 , Xialiang (Frank) <[email-masked]> wrote:

Hi all,

My Comments to Diego:

发件人: I2nsf [ <mailto:[email-masked]> mailto:[email-masked]] 代表 DIEGO LOPEZ GARCIA
发送时间: 2016年6月9日 5:41
收件人: Susan Hares
抄送:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Linda Dunbar
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Hi, 

Be goode,

On 8 Jun 2016, at 19:23 , Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

·         Capability model for South Bound interface (I2NSF manager to NSF device)  <https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/> https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/

 <https://datatracker.ietf.org/doc/draft-fang-i2nsf-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> https://tools.ietf.org/html/draft-zhang-i2nsf-info-model-monitoring-00

Sue Hares

Initial Yang models 

----------

+--rw i2nsf-policy-list

       +--rw net-sec-ctl-rules 

+--i2nsf-sec-content

     |  |

    …. 

     +--rw order-id

     +--rw fcn-name 

     +--rw syn-flood

     |  | ... 

     |  | ... 

     +--rw UDP flood

_______________________________________________
I2nsf mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/i2nsf> https://www.ietf.org/mailman/listinfo/i2nsf

Dr Diego R. Lopez
Telefonica I+D
 <http://people.tid.es/diego.lopez/> http://people.tid.es/diego.lopez/

e-mail:  <mailto:[email-masked]> [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

  _____  

Dr Diego R. Lopez
Telefonica I+D

 

  _____

---

From: Aldo Basile <[email-masked]>
Date: Sun, 19 Jun 2016 11:21:40 +0200

Dear Susan,

further answers to your answers...
I listed the condition match algorithms we support, tried to clarify the 
custom match, exposed the risk for non-interoperability in case of too 
much obscurity for custom match algorithms, and added some more hints on 
the resolution strategies.
Finally, I exposed my idea of capability template (and algebra) to 
reduce the backhaul needed to describe NSFs.

And sorry for the delay in answering...

> model and a security filter model or how these are linked.

------------
Aldo:
I am not sure I understood the question. What we have in SECURED is a 
main model (which should match your security filter model), which 
defines the concepts (conditions, action, resolution strategies, 
matching conditions, etc.) and several sub-models that define the 
concepts in the main model (which should match your simple yang filter 
model). Intuitively, sub-models mainly perform sub-classing and add 
relations among these subclasses and other main model classes.
Sub-models can be nested (to form a tree).
------------

> version with more matching conditions.  However, I'd be very interested in

------------
Aldo:
The model we have developed in SECURED use 4 types of matching conditions:
- set-based (with =, !=)
- range-based (<,=,!=,>,<=,>=)
- regex match (we didn't enter into the details of the actual regex 
engine, we use Java Regex only because our prototype is written in Java)
- custom match (as explained in the previous email, requires to be 
characterized with information on the examined fields and an optional 
algorithm)
------------

> Do you think I have a good base.

------------
Aldo:
Yes, it is definitely a good base.
I fear that in general, several products (like classifier, parental 
control, IDS, IPS, etc.) will have their own custom-match.
This is a risk from the interoperability point of view. To reason about 
the policy and to deduce how a device can be used to enforce a policy 
and what kind of traffic it must receive to be able to correctly work, 
additional info must be associated to custom match. The exact amount of 
information is not completely clear to me, this is why I am assuming a 
black-box I/O definition of the custom match.
------------

> Sue: An interesting strategy for top-down (management).  Is that what you

------------
Aldo:
we support policies that can use DTP as resolution strategy, but we 
don't officially selected one resolution strategy. Every policy can use 
its own. Then we have an algorithm that exports policies in FMR (First 
Matching Rule) to connect with the real world, which in most of the 
cases uses FMR
------------

> This MSTP - is often the default in routing.

------------
Aldo:
yes, MSTP is the first level of decision (prefix length), then 
Administrative distance, then metrics (then, even if not specified 
officially, there should be some internal table order or priority to 
remove the last ambiguities).
This is another ad-hoc resolution strategy for routing.
------------

> but I have not read your documents yet.

------------
Aldo:
I support the idea to have a different mount points for public info to 
be used by rules and their sub-entities (e.g., conditions, as in this case).
But for me, this mount point is a management aspect that is needed to 
dynamically build the conditions that will be actually evaluated. While 
the condition, the operations that can be used, and  wthe data that will 
evaluate in the packets/PDU remains the same.

Hope this better clarifies my point.
------------

> sophisticated devices, it may be the best way.

------------
Aldo:
I agree, for iptables you don't need to specify this structure, however 
in my opinion the policy model should be compliant with it.
------------

> Is there a benefit in this for security work that I am missing?

------------
Aldo:
Not for iptables, but as said before, the underlying policy model should 
be compliant with it.
------------

> logic done on site.  (Age-old trade off: tunnel to process or process on

------------
Aldo:
I agree, a lot of backhaul, but it should be done only once, then I see 
the need for ad hoc templates (written by us / other I2NSF experts) to 
describe the main categories of functions (packet filter, l7 filter, 
VPN, etc.) to allow vendors / NSF developers to easily tag their NSFs. 
Moreover, we are developing a capability algebra for this (nice name for 
start from a known template and add some delta rules to specify 
differences between your NSF and the base template) and for composing 
templates (switch that filters and creates VPN and authenticates and...)
------------

> Not cryptic and I really appreciate your long email.

Thanks.

Regards,
Aldo

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 20 Jun 2016 03:36:01 +0000

Hi Aldo,
Thanks for sharing your research to us. I have reviewed your 2 papers and think they are useful for I2NSF work. My understanding and response are as follows:
1. I really like the definition of conflict resolution strategy of security policy in your papers, it should be part of the I2NSF capability layer security policy. We can work together on it;
2. I think we share the very similar idea of what the security policy is: a set of security rules which is modeled by "event-condition-action". By directly incorporating the definition of default action and conflict resolution strategy, we can improve the current information/data model;
3. About the definition of "event", I think it's necessary. It's not simply another kind of "condition". It represents something happens, and that is either or not related with the flow/traffic that the NSFs should be enabled to control according to the security policy;
4. For the other security capabilities, such as url filtering, anti-virus, file filtering, they have the following features:
	1) they perform not only content checking, but also various actions on the objects (e.g., url, files, programs);
    2) their specific implementations are different for every vendors and should not be aware of and programmed by the third party;
    3) due to the complexity and differentiation of the other security capabilities for every vendors, they are considered and treated as an atomic function in our information model. The third party does not need to know its inner logic. But for more fine-grain controlling of them, we can specify some general input/output parameters to customize their matches and actions in certain level. I think that's what you called "custom match".
5. I also think Sue's data model capture our basic idea of what it should be, let's start with it and keep improving it parallel with the information model.

Your comments and suggestions are warmly welcome!

B.R.
Frank

-----邮件原件-----
发件人: I2nsf [mailto:[email-masked]] 代表 Aldo Basile
发送时间: 2016年6月19日 17:22
收件人: Susan Hares; 'DIEGO LOPEZ GARCIA'
抄送: [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Dear Susan,

further answers to your answers...
I listed the condition match algorithms we support, tried to clarify the custom match, exposed the risk for non-interoperability in case of too much obscurity for custom match algorithms, and added some more hints on the resolution strategies.
Finally, I exposed my idea of capability template (and algebra) to reduce the backhaul needed to describe NSFs.

> model and a security filter model or how these are linked.

------------
Aldo:
I am not sure I understood the question. What we have in SECURED is a main model (which should match your security filter model), which defines the concepts (conditions, action, resolution strategies, matching conditions, etc.) and several sub-models that define the concepts in the main model (which should match your simple yang filter model). Intuitively, sub-models mainly perform sub-classing and add relations among these subclasses and other main model classes.
Sub-models can be nested (to form a tree).
------------

>
> I could not access your papers.  Would you send them (to me directly)?  
> I think we have a lot of good work we can do togheter.
>
> Sue Hares
>
> 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
>
>>> On 1)  I turned the packet matching into a ordered list where a 
>>> match causes the processing to stop.  Your action_to_enforce <--
>>> 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.
>
> 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).
>
> version with more matching conditions.  However, I'd be very 
> interested in yours.
>

------------
Aldo:
The model we have developed in SECURED use 4 types of matching conditions:
- set-based (with =, !=)
- range-based (<,=,!=,>,<=,>=)
- regex match (we didn't enter into the details of the actual regex engine, we use Java Regex only because our prototype is written in Java)
- custom match (as explained in the previous email, requires to be characterized with information on the examined fields and an optional
algorithm)
------------

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

------------
Aldo:
Yes, it is definitely a good base.
I fear that in general, several products (like classifier, parental control, IDS, IPS, etc.) will have their own custom-match.
This is a risk from the interoperability point of view. To reason about the policy and to deduce how a device can be used to enforce a policy and what kind of traffic it must receive to be able to correctly work, additional info must be associated to custom match. The exact amount of information is not completely clear to me, this is why I am assuming a black-box I/O definition of the custom match.
------------

>> needs
> 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?
>
> action to enforce will be Deny (drop in your model) if at least one of 
> the matching rule enforce the Deny.
> Sue: An interesting strategy for top-down (management).  Is that what 
> you were doing?

------------
Aldo:
we support policies that can use DTP as resolution strategy, but we don't officially selected one resolution strategy. Every policy can use its own. Then we have an algorithm that exports policies in FMR (First Matching Rule) to connect with the real world, which in most of the cases uses FMR
------------

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

------------
Aldo:
yes, MSTP is the first level of decision (prefix length), then Administrative distance, then metrics (then, even if not specified officially, there should be some internal table order or priority to remove the last ambiguities).
This is another ad-hoc resolution strategy for routing.
------------

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

------------
Aldo:
I support the idea to have a different mount points for public info to be used by rules and their sub-entities (e.g., conditions, as in this case).
But for me, this mount point is a management aspect that is needed to dynamically build the conditions that will be actually evaluated. While the condition, the operations that can be used, and  wthe data that will evaluate in the packets/PDU remains the same.

>>>  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.
>
>> 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.
>>
> This is a lot of backhaul for a simple security device (iptables) for 
> more sophisticated devices, it may be the best way.

------------
Aldo:
I agree, for iptables you don't need to specify this structure, however in my opinion the policy model should be compliant with it.
------------

------------
Aldo:

------------
Aldo:

Thanks.

Regards,
Aldo

---

From: Aldo Basile <[email-masked]>
Date: Mon, 27 Jun 2016 13:47:43 +0200

Dear Frank,

thanks for positively reviewing my papers. I agree, we share a common 
vision o policies with some reconcilable differences. Moreover, I'm open 
to collaborate on the I2NSF capability layer security policy if you 
think some of the concepts in my papers can be useful.

More answers in-line...

> 1. I really like the definition of conflict resolution strategy of security policy in your papers, it should be part of the I2NSF capability layer security policy. We can work together on it;

Sure.

Thanks.

> 3. About the definition of "event", I think it's necessary. It's not simply another kind of "condition". It represents something happens, and that is either or not related with the flow/traffic tha…

I agree, an event is something that happens and triggers a process that 
must take a decision, in the end, one or more actions to perform/enforce.

In my view of the problem, also reflected in the SECURED model (which I 
don't want to propose, I just want to explain my way of abstracting the 
IETF PEP/PDP model and separating their functions), the event happens at 
the PEP.

When asking the PDP to take a decision, the PEP also passes stateful 
information that may also include data about the event that triggered 
the evaluation (which is just another kind of stateful information, like 
information about the successfully established connections for stateful 
firewalls).

If an NSF needs to react differently depending on the event that 
triggered the evaluation, the policy must contain rules with conditions 
that target the event information.And the policy model must contain 
conditions on events.In this sense, these conditions are normal 
conditions (set-based, or regex, or custom match, depending on on the 
actual function).

This model also covers the case of implicit events (like receiving a 
packet of reassembling a PDU) that do not need to be treated separately 
nor mentioned explicitly.

However, any ECA model should not be in contrast with that idea.

> 	1) they perform not only content checking, but also various actions on the objects (e.g., url, files, programs);

I agree with you. Indeed, in the model we use in SECURED, objects are 
just another kind of data, on which we state conditions, that refers to 
specific parts of the content. We have to find a more elegant way to 
represent it, though.

If you mean that in some cases, NSFs can also perform actions, these 
have been modelled as 'Rewriting Actions' (NATting, URL rewriting, 
dropping attachments from emails, etc.).

>     2) their specific implementations are different for every vendors and should not be aware of and programmed by the third party;

Agreed. 100%.

>     3) due to the complexity and differentiation of the other security capabilities for every vendors, they are considered and treated as an atomic function in our information model. The third party does not need to know its inner logic.
But for more fine-grain controlling of them, we can specify some general 
input/output parameters to customize their matches and actions in 
certain level. I think that's what you called "custom match".

Understood,atomic representation of vendor-specific features simplifies 
a lot the management and reduces the burden to third parties. However, 
this atomic approach poses limits on the high-level features and 
reasoning capabilities that can be added to the infrastructure.
Adding or ignoring the support for fine grained options depends on the 
I2NSF objectives.

In SECURED, we had to deal with policy refinement. A refinement process 
cannot work without (at least) a black-box modelling of the 
vendor-specific features.Otherwise, it does not understand how to use them.
In some cases, even the black-box modelling of vendor-specific features 
is insufficient, even if we didn't cope with these cases (mainly due to 
limited time and resources, SECURED will finish in a few months).

And yes, custom match conditions provide I/O parameters for a more 
fine-grained representation of conditions for refinement purposes.

However, "custom match" only covers conditions, for the actions we have 
the rewriting actions that can also be customized. But we didn't dig 
into them very much as we didn't have time and resources to also cover 
these cases. However, they are interesting for future research.

That is, the SECURED model still needs to be extended to cover these 
cases based on real use cases.But it is better (in my opinion) to do it 
under the bigger and more comprehensive umbrella of the I2NSF WG.

> 5. I also think Sue's data model capture our basic idea of what it should be, let's start with it and keep improving it parallel with the information model.

I also approve this approach.Sue's data model is already very detailed 
and contains already a lot of information about several protocols we 
were too lazy to try to collect.And in general, it does not conflict 
with the extension of the information model.

Regards,
Aldo

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 27 Jun 2016 12:19:51 +0000

Hi,

Just a comment on the black-box vendor capabilities. I have trimmed the text to improve readability.

On 27 Jun 2016, at 14:47 , Aldo Basile <[email-masked]<mailto:[email-masked]>> wrote:

   3) due to the complexity and differentiation of the other security capabilities for every vendors, they are considered and treated as an atomic function in our information model. The third party does not need to know its inner logic.
But for more fine-grain controlling of them, we can specify some general input/output parameters to customize their matches and actions in certain level. I think that's what you called "custom match".

Understood,atomic representation of vendor-specific features simplifies a lot the management and reduces the burden to third parties. However, this atomic approach poses limits on the high-level features and reasoning capabilities that can be added to the infrastructure.
Adding or ignoring the support for fine grained options depends on the I2NSF objectives.

In SECURED, we had to deal with policy refinement. A refinement process cannot work without (at least) a black-box modelling of the vendor-specific features.Otherwise, it does not understand how to use them.
In some cases, even the black-box modelling of vendor-specific features is insufficient, even if we didn't cope with these cases (mainly due to limited time and resources, SECURED will finish in a few months).

And yes, custom match conditions provide I/O parameters for a more fine-grained representation of conditions for refinement purposes.

However, "custom match" only covers conditions, for the actions we have the rewriting actions that can also be customized. But we didn't dig into them very much as we didn't have time and resources to also cover these cases. However, they are interesting for future research.

That is, the SECURED model still needs to be extended to cover these cases based on real use cases.But it is better (in my opinion) to do it under the bigger and more comprehensive umbrella of the I2NSF WG.

When we started talking about the I2NSF ideas, the concept of the atomic vendor capability somehow made uneasy, precisely because of the limitation they imply on the ability of the infrastructure to decide on what and how to do with this functions. I’d say the black-box modeling is the minimum we should require for any capability being registered by an NF. Capabilities not supporting at least this should be ignored by the controller.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 28 Jun 2016 03:16:12 +0000

Diego, I agree your point.

发件人: Diego R. Lopez [mailto:[email-masked]]
发送时间: 2016年6月27日 20:20
收件人: Aldo Basile
抄送: Xialiang (Frank); Susan Hares; [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D