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?
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.
"""
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.
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
