I2NSF Registration Interface YANG Data Model
Department of Computer Engineering
Chosun University309, Pilmun-daero, Dong-guGwangjuJeollanam-do61452Republic of Koreashyun@chosun.ac.kr
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
Electrical Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 290 7222+82 31 299 6673tkroh0198@skku.eduhttp://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57
Electrical Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 290 7222+82 31 299 6673dnl9795@skku.eduhttp://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57
Electronics and Telecommunications Research Institute
218 Gajeong-Ro, Yuseong-GuDaejeon305-700Republic of Korea+82 42 860 6514pjs@etri.re.krInternet-Draft
This document describes an YANG data model for I2NSF registration interface between Security Controller and Developer's Management System. The data model is required for NSF instance registration and dynamic life cycle management of NSF instances.
This document provides a YANG data model that defines the required data for the registration interface between Security Controller and Developer's Management System to dynamically manage a pool of NSF instances. This document defines a YANG data model based on the . The terms used in this document are defined in .
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 , , , , , and .
Network Security Function (NSF): A function that is responsible for specific treatment of received packets. A Network Security Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). Sample Network Security Service Functions are as follows: Firewall, Intrusion Prevention/Detection System (IPS/IDS), Deep Packet Inspection (DPI), Application Visibility and Control (AVC), network virus and malware scanning, sandbox, Data Loss Prevention (DLP), Distributed Denial of Service (DDoS) mitigation and TLS proxy.
Advanced Inspection/Action: As like the I2NSF information model for NSF facing interface , Advanced Inspection/Action means that a security function calls another security function for further inspection based on its own inspection result.
Network Security Function Profile (NSF Capability Information): NSF Capability Information specifies the inspection capabilities of the associated NSF instance. Each NSF instance has its own NSF Capability Information to specify the type of security service it provides and its resource capacity etc.
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 provides an overview of the high level YANG.
Each of these sections mirror sections of .
This section expands the i2nsf-regs-req in .
Registration Request contains the capability information of newly created NSF to notify its capability to Security Controller. The request also contains Network Access Information so that the Security Controller can access the NSF.
This section expands the i2nsf-instance-mgnt-req in .
Instance management request consists of two types: instanciation-request, deinstanciation-request, and reinstanciation-request. The instanciation-request is used to request generation of a new NSF instance with NSF Capability Information which specifies required NSF capability information. The deinstanciation-request is used to remove an existing NSF with NSF Access Information. The reinstanciation nsf request is used to updating a existing NSf information with NSF capabilities.
This section expands the i2nsf-nsf-capability-information in and .
In , ietf-i2nsf-capability refers module ietf-i2nsf-capability in . We add the performance capability because it is absent in and
This section expands the i2nsf-nsf-access-info in and .
This information is used by other components to access an NSF.
This section expands the i2nsf-nsf-performance-caps in .
When the Security Controller requests the Developer Management System to create a new NSF instance, the performance capability is used to specify the performance requirements of the new instance.
This section expands the ietf-netmod-acl-model in .
In , ietf-netmod-acl-model refers module ietf-netmod-acl-model in . We add the role-based ACL because it is absent in .
This section introduces a YANG module for the information model of the required data for the registration interface between Security Controller and Developer's Management System, as defined in the .
Requirement: Registering the IDS NSF with VoIP/VoLTE security capability using Registration interface.
Here is the configuration xml for this Registration Interface:
The information model of the registration interface is based on the I2NSF framework without any architectural changes. Thus, this document shares the security considerations of the I2NSF framwork architecture that are specified in for the purpose of achieving secure communication among components in the proposed architecture.
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).
Key words for use in RFCs toIndicate Requirement LevelsYANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)Information Model of NSFs CapabilitiesFramework for Interface to Network Security Functions Interface to Network Security Functions (I2NSF) Terminology Service Function Chaining-Enabled I2NSF Architecture I2NSF Registration Interface Information ModelI2NSF Capability YANG Data ModelGeneric Policy Information Model for Simplified Use of Policy Abstractions (SUPA)Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)A YANG Data Model for Routing Information Base (RIB)Network Access Control List (ACL) YANG Data Model
The following changes are made from draft-hyun-i2nsf-registration-interface-dm-03:
We added Re-instantiation item.
The references were updated to reflect the latest documents.