[I2nsf] secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: Further Narrowing the I2NSF scope: the new charter for IETF 93

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, May 12, 2015 10:55 PM
To: Linda Dunbar; [e-mail]; Kathleen Moriarty
Cc: [e-mail]; [e-mail]; [e-mail]
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 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 <[e-mail]<mailto:[e-mail]>>
日期: 2015年5月7日 星期四 下午11:53
至: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>
抄送: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
主题: [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 [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/i2nsf