I2NSF Capability YANG Data Model
Huawei
7453 Hickory HillSalineMI48176USA+1-734-604-0332shares@ndzh.com
Department of Software
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 Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 10 8273 0930timkim@skku.edu
HTT Consulting
Oak ParkMIUSA+1-248-968-9809rgm@htt-consult.com
Huawei
Huawei Industrial BaseShenzhenGuangdong 518129Chinalinqiushi@huawei.com
Security
I2NSF Working GroupInternet-Draft
This document defines a YANG data model for capabilities of various Network Security Functions (NSFs) in Interface to Network Security Functions (I2NSF) framework to cetrally manage capabilities of varios NSFs.
As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and VoIP/VoLTE smartphones), service providers have a lot of problems mentioned in .
To resolve these problems, specifies the information model of the capabilities of Network Security Functions (NSFs).
This document provides a data model using YANG that defines the capabilities of NSFs to centrally manage capabilities of those security devices.
The security devices can register their own capabilities into Network Operator Management (Mgmt) System (i.e., Security Controller) with this YANG data model through the registration interface .
With the capabilities of those security devices registered centrally, those security devices can be easily managed .
This YANG data model is based on the information model for I2NSF NSF capabilities .
This YANG data model uses an "Event-Condition-Action" (ECA) policy model that is used as the basis for the design of I2NSF Policy described in and .
Rules.
The "ietf-i2nsf-capability" YANG module defined in this document provides the following features:
Definition for general capabilities of network security functions.
Definition for event capabilities of generic network security function.
Definition for condition capabilities of generic network security function.
Definition for condition capabilities of advanced network security function.
Definition for action capabilities of generic network security function.
Definition for resolution strategy capabilities of generic network security function.
Definition for default action capabilities of generic network security function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
This document uses the terminology described in .
Especially, the following terms are from :
Data Model: A data model is a representation of concepts of
interest to an environment in a form that is dependent on data
repository, data definition language, query language,
implementation language, and protocol.
Information Model: An information model is a representation of
concepts of interest to an environment in a form that is
independent of data repository, data definition language, query
language, implementation language, and protocol.
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only).
Symbols after data node names: "?" means an optional node and "*"
denotes a "list" and "leaf-list".
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
Ellipsis ("...") stands for contents of subtrees that are not
shown.
This section explains overview how the YANG data model can be used in I2NSF framework described in .
shows capabilities of NSFs in I2NSF Framework.
As shown in this figure, Developer's Mgmt System can register NSFs with capabilities that the network security device can support.
To register NSFs in this way, the Developer's Mgmt System utilizes this standardized capabilities YANG data model through registration interface.
With the capabilities of those network security devices registered centrally, those security devices can be easily managed, which can resolve the a lot of problems described in .
The following shows use cases.
Note is used to configure security policy rules of generic network security functions and is used to configure security policy rules of advanced network security functions according to the capabilities of network security devices registed in I2NSF Framework.
If network manager wants to apply security policy rules about blocking malicious users, it is a tremendous burden to apply all of these rules to NSFs one by one.
This problem can be resolved by managing the capabilities of NSFs.
If network manager wants to block malicious users with IPv6, network manager sends the security policy rules about blocking the users to Network Operator Mgmt System using I2NSF user (i.e., a web browser or a software).
When the Network Operator Mgmt System receives the security policy rules, it automatically sends that security policy rules to appropriate NSFs (i.e., NSF-m in Developer Mgmt System A and NSF-1 in Developer Mgmt System B) which can support the capabilities (i.e., IPv6).
Therefore, I2NSF User need not consider NSFs where to apply the rules.
If NSFs find the malicious packets, it is a tremendous burden for network manager to apply the rule about blocking the malicious packets to NSFs one by one.
This problem can be resolved by managing the capabilities of NSFs.
If NSFs find the suspicious packets with IPv4, they can ask the Network Operator Mgmt System for information about the suspicious packets with IPv4.
to alter specific rules and/or configurations.
When the Network Operator Mgmt System receives information, it inspects the information about the suspicious packets with IPv4.
If the suspicious packets are determined to be malicious packets, the Network Operator Mgmt System creates and sends the security policy rule against malicious packets to appropriate NSFs (i.e., NSF-1 in Developer Mgmt System A and NSF-1 and NSF-n in Developer Mgmt System B) which can support the capabilities (i.e., IPv4).
Therefore, the new security policy rule against malicious packets can be applied to appropriate NSFs without intervention of humans.
This section shows an YANG tree diagram of capabilities for network security functions, as defined in the .
This section shows YANG tree diagram for capabilities of network security functions.
This YANG tree diagram shows capabilities of network security functions.
The NSF includes NSF capabilities.
The NSF capabilities include time capabilities, event capabilities, condition capabilities, action capabilities, resolution strategy capabilities, and default action capabilities.
Time capabilities are used to specify capabilities when to execute the I2NSF policy rule.
The time capabilities are defined as absolute time and periodic time.
Event capabilities are used to specify capabilities how to trigger the evaluation of the condition clause of the I2NSF Policy Rule.
The event capabilities are defined as system event and system alarm.
The event capability can be extended according to specific vendor condition features.
The event capability is described in detail in .
Condition capabilities are used to specify capabilities of a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether or not the set of actions in that (imperative) I2NSF policy rule can be executed or not.
The condition capability is classified as condition capabilities of generic network security functions and advanced network security functions.
The condition capabilities of generic network security functions are defined as IPv4 capability, IPv6 capability, tcp capability, udp capability, and icmp capability.
The condition capabilities of advanced network security functions are defined as antivirus capability, antiddos capability, ips capability, http capability, and VoIP/VoLTE capability.
The condition capability can be extended according to specific vendor condition features.
The condition capability is described in detail in .
Action capabilities is used to specify capabilities how to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied.
The action capabilities are defined as ingress action capability, egress action capability, and log action capability.
The action capability can be extended according to specific vendor action features.
The action capability is described in detail in .
Resolution strategy capabilities are used to specify capabilities how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF.
The resolution strategy capabilities are defined as First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized Matching Rule (PMR) with Errors (PMRE), and Prioritized Matching Rule with No Errors (PMRN).
The resolution strategy capability can be extended according to specific vendor action features.
The resolution strategy capability is described in detail in .
Default action capabilities are used to specify capabilities how to execute I2NSF policy rule when no rule matches a packet.
The default action capabilities are defined as pass, drop, reject, alert, and mirror.
The default action capability can be extended according to specific vendor action features.
The default action capability is described in detail in .
IPsec method capabilities are used to specify capabilities how to support an Internet key exchange for the security communication.
The default action capabilities are defined as ike and ikeless.
The default action capability can be extended according to specific vendor action features.
The default action capability is described in detail in .
This section introduces an YANG data module for capabilities of network security functions, as defined in the .
This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in the "YANG Module Names" registry [RFC7950].
name: ietf-i2nsf-capability
namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability
prefix: iicapa
reference: RFC XXXX
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 transport secure transport is Secure Shell (SSH) .
The lowest RESTCONF layer is HTTPS, and the required transport 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.
Key words for use in RFCs to Indicate Requirement LevelsYANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)The YANG 1.1 Data Modeling LanguageInterface to Network Security Functions (I2NSF): Problem Statement and Use CasesFramework for Interface to Network Security FunctionsA YANG Data Model for Routing Information Base (RIB)Information Model of NSFs CapabilitiesInterface to Network Security Functions (I2NSF) TerminologyConfiguration of Advanced Security Functions with I2NSF Security ControllerGeneric Policy Information Model for
Simplified Use of Policy Abstractions (SUPA) I2NSF Network Security Function-Facing Interface YANG Data ModelSoftware-Defined Networking (SDN)-based IPsec Flow Protection
The following changes are made from draft-ietf-i2nsf-capability-data-model-03:
We added a leaf-list for IPsec method capabilities (e.g., ike and ikeless).
We changed http capa fields to url category capa fields.
We added context capa fields (e.g., acl number, application, target, users, group, and geography).
This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government (MSIP)
(No.R-20160222-002755, Cloud based Security Intelligence Technology
Development for the Customized Security Service Provisioning).
This document is made by the group effort of I2NSF working group.
Many people actively contributed to this document.
The following are considered co-authors:
Hyoungshick Kim (Sungkyunkwan University) Daeyoung Hyun (Sungkyunkwan University) Dongjin Hong (Sungkyunkwan University) Liang Xia (Huawei) Jung-Soo Park (ETRI) Tae-Jin Ahn (Korea Telecom) Se-Hui Lee (Korea Telecom)