Subject: [Lime] Fwd: New Non-WG Mailing List: I2NSF -- Interface to Network Security Functions mailing list

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Sep 2014 18:36:43 -0400

Did you gentlemen know this was on the way when you created your draft 
charter? It seems to put security out of LIME's scope if it goes anywhere.

Tom Taylor

-------- Original Message --------
Subject: New Non-WG Mailing List: I2NSF -- Interface to Network Security 
Functions mailing list
Date: Wed, 24 Sep 2014 13:21:05 -0700
From: IETF Secretariat <[email-masked]>
Reply-To: [email-masked]
To: IETF Announcement List <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]

A new IETF non-working group email list has been created.

List address: [email-masked]
Archive: http://www.ietf.org/mail-archive/web/i2nsf/
To subscribe: https://www.ietf.org/mailman/listinfo/I2NSF

Purpose:

The Interface to Network Security Functions (I2NSF) mailing list is for
discussing interfaces for clients (especially enterprises) to request,
negotiate, operate, and/or verify the network security functions that are
not physically present at requesters’ premises. Those security
functions, hosted by service providers or 3rd parties, can be 
instantiated on physical appliances, or as virtual machines instantiated 
on common compute server (i.e. the Virtualized Network Functions defined 
by ETSI NFV).

The Interface to (Virtual) Network Security Functions (I2NSF) initiative
aims at improving the dynamic allocation and operation of network security
functions by documenting a global framework that would include
protocol-based control and management interfaces, along with adequate data
models. The information required for the provisioning, the configuration
and the operation of network security functions will be exchanged through
the said interfaces and protocols. The I2NSF initiative will also take
into account the need for co-existing with legacy configuration and
management systems used to allocate and operate network security functions,
whether they are embedded in network devices or virtualized in data center
environments, for example. The standard Interface to request, negotiate,
allocate, and/or operate (virtual) Network Security Functions is one of the
necessary tools for operators and service providers to offer network
security functions as a service to their corporate clients.

Here are some examples of network security functions under consideration:

· Firewall

· DDOS/Anti-DOS

· Access control/Authorization/Authentication

· Remote identity management

· Secure Key management

· Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)

The security functions offered by 3rd party need Bi-directional periodic
communications between the requesters and the providers for policies
negotiation, validation, potentially re-directing traffic to higher level
security functions, etc. Therefore, the service requires protocol exchange
between multiple entities.

The proposed protocols between requester and provider can be used for the
following scenarios:

· A Client requests a set of certain network security functions from a
provider

· The provider fulfills the request for example, by instantiating an
instance of the service in question, or configures additional rules in an
already provisioned service.

OpenStack has done a project on FW as a service:
https://datatracker.ietf.org/doc/draft-dunbar-nsaas-problem-statement/. 
Here
is the highlight of the relationship with OpenStack:

* “Open-source initiatives are not to be considered as an alternative to
formal standardization processes. On the contrary, they are complementary,
with the former acting as an enabler and accelerator of the latter.
Open-source provides an ideal mechanism to quick prototyping and validating
contending proposals, and demonstrating the feasibility of disruptive ideas
that could otherwise not be considered. In this respect, open-source
facilitates the engagement in the standardization process of small (and
typically more dynamic) players such as start-ups and research groups, that
would see better opportunities of being heard and a clearer rewards to
their efforts. An open-source approach is extremely useful as well for the
production of open reference implementations of the standards at the same
(or even faster) pace they are defined. The availability of such reference
implementations translate into much simpler interoperability and
conformance assessments for both providers and users, and can become the
basis for incremental differentiation of a common solution, thus allowing a
cooperative competition (“coopetition”) model.”*

For additional information, please contact the list administrators.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 24 Sep 2014 14:46:11 -0800

> charter? It seems to put security out of LIME's scope if it goes anywhere.

I don't see how, Tom.  The i2nsf effort is more closely analogous
to i2rs.  It seems to me that if there's any interplay between the
two efforts (neither of which has been chartered!) it would be that
it *might* be possible for a management facility to *use* an i2nsf
api to implement the management application.

Melinda

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Sep 2014 05:42:36 +0000

Hi, Tom:
Interesting. I believe you are referred to security part of FCAPS management area. 
Yes, We haven't considered security aspect in the LIME Charter:
e.g.,
o avoid leaking OAM information to no authorized entities, 
o avoid altering OAM information exposed by each layer.
o ensure reliability of OAM information exposed by each layer.

By reading the introduction to I2NSF, it looks I2NSF work is very specific to Network security function entity rather than OAM entity.
my feeling is the protocol they proposed to address the following scenario:
"
• A Client requests a set of certain network security functions from a provider
• The provider fulfills the request for example, by instantiating an instance of the service in question, or configures additional rules in an already provisioned service.
"
Is more like RESTConf or OpenAPI.

Regards!
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Tom Taylor
发送时间: 2014年9月25日 6:37
收件人: Carlos Pignataro (cpignata); Nagendra Kumar Nainar (naikumar); LIME
主题: [Lime] Fwd: New Non-WG Mailing List: I2NSF -- Interface to Network Security Functions mailing list

Did you gentlemen know this was on the way when you created your draft charter? It seems to put security out of LIME's scope if it goes anywhere.

Tom Taylor

-------- Original Message --------
Subject: New Non-WG Mailing List: I2NSF -- Interface to Network Security Functions mailing list
Date: Wed, 24 Sep 2014 13:21:05 -0700
From: IETF Secretariat <[email-masked]>
Reply-To: [email-masked]
To: IETF Announcement List <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]

Purpose:

The Interface to Network Security Functions (I2NSF) mailing list is for discussing interfaces for clients (especially enterprises) to request, negotiate, operate, and/or verify the network security functions that are not physically present at requesters’ premises. Those security functions, hosted by service providers or 3rd parties, can be instantiated on physical appliances, or as virtual machines instantiated on common compute server (i.e. the Virtualized Network Functions defined by ETSI NFV).

The Interface to (Virtual) Network Security Functions (I2NSF) initiative aims at improving the dynamic allocation and operation of network security functions by documenting a global framework that would include protocol-based control and management interfaces, along with adequate data models. The information required for the provisioning, the configuration and the operation of network security functions will be exchanged through the said interfaces and protocols. The I2NSF initiative will also take into account the need for co-existing with legacy configuration and management systems used to allocate and operate network security functions, whether they are embedded in network devices or virtualized in data center environments, for example. The standard Interface to request, negotiate, allocate, and/or operate (virtual) Network Security Functions is one of the necessary tools for operators and service providers to offer network security functions as a service to their corporate clients.

· Firewall

· DDOS/Anti-DOS

· Secure Key management

The security functions offered by 3rd party need Bi-directional periodic communications between the requesters and the providers for policies negotiation, validation, potentially re-directing traffic to higher level security functions, etc. Therefore, the service requires protocol exchange between multiple entities.

The proposed protocols between requester and provider can be used for the following scenarios:

· A Client requests a set of certain network security functions from a provider

· The provider fulfills the request for example, by instantiating an instance of the service in question, or configures additional rules in an already provisioned service.

* “Open-source initiatives are not to be considered as an alternative to formal standardization processes. On the contrary, they are complementary, with the former acting as an enabler and accelerator of the latter.
Open-source provides an ideal mechanism to quick prototyping and validating contending proposals, and demonstrating the feasibility of disruptive ideas that could otherwise not be considered. In this respect, open-source facilitates the engagement in the standardization process of small (and typically more dynamic) players such as start-ups and research groups, that would see better opportunities of being heard and a clearer rewards to their efforts. An open-source approach is extremely useful as well for the production of open reference implementations of the standards at the same (or even faster) pace they are defined. The availability of such reference implementations translate into much simpler interoperability and conformance assessments for both providers and users, and can become the basis for incremental differentiation of a common solution, thus allowing a cooperative competition (“coopetition”) model.”*

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