Subject: [I2nsf] Revised Narrower scoped I2NSF charter

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 May 2015 18:47:58 +0000

Thanks to many people contributions to I2NSF charter. Here is the revised one. Please provide comments and suggestions if your suggested changes haven't been properly addressed.

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 Capabilities Layer

*       I2NSF Services Layer

The I2NSF Capability Layer specifies the functional security policies, which are translated from the entity defining the goal of the security policy into a form that can be implemented, and are used to monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will only standardize the controlling and monitoring aspects of the NSFs (not devices). An exemplar controlling of flow-based NSFs is "Subject - Object - Function - Action".

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on application and client specific logical networks requirements and context.

The concrete work at the I2NSF Capability Layer includes

-          An information model that defines concepts required for standardizing the controlling and monitoring of NSFs,

-          A set of YANG data models, derived from the above information model, which enables the controlling and monitoring of virtual and/or physical 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 management entity (or entities) and the NSFs being controlled.

 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.

For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for now) to standardize the interface facing clients. However, I2NSF can have informational drafts showing sample data models, APIs, and/or RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.

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

-          Use Case document.

-          Framework Document.

-          Requirement for extensions (if there are 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 capability.

-          (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 Case 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 OpenNFV.

Cheers,

Linda

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 18 May 2015 18:38:56 -0400

Hi Linda,

Please see my comments/edits below. (Just to clarify: I read that the Service Layer is out of scope, correct? I don't see anything related to SL in the book of work. I've tried to make that clear.)

Myo

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 18 May 2015 2:48 PM
To: [email-masked]
Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty
Subject: [I2nsf] Revised Narrower scoped I2NSF charter

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 Capabilities Capability Layer

*         I2NSF Services Service Layer
[MZ:  I personally prefer "Capabilities Layer" and "Services Layer" or even "Service Abstraction Layer." But I'll go with what's entrenched in the carrier space.]

The I2NSF Capability Layer specifies the functional security policies, which are translated from the entity defining the goal of the security policy into a form that can be implemented, and are used to monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will only standardize only the controlling control and monitoring aspects of the NSFs (not devices). An exemplar controlling of flow-based NSFs is "Subject - Object - Function - Action".

[MZ]:  The I2NSF Capability Layer specifies how to control and monitor NSFs at an implementational level. (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.) A sample Capability Layer construct for controlling NSFs is "subject-object-function-action".

[MZ: I personally don't think we should add "subject-object-function-action" in the charter. I'll defer to others on this.]

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on application and client specific logical networks requirements and context.
[MZ]: The I2NSF Service Layer defines how 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:

-          The capability An IANA capabilities registry (IANA) that specifies the characteristics and behaviors of NSFs using a vendor-neutral vocabulary.
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 control and monitoring information between the NSFs and their management entity (or entities). and the NSFs being controlled.

[MZ:  See above.]

It is a non-goal not a goal of I2NSF 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 there are any) to existing protocols used by the WG.

-          IANA registry consideration for flow-based NSFs controlling and monitoring capability capabilities.

[The WG may decide that the Use cases, Framework, and Requirements 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

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

Cheers,

Linda

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 20 May 2015 01:20:34 +0000

Hi,

I support Myo's changes, including the proposal of not adding the "subject-object-function-action” in the charter.

Be goode,

On 19 May 2015, at 06:38 , Zarny, Myo <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda,

Please see my comments/edits below. (Just to clarify: I read that the Service Layer is out of scope, correct? I don’t see anything related to SL in the book of work. I’ve tried to make that clear.)

Myo

To: [email-masked]<mailto:[email-masked]>

Thanks to many people contributions to I2NSF charter. Here is the revised one. Please provide comments and suggestions if your suggested changes haven’t been properly addressed.

There are two layers of interfaces envisioned in the I2NSF approach:
•         I2NSF Capabilities Capability Layer
•         I2NSF Services Service Layer
[MZ:  I personally prefer “Capabilities Layer” and “Services Layer” or even “Service Abstraction Layer.” But I’ll go with what’s entrenched in the carrier space.]

The I2NSF Capability Layer specifies the functional security policies, which are translated from the entity defining the goal of the security policy into a form that can be implemented, and are used to monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will onlystandardize only the controlling control and monitoring aspects of the NSFs (not devices). An exemplar controlling of flow-based NSFs is “Subject – Object – Function – Action”.

[MZ]:  The I2NSF Capability Layer specifies how to control and monitor NSFs at an implementational level. (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.) A sample Capability Layer construct for controlling NSFs is “subject-object-function-action”.

[MZ: I personally don’t think we should add “subject-object-function-action” in the charter. I’ll defer to others on this.]

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on application and client specific logical networks requirements and context.
[MZ]: The I2NSF Service Layer defines how 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 I2NSF WG’s deliverables include:

-          Use Cases document.
-          Framework Document.

Suggested Milestones

[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

Cheers,

Linda
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 20 May 2015 16:16:56 +0000

Myo,

Thanks for the wording change.

Your wording:
The I2NSF Capability Layer specifies how to control and monitor NSFs at an implementational level. (I2NSF will NOT work on any other aspects of NSFs

Is it Ok to say "The I2NSF Capability Layer specifies how to control and monitor NSFs at interface level"?

"Implementation level" can have very different connotation for engineers who implement features on devices, many IETF participants are implementers.

Thanks, Linda

From: Zarny, Myo [mailto:[email-masked]]
Sent: Monday, May 18, 2015 5:39 PM
To: Linda Dunbar; [email-masked]'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'
Subject: RE: Revised Narrower scoped I2NSF charter

Hi Linda,

Myo

-          Use Cases document.

-          Framework Document.

Suggested Milestones

Cheers,

Linda

---

From: "Zarny, Myo" <[email-masked]>
Date: Thu, 21 May 2015 09:35:13 -0400

I see. I suppose "at an interface level" is fine if it's already a widely-understood/agreed-upon term by the majority of IETF participants/vendors. At least to me, an enterprise user of technology, the term is vague; I suspect many others like me will find the same as well. You'll need to add a few more sentences to explain what it means to people like me.

How about "at a functional level"? If that doesn't work-say, because the term "functional" already has some pre-established definition in the vendor space-I'll defer to those from the vendor side to come up with a more precise term/language.

Myo

From: Linda Dunbar [mailto:[email-masked]]
Sent: 20 May 2015 12:17 PM
To: Zarny, Myo [Tech]; [email-masked]'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; Susan Hares
Subject: RE: Revised Narrower scoped I2NSF charter

Myo,

Your wording:

Thanks, Linda

Hi Linda,

Myo

-          Use Cases document.

-          Framework Document.

Suggested Milestones

Cheers,

Linda

---

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

Myo,
Good suggestion. We will use "at functional level".

"The I2NSF capability layer specifies how to control and monitor NSFs at functional level."

Thanks, Linda

From: Zarny, Myo [mailto:[email-masked]]
Sent: Thursday, May 21, 2015 8:35 AM
To: Linda Dunbar; [email-masked]'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; 'Susan Hares'
Subject: RE: Revised Narrower scoped I2NSF charter

Myo

Myo,

Your wording:

Thanks, Linda

Hi Linda,

Myo

-          Use Cases document.

-          Framework Document.

Suggested Milestones

Cheers,

Linda

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 21 May 2015 13:51:58 -0400

I suspect I am missing something here.  I can't improve on the text; 
amny have worked hard at the content.

The capability data models will tend to define the Services layer, so I 
have a hard time separating them.  Narrowing the scope might be a good 
short-term approach and we can revisit this as the data models evolve.

On 05/18/2015 02:47 PM, Linda Dunbar wrote:
>
> Thanks to many people contributions to I2NSF charter. Here is the 
> revised one. Please provide comments and suggestions if your suggested 
> changes haven’t been properly addressed.
>
> 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 Capabilities Layer
>
> ·I2NSF Services Layer
>
> The I2NSF Capability Layer specifies the functional security policies, 
> which are translated from the entity defining the goal of the security 
> policy into a form that can be implemented, and are used to monitor 
> and control the behavior of NSFs. I2NSF will NOT standardize NSFs or 
> devices. Instead, I2NSF will only standardize the controlling and 
> monitoring aspects of the NSFs (not devices). An exemplar controlling 
> of flow-based NSFs is “Subject – Object – Function – Action”.
>
> The I2NSF Service Layer is for clients to express and monitor security 
> policies for their specific flows, which is usually based on 
> application and client specific logical networks requirements and context.
>
> -An information model that defines concepts required for standardizing 
> the controlling and monitoring of NSFs,
>
> -A set of YANG data models, derived from the above information model, 
> which enables the controlling and monitoring of virtual and/or 
> physical 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 management entity (or entities) and 
> the NSFs being controlled.
>
>  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.
>
> For the I2NSF Service Layer, it is out of the scope for I2NSF (at 
> least for now) to standardize the interface facing clients. However, 
> I2NSF can have informational drafts showing sample data models, APIs, 
> and/or RESTful interfaces to clients and demonstrating the feasibility 
> of them being translated to the Capability Layer policies.
>
> -Use Case document.
> -Framework Document.
> -Requirement for extensions (if there are 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 capability.
>
> -(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 OpenNFV.
>
> Cheers,
>
> Linda
>
>
>
> [email-masked]