Hi, Thanks for the feed back. See inline my comments.
BR, Daniel On Wed, Aug 17, 2016 at 5:43 AM, Xialiang (Frank) <[email protected] > wrote: > Hi Daniel, > > Please see my comments inline: > > Thanks for your comments. > > > > > > *发件人:* I2nsf [mailto:[email protected]] *代表 *Daniel Migault > *发送时间:* 2016年8月15日 21:52 > *收件人:* [email protected] > *主题:* [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. > 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? > [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 ;-) > 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). > """ > > 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 > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
