Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

From: "Dacheng Zhang" <[email-masked]>
Date: Wed, 13 May 2015 11:55:02 +0800

Hi，Linda:

I like the current version of charter, which clarifies a reasonable scope of
this work. Some tiny comments.

The concrete work at the L2NSF Capability Layer includes
-          The informational & data models for each category to be
represented to virtual or physical network security functions,

-          The capability registry (IANA) of policy provisioning capability
to flow based security function, and

-          The proper secure communication channels to carry the security
policies between Controller and NSFs.

>>Dacheng: the third bullet is quite trival compared with the first two bullets,
since we will try to re-use the work of I2RS,Netconf where the generation of
security channels have already considered.  So, maybe we could remove it.

The capability registry is to make it feasible to categorize network
security functions provided by different vendors based on security policy
provisioning capability without any need to standardize security functions
themselves.  Standard provisioning capability interface is an essential
building block for Security Service Provider to automate their Security
Controllers that can utilize NSF by multiple vendors. This layer will
leverage the existing protocols and data models defined by I2RS, Netconf,
and NETMOD.

>>Dacheng: I suggest to change the last sentence to “In this layer, we will
leverage the existing protocols and data models defined by I2RS, Netconf, and
NETMOD as much as possible.”

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.

>>Dacheng: the first part of this sentence is redundant. We don’t have to imply
that “we work in this way because I2RS used to do similar things. So if you want
to challenge us, please challenge I2RS first”. Maybe we could remove it.

发件人:  Linda Dunbar <[email-masked]>
日期:  2015年5月7日 星期四 下午11:53
至:  "[email-masked]" <[email-masked]>, Kathleen Moriarty
<[email-masked]>
抄送:  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
主题:  [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF
93

Thanks to I2NSF contributors for the good progresses made since  IETF92 side
meetings. Among the two I2NSF interfaces,  i.e. the client facing Service
Interface and the NSF facing Capability Interface, the work to be done at
the Capability Interface becomes very clear and concrete. But the Service
Interface is still a little vague.
 
The feedback from last IETF side meetings was "the scope is too big for one
IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to the
Capability Interface. The thinking logic is: Once the Capability Interface
is completed, we will see more clearly the work for Service interface. Even
if Capability layer alone is standardized, it is a giant leap forward in
building blocks for Service Provider to automate their Security Controller
that can utilize NSF by multiple vendors
 
Here is the narrower scoped I2NSF charter. Your comments and suggestions are
greatly appreciated. CC’ed to DOTS, I2RS, and Netmod groups for wider
review. 

 
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 European Telecommunications
Standards Institute (ETSI) Network Function Virtualization (NFV) initiative
creates new management challenges for security policies to be enforced by
distributed, virtual, network security functions (vNSF). Without standard
interface to express, monitor, and manage security policies to security
functions deployed at different premises, it becomes virtually impossible
for security service providers to automate the service offering utilizing
security functions by multiple vendors.
 
The ultimate goal of I2NSF is to enable enterprises to utilize security
functions not hosted on their own premises but instead hosted in service
provider domain, to establish how to communicate desired security policies
to NSF and how to get performance data or report out of NSF or vNSF.
 
There are two layers of interfaces:
-         Security Policies facing security functions (I2NSF Capability
Layer)

-         Security Policies facing clients (I2NSF Service Layer)

The I2NSF Capability Layer specifies the functional security policies, which
are translated from the client security policies, to security functions.
I2NSF will NOT standardize security functions or devices. Instead, I2NSF is
only to standardize the policy provisioning to the security functions (not
devices), in the form of “Subject – Object – Function – Action” paradigm.
 
The I2NSF Service Layer is for clients to express and monitor security
policies for their specific flows, which is usually based on customers’
logical networks, addresses and context. I2NSF Service Layer can also be
security expectation or loose security requirement, especially for customers
who don’t have the security expertise.
 
The concrete work at the L2NSF Capability Layer includes
-         The informational & data models for each category to be
represented to virtual or physical network security functions,

-         The capability registry (IANA) of policy provisioning capability
to flow based security function, and

-         The proper secure communication channels to carry the security
policies between Controller and NSFs.

The capability registry is to make it feasible to categorize network
security functions provided by different vendors based on security policy
provisioning capability without any need to standardize security functions
themselves.  Standard provisioning capability interface is an essential
building block for Security Service Provider to automate their Security
Controllers that can utilize NSF by multiple vendors. This layer will
leverage the existing protocols and data models defined by I2RS, Netconf,
and NETMOD.
 
For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for
now) to standardize the interface facing clients. However, I2NSF can have
informational drafts showing sample APIs or/and RESTful interfaces to
clients and demonstrating the feasibility of them being translated to the
Capability Layer policies.
 
Since different security vendors support different features & functions on
their devices, I2NSF will focus on flow based security functions that
provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow
filter. (They are different from other security functions such as
Authentication, Authorization, or Encryption). Exemplar services associated
with Flow Based Security functions include deep packet inspection,
packet/flow/stream filtering or pattern matching and remediation, etc.
 
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.

-         IANA registry consideration for flow based security function
policy provisioning capability.

-          (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 functional components and the
I2NSF work items, is to make I2NSF work more organized.]
 
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
  - IANA registry consideration + 10 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 WG will
communicate with external SDOs like ETSI NFV and will encourage open source
code development related to the WG scope in organizations like ONF,
OpenStack, ODL, and OpenNFV.

Cheers, 
Linda Dunbar
_______________________________________________ I2nsf mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 May 2015 16:26:21 +0000

Da Cheng,

You stated that the bullet for “The proper secure communication channels to carry the security policies between Controller and NSFs”  is trivial. But
SACM is considering using XMPP to exchange data among end devices (instead of NETCONF): see  https://datatracker.ietf.org/doc/draft-salowey-sacm-xmpp-grid/

So there might be more than simple NETCONF, may be TLS +xxx have to be considered.

Linda

From: Dacheng Zhang [mailto:[email-masked]]
Sent: Tuesday, May 12, 2015 10:55 PM
To: Linda Dunbar; [email-masked]; Kathleen Moriarty
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Hi，Linda:

I like the current version of charter, which clarifies a reasonable scope of this work. Some tiny comments.

-          The informational & data models for each category to be represented to virtual or physical network security functions,

-          The capability registry (IANA) of policy provisioning capability to flow based security function, and

-          The proper secure communication channels to carry the security policies between Controller and NSFs.

>>Dacheng: the third bullet is quite trival compared with the first two bullets, since we will try to re-use the work of I2RS,Netconf where the generation of security channels have already considered.  So, maybe we could remove it.

The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

>>Dacheng: I suggest to change the last sentence to “In this layer, we will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD as much as possible.”

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.

>>Dacheng: the first part of this sentence is redundant. We don’t have to imply that “we work in this way because I2RS used to do similar things. So if you want to challenge us, please challenge I2RS first”. Maybe we could remove it.

发件人: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
日期: 2015年5月7日 星期四 下午11:53
至: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
抄送: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Thanks to I2NSF contributors for the good progresses made since  IETF92 side meetings. Among the two I2NSF interfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague.

The feedback from last IETF side meetings was "the scope is too big for one IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to the Capability Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is standardized, it is a giant leap forward in building blocks for Service Provider to automate their Security Controller that can utilize NSF by multiple vendors

Here is the narrower scoped I2NSF charter. Your comments and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, and Netmod groups for wider review.

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 European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). Without standard interface to express, monitor, and manage security policies to security functions deployed at different premises, it becomes virtually impossible for security service providers to automate the service offering utilizing security functions by multiple vendors.

The ultimate goal of I2NSF is to enable enterprises to utilize security functions not hosted on their own premises but instead hosted in service provider domain, to establish how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF.

-          Security Policies facing security functions (I2NSF Capability Layer)

The I2NSF Capability Layer specifies the functional security policies, which are translated from the client security policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the form of “Subject – Object – Function – Action” paradigm.

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers’ logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don’t have the security expertise.

-          The informational & data models for each category to be represented to virtual or physical network security functions,

-          The capability registry (IANA) of policy provisioning capability to flow based security function, and

-          The proper secure communication channels to carry the security policies between Controller and NSFs.
The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for now) to standardize the interface facing clients. However, I2NSF can have informational drafts showing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.

Since different security vendors support different features & functions on their devices, I2NSF will focus on flow based security functions that provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorization, or Encryption). Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

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.

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

-          IANA registry consideration for flow based security function policy provisioning capability.

-           (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 functional components and the I2NSF work items, is to make I2NSF work more organized.]

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

The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

Cheers,
Linda Dunbar
_______________________________________________ I2nsf mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/i2nsf