I2NSF Consumer-Facing Interface YANG Data Model
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
Department of Electronic, Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957darkhong@skku.edu
Korea Telecom
70 Yuseong-Ro, Yuseong-GuDaejeon305-811Republic of Korea+82 42 870 8409taejin.ahn@kt.com
Juniper Networks
1133 Innovation WaySunnyvaleCA94089USArkkumar@juniper.net
Huawei
7453 Hickory HillSalineMI48176USA+1-734-604-0332shares@ndzh.com
Security
I2NSF Working GroupInternet-Draft
This document describes an information model and the corresponding
YANG data model for the Consumer-Facing Interface of the Security
Controller in an Interface to Network Security Functions (I2NSF)
system in a Network Functions Virtualization (NFV) environment.
The information model defines various types of managed objects and
the relationship among them needed to build the flow policies from
users' perspective. This information model is based on the
"Event-Condition-Action" (ECA) policy model defined by a
capability information model for I2NSF, and the YANG data model is
defined for enabling different users of a given I2NSF system to
define, manage, and monitor flow policies within an administrative
domain (e.g., user group).
In a framework of Interface to Network Security Functions (I2NSF)
, each vendor can register their
Network Security Functions (NSFs) using a Developer's Management
System (DMS). Then the I2NSF User (e.g., an application for a security
administrator such as a web application) can configure the NSFs by defining high-level
security policies. Most vendors provide various proprietary
applications or tools to define security policies for their own NSFs.
The Consumer-Facing Interface is required because the
applications developed by each vendor need to have a standard
interface specifying the data types used when the I2NSF User
and Security Controller (i.e., Network Operator Management System)
communicate with each other using this interface. Therefore,
this document specifies the required information such as their
data types and encoding schemes so that high-level security
policies (or configuration information for security policies) can
be transferred to the Security Controller through the
Consumer-Facing Interface. Security Controller will use the
given information to translate the high-level security policies
into the corresponding low-level security policies.
The Security Controller delivers the translated security policies to
the NSFs according to their respective security capabilities for
the required security enforcement.
The Consumer-Facing Interface would be built using a set of objects, with each
object capturing a unique set of information from an I2NSF User needed to express a Security Policy.
An object may have relationship with various other objects to express a
complete set of requirements. An information model captures the managed objects
and relationship among these objects. The information model proposed in this
document is structured in accordance with the "Event-Condition-Action" (ECA)
policy model.
An NSF Capability model is proposed in
as the basic model for both the NSF-Facing interface and Consumer-Facing Interface
security policy model of this document.
explains differences between an information and data model.
This document uses the guidelines in to define both the
information and data model for Consumer-Facing Interface.
shows a high-level abstraction
of Consumer-Facing Interface. A data model, which represents an implementation
of the information model in a specific data representation language, is also
defined in this document.
Data models are defined at a lower level of abstraction and provide many details.
They provide details about the implementation of a protocol's specification,
e.g., rules that explain how to map managed objects onto lower-level protocol
constructs. Since conceptual models can be implemented in different ways,
multiple data models can be derived from a single information model.
The efficient and flexible provisioning of network functions
by a Network Functions Virtualization (NFV) system supports rapid
deployment of newly developed functions. As practical applications,
Network Security Functions (NSFs), such as firewall, Intrusion
Detection System (IDS)/Intrusion Prevention System (IPS), and attack mitigation,
can also be provided as Virtual Network Functions (VNF) in the NFV system.
By the efficient virtualization technology, these VNFs might be automatically
provisioned and dynamically migrated based on real-time security requirements.
This document presents a YANG data model to implement security functions
based on NFV.
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 ,
uses the common YANG types defined in , and
adopts the Network Management Datastore Architecture (NMDA) . The meaning of
the symbols in tree diagrams is defined in .
A Policy object is a means to express a Security Policy set by an
I2NSF User with the Consumer-Facing Interface.
It is sent to the Security Controller which converts it into an NSF-specific
configuration via the NSF-Facing Interface for enforcement of the NSF.
shows the YANG tree of the
Policy object. The Policy object SHALL have the following information:
This field identifies the name of this object.
The language field indicates the language tag that is used
for the natural language text that is included in all of the 'description' attributes.
The language field is encoded following the rules in Section 2.1 of .
The default language tag is "en-US".
This field represents how to resolve conflicts that occur between
actions of the same or different policy rules that
are matched and contained in this particular NSF. The resolution
strategy is described in Section 3.2 of in detail.
This field contains a list of rules. These rules are defined
for implementing business requirements such as
1) supporting communication between two Endpoint Groups
(see ),
2) preventing communication with externally or internally
identified threats, and 3) controlling access to internal or
external resources for meeting regulatory compliance.
An organization may restrict certain communication between a
set of users and applications for example. The threats may be
identified from threat feeds obtained from external sources.
Note that rule conflict analysis should be performed by a
monitoring service for policy rule conflicts in Security
Controller to detect such rule conflicts among the policy
rules installed into network security functions.
A policy contains a list of rules. In order to express a Rule, a Rule must have
complete information such as where and when a policy needs to be applied.
This is done by defining a set of managed objects and relationship among them.
A Policy Rule defined in this module is a set of management guidelines
that defines a desired behavior based on the Event-Condition-Action policy model
(Section 3.1 of ), but that
is independent of a specific device and implementation.
shows the YANG data tree of the Rule object.
The rule object SHALL have the following information:
This field identifies the name of this object.This field identifies the priority of the rule.
This field includes the information to determine whether the
Rule Condition can be evaluated or not (see the definition of Event
in Section 3.1 of ).
See details of the Event Object in .
This field contains a set of attributes, features, and/or values
that are to be matched with the attributes of a packet or traffic flow to
determine whether the Rule Action can be executed or not
(see Section 3.1 of ).
See details of the Condition Object in .
This field identifies the action taken when a rule is matched (see Section 3.1
of ).
There is always an implicit action to drop traffic if no rule
is matched for a traffic type. See details of the Action Object in
.
The Event Object contains information related to scheduling a Rule.
The Event Object activates the evaluation of the Condition Object
based on a security event (i.e., system event and system alarm).
Note that an empty Event Object means that the event will always
evaluate to true and start the evaluation of the Condition Object.
shows the YANG tree
of the Event object. Event object SHALL have the following information:
is defined as a warning about any changes of
configuration, any access violation, the information of
sessions and traffic flows.
is defined as a warning related to service degradation
in system hardware.
The Condition object describes the network traffic pattern or fields
that must be matched against the observed network traffic for the
rule to trigger. The fields used to express the required conditions
to trigger the rule are organized around the class of NSFs
expected to be able to observe or compute them.
shows the YANG tree of
the Condition object. The Condition Sub-model SHALL have the following
information:
This field represents the layer-2 header (e.g., MAC
addresses), layer-3 header (e.g., IPv4 or IPv6 addresses,
ICMPv4 or ICMPv6 parameters, and transport layer protocol)
and layer-4 header (e.g., port numbers) of the network
traffic. Note that the YANG module only provides
high-level ICMP messages that are shared between ICMPv4
and ICMPv6 (e.g., Destination Unreachable: Port Unreachable
which is ICMPv4's type 3 and code 3 or ICMPv6's type 1
and code 4). Also note that QUIC protocol
is excluded in the data model as
it is not considered in the initial I2NSF documents
. The QUIC traffic should not be
treated as UDP traffic and will be considered in the future
I2NSF documents.
This field represents the threshold limit for the rate of
the network traffic to mitigate a DDoS attack. The threshold
configuration can be given in packet rate, byte rate, and
flow rate. Definition of packet rate, byte rate, and flow
rate are defined in Section 6 of
.
This field represents the configuration for an Antivirus.
A specific security profile can be added to Security
Controller in order to update the configuration of the
Antivirus. Also, either a filename or path for such a profile
can be configured for the Antivirus.
This field represents the payload information of the network traffic.
The configuration is given in a high-level form that maps into
the corresponding binary form registered with the Threat Prevention
object (see ).
This field represents the URL to be filtered. This information
can be used to block or allow a certain URL or website. The
url-name is a group of URL or websites to be matched.
This field contains the call source-id, call destination-id,
and user-agent. This information describes
a caller id or receiver id in order to prevent any exploits
(or attacks) of Voice over IP (VoIP) or Voice over Cellular
Network (VoCN).
Note that VoCN can be either Voice over LTE (VoLTE)
or Voice over 5G (Vo5G) .
This field represents the extra information for the
condition such as time, application, device type, user
condition, and geographic location (see Section 5.1 of
).
This field contains the information obtained from threat-feeds.
This field is used when security rule condition is based on the existing
threat reports gathered from other sources.
Note that the identities for ICMP messages provided in the YANG module are combined for
ICMPv4 and ICMPv6 such as echo/echo-reply for ICMPv4 and echo-request/echo-reply for ICMPv6. For more information
about the mapping between ICMPv4 and ICMPv6 messages, refer to
and .
This object represents actions that Security Admin wants to perform
based on certain traffic class.
shows the YANG tree of the Action object. The Action object SHALL
have following information:
This field identifies the action
when a rule is matched by an NSF. The action could be one of
"pass", "drop", "reject", "rate-limit", "mirror",
"invoke-signaling", "tunnel-encapsulation", "forwarding",
and "transformation". This action is related to the
ingress-action-capability and egress-action-capability
in .
Note that if the action is "rate-limit", the limit value should
be given to Security Controller in order to determine the threshold
of the traffic rate.
This field identifies the action when a rule is matched by an NSF. The action could be one of "rule-log" and "session-log". This action is related to the log-action in .
The Policy Endpoint Group is the collection of network nodes that
are labeled and placed together into a group. As shown in
, endpoint groups
include User-Group (),
Device-Group (),
Location-Group (),
and URL-Group ().
An I2NSF User can create and use these objects to
represent a logical entity in their business environment, where a
security policy is to be applied.
shows the YANG tree of the
Endpoint-Groups object.
The endpoint group information delivered by the I2NSF User should
be stored into a secure database available to the Security Controller
for the translation from a high-level security policy to the
corresponding low-level security policy. The information should
be synchronized with other systems in real-time for accurate
translation.
The User-Group object represents the MAC addresses and IP
(IPv4 or IPv6) addresses that are labeled as a group of users (e.g., employees).
shows the YANG tree of the User-Group object.
The User-Group object SHALL have the following information:
This field identifies the name of the user-group. This represents the MAC address(es) for the user-group. This represents the list of IPv4 address ranges for the user-group. This represents the list of IPv6 address ranges for the user-group.
The Device-Group object represents the labeled network devices
that provide services (e.g., servers) hosted on the IP (IPv4 or IPv6) addresses
and application protocol.
shows the YANG tree
of the Device-group object. The Device-Group object SHALL have
the following information:
This field identifies the name of this object. This represents the list of IPv4 address ranges for the device-group. This represents the list of IPv6 address ranges for the device-group. This represents the application layer protocols of devices for the device-group.
The Location-Group object represents the IP (IPv4 or IPv6) addresses
labeled as a geographic location (i.e., country, region,
and city).
shows the YANG tree of
the Location-Group object.
The Location-Group object SHALL have the following information:
This field represents the 2-letter ISO country code conforming to
ISO3166-1 alpha 2, e.g., 'US' for United States,
'JP' for Japan, and 'PL' for Poland.
This field represents the region code conforming to ISO 3166-2.
Examples include 'ID-RI' for Riau province of Indonesia and
'NG-RI' for the Rivers province in Nigeria.
This field represents the city of a
region, e.g., 'Dublin', 'New York', and 'Sao Paulo'.
This represents the list of IPv4 address range of a geographic location in the location group. This represents the list of IPv6 address range of a geographic location in the location group.
The URL-Group object represents the collection of Uniform Resource Locators
(URLs) or hostnames labeled into a group (e.g., sns-websites).
shows
the YANG tree of the URL-Group object.
The URL-Group object SHALL have the following information:
This field identifies the name of this object. This field represents the URL or hostname.
The Voice-Group object represents the collection of Session Initiation
Protocol (SIP) identities labeled into a group.
shows
the YANG tree of the Voice-Group object.
The Voice-Group object SHALL have the following information:
This field identifies the name of this object.
This field represents the SIP identities in SIP URI scheme
(Section 19.1.1 of ).
The Threat Prevention model describes information obtained from
threat feeds (i.e., sources for obtaining the threat information).
The presented information is the features or attributes that identify
a well-known threat (e.g., signatures or payload) to prevent
malicious activity entering the secured network.
There are multiple managed objects that
constitute this category.
shows the YANG tree of a Threat-Prevention object.
This object represents a threat feed which provides the signatures
of malicious activities. shows
the YANG tree of a Threat-feed-list.
The Threat-Feed object SHALL have the following information:
This field identifies the name of
this object.
This field represents the Indicators of Compromise (IOC),
i.e., the critical information of patterns or characteristics
in the threat feed that identifies malicious activities. The format
of the information given in this field is based on the format
field (e.g., STIX, MISP, OpenIOC, and IODEF).
This field represents the format or structure of the
IOC field for the threat-feed such as Structured Threat
Information Expression (STIX) ,
MISP Core ,
OpenIOC , and
Incident Object Description Exchange Format (IODEF) . This can be extended
depending on the implementation of the existing threat-feed.
It is assumed that the I2NSF User obtains the threat signatures
(i.e., threat content patterns) from a threat-feed server (i.e.,
feed provider), which is a server providing threat signatures.
With the obtained threat signatures, the I2NSF User can deliver
them to the Security Controller via the Consumer-Facing
Interface. The retrieval of the threat signatures by the I2NSF
User is out of the scope of this document.
This object represents a list of raw binary patterns of a
packet payload content (i.e., data after a transport layer header) to
describe a threat.
shows the YANG tree of a Payload-content list.
The Payload-content object SHALL have the following information:
This field identifies the name of this object. It is
recommended to use short and simple words that describe the
content. For example, the name "backdoor" indicates the
payload content is related to a backdoor attack.
This represents the description to further describe the
content field in detail. This field is not mandatory
but recommended to be used as it is helpful for future
usage.
This represents the payload content patterns (i.e., data after
a transport layer header), which are involved in a
security attack, in binary. If multiple instances of content
are defined, it should match all contents somewhere in
the session stream. The content pattern should be matched
based on the order given by the user. The scope of the
payload to be matched can be defined by the depth and
offset/distance fields.
This field specifies how far a packet should be searched
for the specified content pattern defined in the content
field. If this field is undefined, then the content pattern
should be searched within the whole payload.
This field specifies the starting point of matching the
content pattern to the payload. If this field is undefined,
then the content pattern should be searched from the beginning
of the payload. The starting point can be defined by either
the offset value or distance value. The offset keyword specifies
where to start searching for the specified content pattern.
The offset is calculated from the beginning of the payload.
The distance keyword specifies how far a payload should be
ignored before starting to search for the specified
content pattern relative to the end of the previous
specified content pattern match. This can be thought
of as exactly the same thing as offset, except it is
relative to the end of the last pattern match instead
of the beginning of the packet. Note that this field
cannot be used if the content is the first order of the list.
The main objective of this document is to provide the YANG data model
of the I2NSF Consumer-Facing Interface. This interface can be used
to deliver control and management messages between an I2NSF User
and Security Controller for the I2NSF User's high-level security
policies.
The semantics of the data model is aligned with the information
model of the Consumer-Facing Interface.
This data model is designed to support the I2NSF framework that can be
extended according to the security needs. In other words, the model
design is independent of the content and meaning of specific policies
as well as the implementation approach.
With the YANG data model of I2NSF Consumer-Facing Interface, this
document provide examples for security policy rules such as
time-based firewall, VoIP/VoCN security service, and
DDoS-attack mitigation in .
This section describes a YANG module of Consumer-Facing Interface.
This document provides identities in the data model to be used for configuration of an NSF.
Each identity is used for a different type of configuration. The details are explained in the description of each identity.
This YANG module imports from .
It makes references to
This section shows XML configuration examples of high-level
security policy rules that are delivered from the I2NSF User to
the Security Controller over the Consumer-Facing Interface. The
considered examples are: Database registration, time-based
firewall for web filtering, VoIP/VoCN security service, and
DDoS-attack mitigation.
The endpoint-group is used to register known network nodes and
label them into a higher-level name (i.e., human recognizable language).
If new endpoints are introduced to the network, it is necessary
to first register their data to the database. For example, if
new members are newly introduced in different
groups (i.e., user-group, device-group, url-group, and voice-group), each of
them should be registered as separate entities with their
corresponding information.
shows an example XML representation of the registered
information for the user-group, device-group, voice-group in
IPv4 address , and url-group.
The IPv4 addresses from 192.0.2.11 to 192.0.2.90 are
labeled as a group of users called "employees".
The IPv4 addresses from 198.51.100.11 to 198.51.100.20
provide services with HTTP and HTTPS application protocol
labeled as "webservers".
The "https://www.sns-example1.com/" and "https://www.sns-example2.com/" URLs
are labeled as "sns-websites".
The "sip:alice@atlanta.com", "sip:bob@203.0.113.15", and
"sip:carol@chicago.com" SIP identities are
labeled as "malicious-id".
Also,
shows an example XML representation of the registered information
for the user-group, device-group, and voice-group in
IPv6 addresses .
The IPv6 addresses from 2001:db8:0:1::11 to 2001:db8:0:1::90 are
labeled as a group of users called "employees-v6".
The IPv6 addresses from 2001:db8:0:2::11 to 2001:db8:0:2::20
provide services with HTTP and HTTPS application protocol
labeled as "webservers-v6".
The "sip:david@[2001:db8:2ef0::32b7]" SIP identity is
labeled as "malicious-id-v6".
The first example scenario is to "block SNS access during office
hours" using a time-based firewall policy. In this scenario,
all users registered as "employees" in the user-group list are
unable to access Social Networking Services (SNS) during the
office hours (weekdays). The XML instance is described below:
Time-based-condition Firewall
The policy name is "security_policy_for_blocking_sns".
The rule name is "block_access_to_sns_during_office_hours".
The Source is "employees".
The destination target is "sns-websites". "sns-websites" is the key which represents the list containing the information, such as URL, about sns-websites.
The action required is to "drop" any attempt to connect to websites related to Social networking.
The second example scenario is to "block malicious VoIP/VoCN
packets coming to a company" using a VoIP policy. In this
scenario, the calls coming from VOIP and/or VoCN sources with
VoCN IDs that are classified as malicious are dropped. The IP
addresses of the employees and malicious VOIP IDs should be
blocked are stored in the database or datastore of the enterprise.
Here and the rest of the cases assume that the security
administrators or someone responsible for the existing and newly
generated policies, are not aware of which and/or how many NSFs
are needed to meet the security requirements.
represents the XML
document generated from YANG discussed in previous sections.
Once a high-level security policy is created by a security
admin, it is delivered by the Consumer-Facing Interface,
through RESTCONF server, to the security controller. The
XML instance is described below:
Custom-condition Firewall
The policy name is "security_policy_for_blocking_malicious_voip_packets".
The rule name is "Block_malicious_voip_and_vocn_packets".
The source is "malicious-id". The "malicious-id" is the key, so that it maps to the SIP identities that are named as "malicious-id". This can be a single SIP identity or a list of SIP identities.
The destination target is "employees". "employees" is the key which represents the list containing information about employees, such as IP addresses.
The action required is "drop" when any incoming SIP packets are coming from "malicious-id" and targeting "employees".
The third example scenario is to "Mitigate flood attacks on a
company web server" using a DDoS-attack mitigation policy.
Here, the time information is not set because the service
provided by the network should be maintained at all times.
If the packets sent by any sources that target "webservers" are
more than the set threshold, then the admin can set the
percentage of the packets to be dropped to safely maintain the
service. Once the rule is set and delivered and enforced to the
NSFs by the security controller, the NSFs will monitor the
incoming packet amounts to act according to the rule set.
The XML instance is described below:
DDoS-condition Firewall
The policy name is "security_policy_for_ddos_attacks".
The rule name is "1000_packets_per_second".
The destination is webservers.
The rate limit exists to limit the incoming amount of
packets per second. In this case the rate limit is "1000"
packets per second. This amount depends on the packet
receiving capacity of the server devices.
The Source is all sources which send abnormal amount of packets.
It is assumed that there is a counter per source IP address in
this DDoS-condition Firewall. The rate of "1000" packets per
second is set for each source to send packets toward the
destinations as webservers.
The action required is to "drop" when the packet reception is
more than "1000" packets per second for each source that sends
packets to the destinations.
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 :
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 Network Configuration Access Control Model (NACM)
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 contents. Thus, NACM SHOULD be used to restrict the NSF
registration from unauthorized users.
There are a number of data nodes defined in this YANG module
that are writable, creatable, and deletable (i.e., config true,
which is the default). These data nodes may be considered
sensitive or vulnerable in some network environments. Write
operations to these data nodes could have a negative effect on
network and security operations. These data nodes have the following
sensitivity/vulnerability:
list i2nsf-cfi-policy: Writing to almost any element of
this YANG module would directly impact the configuration of
NSFs implementing the security policy, e.g., completely
turning off security monitoring and mitigation capabilities;
altering the scope of this monitoring and mitigation;
creating an overwhelming logging volume to overwhelm
downstream analytics or storage capacity; creating logging
patterns which are confusing; or reducing the efficacy of
statistics or artificial models built on historical data.
container endpoint-groups: Writing to any element in this
container can alter the configuration of the security services
and may cause vulnerabilities in the network, e.g., changing
registered malicious endpoints can remove the defense against
known hostile clients. The information given may also be
considered private, hence it is strongly encouraged to inform
affected users/customers of this fact and of the potential
privacy-related consequences and trade-offs.
container threat-prevention: Writing to any element in this
container can alter the configuration of the security services
and may cause vulnerabilities in the network, e.g., changing
registered signature can let malicious content to get across
the secured network without detection.
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. These are the subtrees and data nodes with their
sensitivity/vulnerability:
list i2nsf-cfi-policy: The leak of this node to an attacker
could reveal the specific configuration of security
controls to an attacker. An attacker can craft an attack
path that avoids observation or mitigations; one may reveal
topology information to inform additional targets or enable
lateral movement; one enables the construction of an attack
path that avoids observation or mitigations; one provides
an indication that the operator has discovered the attack.
container endpoint-groups: This node holds a list of
endpoint data that may be considered private to the users.
Disclosure of this information may expose sensitive details
which can be used to define the identity and geographical
location of a user. Malicious actors can leverage this
information to threaten the user with cyber threat, e.g.,
voice phishing, or physical threat.
container threat-prevention: The leak of this node to an
attacker could reveal the specific detection system to an
attacker. An attacker can use this information to design
new unknown attack strategies to circumvent the existing
detection or prevention system.
The Open Group Base Specifications Issue 7, 2018 EditionIEEEISO 3166-1 decoding tableISOISO 3166-2:2007ISOMISP CoreCIRCLCIRCLOpenIOC 1.1 DRAFTMandiantStructured Threat Information Expression (STIX)Assigned Internet Protocol NumbersInternet Assigned Numbers Authority (IANA)Internet Control Message Procotol version 6 (ICMPv6) ParametersInternet Assigned Numbers Authority (IANA)Study on technical aspects on roaming end-to-end scenarios
with Voice over LTE (VoLTE) IP Multimedia Subsystem (IMS) and other networks
3GPP
Summary of Rel-15 Work Items
3GPP
This document is a product by the I2NSF Working Group (WG) including
WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez.
This document took advantage of the review and comments from the following people:
Roman Danyliw, Mahdi F. Dachmehchi, Daeyoung Hyun, Jan Lindblad (YANG doctor),
Tom Petch, Charlie Kaufman, Penglin Yang, and Jung-Soo Park.
The authors sincerely appreciate their sincere efforts and kind help.
This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
Security Intelligence Technology Development for the Customized Security
Service Provisioning).
This work was supported in part by the IITP (2020-0-00395-003, Standard
Development of Blockchain based Network Management Automation Technology).
The following are co-authors of this document:
Patrick Lingga -
Department of Electrical and Computer Engineering,
Sungkyunkwan University,
2066 Seo-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: patricklink@skku.edu
Jinyong Tim Kim -
Department of Electronic, Electrical and Computer Engineering,
Sungkyunkwan University,
2066 Seo-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: timkim@skku.edu
Hyoungshick Kim -
Department of Computer Science and Engineering,
Sungkyunkwan University,
2066 Seo-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: hyoung@skku.edu
Eunsoo Kim -
Department of Electronic, Electrical and Computer Engineering,
Sungkyunkwan University,
2066 Seo-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: eskim86@skku.edu
Seungjin Lee -
Department of Electronic, Electrical and Computer Engineering,
Sungkyunkwan University,
2066 Seo-ro Jangan-gu,
Suwon, Gyeonggi-do 16419,
Republic of Korea.
EMail: jine33@skku.edu
Anil Lohiya -
Juniper Networks,
1133 Innovation Way,
Sunnyvale, CA 94089,
US.
EMail: alohiya@juniper.net
Dave Qi -
Bloomberg,
731 Lexington Avenue,
New York, NY 10022,
US.
EMail: DQI@bloomberg.net
Nabil Bitar -
Nokia,
755 Ravendale Drive,
Mountain View, CA 94043,
US.
EMail: nabil.bitar@nokia.com
Senad Palislamovic -
Nokia,
755 Ravendale Drive,
Mountain View, CA 94043,
US.
EMail: senad.palislamovic@nokia.com
Liang Xia -
Huawei,
101 Software Avenue,
Nanjing, Jiangsu 210012,
China.
EMail: Frank.Xialiang@huawei.com
The following changes are made from draft-ietf-i2nsf-consumer-facing-interface-dm-25:
This version has reflected the 3rd AD Review by Roman Danyliw.