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-actionwhere 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
