I2NSF Application Interface YANG Data Model
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957patricklink@skku.edu
Department of Computer Science and Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Electronics and Telecommunications Research Institute
218 Gajeong-Ro, Yuseong-GuDaejeon305-700Republic of Korea+82 42 860 5978cyc79@etri.re.kr
Security
I2NSF Working GroupInternet-Draft
This document describes an information model and a YANG data model for
the Application Interface between an Interface to Network Security
Functions (I2NSF) Analyzer and Security Controller in an I2NSF system in
a Network Functions Virtualization (NFV) environment. The YANG data model
described in this document is based on the I2NSF NSF-Facing Interface
and the I2NSF Monitoring Interface
for enabling feedback delivery based on the information received
from the Network Security Function (NSF).
In Interface to Network Security Functions (I2NSF) ,
the Monitoring Interface
is defined as an interface to collect information (e.g., network statistics,
resources) from NSF(s). The information can be received by a query
or a report. In a query-based, the information is obtained
by a request from a client (I2NSF Analyzer). But in a report-based, the information
is provided by a server (NSFs) when the notification or alarm is triggered by an
event. In this model, the report-based collection information is used
for realizing the Security Management Automation (SMA) in cloud-based security services
.
as the information is sent automatically by the NSFs.
shows the I2NSF Framework for Security Management Automation.
The automatic reports by the NSFs are collected in a single
instance (i.e., I2NSF Analyzer) to be analyzed. By analyzing the
information, a new security policy can be produced to further
enhance the security of the network. To create the automated system,
the analyzer should be done automatically with the help of machine
learning. The automated analyzer is not in the scope of this
document.
The new security policy needs to be delivered from the I2NSF
Analyzer to the Security Controller so the new policy can be
listed and monitored properly. For that purpose, this document
introduces the Application Interface as the intermediary between
the I2NSF Analyzer and the Security Controller.
Then the policy should be delivered
directly to the NSFs by the Security Controller via the NSF-Facing
Interface .
The purpose of this document is to provide a standard for a feedback interface
in an I2NSF Framework called Application Interface. With the provided Application Interface,
the realization of Security Management Automation (SMA) should be possible.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.
This document uses the terminology described in .
This document follows the guidelines of and
adopts the Network Management Datastore Architecture (NMDA). The meaning of
the symbols in tree diagrams is defined in .
This document introduces Application Interface as an interface
to deliver a report of the augmentation or generation of security policy rules
created by I2NSF Analyzer to Security Controller .
This allows Security Controller to actively reinforce the
network with its security policy management.
shows the high-level concept of
Application Interface such as Policy Reconfiguration and Feedback
Information.
Both policy reconfiguration and feedback information provide
the following high-level abstraction:
NSF Name: It is the name or IP address of the NSF for identifying
the NSF with problem. The name is a unique string to identify
an NSF, including a Fully Qualified Domain Name (FQDN).
Problem: It describes the issue(s) in the NSF that needs to be
handled.
Solution: It specifies the possible solution(s) for the problem.
Policy reconfiguration is the rearrangement of a security policy
in a different form or combination of the existing security
policy to enhance the security service in the network.
A policy reconfiguration is generated by the I2NSF Analyzer
after receiving and analyzing monitoring information of NSF Events
from an NSF .
Policy reconfiguration works together with the three I2NSF interfaces defined for
the I2NSF Framework, i.e.,
NSF-Facing Interface ,
NSF Monitoring Interface ,
and Application Interface, to create a closed-loop system for reinforcing the
network security. shows an illustration
of the closed-loop system for the I2NSF Framework.
shows a close-loop system between Security Controller, NSF, and I2NSF Analyzer.
The Security Controller delivers a security policy to an appropriate NSF via the NSF-Facing Interface .
The NSF will prepare for a security service according to the given configuration and provide a security service for the network.
The NSF SHOULD also provide monitoring information (e.g., NSF Events and System Alarms) to be analyzed.
This monitoring information can be delivered from the NSF to an I2NSF Analyzer via the Monitoring Interface .
Then the I2NSF Analyzer analyzes the monitoring information for the reconfiguration of an existing
security policy, the generation of a new security policy, and the feedback for security system management
(e.g., the scaling-up or scaling-down of resources related to NSFs).
To fully automate the close-loop system, the I2NSF Analyzer should analyze the monitoring information automatically using machine learning techniques
(e.g., Deep Learning ).
The results of the analysis may trigger the reconfiguration of an existing security policy or
the generation of a new security policy to strengthen the network security. The reconfiguration or
configuration request will be delivered from the I2NSF Analyzer to the Security Controller
via the Application Interface.
To realize the close loop system, the Application Interface needs to properly follow the similar
guidelines for the I2NSF Framework .
The Application Interface follows to create a security policy to reconfigure an existing security policy of NSF(s) or to generate a new security policy.
Application Interface holds a list of security policies so that the (re)configuration of
a security policy and the feedback information can be provided to the Security Controller.
Each policy consists of a list of rule to be enhanced on the NSF. Note that the synchronization
of the list of security policies should be done between the Security Controller and the I2NSF
Analyzer and the specific mechanism is out of the scope of this document.
A (re)configured security policy rule should be able to cope with attacks or failures that
can happen to the network in near future.
Such a rule is reconfigured or generated by the I2NSF Analyzer to tackle a detected problem
in the network.
It uses the Event-Condition-Action (ECA) model as the basis for the design of I2NSF
Policy (Re)configuration as described in and .
An example of Policy (Re)configuration is a DDoS Attack that is detected
by a DDoS Mitigator. The DDoS Mitigator creates monitoring
information and delivers it to the I2NSF Analyzer. The I2NSF Analyzer
analyzes the information and generates a new policy to handle
the DDoS Attack, such as a firewall rule to drop all packets from the
source of the DDoS Attack.
The YANG tree structure for policy reconfiguration is
provided through the augmentation of the NSF-Facing Interface YANG Module
as follows:
The policy reconfiguration must include the following
information:
NSF Name: The name or IP address (IPv4 or IPv6) of the NSF to be
configured. If the given nsf-name is not IP address, the
name can be an arbitrary string including FQDN (Fully
Qualified Domain Name).
Problem: The issue that is emitted by an NSF via the
I2NSF Monitoring Interface. The problem for policy configuration
includes the NSF Events described in NSF Monitoring Interface
YANG Data Model ,
such as DDoS detection, Virus detection, Intrusion detection,
Web-attack detection, and Voice over Internet Protocol (VoIP) or Voice over
Cellular Network (VoCN) violation detection.
Solution: The solution for policy (re)configuration is the
security policy that is reconfigured or generated to solve
a detected attack. The security policy can be configured
using the NSF-Facing Interface YANG data model
.
Feedback information is information about problem(s) of an
NSF for a security service such as system resource over-usage or malfunction.
This problem cannot be handled by creating a new policy.
In the similar way with policy reconfiguration, the feedback information
should be delivered from the I2NSF Analyzer to the Security Controller that
will be able to handle the reported problem(s).
shows the
handling of feedback information. For feedback information,
the given feedback is not a security policy, hence the Security
Controller needs to take an action to handle the reported problem(s).
The action includes the reporting to the I2NSF
User and the requesting of the system resource management of the
relevant NSF(s) to the Developer's Management System (DMS).
DMS will communicate with the Management and Orchestration (MANO) Unit
in the Network Functions Virtualization (NFV) Framework to deal with
the system management issue(s) of the relevant NSFs
.
The details of the handling process are out of the scope of this document.
The YANG tree structure for feedback information is
provided with the use of the NSF Monitoring Interface YANG Module
as follows:
shows the high-level
abstraction of Feedback Information. The feedback information
should include:
NSF Name: The name or IP address (IPv4 or IPv6) of the NSF
that detected the problem. If the given nsf-name is not
IP address, the name can be an arbitrary string including
FQDN.
Time: The time of the delivery of the feedback information.
Language: The language tag that is used for the natural
language text that is included in the "message" and
"solution" attributes. The language field is encoded
following the rules in Section 2.1 of .
The default language tag is "en-US".
Problem: The issue that is emitted by an NSF via the
I2NSF Monitoring Interface. The problem for feedback information
includes the system alarms described in NSF Monitoring Interface
YANG Data Model ,
such as Memory alarm, CPU alarm, Disk alarm, Hardware alarm,
and Interface alarm.
Solution: A possible solution given as feedback is in
the form of a free-form string (as a high-level
instruction).
This section shows the YANG module of Application Interface.
The YANG module in this document is referencing to
.
The YANG module makes references to
This document requests IANA to register the following URI in the
"IETF XML Registry" :
This document requests IANA to register the following YANG
module in the "YANG Module Names" registry :
This section shows XML configuration examples of feedback policy
rules that are delivered from the I2NSF Analyzer to the Security
Controller over the Application Interface after the I2NSF Analyzer
analyzes the Monitoring Information.
In this example, the scenario can be seen in .
In this scenario, a DDoS Mitigator detects a DDoS Attack and
sends a notification to the I2NSF Analyzer as shown
in .
In the scenario shown in ,
the description of the XML example is as follows:
The DDoS attack is detected at 9 am on August 27 in 2021.
The sources of the attack are 192.0.2.8, 192.0.2.9, and 192.0.2.10.
The destination of the attack is 203.0.113.0/24.
After receiving the information, the I2NSF Analyzer analyzes
the data and creates a new feedback policy to enforce the
security of the network. The I2NSF Analyzer delivers a feedback
policy to the Security Controller as shown in .
The policy reconfiguration in
means the following:
The feedback policy is named as "feedback_policy_for_ddos_attack".
The rule is named as "deny_ddos_attack".
The rule starts from 09:00 am on August 24 in 2021.
The condition of the rule is from the sources of
the IP addresses 192.0.2.8, 192.0.2.9, and 192.0.2.10.
The action required is to "drop" any access from the
the IP addresses have been identified as malicious.
The NSF to be configured is named "Firewall".
The problem that triggered the generation of the feedback
is a DDoS attack from the sources of the IP addresses
192.0.2.8, 192.0.2.9, and 192.0.2.10 to the protected network
of 203.0.113.0/24.
In this scenario, an NSF is overloaded and sends a notification
to the I2NSF Analyzer as shown in
.
In the scenario shown in ,
the description of the XML example is as follows:
The NSF that sends the information is named "firewall".The memory usage of the NSF triggered the alarm.The memory usage of the NSF is 98 percent.The memory threshold to trigger the alarm is 80 percent.The event is delivered at 2021-08-27T07:43:52.181088+00:00.
After receiving the information, the I2NSF Analyzer analyzes
the data and creates a new feedback policy to solve the problem
that is detected in the NSF. The I2NSF Analyzer delivers a feedback
information to the Security Controller as shown in
.
The feedback information in
means the following:
The name of the NSF that needs to be handled is called
"Firewall".
The feedback information is delivered at
2021-08-27T08:43:52.000000+00:00.
The problem is that the Memory Usage Exceeded the Threshold with
the average usage of memory as 95.
The problem persists for 3,600 seconds (1 hour) without
any fix.
The proposed solution to the problem is to add more
memory capacity in hardware to the NSF or to create a new
NSF with the same security service.
The YANG module specified in this document defines a data
schema designed to be accessed through network management
protocols such as NETCONF or
RESTCONF .
The lowest NETCONF layer is the secure transport layer, and
the required secure transport is Secure Shell (SSH) .
The lowest RESTCONF layer is HTTPS, and the required secure
transport is TLS .
The NETCONF access control model
provides a means of restricting access to specific NETCONF or
RESTCONF users to a preconfigured subset of all available
NETCONF or RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module
that are writable/creatable/deletable (i.e., config true, which
is the default). These data nodes may be considered sensitive
or vulnerable in some network environments. Write operations
(e.g., edit-config) to these data nodes without proper protection
can have a negative effect on network operations. And the data model
in this document uses the data model from NSF-Facing Interface data model,
it MUST follow the Security Considerations mentioned in the
.
Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g., via get,
get-config, or notification) to these data nodes. This document
also MUST follow the Security Considerations about the readable
data nodes mentioned in the .
This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (2020-0-00395, Standard
Development of Blockchain based Network Management Automation Technology).
This work was supported in part by the IITP (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security
Service Provisioning).
This work was supported in part by the MSIT under the Information Technology
Research Center (ITRC) support program (IITP-2021-2017-0-01633) supervised
by the IITP.
This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document, such as Linda Dunbar,
Yoav Nir, Susan Hares, and Diego Lopez.
The authors sincerely appreciate their contributions.
The following are co-authors of this document:
Jeonghyeon Kim
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: jeonghyeon12@skku.edu
Jinyong (Tim) Kim
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seo-ro Jangan-gu
Suwon, Gyeonggi-do 16419
Republic of Korea
EMail: timkim@skku.edu
Jung-Soo Park
Electronics and Telecommunications Research Institute
218 Gajeong-Ro, Yuseong-Gu
Daejeon, 34129
Republic of Korea
EMail: pjs@etri.re.kr
Younghan Kim
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul 06978
Republic of Korea
EMail: younghak@ssu.ac.kr
Deep Learning