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 protected]> wrote: > 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 protected]] *On Behalf Of *Mr. Jaehoon > Paul Jeong > *Sent:* Wednesday, February 16, 2022 1:06 AM > *To:* [email protected] > *Cc:* Roman Danyliw <[email protected]>; Diego R. Lopez < > [email protected]>; ANTONIO AGUSTIN PASTOR PERALES < > [email protected]>; Yoav Nir <[email protected]>; > JungSoo Park <[email protected]>; Linda Dunbar <[email protected]>; > yangpenglin <[email protected]>; Younghan Kim < > [email protected]>; Patrick Lingga <[email protected]>; Meiling > Chen <[email protected]>; skku-iotlab-members < > [email protected]>; Mr. Jaehoon Paul Jeong < > [email protected]>; Yunchul Choi <[email protected]> > *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 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
