Network security functions (NSFs) are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors.

The primary goal of I2NSF is to define an information model,  a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

There are two layers of interfaces envisioned in the I2NSF approach:

*       I2NSF Capability Layer

*       I2NSF Service Layer

The I2NSF capability layer specifies how to control and monitor NSFs at functional level.  (I2NSF will NOT work on any other aspects of NSFs including standardizing NSFs or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher level security policies for the Capability layer).  I2NSF will only standardize the security policies related to the control and monitoring of the NSFs.  A sample capability layer construct for controlling NSFs is "subject-object-function-action".

The I2NSF Service Layer defines how clients' security policies may be expressed and monitored. The Service Layer is out of scope for this phase of I2NSF's work. However, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer policies may be translated to Capability Layer functions.

The concrete work at the I2NSF Capability Layer includes development of

-          An information model that defines concepts required for standardizing the control  and monitoring of NSFs,

-          A set of YANG data models, derived from the above information model.

-          The capability registry (IANA) that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized; the registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment, and

-          The proper secure communication channels to carry the controlling and monitoring information between the NSFs and their management entity (or entities).

 Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for Security Service Providers to automate the use of different NSFs from multiple vendors by their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.
The I2NSF WG's deliverables include:


-          Use Cases document.

-          Framework Document.

-          Requirements for extensions (if any) to existing protocols used by the WG.

-           Gap analysis of existing protocols and modeling languages for specifying, querying, monitoring, and controlling NSFs.

-          A single, unified, Information Model for controlling and monitoring flow-based NSFs.

-          Corresponding YANG Data Models derived from the above Information Model.

-          IANA registry consideration for flow-based NSFs controlling and monitoring capabilities.

-          (Optionally) Document describing how capabilities are used to monitor and control flow-based NSFs.

-          (Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specified information/data models.

[The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG.]

Suggested Milestones
  - Use Cases Document:  Charter time + 1 month to WG Document
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 8 months to WG document
  - Info model: Charter time + 8 months to WG Document
  - IANA registry consideration + 12 months to WG Document
  - All Early Drafts to IESG: 18 months

[decision point - +10 months]
  - Data Models: Charter + 9 Months to WG Document
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 18 months

The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OPNFV.