Subject: Re: [I2nsf] A Proposed Charter for I2NSF WG Re-Chartering

From: "Panwei (William)" <[email-masked]>
Date: Mon, 14 Mar 2022 10:53:47 +0000

Hi Paul, all,

Sorry for the late response.

I feel the re-chartering text below seems not well-organized. The Goals part makes me feel that they are just given by what drafts exist now, not from the perspective of use cases or scenarios. The Program of Work part has deepened this feeling.
I think the new works focus on three aspects: to enhance the automation capability, to increase the security, and to expand the deployable scenario. I suggest re-organizing the goals to put the related content together. The texts could be developed as “to enhance XXX capability, YYY now is missing, or ZZZ is needed”.

> However, the following key components for I2NSF are currently out of I2NSF scope without
> rechartering:

I suggest changing this sentence to “the following key components for I2NSF are needed”. Because “without rechartering” will cause confusion that the following part are not covered in the current charter, and this new charter will become “current charter” when it gets approved.

o I2NSF is vulnerable to insider and supply chain attacks. The security system may collapse
   if there is a malicious attack to the NSF capabilities registration, the I2NSF user security
   policies declaration, the Security Controller, or the monitoring data from an NSF. 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 (e.g., database) or a decentralized way (e.g., Blockchain as a distributed
   ledger technology (DLT)).

I am not quite convinced that DLT is used to mitigate the supply chain attacks. However, the following use of remote attestation can somehow mitigate this threat. The remote attestation can prove the I2NSF components’ integrity which would be compromised if the supply chain attacks happened.

Regards & Thanks!
Wei Pan (潘伟)

From: I2nsf [mailto:[email-masked]] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Wednesday, February 16, 2022 1:06 AM
To: [email-masked]
Cc: Roman Danyliw <[email-masked]>; Diego R. Lopez <[email-masked]>; ANTONIO AGUSTIN PASTOR PERALES <[email-masked]>; Yoav Nir <[email-masked]>; JungSoo Park <[email-masked]>; Linda Dunbar <[email-masked]>; yangpenglin <[email-masked]>; Younghan Kim <[email-masked]>; Patrick Lingga <[email-masked]>; Meiling Chen <[email-masked]>; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>; Yunchul Choi <[email-masked]>
Subject: [I2nsf] A Proposed Charter for I2NSF WG Re-Chartering

Hi I2NSF WG,
Here is a proposed charter for I2NSF WG re-chartering.
I have prepared for this new charter with I2NSF WG chair Linda, Diego,
Antonio, Patrick, Penglin, Meilin, Younghan, Jung-Soo, and Yunchul.

--------------------------------------------------------------------------------------------------
Charter for Working Group

Introduction
===============

Interface to Network Security Functions (I2NSF) provides security function vendors, users,
and operators with a standard framework and interfaces for cloud-based security services.
The I2NSF framework for those security services consists of I2NSF User, Security Controller,
Network Security Functions (NSF), Developer's Management System (DMS), and I2NSF
Analyzer.

Goals
===============

I2NSF Working Group (WG) will standardize a framework and interfaces for security
management automation in an autonomous security system. For this goal, it is necessary
to have a feedback control loop consisting of security policy configuration, monitoring,
notification, data analysis, feedback delivery, and security policy augmentation/generation.
However, the following key components for I2NSF are currently out of I2NSF scope without
rechartering:

o The data analysis entities, feedback delivery and security policy augmentation. The I2NSF
   Analyzer is to process and make data from NSFs available in a way that they are auditable,
   undeniable, and tamper-resistant.

o The I2NSF framework needs a new interface to deliver feedback messages for a security
   policy from I2NSF Analyzer to Security Controller, or to share them among collaborating
   domains. In addition, a proper translation of the planned actions for a given security policy
   onto NSF capabilities requires a well-defined model for representing these actions in
   Security Controller.

o I2NSF is vulnerable to insider and supply chain attacks. The security system may collapse
   if there is a malicious attack to the NSF capabilities registration, the I2NSF user security
   policies declaration, the Security Controller, or the monitoring data from an NSF. 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 (e.g., database) or a decentralized way (e.g., Blockchain as a distributed
   ledger technology (DLT)).

o 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. Beyond this, it
   would be necessary to analyze the impact of new mechanisms for establishing roots of trust,
   such as Quantum Key Distribution (QKD), and providing crypto capabilities, such as Post
   Quantum Cryptography (PQC), on the management mechanisms described in RFC9061.
   In addition, recording events (like done with DLT such as Blockchain), or implementing data
   paths and computational services (as supported by in-network computing) needs to be
   evaluated.

o I2NSF can work effectively and efficiently on container deployments in a cloud native NFV
   architecture. For the operations in this cloud native NFV architecture, the YANG data models
   of the I2NSF interfaces need to be augmented appropriately.

Program of Work
===============

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 not to 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 a framework for security policy translation to support the mapping
   between a high-level YANG module and a low-level YANG module. The working group may
   decide not to 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 YANG data model document for the support of DLT-based distributed system auditing
  (e.g., Blockchain) in the I2NSF framework.

o A single document for I2NSF on container deployments in a cloud native NFV architecture.

o A single document for applicability and use cases in I2NSF-based security management
   automation.

o A single document providing an extended I2NSF capability model for security management
   automation.

Milestones
===============

o November 2023: Adopt an extended I2NSF capability model for security management
   automation as WG document

o July 2023: Adopt applicability and use cases in I2NSF-based security management
   automation as WG document

o March 2023: Adopt a YANG data model for DLT-based distributed system auditing as
   WG document

o March 2023: Adopt I2NSF on container deployments in a cloud native NFV architecture
   as WG document

o November 2022: Adopt remote attestation for I2NSF components, based on the work
   of RATS, as WG document

o July 2022: Adopt a framework for security policy translation as WG document

o July 2022: Adopt a YANG data model for I2NSF Application Interface as WG document

o July 2022 Adopt an extension of I2NSF framework for security management automation
   as WG document
--------------------------------------------------------------------------------------------------

I attach the docx and pdf files for the new I2NSF charter.

If you have comments or suggestions, please let me know.

Thanks.

Best Regards,
Paul
--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
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>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 21 Mar 2022 22:23:50 +0900

Hi Wei Pan,
Thanks for your comments and suggestions on the I2NSF Re-chartering.

I will try to address your comments on our re-chartering text.

Thanks.

Best Regards,
Paul

On Mon, Mar 14, 2022 at 7:53 PM Panwei (William) <[email-masked]>
wrote:

> I feel the re-chartering text below seems not well-organized. The Goals
> part makes me feel that they are just given by what drafts exist now, not
> from the perspective of use cases or scenarios. The Program of Work part
> has deepened this feeling.
>
> I think the new works focus on three aspects: to enhance the automation
> capability, to increase the security, and to expand the deployable
> scenario. I suggest re-organizing the goals to put the related content
> together. The texts could be developed as “to enhance XXX capability, YYY
> now is missing, or ZZZ is needed”.
>
>
>
> I suggest changing this sentence to “the following key components for
> I2NSF are needed”. Because “without rechartering” will cause confusion that
> the following part are not covered in the current charter, and this new
> charter will become “current charter” when it gets approved.
>
>
>
>
>
> I am not quite convinced that DLT is used to mitigate the supply chain
> attacks. However, the following use of remote attestation can somehow
> mitigate this threat. The remote attestation can prove the I2NSF
> components’ integrity which would be compromised if the supply chain
> attacks happened.
>
>
>
> Regards & Thanks!
>
> Wei Pan (潘伟)
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *Mr. Jaehoon
> Paul Jeong
> *Sent:* Wednesday, February 16, 2022 1:06 AM
> *To:* [email-masked]
> *Cc:* Roman Danyliw <[email-masked]>; Diego R. Lopez <
> [email-masked]>; ANTONIO AGUSTIN PASTOR PERALES <
> [email-masked]>; Yoav Nir <[email-masked]>;
> JungSoo Park <[email-masked]>; Linda Dunbar <[email-masked]>;
> yangpenglin <[email-masked]>; Younghan Kim <
> [email-masked]>; Patrick Lingga <[email-masked]>; Meiling
> Chen <[email-masked]>; skku-iotlab-members <
> [email-masked]>; Mr. Jaehoon Paul Jeong <
> [email-masked]>; Yunchul Choi <[email-masked]>
> *Subject:* [I2nsf] A Proposed Charter for I2NSF WG Re-Chartering
>
>
>
> Hi I2NSF WG,
>
> Email: [email-masked], [email-masked]
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>