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

IETF Secretariat <ietf-secretariat@ietf.org> Wed, 24 September 2014 20:21 UTC

Return-Path: <ietf-secretariat@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6421A19EC; Wed, 24 Sep 2014 13:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npxgl8XJjU-P; Wed, 24 Sep 2014 13:21:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DBD1A19E4; Wed, 24 Sep 2014 13:21:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Secretariat <ietf-secretariat@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
Subject: New Non-WG Mailing List: I2NSF -- Interface to Network Security Functions mailing list
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140924202105.26209.81935.idtracker@ietfa.amsl.com>
Date: Wed, 24 Sep 2014 13:21:05 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/8BKmmn8KoSPvRwu18u3E7f2O0Zs
Cc: I2NSF@ietf.org, myo.zarny@gs.com, linda.dunbar@huawei.com
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Sep 2014 20:21:09 -0000

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

List address: i2nsf@ietf.org
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.