Network Working Group S. Hyun
Internet-Draft S. Woo
Intended status: Standards Track Y. Yeo
Expires: May 4, 2017 J. Jeong
Sungkyunkwan University
J. Park
ETRI
October 31, 2016
Registration Interface Information Model
draft-hyun-i2nsf-registration-interface-im-00
Abstract
This document describes an information model for Interface to Network
Security Functions (I2NSF) Registration Interface between Security
Controller and Developer's Management System. The information model
is required for Network Security Function (NSF) instance registration
and dynamic life cycle management of NSF instances. This document
explains the procedures over I2NSF registration interface for these
functionalities. It also describes the detailed information which
should be exchanged via I2NSF registration interface.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Hyun, et al. Expires May 4, 2017 [Page 1]
Internet-Draft Registration Interface Information Model October 2016
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Life-Cycle Managment Mechanism . . . . . . . . . . . . . . 6
5.2. Registration Mechanism . . . . . . . . . . . . . . . . . . 6
5.3. NSF Access Information . . . . . . . . . . . . . . . . . . 7
5.4. NSF Profile (Capabilities of an NSF instance) . . . . . . 7
5.4.1. Packet Content-Matching Capability . . . . . . . . . . 8
5.4.2. Content-Matching Capability . . . . . . . . . . . . . 8
5.4.3. Context-Matching Capability . . . . . . . . . . . . . 8
5.4.4. Attack-Mitigation Capability . . . . . . . . . . . . . 9
5.4.5. Action Capability . . . . . . . . . . . . . . . . . . 9
5.4.6. Performance Capability . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Hyun, et al. Expires May 4, 2017 [Page 2]
Internet-Draft Registration Interface Information Model October 2016
1. Introduction
A number of virtual network security function instances typically
exist in Interface to Network Security Functions (I2NSF) framework
[i2nsf-framework]. In this environment, it is important to
dynamically manage a Network Security Function (NSF) instance pool
for efficient resource utilization. For instance, if a certain NSF
instance is receiving an excessive amount of traffic beyond its
capacity, an additional instance for the same security function
should be created. If an NSF instance is idle for a period of time,
it would be better to destroy it to avoid resource waste. In
addition, the existing information model for NSF facing interface
requires an NSF to trigger another type of NSF for further inspection
[capability-interface-im]. In this case, if there is no available
instance for the latter NSF, a new NSF should be instantiated.
Similarly, in order to enforce a security policy from the client, all
the required NSF instances should be created.
This document describes the procedures which should be performed on
the registration interface between security controller and
developer's management system to dynamically manage a pool of NSF
instances. It further describes the detailed information which
should be exchanged between security controller and developer's
management system.
2. Requirements Language
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 [RFC2119].
3. Terminology
This document uses the terminology described in
[i2nsf-terminology][capability-interface-im][i2nsf-framework]
[nsf-triggered-steering].
o 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
[nsf-triggered-steering].
Hyun, et al. Expires May 4, 2017 [Page 3]
Internet-Draft Registration Interface Information Model October 2016
o Advanced Inspection/Action: As like the I2NSF information model
for NSF facing interface [capability-interface-im], Advanced
Inspection/Action means that a security function calls another
security function for further inspection based on its own
inspection result [nsf-triggered-steering].
o Network Security Function Profile (NSF Profile): NSF Profile
specifies the inspection capabilities of the associated NSF
instance. Each NSF instance has its own NSF Profile to specify
the type of security service and its resource capacity
[nsf-triggered-steering].
4. Objectives
o Efficient network resource utilization through dynamic
instantiation of NSFs and load balancing: In I2NSF framework, it
is sometimes possible that a specific NSF experiences heavy
traffic loads. For example, under DDoS attacks, a huge volume of
traffic would be driven to DoS attack mitigator function to cope
with the attacks. In this case, we should allocate a large
portion of resources to that DoS attack mitigator function by
creating a sufficient number of DoS mitigator instances. After
the attack is terminated, we should eliminate some of the
instances no longer used. In this way, we can achieve efficient
resource utilization. For this purpose, it is indispensable to
define an information model of registration interface for dynamic
instantiation/elimination of NSF instances.
o Creating an NSF instance to serve another NSF's inspection
request: In I2NSF framework, an NSF triggers another type of
NSF(s) when the traffic requires further security inspection. The
following NSF is determined by previous NSF's inspection result
and client's policy. However, if there is no available instance
of the latter NSF required by the former NSF, we should be able to
create an NSF instance via Developer's Management System (DMS) and
registration interface.
o Creating NSF instances required to enforce security policy rules
from Client: In I2NSF framework, client decides which security
service is necessary in the system. If there is no NSF instances
to fully support the client's security requirements, then we
should also create the required instances by requesting DMS via
registration interface.
o Registering NSF instances by Developer's Management System:
Depending on system's security requirements, it may require some
NSFs by default. In this case, DMS creates these default NSF
instances without the need of receiving requests from Security
Hyun, et al. Expires May 4, 2017 [Page 4]
Internet-Draft Registration Interface Information Model October 2016
Controller. DMS then notifies Security Controller of those NSF
instances via registration interface.
5. Information Model
The I2NSF registration interface was only used for registering new
NSF instances to Security Controller. In this document, however, we
extend its utilization to support dynamic NSF life cycle management
and describe the information that should be exchanged via the
registration interface for the functionality . Moreover, we also
define the information model of NSF Profile because, for registration
interface, NSF Profile (i.e., capabilities of an NSF) needs to be
clarified so that the components of I2NSF framework can exchange the
set of capabilities in a standardized manner. This is typically done
through the following process::
1) Security Controller first recognizes the set of capabilities
(i.e., NSF Profile) or the signature of a specific NSF required
or wasted in the current system.
2) Developer's Management System (DMS) matches the recognized
information to an NSF based on the information model definition.
3) Developer's Management System creates or eliminates NSFs matching
with the above information.
4) Security Controller can then add/remove the corresponding NSF
instance to/from its list of available NSF instances in the
system.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Interface Model Design |
| |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| |Life-Cycle Management| | Registration | |
| | Sub-Model | | Sub-Model | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Registration Interface Model Design
As illustrated in Figure 1, the information model for Registration
Interface consists of two sub-models: life-cycle management,
registration sub-models. The life-cycle management functionality and
the registration functionality use NSF Profile to achieve their
goals. In this context, NSF Profile is the capability objects that
Hyun, et al. Expires May 4, 2017 [Page 5]
Internet-Draft Registration Interface Information Model October 2016
describe and/or prescribe inspection capability an NSF instance can
provide.
5.1. Life-Cycle Managment Mechanism
For the life-cycle management of NSFs, Security Controller in I2NSF
framework requires two types of requests: Instance Creation and
Elimination Request Messages. Security Controller sends the request
messages to DMS when required. Once receiving the request, DMS
conducts creating/eliminating the corresponding NSF instance and
responds Security Controller with the results. There are several
cases requiring creation of a new NSF instance which provides
specific security inspection functionalities and elimination of an
existing NSF which is unused for a period of time. For example,
1) When an NSF triggers an advanced inspection of the suspicious
traffic via another type of NSF whose instance is currently
unavailable in the system.
2) When an NSF instance undergoes an excessive amount of traffic
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
|Instance Creation| | Instance Elimination |
| Request Message | | Request Message |
+-+-+-+-^-+-+-+-+-+ +-+-+-+-+-+^+-+-+-+-+-+-+
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| NSF Profile | | NSF Access |
+-+-+-+-+-+-+-+-+ | Information |
+-+-+-+-+-+-+-+-+
Figure 2: Life-Cycle Management Sub-Model Overview
5.2. Registration Mechanism
In order to register a new NSF instance, DMS should generate a
Registration Message to Security Controller. A Registration Message
consists of an NSF Profile and an NSF Access Information. The former
describes the inspection capability of the new NSF instance and the
latter is for enabling network access to the new instance from other
components. After this registration process, as explained in
[capability-interface-im], the I2NSF capability interface can conduct
controlling and monitoring the new registered NSF instance.
Hyun, et al. Expires May 4, 2017 [Page 6]
Internet-Draft Registration Interface Information Model October 2016
+-+-+-+-+-+-+-+-+
| Registration |
| Message |
+-+-+-+-^-+-+-+-+
|
+-----------------------------+
| |
| |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| NSF Profile | | NSF Access |
| | | Information |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 3: Registration Mechanism Sub-Model Overview
5.3. NSF Access Information
NSF Access Information can contain IPv4 Address, IPv6 Address,
Transport Protocol, Port Number etc. In this document, NSF Access
Information is used to identify a specific NSF instance (i.e. NSF
Access Information is the signature of an NSF instance in the overall
system).
5.4. NSF Profile (Capabilities of an NSF instance)
NSF Profile basically refers the inspection capabilities of an NSF
instance. As illustrated in Figure 4, it can be split into five
capabilities (Content-Matching, Context-Matching, Attack-Mitigation,
Action, Performance Capabilities). We share security capabilities
which are defined in Section 3 (Overall Analysis of Security
Capability) in [capability-interface-im] for the first five
capabilities and append one additional capability.
Hyun, et al. Expires May 4, 2017 [Page 7]
Internet-Draft Registration Interface Information Model October 2016
+-+-+-+-+-+-+-+-+
| Capability |
| Objects |
+-+-+-+-^-+-+-+-+
|
+--------------------+--------------------+-----------+
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
|Content-Matching | |Content-Matching | |Context-Matching | |
| (Packet) | | Capability | | Capability | |
| Capability | | | | | |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ |
|
+--------------------+--------------------+-----------+
| | |
| | |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
|Attack Mitigation| | Action | | Performance |
| Capability | | Capability | | Capability |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
Figure 4: NSF Profile Overview
5.4.1. Packet Content-Matching Capability
Refer to the kind of information or attributes acquired directly from
the packet headers or payloads that can be used in the security
policy. It can be any fields or attributes in the packet L2/L3/L4
header, or special segment of bytes in the packet payload.
[capability-interface-im]
5.4.2. Content-Matching Capability
Content security is another category of security capabilities applied
to application layer. Through detecting the contents carried over
the traffic in application layer, these capabilities can realize
various security functions, such as defending against intrusion,
inspecting virus, filtering malicious URL or junk email, blocking
illegal web access or malicious data retrieval.
[capability-interface-im]
5.4.3. Context-Matching Capability
This capability refers to the content information for the received
packets. It can be User, Schedule, Region, Target, State and
Direction information. [capability-interface-im]
Hyun, et al. Expires May 4, 2017 [Page 8]
Internet-Draft Registration Interface Information Model October 2016
5.4.4. Attack-Mitigation Capability
This category of security capabilities is used to detect and mitigate
various types of network attacks. Today's common network attacks can
be classified into the following sets, and each set further consists
of a number of specific attacks: [capability-interface-im]
o DDoS attacks:
* Network layer DDoS attacks: Examples include SYN flood, UDP
flood, ICMP flood, IP fragment flood, IPv6 Routing header
attack, and IPv6 duplicate address detection attack;
* Application layer DDoS attacks: Examples include http flood,
https flood, cache-bypass http floods, WordPress XML RPC
floods, ssl DDoS.
o Single-packet attack:
* Scanning and sniffing attacks: IP sweep, port scanning, etc
* Malformed packet attacks: Ping of Death, Teardrop, etc
* Special packet attacks: Oversized ICMP, Tracert, IP timestamp
option packets, etc
5.4.5. Action Capability
NSFs provide security functions by executing various Actions, which
at least includes: [capability-interface-im]
o Ingress actions, such as pass, drop, mirroring, etc;
o Egress actions, such as invoke signaling, tunnel encapsulation,
packet forwarding and/or transformation;
o Applying a specific Functional Profile or signature (NSF Profile)
- The functional profile or signature file defines the security
capabilities for content security control and/or attack mitigation
control. One goal of I2NSF is to standardize the form and
functional interface of those security capabilities while
supporting vendor-specific implementations of each.
5.4.6. Performance Capability
This capability represents hardware capacity information such as the
amount of traffic it can process per second. In addition, this
information can specify an available amount of each type of resources
Hyun, et al. Expires May 4, 2017 [Page 9]
Internet-Draft Registration Interface Information Model October 2016
such as processing power and memory etc. an NSF instance has.
6. Security Considerations
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 [i2nsf-framework] for the purpose
of achieving secure communication among components in the proposed
architecture.
7. Acknowledgements
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).
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
8.2. Informative References
[capability-interface-im] Xia, L., Zhang, D., Lopez, E., Bouthors,
N., and L. Fang, "Information Model of
Interface to Network Security Functions
Capability Interface",
draft-xia-i2nsf-capability-interface-im-06
(work in progress), July 2016.
[i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L.,
Strassner, J., Zhuang, X., Parrott, J.,
Krishnan, R., Durbha, S., Kumar, R., and
A. Lohiya, "Framework for Interface to
Network Security Functions",
draft-ietf-i2nsf-framework-03 (work in
progress), October 2016.
[i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia,
L., and H. Birkholz, "Interface to Network
Security Functions (I2NSF) Terminology",
draft-ietf-i2nsf-terminology-01 (work in
progress), October 2016.
Hyun, et al. Expires May 4, 2017 [Page 10]
Internet-Draft Registration Interface Information Model October 2016
[nsf-triggered-steering] Hyun, S., Woo, S., Yeo, Y., Jeong, J., and
J. Park, "NSF-Triggered Traffic Steering",
draft-hyun-i2nsf-nsf-triggered-steering-
in-i2nsf-00 (work in progress).
Authors' Addresses
Sangwon Hyun
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 290 7222
Fax: +82 31 299 6673
EMail: swhyun77@skku.edu
URI: http://imtl.skku.ac.kr/
SangUk Woo
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 290 7222
Fax: +82 31 299 6673
EMail: suwoo@imtl.skku.ac.kr,
URI: http://imtl.skku.ac.kr/index.php?mid=member_student
YunSuk Yeo
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 290 7222
Fax: +82 31 299 6673
EMail: yunsuk@imtl.skku.ac.kr,
URI: http://imtl.skku.ac.kr/index.php?mid=member_student
Hyun, et al. Expires May 4, 2017 [Page 11]
Internet-Draft Registration Interface Information Model October 2016
Jaehoon Paul Jeong
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 299 4957
Fax: +82 31 290 7996
EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Jung-Soo Park
Electronics and Telecommunications Research Institute
218 Gajeong-Ro, Yuseong-Gu
Daejeon 305-700
Republic of Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Hyun, et al. Expires May 4, 2017 [Page 12]