Subject: [I2nsf] Revised Charter Text

From: John Strassner <[email-masked]>
Date: Thu, 5 Feb 2015 22:34:58 +0000

I tried to clarify and tighten the language used in the charter. Here is the new version (a tracked Word version is also available if desired):

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 Policy Layer
  - Capability (or Functional) Layer

The Security 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 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 capabiltiies.  The models will include at least 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 include flow/stream pattern matching and remediation, respectively.

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

I2NSF WG Deliverables include:

  - 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 used by the WG. 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 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.

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 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.

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: "Susan Hares" <[email-masked]>
Date: Thu, 5 Feb 2015 19:47:04 -0500

The following is repetitive:

  - 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 used
by the WG. 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

Reduce this to

-          Use case document 

-          Framework document

-          Requirements for extensions to existing protocols used by WG 

-          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 case, Framework, and Requirement are
Informational documents or simply reference documents during the lifetime of
the WG.

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, February 05, 2015 5:35 PM
To: [email-masked]
Cc: John Strassner
Subject: [I2nsf] Revised Charter Text

I tried to clarify and tighten the language used in the charter. Here is the
new version (a tracked Word version is also available if desired):

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 Policy Layer

The Security 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 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 capabiltiies.  The
models will include at least the following security functions:

 

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 include flow/stream pattern matching and
remediation, respectively.

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

  - 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 used
by the WG. 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

  - 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.

Suggested Milestones

  - Requirements for extensions to protocols:  Charter time + 6 months to WG
document

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

regards,

John

logo.gif

Futurewei Technologies

US R&D Center

2330 Central Expressway

  Office:  +1.408.330.4923

---

From: John Strassner <[email-masked]>
Date: Fri, 6 Feb 2015 01:06:50 +0000

Agreed. Thanks Sue.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, February 05, 2015 4:47 PM
To: John Strassner; [email-masked]
Subject: RE: [I2nsf] Revised Charter Text

Reduce this to

-          Use case document

-          Framework document

-          (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 case, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG.

Sue

Suggested Milestones

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 6 Feb 2015 02:39:08 +0000

Sue,

Thank you very much for the suggestion.

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, February 05, 2015 6:47 PM
To: John Strassner; [email-masked]
Subject: Re: [I2nsf] Revised Charter Text

Reduce this to

-          Use case document

-          Framework document

Sue
From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, February 05, 2015 5:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: John Strassner
Subject: [I2nsf] Revised Charter Text

Suggested Milestones

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923