Subject: [I2nsf] Proposed Charter Edit: simple service interface

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jul 2015 10:04:37 -0400

Hi.
I'd really like to see work on the service interface.
I had a wonderful chat  with Ed and Linda where we went over some of the
concerns related to this and issue that  caused the service interface to
be problematic.

We believe that in cases where the policies can be expressed in an
information model identical or very similar to the capability interface,
a service interface is still useful and would be easy to scope.

to that end I propose the following charter edit.
I also propose a small edit to the capability layer definition that will
make it more clear what that interface is.  

As an argument in favor of this level of service interface being easy, I
read a good chunk of the documents and had the direction of flow
backwards.  I assumed they were such an interface already.

Attached is a word diff and new charter:
diff --git a/charter b/charter
index fd0f6d4..c23a2eb 100644
--- a/charter
+++ b/charter
@@ -10,14 +10,14 @@ 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 {+a security controller can+} control and [-management of-]{+manage+} 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-]{+monitored to a security controller that uses the capability layer to control and manage NSFs to implement these policies.  Describing a simple service layer modeled as closely as possible on the capability layer+} is [-out-]{+within scope.  With this simple service layers, security controllers might handle issues like multi-tenancy concerns, and choosing which+} of [-scope-]{+the available NSFs to use+} for [-this phase-]{+a given policy.  Expressing policies in ways other than the model used by the capability layer is out+} of [-I2NSF’s work.-]{+scope.+}  However, I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how {+more complex+} service layer policies {+and policies in other formats+} 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.
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 a security controller can control and manage NSFs may be invoked, operated, and monitored. (I2NSF will not 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 to a security controller that uses the capability layer to control and manage NSFs to implement these policies.  Describing a simple service layer modeled as closely as possible on the capability layer is within scope.  With this simple service layers, security controllers might handle issues like multi-tenancy concerns, and choosing which of the available NSFs to use for a given policy.  Expressing policies in ways other than the model used by the capability layer is out of scope.  However, I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex service layer policies and policies in other formats 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

    Follow-Ups:
        Re: [I2nsf] Comments on charter text
            From: Linda Dunbar

    Prev by Date: Re: [I2nsf] Does it make sense to say: using Packet based approach for Flow-Based NSF provisioning? (was RE: comments on draft-merged-i2nsf-framework-01
    Next by Date: [I2nsf] request for comments to the gap analysis draft
    Previous by thread: [I2nsf] Merging draft-lopez-i2nsf-packet-00 and draft-xia-i2nsf-capability-interface-im-01
    Next by thread: Re: [I2nsf] Comments on charter text
    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.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 Jul 2015 15:04:33 +0000

Sam, 

Thank you very much for the edit of the I2NSF charter. Can you send a clean version? So that we can include in the I2NSF wiki.  

I think that your proposed "Simple Service Layer modeled as closely as possible on the capability layer" is clear and well scoped. 

I believe this Simple Service Layer shouldn't trigger the huge debate on various layers of service language that is hard to grasp (which was the main reason to take it out after the last I2NSF BOF).  

----------------------

The I2NSF Service Layer defines how clients’ security policies may be expressed and monitored to a security controller that uses the capability layer to control and manage NSFs to implement these policies.  Describing a simple service layer modeled as closely as possible on the capability layer is within scope.  With this simple service layers, security controllers might handle issues like multi-tenancy concerns, and choosing which of the available NSFs to use for a given policy.  Expressing policies in ways other than the model used by the capability layer is out of scope.  However, I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex service layer policies and policies in other formats may be translated to Capability Layer functions.

Linda
-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, July 21, 2015 4:05 PM
To: [email-masked]
Subject: [I2nsf] Proposed Charter Edit: simple service interface

Hi.
I'd really like to see work on the service interface.
I had a wonderful chat  with Ed and Linda where we went over some of the concerns related to this and issue that  caused the service interface to be problematic.

We believe that in cases where the policies can be expressed in an information model identical or very similar to the capability interface, a service interface is still useful and would be easy to scope.

to that end I propose the following charter edit.
I also propose a small edit to the capability layer definition that will make it more clear what that interface is.  

As an argument in favor of this level of service interface being easy, I read a good chunk of the documents and had the direction of flow backwards.  I assumed they were such an interface already.

 

Suggested Milestones

    Follow-Ups:

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jul 2015 15:02:16 -0400

>>>>> "Linda" == Linda Dunbar <[email-masked]> writes:

    Linda> Sam, Thank you very much for the edit of the I2NSF
    Linda> charter. Can you send a clean version? So that we can include
    Linda> in the I2NSF wiki.

I thought I did attach a clean copy but

 

Suggested Milestones

    Follow-Ups:

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 22 Jul 2015 08:39:48 +0000

Hi,

As I said during the BoF, I am more than happy to see I2NSF working in the Service Layer as well. And I agree with Linda in that the wording Sam proposes should avoid the objections that caused it to be taken out from the charter.

Be goode,

On 21 Jul 2015, at 17:04 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Sam,

----------------------

Linda
-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Tuesday, July 21, 2015 4:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Proposed Charter Edit: simple service interface

Hi.

Suggested Milestones

   Follow-Ups:

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[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