 The security functions that are inv=
oked to enforce a security
     policy can be located in different equipment and network
     locations.

Hi, 

We have uploaded a new version of =
gap analysis (https://tools.ietf.org/html/draft-zhang-gap-anal=
ysis-03), in which we c=
ompare the relationships between i2nsf and other work in IETF.  Some of the =
work are still as the BoF stage. It would be great if you could give us=
 some comments or feedbacks to help us improve this draft. ^_^

Some of the texts are attached as follows.

Cheers

Dacheng

5.1.6.  S=
UPA BOF

   The IETF SUPA (Simplified Use of Policy Abstractions) BOF is
   proposing an IETF Working Group to develop a set of information
   models for defining standardized policy rules at different levels of
   abstraction, and will show how to map these (technology-independent)
   forms into YANG data models. The BOF introduces the concepts of
   multi-level (multiple levels of abstraction) (similar to figure 5)
   and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to
   address the current separation between development and deployment

Hares & el.      =
Expires December 6, 2015                      [Page 12]

INTERNET DRAFT       =
               I2NSF Gap analysis      June 6, 2015

   operations. Multiple levels of abstraction enable common concepts
   present in different technologies and implementations to be
   represented in a common manner. This facilitates using diverse
   components and technologies to implement a network service.

   Three information models are envisioned:

   o A generic information model that defines concepts needed by policy
   management independent of the form and content of the policy.

   o A more specific information model that refines the generic
   information model to specify how to build policy rules of the
   event-condition-action paradigm.

   o A more specific information model that refines the generic
   information model to specify how to build policy rules that
   declaratively specify what goals to achieve (but not how to achieve
   those goals).

   The set of generic policy information models in SUPA's work will be
   mapped to a set of concrete YANG data models. These data models will
   provide a set of core YANG modules that define how to manage and
   communicate policies, expressed using the event-condition-action
   paradigm or the declarative goal-oriented paradigm, between systems.

   The SUPA BOF/WG plans to focus in the first phase of its work on
   completing the set of information models required to construct an
   extensible, policy-based framework. These information models will
   lead to a set of core YANG data models for a policy-based management
   framework to monitor and control network services.

   The working group will use the distributed data center (DDC) use
   case, which includes the dynamic policy-driven provisioning and
   operation of inter-datacenter (inter-dc) virtual private networks
   (VPNs) of various types, as a means to validate that the generic
   policy-framework is implementable and usable.

   I2NSF versus SUPA BOF work

   I2NSF is focus on passing policies between I2NSF client and I2NSF
   Agent in an interoperable format. The SUPA policies are more generic
   policies (Prescriptive Event-Condition-Action and declarative/Intent-
   based. The protocol between the I2NSF Client and I2NSF agent is
   specific to the security policies. If SUPA was completed now, it
   might provide wisdom for the I2NSF interoperable protocol. With SUPA
   running in parallel, the generic models may or may not provide timely
   advise to structure I2NSF protocol.

Cheers
Dacheng
&n=
bsp;
&n=
bsp;
&n=
bsp;
&n=
bsp;
&n=
bsp;

   The IETF SUPA (Simplified Use of Policy Abstractions=
) BOF is
   proposing an IETF Working Group to develop a set of =
information
   models for defining standardized policy rules at dif=
ferent levels of
   abstraction, and will show how to map these (technol=
ogy-independent)
   forms into YANG data models. The BOF introduces the =
concepts of
   multi-level (multiple levels of abstraction) (simila=
r to figure 5)
   and multi-technology (e.g., IP, VPNs, MPLS) network =
abstractions to
   address the current separation between development a=
nd deployment

Hares & el.    &nb=
sp; Expires December 6, 2015        =
;            &n=
bsp; [Page 12]
=

INTERNET DRAFT    &nbs=
p;            &=
nbsp;    I2NSF Gap analysis      Ju=
ne 6, 2015<=
/o:p>

   operations. Multiple levels of abstraction enable co=
mmon concepts
   present in different technologies and implementation=
s to be
   represented in a common manner. This facilitates usi=
ng diverse
   components and technologies to implement a network s=
ervice.

   Three information models are envisioned:<=
/span>

   o A generic information model that defines concepts =
needed by policy
   management independent of the form and content of th=
e policy.

   o A more specific information model that refines the=
 generic
   information model to specify how to build policy rul=
es of the
   event-condition-action paradigm.

   o A more specific information model that refines the=
 generic
   information model to specify how to build policy rul=
es that
   declaratively specify what goals to achieve (but not=
 how to achieve
   those goals).

   The set of generic policy information models in SUPA=
's work will be
   mapped to a set of concrete YANG data models. These =
data models will
   provide a set of core YANG modules that define how t=
o manage and
   communicate policies, expressed using the event-cond=
ition-action
   paradigm or the declarative goal-oriented paradigm, =
between systems.

   The SUPA BOF/WG plans to focus in the first phase of=
 its work on
   completing the set of information models required to=
 construct an
   extensible, policy-based framework. These informatio=
n models will
   lead to a set of core YANG data models for a policy-=
based management
   framework to monitor and control network services.

   The working group will use the distributed data cent=
er (DDC) use
   case, which includes the dynamic policy-driven provi=
sioning and
   operation of inter-datacenter (inter-dc) virtual pri=
vate networks
   (VPNs) of various types, as a means to validate that=
 the generic
   policy-framework is implementable and usable.

   I2NSF versus SUPA BOF work

   I2NSF is focus on passing policies between I2NSF cli=
ent and I2NSF
   Agent in an interoperable format. The SUPA policies =
are more generic
   policies (Prescriptive Event-Condition-Action and de=
clarative/Intent-
   based. The protocol between the I2NSF Client and I2N=
SF agent is
   specific to the security policies. If SUPA was compl=
eted now, it
   might provide wisdom for the I2NSF interoperable pro=
tocol. With SUPA
   running in parallel, the generic models may or may n=
ot provide timely
   advise to structure I2NSF protocol.

   On early focus on ACL policy =
enforcement on traffic entering a
   network is the 1990s COPS design (PEP =
and PDP) as shown in figure 1.
   The Policy decision point kept =
network-wide policy (E.g. ACLs) and
   sent it to Policy enforcements who =
then would control what data flows
   between the two These decision points =
controlled flow from PEP to
   PEP.

        &nb=
sp;        =
PDP
      =
+-----+    /  \    =
+-----+
      |PEP1 =
|--/     \---|PEP2 |
      =
|     | ACL/policy |     =
|
      =
|     =
|            =
    |     =
|
    --| =
----|------------|-----|-----
      +-----+  data =
flow +-----+

        &nb=
sp;     Figure 1
   Today's security devices in 2015 =
replicate the same concept.The I2NSF
   Security provisioning policy/filter =
decision point (SPDP) and the
   I2NSF Agent Security Enforcement =
point (SEP) still look to control
   this flow through secure devices (see =
figure 2.).

        &nb=
sp;       =
+---------+
        &nb=
sp;       | I2NSF   =
|
        &nb=
sp;       | SPDP    =
|
        &nb=
sp;       =
|         =
|
        &nb=
sp;       =
+---------+
      =
+-----+    /  \    =
+-----+
      | SEP =
|--/     \---| SEP |
      | =
    |        =
    |     =
|
    --| =
----|------------|-----|-----
      +-----+  data =
flow +-----+

        Figure =
2
   The other security protocols work to =
interact to create the
   additional pieces of security the =
flows for users as follows (see

   figure =
3):

   o SACM - examines if policy and =
reality match.It asks the questions
   "Have proper policies been =
pushed to the proper place", and "Has =
any
   policy been =
compromised?"

   o MILE - looks at events that go Bump =
in night in the Security 2015.
   MILE examines when events need to be =
reported or correlated.A MILE
   configuration is a policy pushed out =
by the SPDP

   o DOTS - picks up security the flow =
for when things go really wrong
   during security attacks.In this case, =
an SEP needs to be able to
   SCREAM for help, to get other SEP to =
ease its pain.DOTS policy is
   pushed out via =
SPDP.

   o I2NSF may connect to all of these =
devices to gather information
   about the security policy that is =
pushes down to I2NSF agent. I2NSF
   provides a common interface between =
an I2NSF client as a SPDP and the
   NSF security boxes with SEP agents =
(which may also DOTS agent or Mile
   agent).

        &nb=
sp;       =
+---------+     +------+
      +------+  | =
I2NSF   |=3D=3D=3D=3D=3D| DOTS |
      |SCAM  |  =
| SPDP    |     =
|client|----
      =
|client|=3D=3D|         =
|     +------+   =
|
      +------+  =
|         =
|     +------+   =
|
        &nb=
sp;       =
|         =
|     |MILES |   =
|
    +------+    =
|         =
|     |client|   =
|
    |SCAM  |    =
+---------+     +----:-+   =
|
    |Agent =
|       / =
\            =
   :     |
    =
+------+      /   =
\            =
  :     |
      =
+-----+    /     \    =
+-----+  :     |
      | SEP =
|--/        \---| SEP |  =
:     |
      =
|     =
|            =
   |     |  :     =
|
      =
|     =
|            =
   |MILES|..:     =
|
      =
|     =
|            =
   |Agent|        =
|
      =
|     =
|            =
   |DOTS |        =
|
      =
|     =
|            =
   |Agent|---------
    --| =
----|---------------|-----|-----
      +-----+  data =
flow    +-----+

        Figure =
3

Cheers
Dacheng

   proposing an IETF =
Working Group to develop a set of =
information
   models for defining =
standardized policy rules at different levels =
of
   abstraction, and =
will show how to map these =
(technology-independent)
   forms into YANG data =
models. The BOF introduces the concepts of
   multi-level =
(multiple levels of abstraction) (similar to figure =
5)
   and multi-technology =
(e.g., IP, VPNs, MPLS) network abstractions =
to
   address the current =
separation between development and =
deployment

 =

INTERNET =
DRAFT           &n=
bsp;          I2NSF Gap =
analysis      June 6, 2015

   present in different =
technologies and implementations to be
   represented in a =
common manner. This facilitates using =
diverse
   components and =
technologies to implement a network service.

   management =
independent of the form and content of the =
policy.

   information model to =
specify how to build policy rules of the
   =
event-condition-action paradigm.

   information model to =
specify how to build policy rules that
   declaratively =
specify what goals to achieve (but not how to =
achieve
   those =
goals).

   mapped to a set of =
concrete YANG data models. These data models =
will
   provide a set of =
core YANG modules that define how to manage =
and
   communicate =
policies, expressed using the =
event-condition-action
   paradigm or the =
declarative goal-oriented paradigm, between =
systems.

   completing the set =
of information models required to construct =
an
   extensible, =
policy-based framework. These information models =
will
   lead to a set of =
core YANG data models for a policy-based =
management
   framework to monitor =
and control network services.

   case, which includes =
the dynamic policy-driven provisioning and
   operation of =
inter-datacenter (inter-dc) virtual private =
networks
   (VPNs) of various =
types, as a means to validate that the =
generic
   policy-framework is =
implementable and usable.

   Agent in an =
interoperable format. The SUPA policies are more =
generic
   policies =
(Prescriptive Event-Condition-Action and =
declarative/Intent-
   based. The protocol =
between the I2NSF Client and I2NSF agent is
   specific to the =
security policies. If SUPA was completed now, =
it
   might provide wisdom =
for the I2NSF interoperable protocol. With =
SUPA
   running in parallel, =
the generic models may or may not provide =
timely
   advise to structure =
I2NSF protocol.
Hi Tobias,

Thanks for the support and for the comment. The charter text is preliminary at this point, subject to change before the BOF and if the BOF is successful as function of the comments of the public charter review. The intent of the date currently displayed is to show the date of delivering the last of the documents in the cluster. Maybe we should add this right now to avoid mis-understanding. Further detailed milestones will provide the order and time sequencing that we plan to achieve. 

Regards,

Dan

-----Original Message-----
From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Tobias Gondrom
Sent: Friday, June 12, 2015 1:59 AM
To: i2nsf@ietf.org
Subject: Re: [I2nsf] Comments on charter text
Importance: Low

I fully support the charter text as proposed and including the proposed
adjustment from Joe.

The suggested work items make sense to me and I very much like that the
charter calls out the various WGs its work relates to.

I am not quite sure about the notion that all early drafts have the same
timeline to be submitted to IESG.
"  - All Early Drafts to IESG: 18 months"
I can see that that may sound attractive as the IDs depend on each other. But
equally this will then form a larger work bundle coming all around the same
time representing a lot of review. So am wondering whether we can spread
out the submissions over one per month or so to allow us to get one done
after the other and have enough bandwidth within the WG to give every
draft a good amount of review cycles....

Just a thought.

Best regards, Tobias

     From: "Susan Hares" <shares at ndzh.com>
     To: "'Linda Dunbar'" <linda.dunbar at huawei.com>, "'Joseph Salowey'"
<joe at salowey.net>, <i2nsf at ietf.org>
     Date: Wed, 10 Jun 2015 13:51:04 -0400
     In-reply-to:
<4A95BA014132FF49AE685FAB4B9F17F657C576B3@dfweml701-chm>
     References:
<CAOgPGoCuSVBP3Xs_Kg0sic9V9UJ4=YLTDVc4kLdpcwFwcYjUBQ@mail.gmail
.com>
<4A95BA014132FF49AE685FAB4B9F17F657C576B3@dfweml701-chm>
     List-id: "*I2NSF: Interface to Network Security Functions mailing list*"
<i2nsf.ietf.org>

Linda:

I agree that Joe’s update is a good idea.

Sue

From: I2nsf [mailto:i2nsf-bounces at ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, June 10, 2015 11:48 AM
To: Joseph Salowey; i2nsf at ietf.org
Subject: Re: [I2nsf] Comments on charter text

Joe,

That is a good suggestion.

Your suggested charter wording is now linked to the IETF93 BOF Wiki page.

Cheers,

Linda

From: I2nsf [mailto:i2nsf-bounces at ietf.org] On Behalf Of Joseph Salowey
Sent: Tuesday, June 09, 2015 1:21 PM
To: i2nsf at ietf.org
Subject: [I2nsf] Comments on charter text

I don't want to give the impression that we are going to work on a new
secure channel mechanism for i2nsf, so I would suggest replacing the last
bullet of concrete work at the i2NSF capability layer with:

"-          Examining the existing secure communication mechanisms to
identify the appropriate ones for carrying the controlling and monitoring
information between the NSFs and their management entity (or entities)."

I think with that change the current charter now reads:

Network Security Function (NSF) is to ensure integrity, confidentiality and
availability of network communications, to detect unwanted activity, and to
block it or at least mitigate its effects. NSFs are provided and consumed in
increasingly diverse environments. Users of NSFs could consume network
security services hosted by one or more providers, which may be their own
enterprise, service providers, or a combination of both. Likewise, service
providers of NSFs may offer their customers network security services that
consist of multiple security products and/or functions from different
vendors. NSFs may be provided by physical and/or virtualized infrastructure.
Without standard interfaces to control and monitor the behavior of NSFs, it
has become virtually impossible for security service providers to automate
service offerings that utilize different security functions from multiple
vendors.

The primary goal of I2NSF is to define an information model, a set of
software interfaces and data models for controlling and monitoring aspects
of physical and virtual NSFs. Other aspects of NSFs, such as device or network
provisioning and configuration, are out of scope.
Controlling and monitoring of NSFs should include the ability to specify,
query, monitor, and control the NSFs by one or more management entities.
Since different security vendors support different features and functions on
their devices, I2NSF will focus on flow-based NSFs that provide treatment to
packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet
inspection, or pattern matching and remediation.

There are two layers of interfaces envisioned in the I2NSF approach:

·       The I2NSF Capability Layer specifies how to control and monitor
NSFs at a functional implementation level. That is, I2NSF will standardize a set
of interfaces by which control and management of NSFs may be invoked,
operated, and monitored. (I2NSF will not work on any other aspects of NSFs.
Nor will I2NSF at this stage specify how to derive control and monitoring
capabilities from higher level security policies for the Capability Layer.)

·       The I2NSF Service Layer defines how clients’ security policies
may be expressed and monitored. The Service Layer is out of scope for this
phase of I2NSF’s work. However, I2NSF will provide a forum for
Informational drafts on data models, APIs, etc. that demonstrate how service
layer policies may be translated to Capability Layer functions.

The concrete work at the I2NSF Capability Layer includes development of

-          An information model that defines concepts required for
standardizing the control and monitoring of NSFs.

-          A set of YANG data models, derived from the above information
model.

-          The capability registry (IANA) that enables the
characteristics and behavior of NSFs to be specified using a vendor-neutral
vocabulary without requiring the NSFs themselves to be standardized. The
registry enables various mechanisms, including policy rules, to be used to
match monitor and control functions to the needs of an application and/or
environment.

-          Examining the existing secure communication mechanisms to
identify the appropriate ones for carrying the controlling and monitoring
information between the NSFs and their management entity (or entities).

Standard interfaces for monitoring and controlling the behavior of NSFs are
essential building blocks for Security Service Providers to automate the use
of different NSFs from multiple vendors by their Security management
entities. This work will leverage the existing protocols and data models
defined by I2RS, Netconf, and NETMOD. If extensions to these protocols are
needed, requirements will be developed by this WG, and the extensions will
be developed in cooperation with the WGs responsible for the protocols.

The I2NSF WG’s deliverables include:

-          Use cases, problem statement, gap analysis document [The WG
will decide if to proceed as RFC].

-          Framework Document, presenting an overview of the use of NSFs
and the purpose of the models developed by the WG [The WG will decide if
to proceed as RFC].

-          A single, unified, Information Model for controlling and
monitoring flow-based NSFs.

Corresponding YANG Data Models derived from the above Information
Model.

-          IANA registry consideration for flow-based NSFs controlling
and monitoring capabilities.[maybe merged into data models]

The WG may additionally choose to develop additional documents to
describe requirements for extensions (if any) to existing protocols used by
the WG, and how the data models are used to monitor and control flow-
based NSFs, and to describe how to use I2RS, Netconf, and NETMOD to carry
the content of the data models.

[The WG may decide that the Use cases, Framework, and gap analysis are
simply reference documents during the lifetime of the WG and not to be
published as an RFC.]

The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will
communicate with external SDOs like ETSI NFV and will encourage open
source code development related to the WG scope in organizations like ONF,
OpenStack, ODL, and OPNFV.

Suggested Milestones

   - Use Cases, problem statement, and gap analysis Document: Charter time
+ 1 month

   - Framework: Charter time + 4 months to WG Document

   - Requirements for extensions to protocols:  Charter time + 8 months to
WG document

   - Info model: Charter time + 8 months to WG Document

   - IANA registry consideration + 12 months to WG Document

   - All Early Drafts to IESG: 18 months

[decision point – +10 months]

   - Data Models: Charter + 9 Months to WG Document

   - Applicability Statements: 10 months to WG Document

   - Data Models and Applicability Statements to IESG  - 18 months

     References:
         [I2nsf] Comments on charter text
             From: Joseph Salowey
         Re: [I2nsf] Comments on charter text
             From: Linda Dunbar

     Prev by Date: Re: [I2nsf] Comments on charter text
     Next by Date: [I2nsf] draft-zhang-gap-analysis - security
     Previous by thread: Re: [I2nsf] Comments on charter text
     Next by thread: [I2nsf] request for comments to the gap analysis draft
     Index(es):
         Date
         Thread

Note Well: Messages sent to this mailing list are the opinions of the senders
and do not imply endorsement by the IETF.

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwIGaQ&c=BFpWQw8bsuKpl
1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=ONTTrP
hMnb-
5BSacSltuP2PssPYW1VhswfGmuFmnoD8&s=ge1_IrzAwPbPKDsLe9YSw6dnx9
klQ7rAQ1kEt8bty9g&e=

1300-1500=C2=A0 Afternoon Session I
1300-1500  Afternoon Session I
Karlin I/II      =
      SEC     i2nsf  &nbs=
p;       Interface to Network Security Functions B=
OF
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

5.1.6. S= UPA BOF

5.1.6. SUPA BOF

Hi all

The gap analysis took time to really look at = how the security work in the IETF work fits together. I = published this draft, and I‘ve received no input on the security = area gap analysis. I’d really like feedback. =

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D

5.1.6<= /a>. SUPA = BOF