Aldo, Thank you very much for the explanation. I just want to confirm if the information models specified by the draft-xibassnez-i2nsf-capability are intended for NSF facing interface, the Registration facing interface, or both?
Thanks, Linda -----Original Message----- From: Aldo Basile [mailto:[email protected]] Sent: Thursday, July 06, 2017 5:22 PM To: Linda Dunbar <[email protected]>; [email protected]; [email protected] Subject: Re: Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF? Dear Linda, as written in the abstract, the draft describes what a NSF can do in terms of (security) policy enforcement. There are two aspects to consider to see the link between capabilities and policies, which is very stressed in the draft. One is the analysis. Security experts, admins, etc. understand what a NSF can do by analysing its (security policy) language. That is, a NSF can do what can be: 1) explicitly configured with a policy composed of a set of policy rules + a set of properties to define the ambiguous situations (default action or multiple matching rules); 2) implicitly enabled with some high-level function (e.g., a checkbox 'enable anti-virus'). We have built the model based on the analysis of tens of security controls, by categorizing and giving semantics to the different policy language fields, constraints, properties, etc. Then there is the synthesis (and validation). Knowing the capability associated to a NSF we also know the kind of policies we can specify on that NSF. That is, the capability describes the potentiality of a NSF, which will be exploited in a specific policy (model driven?). The draft proposes examples that prove that the capability model can describe real security controls. Indeed, capabilities and policies are two aspects of the same thing. As written in the draft, (and presented by John at the last I2NSF meeting), there are more elegant ways to describe capabilities that do not require subclassing and complex class hierarchy. These models are more abstract but the capability-policy dichotomy is more evident. However, we preferred to have a very concrete initial model. Then, 'packet 'filter is a generic label for devices that have the capability to filter packets based on IP, ports, and protocol ID (and will actually filter something based on a policy composed of rules with conditions on these fields). 'proto != tcp' is a valid condition for a NSF owning the capability to use conditions on the protocol ID field. Finally, with this very granular model of capabilities, there is not need to specify when a NSF owns more functions, as they will be all summarized by its capability. Hope this long explanation clarifies a bit the purpose of the draft and why several sections were devoted to describing policies and policy rules. Regards, Aldo Thank you very much for posting the revised > draft-xibassnez-i2nsf-capability-02.The draft provides a very > comprehensive description on how to construct rules (or security > policies) to NSFs. > > The Abstract stated: > > /"This document defines the concept of an NSF (Network Security/ > > /Function) Capability, as well as its information model. Capabilities/ > > /are a set of features that are available from a managed entity, and/ > > /are represented as data that unambiguously characterizes an NSF./ > > But most of the sections of the draft focuses on how to construct > security rules to NSFs. > > Intuitively, "packet filters" or the depth of the packet header used in > "conditions" that a NSF can handle would be a "capability". And "proto > != tcp" would be a concrete condition for a security rules. > > Can you explain how to draw the link from the draft's abstract to the > sections in the draft? > > Thank you very much. > > Linda > > p.s. is it appropriate to add a note stating that conventional security > devices deployed, such as FW, may consists of multiple "Functions"? > _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
