[I2nsf] Fwd: New Version Notification for draft-kumar-i2nsf-client-facing-interface-im-03.txt

[Rakesh Kumar]

Updated the information model to align with the requirement draft
identified in draft-ietf-i2nsf-client-facing-interface-req. I missed the
deadline to upload last week.

Thanks
Rakesh

-- Forwarded message --
From: 
Date: Sun, Jul 16, 2017 at 10:23 PM
Subject: New Version Notification for draft-kumar-i2nsf-client-
facing-interface-im-03.txt
To: Dave Qi , Rakesh Kumar ,
Senad Palislamovic , Liang Xia <
frank.xiali...@huawei.com>, Anil Lohiya , Dave Qi <
d...@bloomberg.net>, Nabil Bitar , Liang Xia <
frank.xiali...@huawei.com>



A new version of I-D, draft-kumar-i2nsf-client-facing-interface-im-03.txt
has been successfully submitted by Rakesh Kumar and posted to the
IETF repository.

Name:   draft-kumar-i2nsf-client-facing-interface-im
Revision:   03
Title:  Information model for Client-Facing Interface to Security
Controller
Document date:  2017-07-16
Group:  Individual Submission
Pages:  18
URL:https://www.ietf.org/internet-drafts/draft-kumar-i2nsf-clien
t-facing-interface-im-03.txt
Status: https://datatracker.ietf.org/doc/draft-kumar-i2nsf-client-f
acing-interface-im/
Htmlized:   https://tools.ietf.org/html/draft-kumar-i2nsf-client-facing
-interface-im-03
Htmlized:   https://datatracker.ietf.org/doc/html/draft-kumar-i2nsf-cli
ent-facing-interface-im-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-kumar-i2nsf-client-
facing-interface-im-03

Abstract:
   This document defines information model for Client-Facing interface
   to Security Controller based on the requirements identified in
   [I-D.ietf-i2nsf-client-facing-interface-req].  The information model
   defines various managed objects and relationship among these objects
   needed to build the interface.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to Network Security Functions of the 
IETF.

Title   : Requirements for Client-Facing Interface to Security 
Controller
Authors : Rakesh Kumar
  Anil Lohiya
  Dave Qi
  Nabil Bitar
  Senad Palislamovic
  Liang Xia
Filename: draft-ietf-i2nsf-client-facing-interface-req-03.txt
Pages   : 24
Date: 2017-07-16

Abstract:
   This document captures requirements for Client-Facing interface to
   the Security Controller as defined by [I-D.ietf-i2nsf-framework].
   The interface is expressed using objects and constructs understood by
   Security Admin as opposed to vendor or device specific expressions
   associated with individual product and feature.  This document
   identifies a broad set of requirements needed to express Security
   Policies based on User-constructs which are well understood by the
   User Community.  This gives ability to decouple policy definition
   from policy enforcement on a specific security functional element, be
   it a physical or virtual.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-03
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

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

[John Strassner]

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  > 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 =
> ]=20
> > Sent: Thursday, July 06, 2017 5:22 PM
> > To: Linda Dunbar  >; =
> draft-xibassnez-i2nsf-capabil...@ietf.org =
> ; 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 

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

[Diego R. Lopez]

--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 > 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 =
]=20
> Sent: Thursday, July 06, 2017 5:22 PM
> To: Linda Dunbar >; =
draft-xibassnez-i2nsf-capabil...@ietf.org =
; 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 "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 

Re: [I2nsf] relationship between draft-hares-i2nsf-capability-data-model-03 & draft-kim-i2nsf-nsf-facing-interface-data-model-02? (was RE: Request for Timeslots in I2NSF WG Meeting

[John Strassner]

> Capability YANG data model is used to retrieve capability information of
> an NSF.

This is not quite correct.

Capabilities are used to express functions that can be performed. An NSF
may have multiple Capabilities. Capabilities are first **registered** using
the Registration Interface. I would have expected this model to do that.

> Capability YANG data model is used to query the capability information of
> a requested NSF and NSF-facing YANG data model is used to configure
> the rules of a policy

I find this confusing. Any YANG module should be able to get and set
information. Assuming that "query" means "get" here, I see no reason to
have a separate YANG module for that.

I do, however, see a need for a separate YANG module for
**registering** the capability information.

Note: please be careful in your wording (i.e., "model" vs. "module").

regards,
John

On Mon, Jul 10, 2017 at 8:20 AM, Mr. Jaehoon Paul Jeong <
jaehoon.p...@gmail.com> wrote:

> Hi Linda,
> Here is the clarification between NSF-facing interface YANG data model and
> Capability YANG data model.
>
> NSF-facing YANG data model is used to configure the rules of a policy into
> NSFs.
> This YANG data model is a standard interface for Security Controller to
> manipulate NSFs
> developed by various vendors.
>
> Capability YANG data model is used to retrieve capability information of
> an NSF.
> For example, after an NSF for network security control (i.e., firewall)
> inspects a packet and
> needs an additional security function such as deep packet inspection
> (DPI),
> it can ask Security Controller the location of such an additional security
> function and
> the corresponding IT resources with the Capability YANG data model.
>
> In summary, Capability YANG data model is used to query the capability
> information of
> a requested NSF and NSF-facing YANG data model is used to configure the
> rules of
> a policy (e.g., add/delete/update/read) based on an ECA paradigm.
>
> Thus, since these two models have different purposes, I think that we need
> to have two YANG drafts.
>
> Thanks.
>
> Best Regards,
> Paul
>
> On Sat, Jul 8, 2017 at 8:24 AM, Linda Dunbar 
> wrote:
>
>> Paul and Sue:
>>
>>
>>
>> You requested slots for both draft-hares-i2nsf-capability-data-model-03 &
>> draft-kim-i2nsf-nsf-facing-interface-data-model-02.
>>
>>
>>
>> The abstract of draft-kim-i2nsf-nsf-facing-interface-data-model-02
>> stated that the draft defines the data model for network security
>> functions), such as network security control, content security control, and
>> attack mitigation control,..
>>
>>
>>
>> The draft-hares-i2nsf-capability-data-model-03 has specified the
>> High-Level YANG for Network Security Control, Content Security Control and
>> Attack Mitigation Control.
>>
>>
>>
>> How are those two drafts related?  I have a vague memory that those two
>> drafts are to be merged, are they?
>>
>>
>>
>> Thank you very much,
>>
>>
>>
>> Linda
>>
>>
>>
>>
>>
>> *From:* Mr. Jaehoon Paul Jeong [mailto:jaehoon.p...@gmail.com]
>> *Sent:* Thursday, July 06, 2017 7:54 AM
>> *To:* Linda Dunbar ; Adrian Farrel <
>> adr...@olddog.co.uk>
>> *Cc:* i2nsf@ietf.org; skku_secu-brain_...@googlegroups.com
>> *Subject:* Request for Timeslots in I2NSF WG Meeting
>>
>>
>>
>> Hi Linda and Adrian,
>>
>> I would like to ask the timeslots for our 7 drafts as follows:
>>
>>
>>
>> draft-hares-i2nsf-capability-data-model-03
>>
>> - Presenter: Sue Hares
>>
>> - Time: 10 min
>>
>>
>>
>> draft-kim-i2nsf-nsf-facing-interface-data-model-02
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 10 min
>>
>>
>>
>> draft-jeong-i2nsf-consumer-facing-interface-dm-02
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 10 min
>>
>>
>>
>> draft-jeong-i2nsf-applicability-00
>>
>> - Presenter: Jaehoon Paul Jeong
>>
>> - Time: 15 min
>>
>>
>>
>> draft-hyun-i2nsf-nsf-triggered-steering-03
>>
>> - Presenter: Sangwon Hyun
>>
>> - Time: 10 min
>>
>>
>>
>> draft-hyun-i2nsf-registration-interface-im-02
>>
>> draft-hyun-i2nsf-registration-interface-dm-01
>>
>> - Presenter: Sangwon Hyun
>>
>> - Time: 10 min
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Best Regards,
>>
>> Paul
>>
>> --
>>
>> ===
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957 <+82%2031-299-4957>
>> Email: jaehoon.p...@gmail.com, paulje...@skku.edu
>> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
>> 
>>
>> ___
>> I2nsf mailing list
>> I2nsf@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2nsf
>>
>>
>
>
> --
> ===
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957 <+82%2031-299-4957>
> Email: jaehoon.p...@gmail.com, paulje...@skku.edu
> Personal Homepage: