Subject: [I2nsf] I2NSF Re-chartering Text

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 16 Nov 2020 01:26:47 +0900

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-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 Nov 2020 18:59:39 +0200

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-masked]> wrote:
> 
> Hi Linda and Yoav,
> 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.
> 
> 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.
> Could you schedule our online meeting to discuss this re-chartering text this IETF-109 week?
> 
> Thanks.
> 
> Best Regards,
> Paul
> -- 
> Email: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 16 Nov 2020 10:44:07 +0900

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-masked]> 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
>
> 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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Nov 2020 09:07:21 +0200

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-masked]> wrote:
> 
> Hi Yoav,
> I agree that we can schedule our online interim meeting on the week of the 29th / first week of December.
> 
> I believe that we can get more people to be engaged in the new I2NSF work items
> On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Paul
> 
>> On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Linda and Yoav,

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 16 Nov 2020 17:03:12 +0900

Hi Yoav,
It is good to me.

Thanks.

Best Regards,
Paul

On Mon, Nov 16, 2020 at 4:07 PM Yoav Nir <[email-masked]> wrote:

>> 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.
>>
>> 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.
>>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 16 Nov 2020 09:52:59 +0000

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.

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-masked]<mailto:[email-masked]>
Mobile:  +34 682 051 091
----------------------------------

On 16/11/2020, 08:07, "Yoav Nir" <[email-masked]<mailto:[email-masked]>> wrote:

Yoav

On 16 Nov 2020, at 3:44, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Yoav,

Thanks.

Best Regards,
Paul

On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Paul

Yoav

On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda and Yoav,

Linda,

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-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 16 Nov 2020 16:11:28 +0000

Yoav,

Your proposed time works for me.

Linda

From: Yoav Nir <[email-masked]>
Sent: Monday, November 16, 2020 1:07 AM
To: Mr. Jaehoon Paul Jeong <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; [email-masked]; Roman Danyliw <[email-masked]>; DIEGO LOPEZ GARCIA <[email-masked]>; Younghan Kim <[email-masked]>; 양현식 <[email-masked]>; Susan Hares <[email-masked]>; JungSoo Park <[email-masked]>; Yunchul Choi <[email-masked]>; skku-iotlab-members <[email-masked]>
Subject: Re: I2NSF Re-chartering Text

Yoav

Hi Yoav,

Thanks.

Best Regards,
Paul

Yoav

Hi Linda and Yoav,

Linda,

Thanks.

Best Regards,
Paul
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpslab.skku.edu%2Fpeople-jaehoon-jeong.php&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce3d8ca7da75d46c78bc608d889fe469d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637411072489122191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=38rnhqGTL6AKjTUt%2BRS7KbeAhTistg3zfKA4FU21T8g%3D&reserved=0>

Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcpslab.skku.edu%2Fpeople-jaehoon-jeong.php&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce3d8ca7da75d46c78bc608d889fe469d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637411072489122191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=38rnhqGTL6AKjTUt%2BRS7KbeAhTistg3zfKA4FU21T8g%3D&reserved=0>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 16 Nov 2020 17:05:07 +0000

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:

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*.

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

Dr Diego R. Lopez
Telefonica I+D

On 16/11/2020, 10:52, "Diego R. Lopez" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Be goode,

Dr Diego R. Lopez
Telefonica I+D

Yoav

Hi Yoav,

Thanks.

Best Regards,
Paul

Yoav

Hi Linda and Yoav,

Linda,

Thanks.

Best Regards,
Paul

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 17 Nov 2020 10:44:12 +0900

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-masked]>
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**.
>
> 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.
>
> 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
> 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
> 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.
>
> 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
>
>
>
> --
>
> e-mail: [email-masked]
>
> Mobile:  +34 682 051 091
>
> On 16/11/2020, 10:52, "Diego R. Lopez" <[email-masked]>
> wrote:
>
>
>
> Hi,
>
>
>
> 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**.
>
> 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.
>
> 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
> 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
> 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.
>
> o A single document for I2NSF in **container deployments**.
>
>
>
> Be goode,
>
>
>
> --
>
> e-mail: [email-masked]
>
> Mobile:  +34 682 051 091
>
> On 16/11/2020, 08:07, "Yoav Nir" <[email-masked]> wrote:
>
>
>
> ------------------------------
>
> 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
>