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.
