Subject: Re: [I2nsf] comments on draft-basprez-i2nsf-capabilities-00

From: Aldo Basile <[email-masked]>
Date: Wed, 7 Sep 2016 14:07:20 +0200

Dear Daniel, Frank,

thanks for your comments and replies and sorry for the very late answer 
(I was in vacation). You can find my comments in-line (I also read Frank 
comments and your answers, I tried to incoroporate them here, to avoid a 
too nested email).

On 15/08/2016 15:52, Daniel Migault wrote:
> Hi,
>
> Please find my comments reading the document. In addition to these
> comments I have two questions regarding the policy model.
>
> The draft provide example for a policy where actions are "deny" or
> "allow". I am wondering if I2NSF considers also more complex actions and
> be a service such as "anti-dns-reflexion-attack" - or if there is a
> preferred way to do this?

The draft mainly presents examples with "deny" and "allow" because they 
are very simple and intelligible. However, it can address more 
sophisticated actions, as Frank pointed out.

The only caveat is that the 'condition part' must be carefully separated 
from the 'action part'. Actions can be elementary or not, provided they 
are clearly specified and action-only. However, I have never faced cases 
of very sophisticated actions, a model adaptation can be required to 
face new issues.

Following your example, if "anti-dns-reflection-attack" is only the set 
of operations to perform, yes, this can be an action. If if also 
includes the detection logic it is not correct to express it.
A quick and dirt try to model your scanario would be (maybe there are 
better ways)

if (event)
if (DNS_reflection_attack == true)
    then apply anti-dns-reflection-attack-action

where DNS_reflection_attack is some stateful info updated by some 
detection logic in the NSF.

>
> In addition, although the draft is describing policies, but is there any
> "future work" or intentions to model strategies. In other words, do we
> think that strategies will have their own structure or do we expect
> strategies being described vi the policies conditions?
>
> BR,
>
> Daniel
>
>
>
> 3.  Policy model
>    """
>    Moreover, it is known that packet
>    filter rules are prioritized and it is possible to specify a default
>    action.  More precisely, packet filters implement the First Matching
>    Rule (FMR) or Last Matching Rule (LMR) resolution strategies.
>    """
> My understanding  is that the document provides an abstract way to
> describe policies. It is not clear to me weather LMR or FMT are part of
> the policies themselves. I think what confuses me is that LMR or FMT are
> not part of policies, but instead related to how to interpret a "set of
> policies" in which case it would not be a parameter of a single policy.
> What is not clear to me is whether LMR FMT are part of the policies
> (implicit or explicit), or the implementation of the policies - that is
> given a set of policies, and the southbound NFS the implementation the
> controller uses one or the other.
>

The real advantage of the policy model behind the baspez proposal is 
that it includes the resolution strategy as a vital part of the policy.
The policy is telling the NSF, exactly, how to react on all the possible 
occurrences under its examination.

Every rule determines what to do in specific situations (= if event and 
condition then perform action).

The set of rules (probably you intended set of rules not set of 
policies) aggregates all the rules = the way to manage specific 
situations, however, only when the resolution strategy (and all the 
required data needed to make it work) and the default action are 
explicit it is possible to unequivocally determine the behaviour of the NSF.

The same rule set can be used with different resolution strategies and 
defualt actions, thus achieving a different behaviour, thus policy.

Another note: the resolution strategy is exactly the set of all the if 
statements that you defined 'conditions resolutions'.

If you wanted to compose set of policies, each of them being a 
completely specified behaviour of a NSF, then the problem is different, 
each one will have an internal resolution strategy, while the 
composition of actions from different policies would need to be composed 
with a reconciliation strategy.
I explained this idea in a paper 
(http://ieeexplore.ieee.org/document/7092779/?arnumber=7092779)

>    """
>    For instance, in Figure
>    Figure 1 the conditions are s1 [ S1 (read as s1 subset of S1) and s2
>    [ S2 (s1 subset of S2), both s1 and s2 match the packet x1, while
>    only s2 matches x2.
>    """
> The sentence needs some nits "Figure" is repeated and ther eis a "]"
> missing. I also find the notation confusing. From the text this is what
> I understand: s1 is a condition. On the other hand I also understand
> that s1 is the value of the selector that is testes against S1 the
> subset of accepatble values. It also seems to me that index for packets
> and those used for the selectors are different and so it may be better
> to use a different notation. I might by wrong but here is the text I
> would expect:
>
>    NEW TEXT:
>    """
>    A condition selector c(S, x.s) is met with packet x if the selector s
> from x is a subset of S.
>    For instance, in Figure 1 the multiselector condition is expressed as
> the intersection of  selector conditions c([IP_start, ..., IP_stop],
> x.ip_src) and c([port_start, ..., port_stop], x.port_dst).
>    """
>
>   Some nits should be corrected from the line above.
>
>      c = s1 X s2 X ...  X sm [ S1 \times S1 X S2 X ...  X Sm = S
>
> I also suggest that if you are using a specific notation with [] you
> explicitly provide the explanation of the notation. It seems you use the
> notation and then add text to clarify the use of it. I beleive this
> could be done once for all and have formal and informal description
> separated.
>
> In the text below, it is not clear to me how the use of chain can be
> used as how it could be added. Maybe some additional text could clarify
> this.
>
>    """
>    However, security controls may have specific characteristics that
>    automatic processes or administrators need to know when they have to
>    generate configurations, like the available resolution strategies and
>    the possibility to set default actions.  We have ignored, to simplify
>    this presentation, options to generate configurations that may have
>    better performance, like the use of chains or ad hoc structures
>    [Taylor].  However, security controls may have specific
> characteristics that
>    automatic processes or administrators need to know when they have to
>    generate configurations, like the available resolution strategies and
>    the possibility to set default actions.  We have ignored, to simplify
>    this presentation, options to generate configurations that may have
>    better performance, like the use of chains or ad hoc structures
>    [Taylor].  Adding support to these forms of optimization is certainly
>    feasible with a limited effort but it was outside the scope of this
>    paper, that is, to show that adding security awareness to NFV
>    management and orchestration features is possible.  It is one of the
>    task for future work.
>    """
>
>  section 4.1 time structure has not been defined.
>

I will address the last three points in the new version of the draft 
(the merged one I guess).

For the format of the formulas, thank you for your suggestion, I am 
sorry but my mind conceives formulas in Latex and just converting them 
in a txt-equivalent format may be confusing. I'll try with some inline 
C-style approach.

Regards,
Aldo