Ed Lopez and I had a 1.5 hours long talk yesterday and discussed his concern of the current I2NSF charter, his thinking of SDN approach for NSF, as well as how to focus I2NSF to make it valuable for the industry.

Here is what he thinks on what I2NSF should focus.

Ultimate goal of I2NSF:

-          Establish how to communicate with (virtual & physical) Network Security Functions (i.e. develop a standard mechanism to express security service intent and information/data model to security functions),

-          How to get performance data out of vNSF  and How to get report from (v)NSF

To make the I2NSF charter more focused, Ed suggested that I2NSF can start with Flow Based Security Functions (instead of FW devices because different vendors have different features on FW). Flow Based Security Functions provide treatment to packets/flows, such as IPS/IDS, Web filter, and Stateless flow filter. (They are different from Application layer security functions, such as email filter, virus treatment, etc). After Flow Based Security functions, the I2NSF can start to look into Stateful Security functions.

The purpose of the mentioned security functions is to make the I2NSF discussion more focused and to validate if the proposed mechanisms to communicate with NSF work properly.

To address Ed Lopez's concern of different security vendors supporting different features & functions on their devices, we updated the I2NSF charter (removed specific device name (e.g. FW), but instead focusing on Flow Based Security Functions).  Similar to I2RS focusing on the interface to RIB/FIB even though virtually all routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors' specific devices.

Based on this discussion, here is  the revised charter. What do people think?

Linda

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 layers:
  - Security Service and Policy Layer
  - Functional Layer

The Security Policy Layer is for clients to express and monitor security policies for their specific flows, which is security service oriented. This layer will leverage existing protocols, such as those defined in RESTconf, Netconf, AAA, and SACM, to carry security policies that can be expressed by Discretionary Access Control, Mandatory Access Control, Role Based Access Control, Attribute-Based Access Control, Policy-Based Access Control, or combinations of these.

The Functional layer specifies the informational and data models for security functions. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

The ultimate goal of I2NSF is to establish how to communicate with vNSF and how to get performance data or report out of vNSF.
I2NSF enables clients to communicate their specific security 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 function capability; associated Data Models will be derived from this Information Model to support Operation, Administration, Maintenance and Provisioning (OAMP) functions for security policies and security functions.

Since different security vendors support different features & functions on their devices, I2NSF will focus on a few specific functions. I2NSF will start with Flow Based Security functions. Flow Based Security Functions provide treatment to packets/flows, such as IPS/IDS, Web filter, and Stateless flow filter. (They are different from Application layer security functions, such as email filter, virus treatment, etc). Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering, and redirection (remote and local). Exemplar IDS/IDP functions includes flow/stream pattern matching and remediation, respectively.

The purpose of the focused security functions is to make the I2NSF discussion more focused and to validate if the proposed mechanisms to communicate with NSF work properly. Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors' specific devices.

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 expressing policies to the Flow Based Security Functions described above.
  - 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. The framework, that describes the reference points and functional components, is to make the discussion more focused.]

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.