Re: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?
The concept of a Capability is INDEPENDENT of consumer or producer. Hence, a Capability: - MUST first be registered using the I2NSF Registration Interface (before any other actions can take place) - SHOULD be able to be requested over the I2NSF Client-Facing Interface - MUST be able to be invoked using the I2NSF NSF-Facing Interface For example, why couldn't a consumer say "I need a Foo Capability"? How else would they express that, if not over the I2NSF Client-Facing Interface? best regards, John On Sun, Jul 16, 2017 at 3:34 PM, Diego R. Lopez < diego.r.lo...@telefonica.com> wrote: > > --Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=utf-8 > > Hi Linda, > > As far as I can tell, both (and may be other interfaces as well): The = > available capabilities would be declared through the Registration = > Interface, and invoked through the NSF-facing one=E2=80=A6 > > Be goode, > > > On 8 Jul 2017, at 01:27 , Linda Dunbar <linda.dun...@huawei.com = > <mailto:linda.dun...@huawei.com>> wrote: > >=20 > > Aldo,=20 > >=20 > > 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? > >=20 > > Thanks, Linda > >=20 > > -Original Message- > > From: Aldo Basile [mailto:cataldo.bas...@polito.it = > <mailto:cataldo.bas...@polito.it>]=20 > > Sent: Thursday, July 06, 2017 5:22 PM > > To: Linda Dunbar <linda.dun...@huawei.com = > <mailto:linda.dun...@huawei.com>>; = > draft-xibassnez-i2nsf-capabil...@ietf.org = > <mailto:draft-xibassnez-i2nsf-capabil...@ietf.org>; i2nsf@ietf.org = > <mailto:i2nsf@ietf.org> > > Subject: Re: Does "draft-xibassnez-i2nsf-capability" also specify the = > information model to NSF? > >=20 > > Dear Linda, > >=20 > > as written in the abstract, the draft describes what a NSF can do in=20= > > > terms of (security) policy enforcement. > >=20 > > There are two aspects to consider to see the link between > capabilities=20= > > > and policies, which is very stressed in the draft. > >=20 > > One is the analysis. > > Security experts, admins, etc. understand what a NSF can do by = > analysing=20 > > 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=20 > > + a set of properties to define the ambiguous situations (default = > action=20 > > or multiple matching rules); > > 2) implicitly enabled with some high-level function (e.g., a checkbox=20= > > > 'enable anti-virus'). > > We have built the model based on the analysis of tens of security=20 > > controls, by categorizing and giving semantics to the different > policy=20= > > > language fields, constraints, properties, etc. > >=20 > > Then there is the synthesis (and validation). > > Knowing the capability associated to a NSF we also know the kind of=20 > > policies we can specify on that NSF. That is, the capability > describes=20= > > > the potentiality of a NSF, which will be exploited in a specific = > policy=20 > > (model driven?). > > The draft proposes examples that prove that the capability model can=20= > > > describe real security controls. > >=20 > > Indeed, capabilities and policies are two aspects of the same thing. > >=20 > > As written in the draft, (and presented by John at the last I2NSF=20 > > meeting), there are more elegant ways to describe capabilities that > do=20= > > > not require subclassing and complex class hierarchy. These models are=20= > > > more abstract but the capability-policy dichotomy is more evident.=20 > > However, we preferred to have a very concrete initial model. > >=20 > > Then, 'packet 'filter is a generic label for devices that have the=20 > > capability to filter packets based on IP, ports, and protocol ID (and=20= > > > will actually filter something based on a policy composed of rules = > with=20 > > conditions on these fields). > > 'proto !=3D tcp' is a valid condition for a NSF owning the capability = > to=20 > > use conditions on the protocol ID field. > >=20 > > Finally, with this very granular model of capabilities, there is not=20= > > > need to specify when a NSF owns more functions, as they will be all=20 > > summarized by its capability. > >=20 > >=20 &
Re: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?
--Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Linda, As far as I can tell, both (and may be other interfaces as well): The = available capabilities would be declared through the Registration = Interface, and invoked through the NSF-facing one=E2=80=A6 Be goode, > On 8 Jul 2017, at 01:27 , Linda Dunbar <linda.dun...@huawei.com = <mailto:linda.dun...@huawei.com>> wrote: >=20 > Aldo,=20 >=20 > 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? >=20 > Thanks, Linda >=20 > -Original Message- > From: Aldo Basile [mailto:cataldo.bas...@polito.it = <mailto:cataldo.bas...@polito.it>]=20 > Sent: Thursday, July 06, 2017 5:22 PM > To: Linda Dunbar <linda.dun...@huawei.com = <mailto:linda.dun...@huawei.com>>; = draft-xibassnez-i2nsf-capabil...@ietf.org = <mailto:draft-xibassnez-i2nsf-capabil...@ietf.org>; i2nsf@ietf.org = <mailto:i2nsf@ietf.org> > Subject: Re: Does "draft-xibassnez-i2nsf-capability" also specify the = information model to NSF? >=20 > Dear Linda, >=20 > as written in the abstract, the draft describes what a NSF can do in=20= > terms of (security) policy enforcement. >=20 > There are two aspects to consider to see the link between capabilities=20= > and policies, which is very stressed in the draft. >=20 > One is the analysis. > Security experts, admins, etc. understand what a NSF can do by = analysing=20 > 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=20 > + a set of properties to define the ambiguous situations (default = action=20 > or multiple matching rules); > 2) implicitly enabled with some high-level function (e.g., a checkbox=20= > 'enable anti-virus'). > We have built the model based on the analysis of tens of security=20 > controls, by categorizing and giving semantics to the different policy=20= > language fields, constraints, properties, etc. >=20 > Then there is the synthesis (and validation). > Knowing the capability associated to a NSF we also know the kind of=20 > policies we can specify on that NSF. That is, the capability describes=20= > the potentiality of a NSF, which will be exploited in a specific = policy=20 > (model driven?). > The draft proposes examples that prove that the capability model can=20= > describe real security controls. >=20 > Indeed, capabilities and policies are two aspects of the same thing. >=20 > As written in the draft, (and presented by John at the last I2NSF=20 > meeting), there are more elegant ways to describe capabilities that do=20= > not require subclassing and complex class hierarchy. These models are=20= > more abstract but the capability-policy dichotomy is more evident.=20 > However, we preferred to have a very concrete initial model. >=20 > Then, 'packet 'filter is a generic label for devices that have the=20 > capability to filter packets based on IP, ports, and protocol ID (and=20= > will actually filter something based on a policy composed of rules = with=20 > conditions on these fields). > 'proto !=3D tcp' is a valid condition for a NSF owning the capability = to=20 > use conditions on the protocol ID field. >=20 > Finally, with this very granular model of capabilities, there is not=20= > need to specify when a NSF owns more functions, as they will be all=20 > summarized by its capability. >=20 >=20 > Hope this long explanation clarifies a bit the purpose of the draft = and=20 > why several sections were devoted to describing policies and policy = rules. >=20 >=20 > Regards, > Aldo >=20 > Thank you very much for posting the revised >> draft-xibassnez-i2nsf-capability-02.The draft provides a very=20 >> comprehensive description on how to construct rules (or security=20 >> policies) to NSFs. >>=20 >> The Abstract stated: >>=20 >> /"This document defines the concept of an NSF (Network Security/ >>=20 >> /Function) Capability, as well as its information model. = Capabilities/ >>=20 >> /are a set of features that are available from a managed entity, and/ >>=20 >> /are represented as data that unambiguously characterizes an NSF./ >>=20 >> But most of the sections of the draft focuses on how to construct=20 >> security rules to NSFs. >>=20 >> Intuitively, "packet filters" or the depth of the packet header used = in=20 >> "conditions" that a NSF can handle would be a
Re: [I2nsf] 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"? smime.p7s Description: S/MIME Cryptographic Signature ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
