Hi, Paul

As Roman said in a separate email message, we can’t schedule a meeting during 
IETF week. It also requires two weeks notice, so it anyway can only be done on 
the week of the 29th / first week of December.

That’s not a bad thing: it will give people enough time to read the charter and 
form an opinion before coming to the meeting.

If and when we have this meeting, I think we need to get a good number (5 
maybe?) or people who are not authors and will commit to reviewing the proposed 
documents. I think it is very obvious that this working group has lost energy, 
and we wouldn’t want to take on more work unless there is a clear indication 
that there will be such energy going forward.

Yoav

> On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong <[email protected]> 
> wrote:
> 
> 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: [email protected] <mailto:[email protected]>, 
> [email protected] <mailto:[email protected]>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>

_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf

Reply via email to