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

From: Daniel Migault <[email-masked]>
Date: Mon, 15 Aug 2016 09:52:00 -0400

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.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 17 Aug 2016 09:43:48 +0000

Hi Daniel,
Please see my comments inline:
Thanks for your comments.

发件人: I2nsf [mailto:[email-masked]] 代表 Daniel Migault
发送时间: 2016年8月15日 21:52
收件人: [email-masked]
主题: [I2nsf] comments on draft-basprez-i2nsf-capabilities-00

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?
[Frank]: right now, for I2NSF capability interface, various actions are supported, i.e., allow, deny, call a function, redirect, send notification, URL, etc, and it is not exhausted and can be added as individual value to action attribute any time. For your suggestion, I think it makes sense. But I suggest to define this kind of service actions for the service interface (customer-facing interface), since they are more appropriate to be used for this interface.
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?
[Frank]: what exactly do you mean for strategies here? Are they like the condition resolution strategies below? Or other examples?
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.
[Frank]: Firstly, I support that I2NSF policy should include the condition resolution strategies since the requirement is solid and it is indeed useful. In other, this strategy is part of the i2nsf policy. Secondly, I don’t get what is your real concern. For example, what is the difference between implicit or explicit way? Could you clarify more?

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

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.

   """
   [Taylor].  However, security controls may have specific characteristics that

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Aug 2016 10:42:36 -0400

Hi,

Thanks for the feed back. See inline my comments.

BR,
Daniel

On Wed, Aug 17, 2016 at 5:43 AM, Xialiang (Frank) <[email-masked]
> wrote:

> *发件人:* I2nsf [mailto:[email-masked]] *代表 *Daniel Migault
> *发送时间:* 2016年8月15日 21:52
> *收件人:* [email-masked]
> *主题:* [I2nsf] comments on draft-basprez-i2nsf-capabilities-00
>
>
>
> 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?
>
> [Frank]: right now, for I2NSF capability interface, various actions are
> supported, i.e., allow, deny, call a function, redirect, send notification,
> URL, etc, and it is not exhausted and can be added as individual value to
> action attribute any time. For your suggestion, I think it makes sense. But
> I suggest to define this kind of service actions for the service interface
> (customer-facing interface), since they are more appropriate to be used for
> this interface.
>

  [MGLT] If I understand correctly, the action can be extended. Currently
there are more actions defined than deny, allow. However, your
recommendation would be to consider that the service will be implemented at
customer interface, and then translated into the currently defined actions.
In other words, the idea is to keep action as elementary as possible.

> [Frank]: what exactly do you mean for strategies here? Are they like the
> condition resolution strategies below? Or other examples?
>
[MGLT] So first you are right strategies can mostly be achieved with
conditions resolutions. Grouping policies into Sets of policies maybe
useful, but I guess that is an implementation matter. However, there are
some "conditions" that looks to me hard to deploy at the policy level and
that only make sense within a set of rules. For example, when policies are
not independent, an order may be specified. As some implementations do not
necessarily interpret the policies in the same order, it would maybe make
sense to specify if the set of policies should be interpreted in one order
or the other. This is the only example I had in mind but I am not sure
there is no other "conditions" that could only make sense to a set of
policies. If that is not a problem I am fine too ;-)

> 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.
>
> [Frank]: Firstly, I support that I2NSF policy should include the condition
> resolution strategies since the requirement is solid and it is indeed
> useful. In other, this strategy is part of the i2nsf policy. Secondly, I
> don’t get what is your real concern. For example, what is the difference
> between implicit or explicit way? Could you clarify more?
>
>
>
>    """
>    For instance, in Figure
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>