Does Thursday, December 3rd at 14:00 UTC work for everyone? It’s 16:00 for me, 15:00 for much of Europe, 9:00 AM EST, 6:00 AM PST, and unfortunately, 23:00 in Seoul.
I’ll wait 24 hours before scheduling the meeting in case there are objections. Yoav > On 16 Nov 2020, at 3:44, Mr. Jaehoon Paul Jeong <[email protected]> > wrote: > > Hi Yoav, > I agree that we can schedule our online interim meeting on the week of the > 29th / first week of December. > > Could you schedule such an interim meeting? > > I believe that we can get more people to be engaged in the new I2NSF work > items > other than the authors of the current I2NSF WG and individual drafts. > With those people, I hope our I2NSF WG can have more energy. :) > > Thanks. > > Best Regards, > Paul > > On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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> > > > > -- > =========================== > 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
