Subject: Re: [Nfvrg] I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

From: Sumandra Majee <[email-masked]>
Date: Mon, 29 Sep 2014 20:51:50 +0000

Hi,

I believe it is critical to start working on 1/2 use cases which includes the workflow. Something like,
   If (event X) then
         Install rule Y on FW f1
         Monitor on M1
And so on.

The APIs can be helpful for NFVRG but I don’t see any direct relation of this with VNF.

Regards.

Sumandra

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 25, 2014 at 9:49 AM
To: "Natale, Bob" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Nfvrg] I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

Bob,

Thank you very much for the suggestions.
How about this order?

The intended deliverables will include:

·       Tightly scoped key use cases for operational use of I2VNSF

·       Problem statement

·       An analysis of existing IETF and other protocols and encoding
languages against the requirements derived from the problem statement and use case documents.

·       High-level architecture for I2VNSF security policy request/negotiation/validation

·       Abstract information models consistent with the use cases.

Linda

From: Natale, Bob [mailto:[email-masked]]
Sent: Thursday, September 25, 2014 11:38 AM
To: Linda Dunbar
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

Hi Linda,

Given the (implied) order of your list of intended deliverables below, I believe that what is currently shown as the last item (analysis of existing IETF and other protocols and encoding languages) should be moved up to at least the third position (i.e., following the “Problem statement”) … it could conceivably even occur after the first item (use cases) as a means of further refining  the problem statement a priori.

Avanti,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, September 25, 2014 12:05 PM
To: ramki Krishnan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

Ramki,

Thank you very much for the feedback.  You point out a very important area for the I2NSF work: data model & information model. we’re informally thinking of modeling work going forward on the I2RS working group.

I2NSF aims at documenting a high-level architecture that will describe the functional building blocks for the dynamic negotiation of security service parameters, the dynamic and subsequent allocation of network security resources and the operation of such resources, including means to assess that what has been allocated complies with what has been negotiated. The work to be conducted by the I2NSF WG also includes the documentation of use cases as well as the specification of information and data models that will provide the adequate level of abstraction. In addition, the I2NSF WG will analyze candidate protocols that may carry the information to be exchanged through the various interfaces (e.g., between a customer and a service provider, between the control plane and the data plane, etc.) for the purpose of network security resource negotiation, allocation and operation. Small and well-scoped use cases are critical to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes.

The intended deliverables will include:

·       Tightly scoped key use cases for operational use of I2VNSF

·       Problem statement

·       High-level architecture for I2VNSF security policy request/negotiation/validation

·       Abstract information models consistent with the use cases.

·       An analysis of existing IETF and other protocols and encoding
languages against the requirements derived from the problem statement and use case documents.

Linda

From: ramki Krishnan [mailto:[email-masked]]
Sent: Wednesday, September 24, 2014 7:52 PM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: RE: I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

Hi Linda,

Thanks for your note on I2NSF. The work produced by NFVRG is certainly complementary. Also, please keep in mind that NFVRG does not produce any standards.

Based on the charter, it looks like the goal of I2NSF is to standardize the northbound (service) interface of various network security functions. Do we need a new protocol for this? In my opinion, the information/data model is the critical piece of the puzzle.

Thanks,

Ramki

-----Original Message-----
From: Nfvrg [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, September 24, 2014 2:46 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Nfvrg] I2NSF (was NSaaS) -- Interface to Network Security Functions can be one of the tools for NFVRG

Based on the feedback that we’ve received on the NSaaS list, we are narrowing down the scope to Interface to Network Security Function (I2NSF). We believe that the I2NSF is one of the enabling tools for Network Security as a Service (NSaaS), which is a subset of VNF as a Service specified by ETSI NFV Group Specification Use Cases (gs_NFV001v010101p).

We are hoping that work produced by NFVRG research group can complement the work to be developed by I2NSF. Here is the detailed description of the narrower scoped I2NSF. Appreciate comments and suggestions.

Cheers,  Linda Dunbar

-----Original Message-----

From: IETF Secretariat [mailto:[email-masked]]

Sent: Wednesday, September 24, 2014 3:21 PM

To: IETF Announcement List

Cc: Linda Dunbar; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

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

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

List address: [email-masked]<mailto:[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.

_______________________________________________

Nfvrg mailing list

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

https://www.irtf.org/mailman/listinfo/nfvrg