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

[Aldo Basile <[e-mail]>]

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


On 16/06/2016 04:06, Susan Hares wrote:
> 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.


------------
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
>
> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Wednesday, June 15, 2016 10:02 PM
> To: 'Aldo Basile'; 'DIEGO LOPEZ GARCIA'
> Cc: '[e-mail]'; '[e-mail]'; 'Linda Dunbar'
> Subject: RE: [I2nsf] Help on turning I2NSF Information Models to Data Models
>
> Aldo:
>
> I'm going to answer in summary, and then with "sue:" in the text below.  On,
> hares-i2rs-pkt-eca-policy - I agree it is missing
>
> -----Original Message-----
> From: I2nsf [mailto:[e-mail]] On Behalf Of Aldo Basile
> Sent: Friday, June 10, 2016 6:46 AM
> To: Susan Hares; 'DIEGO LOPEZ GARCIA'
> Cc: [e-mail]; [e-mail]; 'Linda Dunbar'
> Subject: Re: [I2nsf] Help on turning I2NSF Information Models to Data Models
>
> Dear Susan,
>
> more comments in-line...
>
>
>
> On 09/06/2016 21:30, Susan Hares wrote:
>>> Alod:
>>>
>>> The minor changes to getting IPTable deployments are why I started
>>> this thread.
>>>
>>> On 1)  I turned the packet matching into a ordered list where a match
>>> causes the processing to stop.  Your action_to_enforce <--
>>> Resolution{Rx,Ry,Rt,...}.   You can see some of the ideas in my I2RS
> draft
>>> (draft-hares-i2rs-pkt-eca-policy), but it needed changes for I2RS and for
>>> the policy.   The draft-hares-i2rs-fb-rib-data-model shows how you can
> use
>>> this policy on specific interfaces, and have a default RIB for things
>>> which do not match.  I am interested to discuss your ideas on the
>>> more complex policy model.
>
>> I have checked your draft, I see that you can easily model iptables
>> rules. I also noticed that you mapped an incredibly high number of
>> conditions on the
>  > most important (if not all) protocols at the first four ISO layers.
> Excellent work that we may want to reuse.
>
> Thank you.
>
>> Compared to our model, there is a missing information: the condition
>> matching algorithm, i.e., the types of operations allowed when
>> specifying a >condition on a given field. That is, when you express
> conditions on IP Protocol Type field you specify a list of values and don't
> need to use ranges (= set based), for source or dest ports you may want to
> use  inequalities or ranges (= range based) and for IP source and dest you
> may want to use prefixes (= prefix based ~ range based).
>> For URLs and other upper protocol conditions on strings you may want to
>> use string match (like squid dstdomain acl) or regex match  (like squid
> url_regex acl).
>
> Sue: I agree.  I am waiting for the WG LC to be completed to release a
> version with more matching conditions.  However, I'd be very interested in
> yours.
>

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

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

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


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

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


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

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

>
>> Note that not all the device use prioritized rules (= list of rules) to
> make decisions. A simple example: the ipsec tools use the {Default, Use,
> Require, >Unique} attributes that slightly change the ordered list
> behavious. Therefore, the concept of resolution strategy needs to be
> explicitly reported in a data >model (in my opinion).
>
> Yes - the resolution strategy does need to  indicate whether it is ordered
> or "all rules match", or something else
>
> If you are interested in my policy model, a more detailed (and formal
> definition) description of resolution strategies and the policy model for
> our work on capabilities can be found here:
>
> (for packet filters)
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6111329
>
> (extension on application filters)
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6690252
>
> Could you send me a copy via email (outside the mail list) with this
> documents. I cannot get access.
>
>>>
>>> On 2) My packet filters can be expanded to include application
>>> filters or we can create a another grouping of filters.
>
>> I agree it is a very easy step in your model.
>
> Thank you for your input.
>
>>
>> On 3) security controls in network security control I agree that the
>> matching is complex or the actions are complex.  In many
>> cases, these actions are specific to a vendor.   However, let's start with
>> simple URL filtering as an example.  I assumed that the URL Filtering
>> was point to a URL Filtering list.  There could be public lists or vendor
>> generated lists.   Therefore in high level yang, the first part of the
> i2NSF
>> Security content might be:
>>
>> Module -i2nsf-sec-content
>>     +--rw i2nsf-sec-content-cap* [order-id rule]
>>      +--rw order-id
>>      +--rw rule-name
>>      +--rw anti-virus
>>      |  +--rw public-anti-virus* [name]
>>      | ....
>>      |  +--rw vendor-anti-virus* [vendor]
>>      |  ....
>>      +--rw IPS
>>      |  +--rw snort-rules* [date]
>>      |  | ...
>>      |  +--rw vendor-IPS-rule* [Vendor]
>>      |  | ...
>>      +--rw URL Filtering
>>      |  +--rw public-url* [name]
>>      |  | ...
>>      |  +--rw vendor-url*[vendor]
>>      |  | ....
>>
>> I think this matches your work.   However, I think the results of the
> filter
>> process can be match or not.  The question is once you match, what do
>> you do?
>
> Aldo's comments:
>> If I understand correctly, you implicitly assume an action when using URL
> filters.
>> For me, URL filtering is just a condition of regex/string based type.
>> If (the URL in the PDU under examination matches some_URL_strings) then
> return TRUE.
>
> Sue: Agreed
>
>>> some_URL_strings can be either manually written by the policy editor or
> obtained by some vendor or public source of URLs.
>
>> Then this condition on URLs can be mixed with other conditions to form
> other rules.
>> if (URLcondition) ^ (other conditions) Then ACTION You can see a
>> simple example of what I'm describing in squid
>>
>> acl goodurl url_regex myurl1 myurl2 myurl3 acl goodip dst 1.1.1.1
>>
>> http_access allow goodurl goodip
>> If the list {myurl1 myurl2 myurl3 } is downloaded from a site, the matching
> does not change, the way to retrieve the data of course changes.
>>> I follow the same approach (i.e., I model them as conditions) also for for
> snort rules, VendorIPS rules etc.
>
> This was  my assumption in my code.   The reason I had two places was to
> allow the user a mount point for the public rules (e.g. snort filters from a
> public site), and vendor developed (from IDS/IPS).  I am missing your point,
> but I have not read your documents yet.


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

>>>
>>> The packet eca actions can have many types
>>>   |        +--rw eca-actions
>>>  |        |  +--rw eca-ingress-act*
>>>   |        |  | ... (permit, deny, mirror)
>>>   |        +  +--rw eca-fwd-actions*
>>>   |        | ...  (invoke, tunnel encap, fwd, drop)
>>>   |        |  +--rw eca-egress-act*
>>>   |        |  |   (rate limit output,..)
>>>   |        |  +--rw eca-qos-actions*
>>>   |        |  | .. (set bits in packet
>>>   |        +  +--rw eca-security-actions*
>>>   |        |    uses i2nsf-sec-content-cap
>>>
>>>  I was starting to work on these complex set of actions when I felt I
>>> needed to make sure I was on the right track.
>
>> I agree on these action types, I have considered all of them in my model.
>
>> To the URL filter example before, for me, the eca-fwd-actions drop is
>> the one that it is actually applied for blacklists of URL and fwd
>> (~allow/accept) is the one in case of white lists.
>
>> Hope this has clarified my idea on the complex actions that I saw in
>> the  Capabilities draft.
>
> Yes I has clarified our work.
>
>>
>> 4) PDP and PEP is a valuable concept.   I think that ordered lists of
>> packet-based ECA policy is simply a means for the PDP to send the PEP a
>> specific set of ordered filters.   Similarly, the exchange of capabilities
>> is simply the  I2NSF sending the NSF its capabilities as ordered rules.
>>
>> +--rw i2nsf-policy-list
>>    +--rw policy-list-name string
>>    +--rw policy-rule [name]
>>        +--rw name  string
>>        +--rw net-sec-ctl-rules*
>>           uses ietf-pkt-eca-policy-cfg
>>        +--rw net-sec-content
>>           uses i2nsf-content-rules*
>>        +--rw net-attack-mitigate*
>>             uses i2nsf-mitigate-rules
>>
>> Have I misunderstood previous conversations on this topic?
>
>> Yes, you interpreted correctly my idea of events. However, in our model
>> we see in a slightly different way the PDP-PEP exchanges and capability
>> interfaces.
>>
>> The PEP sends the PDP the stateful info (i.e., the context) together
>> with the flow/packet/PDU data to evaluate (note that some additional
>> info can be obtained from a PIP, but this is a minor detail).
>> This context info also contains the events that triggered the
>> evaluation from the PEP.
>
> This is a lot of backhaul for a simple security device (iptables) for more
> sophisticated devices, it may be the best way.

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


>
>> The PDP looks into the Policy in the PolicyDB, checks matching rules
>> and decides actions (some of these rules will contain conditions on the
>> events), then the PDP sends the PEP the action (+ provisional data).
>> [maybe it is not 100% compliant with IETF but just for lack of room,
>> it's already a long email.]
>
> I understand the concept.  It is the original PDP/PEP work.
> Is there a benefit in this for security work that I am missing?

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

>
>> In a SECURED-equivalent approach, the I2NSF controller knows (from a
>> repository) or asks the NSF its capabilities (through an API),
>> capabilities that include the list the actions that can enforce, the
>> conditions that allow to determine the traffic on which enforce
>> actions, plus all the other info needed to build a valid configuration
>> for that device.
>> Then the SECURED infrastructure uses this info to derive a
>> configuration for the NSF (i.e., a policy composed of rules for the
>> specific NSF), based on high-level policies (i.e., vendor- NSF-agnostic
>> security requirements).
>
> Sue: This is a reasonable approach, the only problem is how much "backhaul"
> of data needs to be done.  In modern switches fabrics, You can get a lot of
> logic done on site.  (Age-old trade off: tunnel to process or process on
> edge of network)

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


>
>> That is, the policy is built on the NSF capabilities (capabilities that
>> describe what an NSF can do if the infrastructure wants to use it for
>> enforcing security policies) but it is not a capability.
>
> Hope I am not cryptic and boring with these long emails...
>
> Not cryptic and I really appreciate your long email.

Thanks.

Regards,
Aldo