Hi Linda and Yoav, Is there an I2NSF WG session in IETF 115 in London? Since we have finished all the five I2NSF YANG drafts, we can finalize the Re-chartering text and request the approval of the IESG.
Here is the Re-chartering text: ------------------------------- 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 closed-loop security control consisting of security policy configuration, monitoring, notification, data analysis, analytics information delivery, and security policy (re)configuration. However, the following are needed for I2NSF: 1. The I2NSF framework needs to be extended to provide Security Management Automation to a target network through a closed-loop security control. For this Security Management Automation, I2NSF WG needs to identify which system components and interfaces are required. Also, it enumerates and analyzes what services are required for the I2NSF system. 2. The I2NSF framework needs a new interface (called Analytics 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 the Security Controller. 3. The I2NSF framework needs Security Policy Translation from a high-level security policy to a low-level security policy. To build a security policy translator, a fundamental understanding is required for the relationship of Consumer-Facing Interface and NSF-Facing Interface. An exemplary architecture and procedure will be used for a security policy translator. 4. 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 for auditing in a security audit system (e.g., remote attestation and Blockchain). 5. I2NSF can support IPsec Management for BGP routers in a centralized way of Software-Defined Networking (SDN). I2NSF's Security Controller can be in charge of IPsec parameter setting and key management for BGP routers which establish IPsec sessions for their BGP message exchanges in a secure way. For IPsec for BGP over IPsec, an interface can be defined for SDN-based IPsec flow protection in BGP. 6. I2NSF needs to support recently developed protocols such as QUIC and HTTP/3. For this support, the I2NSF YANG data models, which are Capability, Consumer-Facing Interface (CFI), NSF-Facing Interface (NFI), Registration Interface (RI), and Monitoring Interface(MI), need to be extended to accommodate those recently developed protocols. Program of Work =============== The I2NSF working group's deliverables include: 1. A single document for security management automation in the I2NSF framework. This document will initially be used to enhance the I2NSF framework for security management automation. It can be used as an applicability document to handle various requirements and possible approaches for such security management automation in real environments. 2. A YANG data model document for I2NSF Analytics Interface to deliver analytics information from I2NSF Analyzer to Security Controller. 3. A single document for Guidelines for Security Policy Translation to support the mapping between a high-level YANG module and a low-level YANG module. This document can get feedback from NMRG and OPSAWG for the synchronization with the translation work in those groups. 4. A YANG data model document for Remote Attestation Interface for the remote attestation for I2NSF components, based on the work of the RATS WG. 5. A YANG data model document for BGP Interface for IPsec for BGP over IPsec, based on the work of the IPSECME WG. 6. YANG data model documents for I2NSF Capability and Interfaces (i.e., CFI, NFI, RI, and MI) to support recently developed protocols (e.g., QUIC and HTTP/3). Milestones =============== 1. November 2022 Adopt security management automation in I2NSF framework as a WG document 2. November 2022: Adopt a YANG data model for I2NSF Analytics Interface as a WG document 3. November 2022: Adopt guidelines for security policy translation as a WG document 4. March 2023: Adopt a YANG data model for Remote Attestation Interface as a WG document 5. March 2023: Adopt a YANG data model for BGP IPsec Interface as a WG document 6. November 2023: Adopt YANG data models for I2NSF Capability and Interfaces (i.e., CFI, NFI, RI, and MI) as WG documents ------------------------------- 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: paulje...@skku.edu, jaehoon.p...@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
