I2RSers and NFVRGers,

Appreciate your comments to the further trimmed I2NSF charter.

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

Thanks, Linda

From: Linda Dunbar
Sent: Wednesday, February 04, 2015 11:52 AM
To: 'Kathleen Moriarty'; [email protected]
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?


_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to