Hi, Agree with Dan (and therefore Myo) in the suggested changes and in the fact that mentioning ETSI out of the introduction is fine.
And just a minor nit: I'd refrain to mention DPI as an exemplar function (the days of DPI as we know it days are close to be over, given the current concerns about privacy and the usage of E2E encryption) and rephrase the sentence mentioning it from "Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc." into "Exemplar services associated with Flow Based Security functions include malware detection, packet/flow/stream filtering or pattern matching and remediation, etc." Be goode, On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) <[email protected]<mailto:[email protected]>> wrote: I am fine with the editing proposed by Myo as it makes the scope more clear. Maybe the only thing I would suggest is to use ‘non-standard’ rather than ‘bespoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points to the fact that we are aiming to work in cooperation with other SDOs and avoid duplicating work. In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduction is fine. Thanks and Regards, Dan From: I2nsf [mailto:[email protected]] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; '[email protected]<mailto:[email protected]>'; 'Kathleen Moriarty' Cc: '[email protected]<mailto:[email protected]>'; '[email protected]<mailto:[email protected]>'; '[email protected]<mailto:[email protected]>' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to be tightened if it is to be meaningful. I’m fine with the suggested deliverables, milestones, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a position on where the security functions are hosted or if the caller and the security service function belong to the same or different domains. Also, not sure if we should bring in another organization’s name (ETSI) into an IETF charter. I’ve taken a stab at rewording the first few paragraphs… Network security functions (NSFs) are increasingly provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers may offer their customers network security services that consist of multiple security products from different vendors. Yet because no widely accepted industry standard security interfaces exist today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be bespoke, essentially as offered by product vendors. As a result, automation of such services, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models for policy provisioning and management aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: • I2NSF Capabilities Layer • I2NSF Services Layer … I’ve made a few comments inline below as well. I’m not familiar with how detailed a charter needs to be, so I’ll leave it others to comment on whether the level of detail here is sufficient, too much or too light. Myo From: I2nsf [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: [email protected]<mailto:[email protected]>; Kathleen Moriarty Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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. MZ: Not sure if we need to explicitly specify a potential solution(“Subject-Object-Function-Action”) in the charter. 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. MZ: I suggest “I2NSF Services Layer provides a set of interfaces for clients to express and monitor security policies. The policies may be intent-based.” 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 protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
