Re: [I2nsf] I2NSF Re-chartering Text

["Diego R. Lopez" <[e-mail]>]

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 NSFs, 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: [e-mail]<mailto:[e-mail]>
Mobile:  [phone]
----------------------------------

On 16/11/2020, 10:52, "Diego R. Lopez" <[e-mail]<mailto:[e-mail]>> 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 NSFs, 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: [e-mail]<mailto:[e-mail]>
Mobile:  [phone]
----------------------------------

On 16/11/2020, 08:07, "Yoav Nir" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
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: [phone]
Email: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
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