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 protected]] Sent: Monday, July 17, 2017 4:03 PM To: Linda Dunbar <[email protected]>; John Strassner <[email protected]>; Diego R. Lopez <[email protected]> Cc: [email protected]; [email protected] Subject: Re: how to derive a policy of "Deny traffic from HR destined to R&D" from "draft-xibassnez-i2nsf-capability"? 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: > 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 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 protected]] > *Sent:* Monday, July 17, 2017 12:39 AM > *To:* Diego R. Lopez <[email protected]>; John Strassner > <[email protected]> > *Cc:* Linda Dunbar <[email protected]>; [email protected]; > [email protected]; Aldo Basile > <[email protected]> > *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 protected] <mailto:[email protected]>> 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 protected] > <mailto:[email protected]> = > <mailto:[email protected] <mailto:[email protected]>>> > 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 protected] > <mailto:[email protected]> = > <mailto:[email protected] <mailto:[email protected]>>]=20 > > Sent: Thursday, July 06, 2017 5:22 PM > > To: Linda Dunbar <[email protected] > <mailto:[email protected]> = > <mailto:[email protected] <mailto:[email protected]>>>; = > [email protected] > <mailto:[email protected]> = > <mailto:[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> = > <mailto:[email protected] <mailto:[email protected]>> > > 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 protected] > <mailto:[email protected]> > 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 > <<a = > href=3D"mailto:[email protected] > <mailto:[email protected]>" = > class=3D"">[email protected] > <mailto:[email protected]></a>> 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, = > 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 protected] > <mailto:[email protected]>" = > class=3D"">mailto:[email protected] > <mailto:[email protected]></a>] <br class=3D"">Sent: = > Thursday, July 06, 2017 5:22 PM<br class=3D"">To: Linda Dunbar <<a = > href=3D"mailto:[email protected] > <mailto:[email protected]>" = > class=3D"">[email protected] > <mailto:[email protected]></a>>; <a = > href=3D"mailto:[email protected] > <mailto:[email protected]>" = > class=3D"">[email protected] > <mailto:[email protected]></a>; <a = > href=3D"mailto:[email protected] <mailto:[email protected]>" > class=3D"">[email protected] <mailto:[email protected]></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' 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 protected] > <mailto:[email protected]>" = > class=3D"">[email protected] > <mailto:[email protected]></a><br class=3D"">Tel: = > +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 protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > -- > > regards, > > John > _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
