Subject: [I2nsf] how to derive a policy of "Deny traffic from HR destined to R&D" from "draft-xibassnez-i2nsf-capability"?

From: Linda Dunbar <[email-masked]>
Date: Mon, 17 Jul 2017 12:44:13 +0000

John,

Can you show an example of expressing the following rule/policy using “draft-xibassnez-i2nsf-capability”?

1.  “Deny traffic from HR destined to R&D” over Client facing interface;

2.  “Deny tcp traffic from 10.10.10.1/24, destined to 11.11.11.1/24” over NSF facing interface

Thanks, Linda

From: John Strassner [mailto:[email-masked]]
Sent: Monday, July 17, 2017 12:39 AM
To: Diego R. Lopez <[email-masked]>; John Strassner <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]; Aldo Basile <[email-masked]>
Subject: 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]> =
<mailto:[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
> Thanks, Linda
>=20
> -----Original Message-----
> From: Aldo Basile [mailto:[email-masked]<mailto:[email-masked]> =
<mailto:[email-masked]<mailto:[email-masked]>>]=20
> Sent: Thursday, July 06, 2017 5:22 PM
> To: Linda Dunbar <[email-masked]<mailto:[email-masked]> =
<mailto:[email-masked]<mailto:[email-masked]>>>; =
[email-masked]<mailto:[email-masked]> =
<mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> =
<mailto:[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=

> 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 "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
>> devices deployed, such as FW, may consists of multiple "Functions"?
>>=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]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
----------------------------------

--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]<mailto:[email-masked]>" =
class=3D"">[email-masked]<mailto:[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]<mailto:[email-masked]>" =
class=3D"">mailto:[email-masked]<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]<mailto:[email-masked]>" =
class=3D"">[email-masked]<mailto:[email-masked]></a>&gt;; <a =
href=3D"mailto:[email-masked]<mailto:[email-masked]>" =
class=3D"">[email-masked]<mailto:[email-masked]></a>; <a =
href=3D"mailto:[email-masked]<mailto:[email-masked]>" class=3D"">[email-masked]<mailto:[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]<mailto:[email-masked]>" =
class=3D"">[email-masked]<mailto:[email-masked]></a><br class=3D"">Tel: &nbsp; =
&nbsp;+34 913 129 041<tel:%2B34%20913%20129%20041><br class=3D"">Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091><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

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

--
regards,
John

---

From: Aldo Basile <[email-masked]>
Date: Mon, 17 Jul 2017 16:03:16 +0200

Dear Linda,

I'm adding a short explanation in-line, John will add further details, 
if needed.

On 17/07/2017 14:44, Linda Dunbar wrote:
> 1.“Deny traffic from HR destined to R&D” over Client facing interface;
> 
> 2.“Deny tcp traffic from 10.10.10.1/24, destined to 11.11.11.1/24” over 
> NSF facing interface

The capability model in “draft-xibassnez-i2nsf-capability” allows us to 
describe what the NSF can do.

Thus, you can describe that an NSF named PF1 is able to perform packet 
filtering by writing the 5-tuple capability description:

PF1 = (
  Ac = {Allow, Deny},
  Cc = {protocol type, source IP, destination IP, source IP , 
destination port},
  Ec = {},
  RSc = {FMR},
  Dc = {Allow, Deny}
)

Therefore, whatever is the interface and the entity in the NSF 
management workflow requiring the enforcement of a rule, you know that 
PF1 is able to enforce both rules, because:

- rule 1. (provided you have previously associated HR and R&D to IP ranges)

action: Deny [which is in the Ac set of PF1]
condition 1: source IP = IPRange(HR) [source IP is in Cc]
condition 2: destination IP = IPRange(R&D) [destination IP is in Cc]

- rule 2.
action: Deny [which is in the Ac set of PF1]
condition 1: source IP = 10.10.10.1/24 [source IP is in Cc]
condition 2: destination IP = 11.11.11.1/24 [destination IP is in Cc]
condition 3: protocol type = TCP [protocol type is in Cc]

The format for specifying these policies can be obtained (model-driven) 
from the capability model, thus the syntax is pretty inessential (at 
design time).

Additional details for a coherent policy specification:

1)
In rule 1. condition 1 and condition 2 are implicitly AND-ed, the same 
for conditions 1,2,3 in rule 2.
In the draft we ask you to comment about conditions in DNF and other 
condition 'composition' functions.

2)
in case of one rule may be optional, but you need to specify the 
resolution strategy (in this case FMR is the only one allowed in RSc)

3)
the default action needs to be specified (Allow or Deny are available)

Regards,
Aldo

> 
> Thanks, Linda
> 
> *From:*John Strassner [mailto:[email-masked]]
> *Sent:* Monday, July 17, 2017 12:39 AM
> *To:* Diego R. Lopez <[email-masked]>; John Strassner 
> <[email-masked]>
> *Cc:* Linda Dunbar <[email-masked]>; [email-masked]; 
> [email-masked]; Aldo Basile 
> <[email-masked]>
> *Subject:* Re: [I2nsf] Does "draft-xibassnez-i2nsf-capability" also 
> specify the information model to NSF?
> 
>     - MUST first be registered using the I2NSF Registration Interface 
> (before any other actions can take place)
> 
> 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] <mailto:[email-masked]>> wrote:
> 
> 
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >=20
>      > Aldo,=20
>      >=20
>     <mailto:[email-masked] <mailto:[email-masked]>>]=20
>     <mailto:[email-masked] <mailto:[email-masked]>>>; =
>     [email-masked]
>     <mailto:[email-masked]> =
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]> =
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     Tel: +34 913 129 041 <tel:%2B34%20913%20129%20041>
>     Mobile: +34 682 051 091 <tel:%2B34%20682%20051%20091>
>     class=3D"">[email-masked]
>     <mailto:[email-masked]></a>&gt; wrote:</div><br =
>     class=3D"">mailto:[email-masked]
>     <mailto:[email-masked]></a>] <br class=3D"">Sent: =
>     class=3D"">[email-masked]
>     <mailto:[email-masked]></a>&gt;; <a =
>     href=3D"mailto:[email-masked]
>     <mailto:[email-masked]>" =
>     class=3D"">[email-masked]
>     <mailto:[email-masked]></a>; <a =
>     href=3D"mailto:[email-masked] <mailto:[email-masked]>"
>     class=3D"">[email-masked] <mailto:[email-masked]></a><br =
>     class=3D"">[email-masked]
>     <mailto:[email-masked]></a><br class=3D"">Tel: &nbsp; =
>     &nbsp;+34 913 129 041 <tel:%2B34%20913%20129%20041><br
>     class=3D"">Mobile: +34 682 051 091 <tel:%2B34%20682%20051%20091><br =
>     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
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 17 Jul 2017 14:40:39 +0000

Aldo, 

Thank you so much for the concrete example. It would be very helpful to add an example section in the draft-xibassnez-i2nsf-capability, including the example you depicted here.  

Linda

-----Original Message-----
From: Aldo Basile [mailto:[email-masked]] 
Sent: Monday, July 17, 2017 4:03 PM
To: Linda Dunbar <[email-masked]>; John Strassner <[email-masked]>; Diego R. Lopez <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: how to derive a policy of "Deny traffic from HR destined to R&D" from "draft-xibassnez-i2nsf-capability"?

Dear Linda,

PF1 = (
  Ac = {Allow, Deny},

- rule 2.

1)

2)

3)

Regards,
Aldo