New Non-WG Mailing List: NSaaS: Network Security as a Service

IETF Secretariat <> Mon, 11 August 2014 22:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C3D51A024E; Mon, 11 Aug 2014 15:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zEDzvl7-9oUr; Mon, 11 Aug 2014 15:15:41 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 77BFE1A01FF; Mon, 11 Aug 2014 15:15:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Secretariat <>
To: IETF Announcement List <>
Subject: New Non-WG Mailing List: NSaaS: Network Security as a Service
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Mon, 11 Aug 2014 15:15:41 -0700
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Aug 2014 22:15:43 -0000

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

List address:
To subscribe:


 Network Security as a Service (NSaaS) mailing list is for discussing
 topics related to protocols (or the interface) and architectures for
 “Requesters” to negotiate the network security related functions, that are
 not physically present at Requesters’ premises, as well as the associated

 The security functions under discussion are the ones that can be requested
 by one domain (e.g., two different domains of one service provider,
 enterprise clients, or applications, etc.) but may be owned or managed by
 another domain (e.g., service provider). Those security functions may be
 hosted on physical appliances or instantiated as virtual machines on common
 compute server (i.e. the Virtualized network functions defined by ETSI

 The “requester <-> provider” relationship has different connotations in
 different scenarios:

 · Client <-> Provider relationship, i.e. client requesting some
 network functions from its provider;

 · Inter-domain, e.g. Domain A <-> Domain B relationship, i.e. one
 operator domain requesting some network functions from another operator
 domain, where “A” and “B” can be from same operator or different operators;

 · Applications <-> Network relationship, i.e. an application (e.g.
 cluster of servers) requesting some functions from network, etc.

 The security functions offered by 3rd party need Bi-directional periodic
 communications between the requesters and the providers for policy
 negotiation, validation, potentially re-directing traffic to higher level
 security functions, etc. Therefore, the service requires protocol exchange.
 Simply, an API is not enough.

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

 · A Client requests a certain network security function from a

 · 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.

 Even though OpenStack has done a project on FW as a service:, the
 specifications are very primitive, far from enough for NSaaS, due to it is
 open source code and there is no validation on its accuracy or
 completeness. Our goal is for IETF to take up the role of defining the
 complete specification, and providing a hand-off to OpenStack or other Open
 Source communities to provide the source code. 

For additional information, please contact the list administrators.