Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter

From: Linda Dunbar <[email-masked]>
Date: Thu, 21 May 2015 17:00:55 +0000

Network security functions (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 express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their 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 NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies 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:

*       I2NSF Capability Layer

*       I2NSF Service Layer

The I2NSF capability layer specifies how to control and monitor NSFs at functional level.  (I2NSF will NOT work on any other aspects of NSFs including standardizing NSFs or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher level security policies for the Capability layer).  I2NSF will only standardize the security policies related to the control and monitoring of the NSFs.  A sample capability layer construct for controlling NSFs is "subject-object-function-action".

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 information 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, and

-          The proper secure communication channels to carry 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 layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.
The I2NSF WG's deliverables include:

-          Use Cases document.

-          Framework Document.

-          Requirements for extensions (if any) to existing protocols used by the WG.

-           Gap analysis of existing protocols and modeling languages for specifying, querying, monitoring, and controlling NSFs.

-          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.

-          (Optionally) Document describing how capabilities are used to monitor and control flow-based NSFs.

-          (Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specified information/data models.

[The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG.]

Suggested Milestones
  - Use Cases Document:  Charter time + 1 month to WG Document
  - 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

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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 21 May 2015 17:35:33 +0000

This looks good to me.

One thing based on a comment made by Kathleen earlier in the process. The IESG is not very sympathetic nowadays on the WGs spending resources on progressing use cases documents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of work. Maybe it's better to mark those deliverables in brackets with the note (the WG will decide if to proceed as RFC).

Thanks for progressing this, Linda!

Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: [email-masked]'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter

*         I2NSF Capability Layer

*         I2NSF Service Layer

-          Use Cases document.

-          Framework Document.

Suggested Milestones

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 21 May 2015 22:16:37 +0000

The version posted has this statement:

Is it good enough?

Linda
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, May 21, 2015 12:36 PM
To: Linda Dunbar; [email-masked]'
Subject: RE: Clean version of the narrower scoped I2NSF charter

This looks good to me.

Regards,

Dan

*       I2NSF Capability Layer

*       I2NSF Service Layer

-          Use Cases document.

-          Framework Document.

Suggested Milestones

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 May 2015 18:32:29 -0400

On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar <[email-masked]>
wrote:

> [The WG may decide that the Use cases, Framework, and Requirement are
> Informational documents or simply reference documents during the lifetime
> of the WG.]
>
>
>
> Is it good enough?
>

That is helpful, thank you.  It's good to not waste too much time on these
types of documents so the work can start.

Kathleen

>
>
> Linda
>
> *From:* Romascanu, Dan (Dan) [mailto:[email-masked]]
> *Sent:* Thursday, May 21, 2015 12:36 PM
> *To:* Linda Dunbar; [email-masked]'
> *Subject:* RE: Clean version of the narrower scoped I2NSF charter
>
>
>
> This looks good to me.
>
>
>
> One thing based on a comment made by Kathleen earlier in the process. The
> IESG is not very sympathetic nowadays on the WGs spending resources on
> progressing use cases documents to RFC. Same applies I think to the gap
> analysis, which is more a help tool while we define the scope of work.
> Maybe it’s better to mark those deliverables in brackets with the note (the
> WG will decide if to proceed as RFC).
>
>
>
> *From:* I2nsf [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Linda Dunbar
> *Sent:* Thursday, May 21, 2015 8:01 PM
> *To:* [email-masked]'
> *Subject:* [I2nsf] Clean version of the narrower scoped I2NSF charter
>
>
>
>
>
> Network security functions (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 express, monitor, and
> control security policies that govern the behavior of NSFs, it becomes
> virtually impossible for security service providers to automate their
> 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 NSFs (both physical and virtual). Other aspects of NSFs such as device
> or network provisioning and configuration are out of scope. Controlling and
> monitoring of NSFs should include the use of policies 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.
>
>
>
> ·       I2NSF Capability Layer
> ·       I2NSF Service Layer
> The I2NSF capability layer specifies how to control and monitor NSFs at
> functional level.  (I2NSF will NOT work on any other aspects of NSFs
> including standardizing NSFs or devices.  Nor will I2NSF at this stage
> specify how to derive control and monitoring capabilities from higher level
> security policies for the Capability layer).  I2NSF will only standardize
> the security policies related to the control and monitoring of the NSFs.  A
> sample capability layer construct for controlling NSFs is
> “subject-object-function-action”.
>
>
>
> 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 information drafts
> on data models, APIs, etc. that demonstrate how service layer policies may
> be translated to Capability Layer functions.
>
>
>
> -          An information model that defines concepts required for
> standardizing the control  and monitoring of NSFs,
>
> -          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, and
>
> -          The proper secure communication channels to carry 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 layer will leverage the existing protocols and
> data models defined by I2RS, Netconf, and NETMOD.
>
>
>
> The I2NSF WG’s deliverables include:
>
>
>
> -          Use Cases document.
>
> -          Framework Document.
>
> -           Gap analysis of existing protocols and modeling languages for
> specifying, querying, monitoring, and controlling NSFs.
>
> -          (Optionally) Applicability Statements on how to use I2RS,
> Netconf, and NETMOD to carry the content of the specified information/data
> models.
>
>
>
> [The WG may decide that the Use cases, Framework, and Requirement are
> Informational documents or simply reference documents during the lifetime
> of the WG.]
>
>
>
> Suggested Milestones
>
> [decision point – +10 months]
>
> 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.
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

-- 

Best regards,
Kathleen

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 22 May 2015 09:24:48 +0000

I missed this, sorry. Sure - this is fine.

Thanks and Regards,

Dan

From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, May 22, 2015 1:17 AM
To: Romascanu, Dan (Dan); [email-masked]'
Subject: RE: Clean version of the narrower scoped I2NSF charter

Is it good enough?

Linda

This looks good to me.

Regards,

Dan

*         I2NSF Capability Layer

*         I2NSF Service Layer

-          Use Cases document.

-          Framework Document.

Suggested Milestones

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 22 May 2015 14:49:42 -0400

+1

On 05/21/2015 06:32 PM, Kathleen Moriarty wrote:
>
>
> On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [The WG may decide that the Use cases, Framework, and Requirement
>     are Informational documents or simply reference documents during
>     the lifetime of the WG.]
>
>     Is it good enough?
>
>
> That is helpful, thank you.  It's good to not waste too much time on 
> these types of documents so the work can start.
>
> Kathleen
>
>     Linda
>
>     *From:*Romascanu, Dan (Dan) [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Linda Dunbar; [email-masked] <mailto:[email-masked]>'
>     One thing based on a comment made by Kathleen earlier in the
>     process. The IESG is not very sympathetic nowadays on the WGs
>     spending resources on progressing use cases documents to RFC. Same
>     applies I think to the gap analysis, which is more a help tool
>     while we define the scope of work. Maybe it’s better to mark those
>     deliverables in brackets with the note (the WG will decide if to
>     proceed as RFC).
>
>     *From:*I2nsf [mailto:[email-masked]] *On Behalf Of *Linda
>     Dunbar
>     *To:* [email-masked] <mailto:[email-masked]>'
>     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 express, monitor, and control
>     security policies that govern the behavior of NSFs, it becomes
>     virtually impossible for security service providers to automate
>     their 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 NSFs (both physical and virtual). Other
>     aspects of NSFs such as device or network provisioning and
>     configuration are out of scope. Controlling and monitoring of NSFs
>     should include the use of policies 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.
>
>     ·I2NSF Capability Layer
>     ·I2NSF Service Layer
>     The I2NSF capability layer specifies how to control and monitor
>     NSFs at functional level.  (I2NSF will NOT work on any other
>     aspects of NSFs including standardizing NSFs or devices.  Nor will
>     I2NSF at this stage specify how to derive control and monitoring
>     capabilities from higher level security policies for the
>     Capability layer).  I2NSF will only standardize the security
>     policies related to the control and monitoring of the NSFs.  A
>     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 information drafts on data models, APIs, etc. that demonstrate
>     how service layer policies may be translated to Capability Layer
>     functions.
>
>     -An information model that defines concepts required for
>     -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, and
>
>     -The proper secure communication channels to carry 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 layer will
>     leverage the existing protocols and data models defined by I2RS,
>     Netconf, and NETMOD.
>
>     -Use Cases document.
>     -Framework Document.
>     -Requirements for extensions (if any) to existing protocols used
>     by the WG.
>
>     -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.
>
>     -(Optionally) Document describing how capabilities are used to
>     monitor and control flow-based NSFs.
>
>     -(Optionally) Applicability Statements on how to use I2RS,
>     Netconf, and NETMOD to carry the content of the specified
>     information/data models.
>
>     [The WG may decide that the Use cases, Framework, and Requirement
>     are Informational documents or simply reference documents during
>     the lifetime of the WG.]
>
>     Suggested Milestones
>
>     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.
>
>
>     [email-masked] <mailto:[email-masked]>