Subject: [sacm] FW: New Non-WG Mailing List: NSaaS: Network Security as a Service

From: Linda Dunbar <[email-masked]>
Date: Mon, 11 Aug 2014 22:54:09 +0000

The benefits of virtualized network functions are to increase the flexibility to share resources and decrease setup and management costs. NSaaS is to focus on a small aspects of NFV: how Enterprises and other service providers (operators) may deploy certain services based on a service catalog within the network of a hosting service provider (hosting operator). 

There are many network functions being deployed and new ones are popping up with business and application demands. NSaaS focus on the following security related functions: 
-	Firewall
-	DDOS/AntiDoS 
-	Access control/Authorization/Authentication
-	Intrusion detection system/ Intrusion prevention system
-	Threat detection: Eavesdropping, Trojans, Viruses and worms, Malware, …

The reason for starting with security-related functions is due to the wide acceptance of security functions that are not running on customer/enterprise premises. Numerous security vendors are now leveraging cloud based models to deliver security solutions. This shift has occurred for a variety of reasons including greater economies of scale, streamlined delivery mechanisms, and the demand of business and applications for more sophisticated security functions that they do not have.  Consumers, enterprise clients as well as applications are embracing the business model of requesting for security functions that do not run on their own premises on demand, a.k.a. Security as a Service.

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. 

In order to make the service function available to wider range of clients, it is necessary to have standard interfaces.

[email-masked] list is for the purpose of this discussion. 

If you are interested, please subscribe to the list. 

Linda

-----Original Message-----
From: IETF Secretariat [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 5:16 PM
To: IETF Announcement List
Cc: Linda Dunbar; [email-masked]; [email-masked]
Subject: New Non-WG Mailing List: NSaaS: Network Security as a Service

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

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

Purpose:

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

 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  NFV).

 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;  or

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

 Even though OpenStack has done a project on FW as a service:
 https://datatracker.ietf.org/doc/draft-dunbar-nsaas-problem-statement/, 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.