Hi Linda and Yoav, Here is the text for I2NSF WG Re-chartering. --------------------------------------------------------------------------------------------------------------- Charter for Working Group
Interface to Network Security Functions (I2NSF) provides security vendors with a standard framework and interfaces for cloud-based security services. I2NSF enables the enforcement of a high-level security policy of a user's perspective in a target network (e.g., cloud network and edge network). This security policy enforcement in I2NSF is a data-driven approach using NETCONF/YANG or RESTCONF/YANG where a security policy is constructed into an XML file based on a YANG data model. The I2NSF framework consists of four components such as I2NSF User, Security Controller, Network Security Function (NSF), and Developer's Management System (DMS). I2NSF User specifies a high-level security policy for a target network (e.g., cloud network). Security Controller maintains the capability of an NSF and takes a security policy from I2NSF User for the enforcement of the corresponding security service. An NSF performs a specific security service (e.g., firewall, web filter, deep packet inspection, and DDOS-attack mitigator) according to a security policy rule. DMS registers the capability of an NSF with Security Controller. The I2NSF framework has four interfaces such as Consumer-Facing Interface, NSF-Facing Interface, Registration Interface, and Monitoring Interface. Consumer-Facing Interface is used to deliver a high-level security policy from I2NSF User to Security Controller. NSF-Facing Interface is used to deliver a low-level security policy from Security Controller to an NSF. Registration Interface is used to register the capability of an NSF with Security Controller. Monitoring Interface is used to collect monitoring data from an NSF. The goal of I2NSF is to define a set of software interfaces and data models of such interfaces for configuring, maintaining, and monitoring NSFs in Network Functions Virtualization (NFV) environments. For security management automation in an autonomous security system, I2NSF needs to have a feedback control loop consisting of security policy configuration in an NSF, monitoring for an NSF, data analysis for NSF monitoring data, feedback delivery, and security policy augmentation/generation. For this security management automation, the I2NSF framework requires a new component to collect NSF monitoring data and analyze them, which is called I2NSF Analyzer. Also, the I2NSF framework needs a new interface to deliver a feedback message for security policy adjustment from I2NSF Analyzer to Security Controller. I2NSF is vulnerable to an inside attack and a supply chain attack since it trusts in NSFs provided by DMS, assuming that NSFs work for their security services appropriately. Also, I2NSF trusts in I2NSF User and Security Controller. The registration of an NSF's capability, the enforcement of a security policy from either I2NSF User or Security Controller, and the monitoring data from an NSF are assumed to be genuine and non-malicious. If one of such activities is malicious, the security system based on I2NSF may collapse. To prevent this malicious activity from happening in the I2NSF framework or detect the root of a security attack, all the activities in the I2NSF framework should be logged in either a centralized way or a decentralized way (e.g., blockchain). Also, the operations and activities of the I2NSF components (i.e., I2NSF User, Security Controller, NSF, DMS, and I2NSF Analyzer) need to be verified by remote attestation. Furthermore, an NSF can be instantiated as either a Virtual Network Function (VNF) in an NFV-based cloud or a container in a native cloud. The current YANG data models for the I2NSF interfaces are designed on the basis of VNF, so they need to be redesigned for the case where I2NSF components are instantiated by containers. The I2NSF working group's deliverables include: o A single document for an extension of I2NSF framework for security management automation. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC. o A YANG data model document for I2NSF Application Interface to deliver feedback from I2NSF Analyzer to Security Controller. o A single document for applicability and use cases in I2NSF-based security management automation. o A single document for security policy translator to support the mapping between a high-level YANG module and a low-level YANG module: the working group may decide to not publish this document as an RFC. o A single document for remote attestation for I2NSF components. o A single document for I2NSF in Cloud Native NFV Architecture. --------------------------------------------------------------------------------------------------------------- Linda, Could you schedule our online meeting to discuss this re-chartering text this IETF-109 week? Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.p...@gmail.com, paulje...@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
