Dear Linda, First, thank you for pulling together these changes. The charter development has progressed nicely.
Second, attached is a word document with my edits and suggestions for consideration by the working group. Despite the large number of edits and comments, I am very supportive of I2NSF being made a working group, and would like to volunteer to work on its deliverables. My edits and comments are to address the work that you started in better focusing the working group, and I hope that they help in this process. Best regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] 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 protected] From: I2nsf [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: [email protected]; Kathleen Moriarty Cc: [email protected]; [email protected]; [email protected] Subject: [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 charter-jcs-20150512.docx
Description: i2nsf charter-jcs-20150512.docx
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
