Hi Diego, Your augmented text for the I2NSF re-chartering looks good to me. Thanks for the improved text.
Linda and Yoav, Let's use this text for our discussion on the re-chartering. Thanks. Best Regards, Paul On Tue, Nov 17, 2020 at 2:05 AM Diego R. Lopez <[email protected]> wrote: > Hi, > > > > A couple of additions (in blue this time, and surrounded by asterisks > anyway) that came to my mind reviewing the agendas and documents of related > WG (specifically, s: > > > > Interface to Network Security Functions (I2NSF) provides security * > *function** vendors **users, and operators** with a standard framework > and interfaces for cloud-based security services. I2NSF enables the > enforcement of a high-level security policy, **expressed according to a** > user's perspective **of the target network**. This security policy > enforcement in I2NSF is a data-driven approach using NETCONF/YANG or > RESTCONF/YANG, where a security policy is constructed **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). The 2NSF User specifies a high-level security > policy for a target network. The Security Controller **is aware of the > capabilities of the attached **NSF**s, using them to build the security > service(s) satisfying the policy expressed by the I2NSF User**. An NSF * > *provides** a **set of** specific security **capabilities** (e.g., > firewalling, web filtering, packet inspection, DDOS-attack mitigation…), * > *applying** security policy rules. The DMS registers the capabilities of > an NSF with the 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 high-level security policies > from the I2NSF User to the Security Controller. NSF-Facing Interface is > used to deliver low-level security policies from the Security Controller > to an NSF. The Registration Interface is used to register the capabilities > of an NSF with the Security Controller. The 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 **cloud environments**, including NFV and edge deployments**. 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 feedback messages for security policy > adjustment from I2NSF Analyzer to Security Controller. **A proper > translation of the planned actions onto NSF capabilities requires a > well-defined model for representing these actions**. > > I2NSF is vulnerable to inside and supply chain attacks since it trusts * > *NSF** capability declarations **as** provided by DMS, assuming that NSFs > work **appropriately **in all circumstances, as well as I2NSF User’s > policy declarations and the actions of the Security Controller**. The > registration of NSF capabilities, the **declaration** of a security > policy from either the I2NSF User or **its enforcement by the** 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 or decentralized (e.g., blockchain) way. Also, the **provenance > and status** of the I2NSF components (i.e., I2NSF User, Security > Controller, NSF, DMS, and I2NSF Analyzer) need to be verified by remote > attestation, **leveraging the current results mostly focused on IT > environments**. > > Finally, the current YANG data models for the I2NSF interfaces **are > designed on the basis of **NSFs implemented as virtual machines, **and > therefore** 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. **This document > will apply the recommendations under discussion in NETMOD and OPSAWG on > event modeling**. > o A single document for remote attestation for I2NSF components, **based > on the work of the RATS WG**. > o A single document for I2NSF on **container deployments**. > > > > Be goode > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > https://www.linkedin.com/in/dr2lopez/ > > > > e-mail: [email protected] > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 16/11/2020, 10:52, "Diego R. Lopez" <[email protected]> > wrote: > > > > Hi, > > > > The date does suit me reasonably. Thanks, Yoav! > > > > I am not sure if I am counted as an author of the recharter proposal, but > let me share with you a few suggested changes (highlighted in red and with > asterisk around, in case you do not enjoy an HTML-enabled email reader: > > > > Interface to Network Security Functions (I2NSF) provides security * > *function** vendors **users, and operators** with a standard framework > and interfaces for cloud-based security services. I2NSF enables the > enforcement of a high-level security policy, **expressed according to a** > user's perspective **of the target network**. This security policy > enforcement in I2NSF is a data-driven approach using NETCONF/YANG or > RESTCONF/YANG, where a security policy is constructed **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). The 2NSF User specifies a high-level security > policy for a target network. The Security Controller **is aware of the > capabilities of the attached **NSF**s, using them to build the security > service(s) satisfying the policy expressed by the I2NSF User**. An NSF * > *provides** a **set of** specific security **capabilities** (e.g., > firewalling, web filtering, packet inspection, DDOS-attack mitigation…), * > *applying** security policy rules. The DMS registers the capabilities of > an NSF with the 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 high-level security policies > from the I2NSF User to the Security Controller. NSF-Facing Interface is > used to deliver low-level security policies from the Security Controller > to an NSF. The Registration Interface is used to register the capabilities > of an NSF with the Security Controller. The 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 **cloud environments**, including NFV and edge deployments**. 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 feedback messages for security policy > adjustment from I2NSF Analyzer to Security Controller. > > I2NSF is vulnerable to inside and supply chain attacks since it trusts * > *NSF** capability declarations **as** provided by DMS, assuming that NSFs > work **appropriately **in all circumstances, as well as I2NSF User’s > policy declarations and the actions of the Security Controller**. The > registration of NSF capabilities, the **declaration** of a security > policy from either the I2NSF User or **its enforcement by the** 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 or decentralized (e.g., blockchain) way. Also, the **provenance > and status** of the I2NSF components (i.e., I2NSF User, Security > Controller, NSF, DMS, and I2NSF Analyzer) need to be verified by remote > attestation. > > Finally, the current YANG data models for the I2NSF interfaces **are > designed on the basis of **NSFs implemented as virtual machines, **and > therefore** 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 **container deployments**. > > > > Be goode, > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > https://www.linkedin.com/in/dr2lopez/ > > > > e-mail: [email protected] > > Mobile: +34 682 051 091 > > ---------------------------------- > > > > On 16/11/2020, 08:07, "Yoav Nir" <[email protected]> wrote: > > > > 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]> 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]> > 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], [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], [email protected] > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > <http://cpslab.skku.edu/people-jaehoon-jeong.php> > > > > ------------------------------ > > 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 > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: [email protected], [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
