Subject: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Jul 2017 23:21:31 +0000

Frank, John, Aldo, and Diego

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"?

---

From: Aldo Basile <[email-masked]>
Date: Fri, 7 Jul 2017 00:22:28 +0200

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./
> 
> 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"?
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Jul 2017 23:27:15 +0000

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-masked]] 
Sent: Thursday, July 06, 2017 5:22 PM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?

Dear Linda,

One is the analysis.

Regards,
Aldo

> /"This document defines the concept of an NSF (Network Security/
> 
> "conditions" that a NSF can handle would be a "capability". And "proto 
> != tcp" would be a concrete condition for a security rules.
>

---

From: John Strassner <[email-masked]>
Date: Fri, 7 Jul 2017 23:47:23 +0000

Hi Linda,

The information model does NOT model any of the interfaces. It models policy rules and capabilities.
The policy rules and capabilities can both be used by Consumers and Producers. Hence, the Policies and Capabilities will be communicated over the Consumer-Facing Interface AND the NSF-Facing Interface.
The Registration Interface is used to Register Capabilities.

That being said, I do not think that the working group has decided what types of models are sent over which interfaces. IMHO, information and data models for Policies and Capabilities should be able to use both the Consumer-Facing and NSF-Facing Interfaces. This is because I2NSF components should be able to exchange design-time information as well as run-time objects over those interfaces. However, I think that only objects (i.e., data models) of Policies and Capabilities should be able to be registered.

Regards,
John 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 07, 2017 4:27 PM
To: Aldo Basile <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also specify the information model to NSF?

Aldo, 

Thanks, Linda

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]]
Sent: Thursday, July 06, 2017 5:22 PM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
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.

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

> devices deployed, such as FW, may consists of multiple "Functions"?

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 16 Jul 2017 22:34:44 +0000

--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 <[email-masked] =
<mailto:[email-masked]>> 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
>=20
> From: Aldo Basile [mailto:[email-masked] =
<mailto:[email-masked]>]=20
> To: Linda Dunbar <[email-masked] =
<mailto:[email-masked]>>; =
[email-masked] =
<mailto:[email-masked]>; [email-masked] =
<mailto:[email-masked]>
> 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=

>=20
> There are two aspects to consider to see the link between capabilities=20=

>=20
> Security experts, admins, etc. understand what a NSF can do by =
analysing=20
> 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
> 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=

>=20
> 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=

>=20
>=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
>=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
> 'proto !=3D tcp'  is a valid condition for a NSF owning the capability =
to=20
>=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
>=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
>=20
>> 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
>>=20
>> /Function) Capability, as well as its information model. =
Capabilities/
>>=20
>>=20
>>=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 "capability". And =
"proto=20
>> !=3D tcp" would be a concrete condition for a security rules.
>>=20
>> Can you explain how to draw the link from the draft's abstract to the=20=

>> sections in the draft?
>>=20
>> Thank you very much.
>>=20
>> Linda
>>=20
>> p.s. is it appropriate to add a note stating that conventional =
security=20
>>=20
>=20
>=20

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/ <http://people.tid.es/diego.lopez/>

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

--Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi Linda,<div class=3D""><br class=3D""></div><div =
class=3D"">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<di=
v class=3D""><br class=3D""></div><div class=3D"">Be goode,</div><div =
class=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On 8 Jul 2017, at 01:27 , Linda Dunbar &lt;<a =
href=3D"mailto:[email-masked]" =
class=3D"">[email-masked]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">Aldo, <br =
class=3D""><br class=3D"">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, =
&nbsp;the Registration facing interface, or both?<br class=3D""><br =
class=3D"">Thanks, Linda<br class=3D""><br class=3D"">-----Original =
Message-----<br class=3D"">From: Aldo Basile [<a =
href=3D"mailto:[email-masked]" =
class=3D"">mailto:[email-masked]</a>] <br class=3D"">Sent: =
Thursday, July 06, 2017 5:22 PM<br class=3D"">To: Linda Dunbar &lt;<a =
href=3D"mailto:[email-masked]" =
class=3D"">[email-masked]</a>&gt;; <a =
href=3D"mailto:[email-masked]" =
class=3D"">[email-masked]</a>; <a =
href=3D"mailto:[email-masked]" class=3D"">[email-masked]</a><br =
class=3D"">Subject: Re: Does "draft-xibassnez-i2nsf-capability" also =
specify the information model to NSF?<br class=3D""><br class=3D"">Dear =
Linda,<br class=3D""><br class=3D"">as written in the abstract, the =
draft describes what a NSF can do in <br class=3D"">terms of (security) =
policy enforcement.<br class=3D""><br class=3D"">There are two aspects =
to consider to see the link between capabilities <br class=3D"">and =
policies, which is very stressed in the draft.<br class=3D""><br =
class=3D"">One is the analysis.<br class=3D"">Security experts, admins, =
etc. understand what a NSF can do by analysing <br class=3D"">its =
(security policy) language.<br class=3D"">That is, a NSF can do what can =
be:<br class=3D"">1) explicitly configured with a policy composed of a =
set of policy rules <br class=3D"">+ a set of properties to define the =
ambiguous situations (default action <br class=3D"">or multiple matching =
rules);<br class=3D"">2) implicitly enabled with some high-level =
function (e.g., a checkbox <br class=3D"">'enable anti-virus').<br =
class=3D"">We have built the model based on the analysis of tens of =
security <br class=3D"">controls, by categorizing and giving semantics =
to the different policy <br class=3D"">language fields, constraints, =
properties, etc.<br class=3D""><br class=3D"">Then there is the =
synthesis (and validation).<br class=3D"">Knowing the capability =
associated to a NSF we also know the kind of <br class=3D"">policies we =
can specify on that NSF. That is, the capability describes <br =
class=3D"">the potentiality of a NSF, which will be exploited in a =
specific policy <br class=3D"">(model driven?).<br class=3D"">The draft =
proposes examples that prove that the capability model can <br =
class=3D"">describe real security controls.<br class=3D""><br =
class=3D"">Indeed, capabilities and policies are two aspects of the same =
thing.<br class=3D""><br class=3D"">As written in the draft, (and =
presented by John at the last I2NSF <br class=3D"">meeting), there are =
more elegant ways to describe capabilities that do <br class=3D"">not =
require subclassing and complex class hierarchy. These models are <br =
class=3D"">more abstract but the capability-policy dichotomy is more =
evident. <br class=3D"">However, we preferred to have a very concrete =
initial model.<br class=3D""><br class=3D"">Then, 'packet 'filter is a =
generic label for devices that have the <br class=3D"">capability to =
filter packets based on IP, ports, and protocol ID (and <br =
class=3D"">will actually filter something based on a policy composed of =
rules with <br class=3D"">conditions on these fields).<br =
class=3D"">'proto !=3D tcp' &nbsp;is a valid condition for a NSF owning =
the capability to <br class=3D"">use conditions on the protocol ID =
field.<br class=3D""><br class=3D"">Finally, with this very granular =
model of capabilities, there is not <br class=3D"">need to specify when =
a NSF owns more functions, as they will be all <br class=3D"">summarized =
by its capability.<br class=3D""><br class=3D""><br class=3D"">Hope this =
long explanation clarifies a bit the purpose of the draft and <br =
class=3D"">why several sections were devoted to describing policies and =
policy rules.<br class=3D""><br class=3D""><br class=3D"">Regards,<br =
class=3D"">Aldo<br class=3D""><br class=3D"">Thank you very much for =
posting the revised<br class=3D""><blockquote type=3D"cite" =
class=3D"">draft-xibassnez-i2nsf-capability-02.The draft provides a very =
<br class=3D"">comprehensive description on how to construct rules (or =
security <br class=3D"">policies) to NSFs.<br class=3D""><br =
class=3D"">The Abstract stated:<br class=3D""><br class=3D"">/"This =
document defines the concept of an NSF (Network Security/<br =
class=3D""><br class=3D"">/Function) Capability, as well as its =
information model. Capabilities/<br class=3D""><br class=3D"">/are a set =
of features that are available from a managed entity, and/<br =
class=3D""><br class=3D"">/are represented as data that unambiguously =
characterizes an NSF./<br class=3D""><br class=3D"">But most of the =
sections of the draft focuses on how to construct <br class=3D"">security =
rules to NSFs.<br class=3D""><br class=3D"">Intuitively, "packet =
filters" or the depth of the packet header used in <br =
class=3D"">"conditions" that a NSF can handle would be a "capability". =
And "proto <br class=3D"">!=3D tcp" would be a concrete condition for a =
security rules.<br class=3D""><br class=3D"">Can you explain how to draw =
the link from the draft's abstract to the <br class=3D"">sections in the =
draft?<br class=3D""><br class=3D"">Thank you very much.<br class=3D""><br=
 class=3D"">Linda<br class=3D""><br class=3D"">p.s. is it appropriate to =
add a note stating that conventional security <br class=3D"">devices =
deployed, such as FW, may consists of multiple "Functions"?<br =
class=3D""><br class=3D""></blockquote><br class=3D""><br =
class=3D""></div></blockquote></div><br class=3D""><div =
apple-content-edited=3D"true" class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">--<br class=3D"">"Esta vez no fallaremos, Doctor Infierno"<br =
class=3D""><br class=3D"">Dr Diego R. Lopez<br class=3D"">Telefonica =
I+D<br class=3D""><a href=3D"http://people.tid.es/diego.lopez/" =
class=3D"">http://people.tid.es/diego.lopez/</a><br class=3D""><br =
class=3D"">e-mail: <a href=3D"mailto:[email-masked]" =
class=3D"">[email-masked]</a><br class=3D"">Tel: &nbsp; =
&nbsp;+34 913 129 041<br class=3D"">Mobile: +34 682 051 091<br =
class=3D"">----------------------------------</div>

</div>
<br class=3D""></div></div></body></html>=

--Apple-Mail=_C3B9062D-559E-4C84-BCC3-0B49169B81F1--

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: John Strassner <[email-masked]>
Date: Sun, 16 Jul 2017 15:39:20 -0700

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 <
[email-masked]> wrote:

> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

-- 
regards,
John