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.comInternet-Draft
This document defines a YANG data model for capabilities that enables an I2NSF user to control various network security functions in network security devices.
As the industry becomes more sophisticated and network devices (i.e., IoT, Intelligent Vehicle, and VoIP/VoLTE Phone), service providers has a lot of problems .
To resolve this problem, standardize capabilities of network security functions.
This document provides a YANG data model that defines the capabilities to express capabilities of security devices.
The security devices can register own capabilities to Network Operator Mgmt System with this YANG data model through registration interface.
After the capabilities of the devices are registered, this YANG data model can be used by the IN2SF user or Service Function Forwarder (SFF) to acquire appropriate NSFs that can be controlled by the Network Operator Mgmt System.
This document defines a YANG data model based on the . Terms used in document are defined in .
The "Event-Condition-Action" (ECA) policy model is used as the basis for the design of I2NSF Policy
Rules.
The "ietf-i2nsf-capability" YANG module defined in this document provides the following features:
Configuration of identification for generic network security function policy
Configuration of event capabilities for generic network security function policy
Configuration of condition capabilities for generic network security function policy
Configuration of action capabilities for generic network security function policy
Configuration of strategy capabilities for generic network security function policy
Configuration of default action capabilities for generic network security function policy
RPC for acquiring appropriate network security function according to type of NSF and/or target devices.
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 by I2NSF User, Developer's Mgmt System, and SFF.
shows capabilities of NSFs in I2NSF Framework.
As shown in this figure, Developer's Mgmt System can register NSFs with capabilities that the device can support.
To register NSFs in this way, the Developer's Mgmt System utilizes this standardized capabilities YANG data model through registration interface.
Through this registration of capabilities, the a lot of problems can be resolved.
The following shows use cases.
Note is used to configure rules of NSFs in I2NSF Framework.
If I2NSF User wants to apply 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 standardizing the capabilities of NSFs.
If I2NSF User wants to block malicious users with IPv6, I2NSF User sends the rules about blocking the users to Network Operator Mgmt System.
When the Network Operator Mgmt System receives the rules, it sends that 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 I2NSF User to apply the rule about blocking the malicious packets to NSFs one by one.
This problem can be resolved by standardizing the capabilities of NSFs.
If NSFs find the malicious packets with IPv4, they can ask the Network Operator Mgmt System to alter specific rules and/or configurations.
When the Network Operator Mgmt System receives the rules for malicious packets, it inspects whether the rules are reasonable and sends the rules 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 rules can be applied to appropriate NSFs without control of I2NSF USer.
If NSFs of Service Function Chaining (SFC) fail, it is a tremendous burden for I2NSF User to reconfigure the policy of SFC immediately.
This problem can be resolved by periodically acquiring information of appropriate NSFs of SFC.
If SFF needs information of Web Application Firewall for SFC, it can ask the Network Operator Mgmt System to acquire the location information of appropriate Web Application Firewall.
When the Network Operator Mgmt System receives requested information from SFF, it sends location information of Web Application Firewall to the SFF.
Therefore, the policy about the NSFs of SFC can be periodically updated without control of I2NSF USer.
This shows a identification for generic network security functions.
These objects are defined as location information and target device information.
This shows a event capabilities for generic network security functions policy.
This is used to specify capabilities about any important occurrence in time of a change in the system being managed, and/or in the environment of the system being managed.
When used in the context of I2NSF Policy Rules, it is used to determine whether the Condition clause of the I2NSF Policy Rule can be evaluated or not.
These object of event capabilities is defined as user security event capabilities, device security event capabilities, system security event capabilities, and time security event capabilities.
These object of event capabilities can be extended according to specific vendor event features.
This shows a condition capabilities for generic network security functions policy.
This is used to specify capabilities about 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.
These object of condition capabilities is defined as packet security condition capabilities, packet payload security condition capabilities, target security condition capabilities, user security condition capabilities, context condition capabilities, and generic context condition capabilities.
These object of condition capabilities can be extended according to specific vendor condition features.
This shows a action capabilities for generic network security functions policy.
This is used to specify capabilities to control and monitor aspects of flow-based NSFs when the event and condition clauses are satisfied. NSFs provide security functions by executing various Actions.
These object of action capabilities is defined as ingress action capabilities, egress action capabilities, and apply profile action capabilities.
These object of action capabilities can be extended according to specific vendor action features.
This shows a resolution strategy capabilities for generic network security functions policy.
This can be 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.
These objects are defined as first-matching-rule capability and last-matching-rule capability.
These objects can be extended according to specific vendor resolution strategy features.
This shows a default action policy for generic network security functions.
This can be used to specify capabilities about a predefined action when no other alternative action was matched by the currently executing I2NSF Policy Rule.
This shows a RPC for acquiring an appropriate network security function according to type of NSF and/or target devices.
If the SFF does not have the location information of network security functions that it should send in own cache table, this can be used to acquire the information.
These objects are defined as input data (i.e., NSF type and target devices) and output data (i.e., location information of NSF).
This section shows an overview of
a structure tree of capabilities for generic network security functions, as defined in the .
The data model for network security function identification has the following structure:
This draft also utilizes the
concepts originated in Basile, Lioy, Pitscheider, and Zhao[2015]
concerning conflict resolution, use of external data, and
target device. The authors are grateful to Cataldo for pointing out
this excellent work.
The nsf-type object can be used for configuration about type of a NSF.
The types of NSF consists of Network Firewall, Web Application Firewall, Anti-Virus, IDS, IPS, and DDoS Mitigator.
The nsf-address object can be used for configuration about location of a NSF.
The target-device object can be used for configuration about target devices.
We will add additional type of a NSF for more generic network security functions.
The data model for Generic NSF capabilities has the following structure:
The data model for event capabilities has the following structure:
These objects are defined as capabilities of user security event, device security event, system security event, and time security event.
These objects can be extended according to specific vendor event features.
We will add additional event objects for more generic network security functions.
The data model for condition capabilities has the following structure:
These objects are defined as capabilities of packet security condition, packet payload security condition, target security condition, user security condition, context condition, and generic context condition.
These objects can be extended according to specific vendor condition features.
We will add additional condition objects for more generic network security functions.
The data model for action capabilities has the following structure:
These objects are defined capabilities as ingress action, egress action, and apply profile action.
These objects can be extended according to specific vendor action feature.
We will add additional action objects for more generic network security functions.
The data model for resolution strategy capabilities has the following structure:
These objects are defined capabilities as first-matching-rule and last-matching-rule.
These objects can be extended according to specific vendor resolution strategy features.
We will add additional resolution strategy objects for more generic network security functions.
The data model for default action capabilities has the following structure:
The data model for RPC for Acquiring Appropriate Network Security Function has the following structure:
This shows a RPC for acquiring an appropriate network security function according to type of NSF and/or target devices.
If the SFF does not have the location information of network security functions that it should send in own cache table, this can be used to acquire the information.
These objects are defined as input data (i.e., NSF type and target devices) and output data (i.e., location information of NSF).
This section introduces a YANG module for the information model of network
security functions, as defined in the .
No IANA considerations exist for this document at this time. URL will be added.
This document introduces no additional security threats and SHOULD
follow the security requirements as stated in .
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).
I2NSF is a group effort.
I2NSF has had a number of contributing authors.
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) Key words for use in RFCs to Indicate Requirement LevelsYANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)Interface to Network Security Functions (I2NSF): Problem Statement and Use CasesFramework for Interface to Network Security FunctionsInformation Model of NSFs CapabilitiesInterface to Network Security Functions (I2NSF) TerminologyA YANG Data Model for Routing Information Base (RIB)Generic Policy Information Model for
Simplified Use of Policy Abstractions (SUPA) Service Function Chaining-Enabled I2NSF ArchitectureI2NSF Network Security Function-Facing Interface YANG Data Model
This section gives a simple example of how VoIP-VoLTE Security Function Capabilities
module could be extended.
This section gives a xml examples for a configuration of Capability module according to a requirement.
This section gives a xml example for generic network security function capability configuration according to a requirement.
Requirement: Register packet filter according to requirements.
The location of the NSF is 221.159.112.150.
The NSF can obtain the best effect if the packet was generated by PC or IoT.
The NSF can apply policies according to time.
The NSF should be able to block the source packets or destination packets with IPv4 address.
The NSF should be able to pass, reject, or alert packets.
Here is XML example for the generic network security function capability configuration:
This section gives a xml example for extended VoIP-VoLTE security function capabilities (See ) configuration according to a requirement.
Requirement: Register VoIP/VoLTe security function according to requirements.
The location of the NSF is 221.159.112.151.
The NSF can obtain the best effect if the packet was generated by VoIP-VoLTE phone.
The NSF should be able to block the malicious sip packets with user agent.
The NSF should be able to pass, reject, or alert packets.
Here is XML example for the VoIP-VoLTE security function capabilities configuration:
The following changes are made from draft-hares-i2nsf-capability-data-model-06:
We added the the capability for time zone and time interval.