Subject: Re: [I2nsf] Comments on charter text

From: Tobias Gondrom <[email-masked]>
Date: Fri, 12 Jun 2015 00:58:58 +0200

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=[email-masked]> 
<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.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Jun 2015 08:06:35 +0000

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:[email-masked]] On Behalf Of Tobias Gondrom
> Sent: Friday, June 12, 2015 1:59 AM
> To: [email-masked]
> Importance: Low
> 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
> 
> 
> 
> 
> 
>      To: "'Linda Dunbar'" <linda.dunbar at huawei.com>, "'Joseph Salowey'"
> <joe at salowey.net>, <i2nsf at ietf.org>
>      In-reply-to:
>      List-id: "*I2NSF: Interface to Network Security Functions mailing list*"
> <i2nsf.ietf.org>
> 
> Linda:
> 
> 
> 
> secure channel mechanism for i2nsf, so I would suggest replacing the last
> bullet of concrete work at the i2NSF capability layer with:
> 
> 
> 
> identify the appropriate ones for carrying the controlling and monitoring
> information between the NSFs and their management entity (or entities)."
> 
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> 
> 
> 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.)
> 
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
> 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.
> 
> 
> 
> 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
> 
>    - Requirements for extensions to protocols:  Charter time + 8 months to
> WG document
> 
> 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
> [email-masked]
> 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=

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 14 Jun 2015 11:40:38 +0200

Hi Dan,

thanks for your reply.
I fully agree that milestones are subject to charter discussions at the 
BOF.
I just thought it noteworthy that we don't want to ship everything at 
once but will progress to IESG LCs in successive steps as soon as the 
docs are ready. Maybe this was already obvious, otherwise please feel 
free to point it out as you suggest.

Best regards, Tobias