> 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:
> 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.
To see the collection of prior postings to the list,
visit the Nsaas
Archives or Nsaas MHonArc Archives.
Subscribe to Nsaas by filling out the following
You will be sent email requesting confirmation, to
prevent others from gratuitously subscribing you. This is a private list, which means that the
list of members is not available to non-members.