Subject: [I2nsf] I2NSF charter that removed specific device name (e.g. FW), but instead focusing on Flow Based Security Functions

From: Linda Dunbar <[email-masked]>
Date: Wed, 11 Feb 2015 21:20:35 +0000

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.

---

From: John Strassner <[email-masked]>
Date: Wed, 11 Feb 2015 22:44:18 +0000

Hi Linda,

I'm a bit confused about the shortening of the description of the Functional Layer. It currently says:
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.

It used to say:
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 first problem is that the current version (at least to me) does not explicitly state the need for expressing security device capabilities. IFF we are going to build a declarative (i.e., "intent-based") interface (much less language!) to request NSFs, we need to know what the security device is capable of doing. Most data models don't provide this information. (I do note that this appears later in the charter, but that seems almost to contradict the cited paragraph).

The second problem is that it loses the notion of ONE information model from which multiple data models can be derived. We currently have a growing proliferation of Yang models with no standards-based mechanism to enable them to interoperate. I'm NOT suggesting that this group solve that problem, but I am hoping that this group does not contribute to the problem. :)

I don't understand the following summary:
The ultimate goal of I2NSF is to establish how to communicate with vNSF and how to get performance data or report out of vNSF.

Why are basic things, like expressing a configuration change using an intent (i.e., declarative vs. imperative) interface not included in the summary? Furthermore, while performance data and reports are of course both important, they are both passive - they don't change anything. The hard part is doing the change.

If you want, I could edit the charter again; please let me know.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, February 11, 2015 1:21 PM
To: [email-masked]; Kathleen Moriarty; Romascanu, Dan (Dan)
Cc: Edward Lopez; Joseph Salowey
Subject: [I2nsf] I2NSF charter that removed specific device name (e.g. FW), but instead focusing on Flow Based Security Functions

Ultimate goal of I2NSF:

Linda

  - Use Case document.
  - Framework Document.

Suggested Milestones