Subject: Re: [I2nsf] Proposed extended charter for I2NSF

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Dec 2021 16:13:55 +0000

Just want to add a concrete example of  Analyzer needing other network domain security intelligence.
For example NSFs within AWS VPC needing Analytics from AWS Cloud Watch: AWS re:Inforce 2019: The Fundamentals of AWS Cloud Security (FND209-R) - YouTube<https://www.youtube.com/watch?v=-ObImxw1PmI>

My two cents.

Linda Dunbar

From: [email-masked] <[email-masked]>
Sent: Wednesday, December 15, 2021 12:38 AM
To: Diego R. Lopez <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>; chenmeiling <[email-masked]>; Patrick Lingga <[email-masked]>; ANTONIO AGUSTIN PASTOR PERALES <[email-masked]>; Linda Dunbar <[email-masked]>
Cc: skku-iotlab-members <[email-masked]>
Subject: Re: Proposed extended charter for I2NSF

Hi Diego and all，

Generally I think the outline of charter is fine, but three suggestions I think are useful for the development of NSF.

  *   Cross-domain security intelligence sharing. Take the example of Analyzer, Analyzer may need other network domain's security intelligence as reference  to make decision, or it wants to share its threat intelligence to cooperate with partner to promote the security capability of NSF. The requirements of this threat intelligence sharing mechanism should be auditable, undeniable and tamper-resistant. Block-chain based architecture is one of the proper solutions. Finally, the NSF architecture could be used and spread in a more wide range like cross-company, cross-domain, or even cross-country cooperation. And I do think NSF with this mechanism will be much more viable.  In order to achieve that, we need to design the future NSF architecture with redundancy and flexibility that could be used to expand and develop.
  *   New technologies keep emerging up, like confidential computing, homomorphic encryption, computing in network, etc.  We don't have to adopt these new techs to NSF immediately, but pay attention to them maybe helpful.
  *   Do we have to restrict the deliverables as the listed documents, or the listed documents are not used for ruling out other documents.

BR
Penglin

From: Diego R. Lopez<mailto:[email-masked]>
Date: 2021-12-14 15:51
To: [email-masked]<mailto:[email-masked]>; Mr. Jaehoon Paul Jeong<mailto:[email-masked]>; chenmeiling<mailto:[email-masked]>; Patrick Lingga<mailto:[email-masked]>; ANTONIO AGUSTIN PASTOR PERALES<mailto:[email-masked]>; Linda Dunbar<mailto:[email-masked]>
CC: skku-iotlab-members<mailto:[email-masked]>
Subject: Proposed extended charter for I2NSF
Hi,

As mentioned during our call today, this is the extended charter we are planning to propose for I2NSF:

8<
------------------------------------------------------------------------------------------------------------------------------
<I2NSF WG Re-chartering Text>

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, which is 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 current I2NSF framework consists of four components such as I2NSF User, Security Controller,
Network Security Function (NSF), and Developer's Management System (DMS). The I2NSF
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, and DDoS-attack mitigation), applying security
policy rules. The DMS registers the capabilities of an NSF with the Security Controller.

The current 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. In addition, the impact of new mechanisms for
establishing roots of trust (like QKD), providing crypto capabilities (like PQC),  modeling and
recording events (like done with DLT) or implementing data paths and computational services
(as supported by in-network computing) needs to be evaluated.

When it comes to modeling, 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, and to address the implications
of their deployment in cloud-native environments. Finally, an adaptation of the current capability
model to this new environment, especially focused to support translation and automated
management, will have to be considered.

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 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
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 in a cloud native NFV architecture.
o A single document providing an extended I2NSF capability model.

--------------
Milestones

o July 2022: Adopt applicability and use cases in I2NSF-based security management automation
as WG document
o July 2022: Adopt remote attestation for I2NSF components as WG document
o March 2023: Adopt I2NSF on container deployments in a cloud native NFV architecture as WG
document
o November 2023: Adopt a framework for security policy translation as WG document
o November 2023: Adopt a YANG data model for I2NSF Application Interface as WG document
o March 2024: Adopt an extension of I2NSF framework for security management automation as
WG document
-------------------------------------------------------------------------------------------------------------------------------
>8

Let me know what you think. If you confirm you agree with it, my plan would be to share it on the I2NSF list before the Christmas break. You’d be expected to express your support. I hope that, if we can show our AD a sufficient number of support expressions, the WG will be rechartered and support the ongoing and future work on attestation, automation and cloud-nativeness.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fdr2lopez%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfa51c2dfd48f485f273608d9bf957f73%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637751471094324354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a09McbG3%2BswhSuv0f%2FJrpopCWHRO5obIydHD%2B6XKwww%3D&reserved=0>

e-mail: [email-masked]<mailto:[email-masked]>
Mobile:  +34 682 051 091
----------------------------------

________________________________

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