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 InterfaceFor 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, JohnOn 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
