Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises.  In addition, the ETSI Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). These trends require a standard interface to express, monitor, and manage security policies for physical and virtual distributed security functions that may be running on different premises.

In order to address the above challenges, vNSF devices may include two functional layers:
  - Security Service and Policy Layer
  - Capability (or Functional) Layer

The Security Service and Policy Layer is for clients to express and monitor security policies for their specific flows. This layer will leverage existing protocols, such as those defined in Netconf, AAA, and SACM, to carry new abstractions that support Discretionary Access Control, Mandatory Access Control, Role Based Access Control, Attribute-Based Access Control, Policy-Based Access Control, or combinations of these.

The Capability (or Functional) Layer specifies how client security policies can request the capabilities of security devices, and then map security policies to a form that security devices can use. This requires the definition of an information model, along with one or more data models, to represent virtual and physical security functions and devices. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

The Interface to Network Security Functions (I2NSF) enables clients to communicate their specific security services and policies (request/monitor/report) to a system, and map these security policies to the security functions present in security devices in that system.  I2NSF will specify a set of standardized mechanisms for clients and applications to request, negotiate, manage, and validate security functions using a declarative programmatic interface to physical and virtual devices. In order to support this programmatic interface, an Information Model will be defined to serve as a common vocabulary of security policy concepts and security device capabilities; associated Data Models will be derived from this Information Model to support Operation, Administration, Maintenance and Provisioning (OAMP) functions for security policies and security device capabilities.  The models will include at least the services provided by the following security functions:

  - Firewall, and its associated services
  - Intrusion Detection System / Intrusion Prevention System (IDS/IPS)


Exemplar services associated with a firewall include stateful or deep packet inspection, packet/flow/stream filtering, and redirection (remote and local). Exemplar IDS/IDP functions includes flow/stream pattern matching and remediation, respectively.

It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

  - Use Case document.
  - Framework Document.
  - Requirement for extensions (if there are any) to existing protocols used by the WG.
  - Gap analysis of existing protocols and modeling languages
  - A single, unified, Information Model for the security functions listed above and associated capabilities.
  - Corresponding Data Models (e.g. YANG models) derived from the above Information Model.
  - (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 Case Document:  Charter time + 1 month to WG Document
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 6 months to WG document
  - Info model: Charter time + 7 months to WG Document
  - All Early Drafts to IESG: 10 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  - 16 months

The WG will work closely with I2RS, Netconf and Netmod WGs.

The framework, that describes the reference points and functional components, is to make the discussion more focused.