> 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.
>
To see the collection of prior postings to the list,
visit the Nsaas
Archives.
|
Subscribe to Nsaas by filling out the following
form.
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.
|