Registration Interface Information Model for Interface to Network Security Functions
draft-hyun-i2nsf-registration-interface-im-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Sangwon Hyun , Jaehoon Paul Jeong , SangUk Woo , yunsuk@imtl.skku.ac.kr, Park Jung-Soo | ||
| Last updated | 2017-03-13 (Latest revision 2016-10-31) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hyun-i2nsf-registration-interface-im-01
Network Working Group S. Hyun
Internet-Draft J. Jeong
Intended status: Standards Track S. Woo
Expires: September 14, 2017 Y. Yeo
Sungkyunkwan University
J. Park
ETRI
March 13, 2017
Registration Interface Information Model for Interface to Network
Security Functions
draft-hyun-i2nsf-registration-interface-im-01
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 the 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 September 14, 2017.
Hyun, et al. Expires September 14, 2017 [Page 1]
Internet-Draft Registration Interface Information Model March 2017
Copyright Notice
Copyright (c) 2017 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
Appendix A. Changes from
draft-hyun-i2nsf-registration-interface-im-00 . . . . 11
Hyun, et al. Expires September 14, 2017 [Page 2]
Internet-Draft Registration Interface Information Model March 2017
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-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-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 September 14, 2017 [Page 3]
Internet-Draft Registration Interface Information Model March 2017
o Advanced Inspection/Action: As like the I2NSF information model
for NSF-facing interface [capability-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 security and performance capability of an NSF
instance. Each NSF instance has its own NSF Profile which
describes the type of security service it can provide 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 delivered 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. In
addition, 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 essential
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 can trigger another type of
NSF(s) for more advanced security inspection of the traffic. In
this case, the next NSF is determined by the current NSF's
inspection result and client's policy. However, if there is no
available NSF instance to serve the former NSF's request, we
should create an NSF instance by requesting Developer's Management
System (DMS) through registration interface.
o Creating NSF instances required to enforce security policy rules
from Client: In I2NSF framework, users decide which security
service is necessary in the system. If there is no NSF instances
to enforce the client's security policy, then we should also
create the required instances by requesting DMS via registration
interface.
o Registering NSF instances from 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 September 14, 2017 [Page 4]
Internet-Draft Registration Interface Information Model March 2017
Controller. After creating them, DMS 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 Information Design |
| |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| |Life-Cycle Management| | Registration | |
| | Sub-Model | | Sub-Model | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Registration Interface Information 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 September 14, 2017 [Page 5]
Internet-Draft Registration Interface Information Model March 2017
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-im], the I2NSF capability interface can conduct
controlling and monitoring the new registered NSF instance.
Hyun, et al. Expires September 14, 2017 [Page 6]
Internet-Draft Registration Interface Information Model March 2017
+-+-+-+-+-+-+-+-+
| Registration |
| Message |
+-+-+-+-^-+-+-+-+
|
+-----------------------------+
| |
| |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
| NSF Profile | | NSF Access |
| | | Information |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 3: Registration Mechanism Sub-Model Overview
5.3. NSF Access Information
NSF Access Information contains the followings that are required to
communicate with an NSF: IPv4 address, IPv6 address, port number, and
supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN)
[RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE)
[nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.).
In this document, NSF Access Information is used to identify a
specific NSF instance (i.e. NSF Access Information is the
signature(unique identifier) 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 the security
capabilities which are defined in Section 3 (Overall Analysis of
Security Capability) in [capability-im] for the first five
capabilities and append one additional capability.
Hyun, et al. Expires September 14, 2017 [Page 7]
Internet-Draft Registration Interface Information Model March 2017
+-+-+-+-+-+-+-+-+
| 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-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-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-im]
Hyun, et al. Expires September 14, 2017 [Page 8]
Internet-Draft Registration Interface Information Model March 2017
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-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-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 information basically represents the processing capability of an
NSF, i.e., the amount of traffic it can process for a unit time
period. This information can be used to determine whether the NSF is
Hyun, et al. Expires September 14, 2017 [Page 9]
Internet-Draft Registration Interface Information Model March 2017
in congestion by comparing this with the workload that the NSF
currently undergoes. Moreover, this information can specify an
available amount of each type of resources such as processing power
and memory which are available on the NSF.
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
that are specified in [i2nsf-framework] for the purpose of achieving
secure communication between 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-im] Xia, L., Strassner, J., Basile, C., and D.
Lopez, "Information Model of NSFs
Capabilities",
draft-xibassnez-i2nsf-capability-01 (work
in progress), March 2017.
[i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L.,
Strassner, J., and R. Kumar, "Framework for
Interface to Network Security Functions",
draft-ietf-i2nsf-framework-04 (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-03 (work in
progress), March 2017.
Hyun, et al. Expires September 14, 2017 [Page 10]
Internet-Draft Registration Interface Information Model March 2017
[nsf-triggered-steering] Hyun, S., Jeong, J., Woo, S., Yeo, Y., and
J. Park, "NSF-Triggered Traffic Steering",
draft-hyun-i2nsf-nsf-triggered-steering-02
(work in progress), March 2017.
[nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur,
"Generic Protocol Extension for VXLAN",
draft-ietf-nvo3-vxlan-gpe-03 (work in
progress), October 2016.
Appendix A. Changes from draft-hyun-i2nsf-registration-interface-im-00
The following changes are made from
draft-hyun-i2nsf-registration-interface-im-00:
o Miscellaneous expressions in the whole descriptions are corrected.
o The description of NSF Access Information and Performance
Capability is specified in more detail than the previous version.
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/
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
Hyun, et al. Expires September 14, 2017 [Page 11]
Internet-Draft Registration Interface Information Model March 2017
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
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 September 14, 2017 [Page 12]