Subject: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added

From: Linda Dunbar <[email-masked]>
Date: Wed, 4 Feb 2015 18:20:22 +0000

I2RSers and NFVRGers,

Appreciate your comments to the further trimmed I2NSF charter.

Please copy your comments to [email-masked]<mailto:[email-masked]>

Thanks, Linda

From: Linda Dunbar
Sent: Wednesday, February 04, 2015 11:52 AM
To: 'Kathleen Moriarty'; [email-masked]
Cc: 'Romascanu, Dan (Dan)'; Joseph Salowey
Subject: further trimed the I2NSF charter, with the timeline for deliverables added

Kathleen,

Thank you very much for the I2NSF BOF preparation call yesterday and the suggestion of further narrowing the scope.

With Dan Romascanu's help, we further trimmed down the scope of I2NSF to make the charter more focused.

We also incorporated the comments received from the I2NSF mailing list.

Here is the revised charter, with the timeline for the deliverables added.
Comments and suggestions are greatly appreciated.

Thanks, Linda

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

vNSF devices include two functional layers:

-          Security Policy Layer, which is for clients to express & monitor the needed security policies for their specific flows.  This layer will leverage the existing protocols in RESTconf, AAA, SACM, and security policy expression using Role Based Access Control (RBAC), Mandatory Access Control (MAC), or Attribute-based access control (ABAC).

-          Capability (or Functional) Layer, which specifies the information/data models to Security functions/devices (virtual & physical). This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate their specific security policies (request/monitor/report) to security functions.  I2NSF will specify a vNSF framework, requirements for programmatic interface to vNSF devices (configuration and dynamic programmatic)[L1]     , and Information and Data models for security functions' Operation, Administration, Maintenance and Provisioning (OAM).  The information models will include the following security functions:

*       Firewall
including various services associated with FW, such as stateful or deep packet inspection,  packet/flow/stream filtering and redirect (remote and local), etc

*       Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)
Including intrusion detection (flow/stream pattern matching)

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

I2NSF WG Deliverables

-          Use Case document - the WG will decide in a later phase if this document will become an Informational RFC, or will just be used as a reference during the WG lifetime

-          Framework Document - the WG will decide in a later phase if this document will become an Informational RFC, or will just be used as a reference during the WG lifetime

-          Requirement for extensions (if there are any) to existing protocols at security layer and capability - the WG will decide in a later phase if this document will become an Informational RFC, or will just be used as a reference during the WG lifetime

-          Gap analysis of existing protocols and data modeling language

-          Information Models for the security functions listed above and associated capabilities.

-          Corresponding Data Models (e.g. YANG model).

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

Suggested Milestones

-          Use 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 models: Charter time + 8 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.

Is it better to be left out to emphasize the final deliverables?