Network Working Group H. Yang Internet-Draft Y. Kim Intended status: Informational Soongsil University Expires: May 10, 2019 J. Jeong J. Kim Sungkyunkwan University November 6, 2018 I2NSF on the NFV Reference Architecture draft-yang-i2nsf-nfv-architecture-04 Abstract This document describes the integration of Interface to Network Security Functions (I2NSF) Framework into the Network Functions Virtualization (NFV) Reference Model. This document explains how the components and interfaces in the I2NSF Framework can be placed in the NFV reference architecture, and also explains the procedures of the lifecycle management of Network Security Functions (NSFs) according to a user's security policy specification in the I2NSF framework on the NFV system. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 10, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of Yang, et al. Expires May 10, 2019 [Page 1] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. I2NSF framework onto the NFV Reference Model . . . . . . . . 3 3.1. Network Security Function . . . . . . . . . . . . . . . . 4 3.2. Security Controller . . . . . . . . . . . . . . . . . . . 5 3.3. Developer's Management System . . . . . . . . . . . . . . 5 3.4. I2NSF Interfaces . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Consumer-Facing Interface . . . . . . . . . . . . . . 5 3.4.2. NSF-Facing Interface . . . . . . . . . . . . . . . . 6 3.4.3. Registration Interface . . . . . . . . . . . . . . . 6 3.4.4. Interface for NSF Management . . . . . . . . . . . . 6 4. Initial Configuration Procedure in NFV Architecture . . . . . 6 5. Multi-site Consideration . . . . . . . . . . . . . . . . . . 10 6. Use Case of SFC-Enabled I2NSF Framework . . . . . . . . . . . 10 6.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 11 6.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 11 6.3. Developer's Management System in SFC-Enabled I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-03 . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The goal of Interface to Network Security Functions (I2NSF) is to define a set of software interfaces and components for controlling and monitoring aspects of physical and virtual Network Security Functions (NSFs), with which a user can specify high-level security policy. To achieve this goal, the I2NSF framework not only considers physical infrastructure, but also considers a Network Functions Virtualization (NFV) environment since an NSF may be provided by virtualized infrastructure as a Virtual Network Function (VNF). Especially, the I2NSF applicability document [I2NSF-Applicability] describes the applicability of I2NSF to network-based security services in an NFV environment. Although it explains how I2NSF framework in an NFV environment for security services, it does not explain the procedures of the lifecycle management of NSFs in detail. Yang, et al. Expires May 10, 2019 [Page 2] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 Thus, this document explains such procedures in the I2NSF framework on the NSF system along with the places of the components of the I2NSF framework in the NFV system. 2. Terminology 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]. This document uses the terminology described in [RFC8329] [I2NSF-Terminology], [I2NSF-Applicability], [ETSI-GS-NFV-003], [Registration-Interface], [ETSI-GS-IFA-008], and [NSF-Triggered-Steering]. 3. I2NSF framework onto the NFV Reference Model The European Telecommunications Standards Institute (ETSI) defined the components for the basic NFV architecture including the NFV Infrastructure (NFVI), VNF Manager (VNFM), Virtualization Infrastructure Manager (VIM), and NFV Orchestrator (NFVO) [ETSI-GS-NFV-003]. NFVI provides the virtual resources, such as a Virtual Machine (VM) and a Virtual Network, which are used to create, update, and delete VNFs running applications. VNFs are implemented through software virtualization techniques running over the NFVI. Virtualized Infrastructure Manager (VIM) has a function for controlling and managing the NFVI compute, storage and network nodes, within one operator's infrastructure sub-domain. It also collects and forwards performance measurement data and events. VNFM manages the VNF lifecycle. When a VNF is created, the VNFM manages the VNF instance in the lifecycle, and the VNFM performs several actions such as software update/modification, monitoring data collection (e.g., fault event in the VNF, and instance termination). In [RFC8329], the I2NSF framework has four components (i.e., I2NSF User, Security Controller, NSF, and Developer's Management System (DMS)) along with three main interfaces (i.e., Consumer-Facing Interface, NSF-Facing Interface, and Registration Interface). To adopt these components to the NFV reference architecture, each component should be classified based on functionality. According to component functionality, it would correspond to NFV reference architecture components as Figure 1. Yang, et al. Expires May 10, 2019 [Page 3] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 +--------------------+ +-------------------------------------------+ | ---------------- | | OSS/BSS | | | NFV | | +---------+---------------------------------+ | | Orchestrator +-+| | (b) | +--+-----------+ || +---------|---------------------------------+ | | || | +------+------+ +-----------------+ | | | || | | Security | | Developer's Mgmt| | | | || | | Controller +--(a)-+ System(EM) | | | | || | +------+------+ +-----------------+ | | +--+---------+ || | | (c) | | | | || | +---+----+ +---+----+ +---+----+ +-(d)-+ VNFM | || | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | || | | | | | | | | | +--+---------+ || | +--------+ +--------+ +--------+ | | | || +-------------------------------------------+ | | || +-------------------------------------------+ | | || | NFV Infrastructure (NFVI) | | | || | +---------+ +---------+ +---------+ | | | || | | Virtual | | Virtual | | Virtual | | | | || | | Compute | | Storage | | Network | | | | || | +---------+ +---------+ +---------+ | | +--+-----+ || | +---------------------------------------+ | | | | || | | Virtualization Layer | +-----+ VIM(s) +-------+| | +---------------------------------------+ | | | | | | +---------------------------------------+ | | +--------+ | | | +---------+ +---------+ +---------+ | | | | | | | Compute | | Storage | | Network | | | | | | | | Hardware| | Hardware| | Hardware| | | | | | | +---------+ +---------+ +---------+ | | | NFV Management | | | Hardware Resources | | | and Orchestration | | +---------------------------------------+ | | (MANO) | +-------------------------------------------+ +--------------------+ (a) = Registration Interface, (b) = Consumer-Facing Interface (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface Figure 1: I2NSF Framework on NFV Reference Architecture 3.1. Network Security Function A Network Security Function (NSF) is one of the security service functions. In the ETSI reference architecture, a VNF is a network function which provides a specific service. Therefore, an NSF corresponds to a VNF in the NFV reference architecture. Yang, et al. Expires May 10, 2019 [Page 4] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 3.2. Security Controller According to an I2NSF framework, Security Controller has a role to translate an I2NSF User's high-level security policy into a low-level security policy for an NSF. It also collects an NSF's capability information from DMS. Based on the features of the I2NSF framework, Security Controller receives a high-level security policy from an I2NSF user over Consumer-Facing Interface, and after the security policy translation, it can forward the corresponding low-level security policy to an appropriate NSF over NSF-Facing Interface. In the NFV reference architecture, Element Management (EM) has a role to manage its service function (e.g., firewall, Deep Packet Inspection, DDoS-attack mitigator) and collaborate with the VNF Manager for the lifecycle management (e.g., the instantiation and de- instantiation) of a VNF corresponding to the required security function. This lifecycle management requires the exchange of information regarding the NFVI resources associated with the VNF. EM performs typical management functionality for its own VNFs. This document proposes that Security Controller can be implemented as an EM that can give a security policy to an NSF, and control the NSF. Note that from the perspective of implementation, it can also be configured as an independent component in the NFV system. 3.3. Developer's Management System According to the definition of I2NSF Registration Interface, DMS registers its NSF, which can be provided by a specific vendor, into Security Controller along with the capability of the NSF. In the NFV reference architecture, when a general VNFM creates and manages an NSF, DMS can be used as an EM to manage the specific function of an NSF. 3.4. I2NSF Interfaces 3.4.1. Consumer-Facing Interface The Consumer-Facing Interface is an interface for communication between I2NSF User and Security Controller. It is used to enable different I2NSF Users in a given I2NSF system to define, manage, and monitor security policies for specific flows within an administrative domain. In the NFV reference architecture, Operational Support Systems (OSS) and Business Support Systems (BSS) are used to manipulate their applications (e.g., security services) with their policies and rules. Yang, et al. Expires May 10, 2019 [Page 5] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 OSS and BSS support a user-domain-specific system for users, such as security enforcement, billing, order, and metering. Although an interface is not defined between an I2NSF User and a VNF in the NFV reference architecture, Consumer-Facing interface can be deployed for the interaction between an I2NSF user and an VNF, as illustrated in Figure 1. 3.4.2. NSF-Facing Interface The NSF-Facing Interface is an interface for communication between Security Controller and NSF. It is used to specify and monitor flow- based security policies enforced by one or more NSFs. In the NFV reference architecture, Software Architecture (SWA)-4 Interface is defined. The interface SWA-4 is used by the EM to communicate with a VNF. This management interface is used for the runtime management of the VNF according to Fulfillment, Assurance, Billing, and FCAPS (Fault, Configuration, Accounting, Performance, Security) network management models and frameworks. Therefore, NSF-Facing Interface corresponds to the SWA-4 interface. 3.4.3. Registration Interface Registration Interface is used to register an NSF from DMS System to Security Controller. An NSF's capabilities can either be pre- configured or retrieved dynamically through the I2NSF Registration Interface. Also, it is to search an appropriate NSF with the required capability that can execute the requested security service. In the NFV reference architecture, an interface is not defined between EM, the registraion-interface can be deployed like a Figure 1. 3.4.4. Interface for NSF Management In this model, DMS needs to communicate with VNFM to create an NSF dynamically. This interface is not defined in the I2NSF framework, since it is out of the scope of the I2NSF. However, ETSI defined an interface "Ve-Vnfm" between EM and VNFM [ETSI-GS-IFA-008]. Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to communicate with VNFM. 4. Initial Configuration Procedure in NFV Architecture The security service procedure in the proposed architecture is as follows. When an I2NSF User requests a security service to Security Controller with a high-level policy, Security Controller translates the high-level policy into the corresponding low-level policy. Then, Yang, et al. Expires May 10, 2019 [Page 6] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 it searches the NSF list with capabilities for the requested security service according to the low-level policy. In this step, there are two use cases. As shown in Figure 2, the first case is the case that when an NSF with the required capability is in active state. The second case is the case that when an NSF with required capability is in inactive state. When the NSF is in active state, Security Controller generates a low-level policy and forwards it to the NSF to set the low-level policy up. On the other hand, when the NSF is in inactive state, Security Controller sends an NSF initiation request message to the DMS via Registration Interface and DMS analyzes the message according to the vendor's configuration [Registration-Interface]. After that, DMS forwards the NSF initiation request message to VNFM via Ve-Vnfm Interface [ETSI-GS-IFA-008]. After the initiation of the NSF, VNFM sends back an NSF initiation response message to Security Controller with an NSF's access information (e.g., IP address, transport-layer protocol, port number, and the NSF's name). With the received NSF access information, Security Controller generates a low- level policy and forwards it to the NSF to set the security policy up. Yang, et al. Expires May 10, 2019 [Page 7] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 I2NSF Security Developer's VNFM NSF User Controller Mgmt System | | | | | | | | | | |--High-level-->| | | | |policy Request | | | | | | | | | | | | | | | | | | | | Translation: | | | | Data Conversion | | | | | | | | | | | | | case 1: NSFs available(activated) : Go to Policy Generation | | | | | | |++case 2: NSFs available(de-activated)+++++++++++++| | | | | | | | |-NSF initiation->| | | | | Request(Reg) |-------NSF initiation----->| | | | Request(Ve-Vnfm) | | | | | NSF | | | | Creation | | | | | | | |<------NSF initiation------| | |<-NSF initiation-| Response(Ve-Vnfm) | | | Response(Reg) | | | | | | | | |++case 2: NSFs available(de-activated)+++++++++++++| | | | | | | | Translation: | | | | Policy Generation | | | | | | | | | | | | | | |---------Low-level policy Request----------->| | |<--------Low-level policy Response-----------| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Figure 2: Procedure of I2NSF Framework on NFV for the Case of 'NSF Available' Yang, et al. Expires May 10, 2019 [Page 8] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 I2NSF Security Developer's VNFM NSF User Controller Mgmt System | | | | | |--High-level-->| | | | |policy Request | | | | | | | | | | Translation: | | | | Data Conversion | | | | | | | | | Profile Entry | | | | not matched | | | | | | | | | |Capability Query->| | | | | | | | |++case 1: Capability not Searched+++++++++++++++++++| | | | | | | | |<--No-NSF-found---| | | | | Reply | | | |<--High-level--| | | | policy Response(failure) | | | | | | | | |++case 1: Capability not Searched+++++++++++++++++++| | | | | | | | +case 2: Capability not Searched++++++++++++++++++++++ | | | | | | | | | |--NSF Creation--->| | | | | | Request(Reg) |-------NSF Creation------->| | | | | Request(Ve-Vnfm) | | | | | | NSF | | | | | Creation | | | | | | | | | |<------NSF Creation--------| | | |<--NSF Creation---| Response(Ve-Vnfm) | | | | Response(Reg) | (with NSF info) | | | | | | | | | Translation: | | | | | Policy Generation | | | | | | | | | | | |----------Low-level policy Request----------->| | | |<---------Low-level policy Response-----------| | | | | | | |<--High-level--| | | | policy Response(Success) | | | | | | | | | Yang, et al. Expires May 10, 2019 [Page 9] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 Figure 3: Procedure of I2NSF Framework on NFV for the Case of 'No NSF Existing' However, when the NSF does not exist, The procedure is as follows. As shown in Figure 3, when an NSF does not exist, Security Controller sends a Capability Query message to DMS to search for an NSF with the requested capability. When DMS does not find such an NSF, the procedure is terminated after sending Security Controller a failure notification message, which means that it does not have any NSF with the requested capability. On the other hand, When there exists an NSF corresponding to the requested capability, DMS sends an NSF creation request message to the VNFM. After the creation of the NSF as a VNF, it is registered into DMS. DMS registers the NSF with capability and access information into Security Controller via Registration Interface. The remaining procedure is the same as the previous case. 5. Multi-site Consideration The previous section described how the I2NSF framework is plugged into the NFV architecture in a single site. From the perspective of NFV, when security functions are deployed, it might be deployed at a single site or multiple sites. Basically, the I2NSF framework only considers that a single DMS could manage all its NSFs. From the perspective of ETSI reference architecture, when NSFs are deployed at a multi-site environment, a DMS could manage all of the NSFs in such an environment in the same way of a single site. Alternatively, multiple DMSs could manage the NSFs together. The I2NSF framework only considers a single Security Controller that manages all the NSFs in its management domain. This implies that one Security Controller as an EM should be located at the domain. However, from the perspective of ETSI reference architecture, an EM usually is located at each site and controls a VNF which belongs to that site. The I2NSF framework should consider the placement of Security Controller in a multi-site environment, since there is a conflict between the I2NSF framework and the ETSI NFV reference architecture regarding the placement of Security Controller as an EM. 6. Use Case of SFC-Enabled I2NSF Framework A service service in the I2NSF applicability in [I2NSF-Applicability]> requires a forwarding mechanism for cloud- based security services. Especially, a Service Function Chaining (SFC)-enabled I2NSF Architecture in [NSF-Triggered-Steering] shows a use case that uses SFC as a forwarding mechanism. In addition, it Yang, et al. Expires May 10, 2019 [Page 10] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 specifies SFC components for I2NSF-based sercurity services (e.g., Classifier and Service Function Forwarder (SFF)) and defines the required functionality of the components. Therefore, the following subsections explain the details of each component and consider how it corresponds to the NFV reference architecture. 6.1. SFC Policy Manager SFC Policy Manager is a part of Security Controller. It is responsible for interpreting a high-level security policy into a low- level security policy, which is given by I2NSF User. It also handles the delivery of the interpreted policy to SFC Classifier(s) for security function chaining. Moreover, it also generates the information of the security function chaining for the requested security service to SFF(s). In the NFV reference architecture, Management and Orchestration (MANO) performs similar functions as the SFC Policy Manager. More specifically, the NFV Orchestrator (NFVO) performs on-boarding of a new Network Service (NS), VNF-FG (Forwarding Graph), and VNF Packages. In addition, it manages NS lifecycle (including instantiation, scale-out/in, performance measurement, event correlation, and termination). Therefore, SFC Policy Manager corresponds to NFVO. In addition, if SFC Policy Manager is a part of Security Controller, this function should be separated from Security Controller, and then be placed in MANO. 6.2. SFC Catalog Manager SFC Catalog Manager is a part of Security Controller. It is responsible for maintaining the information of every available SF instance such as IP address, transport-layer protocol, port number, service name, and load status. Moreover, it should respond to the queries for available NSF instances from SFC Policy Manager in order to help the generation of a forwarding table entry relevant to a given SFP. It also requests DMS to dynamically instantiate additional SF instances in order to avoid service congestion in an NSF or the elimination of an idle NSF instance to avoid resource waste. In the NFV reference architecture, SFC Catalog Manager corresponds to an EM since the information related to VNF capability is managed by the EM. Moreover, its functions are similar to Security Controller's as explained before. Yang, et al. Expires May 10, 2019 [Page 11] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 6.3. Developer's Management System in SFC-Enabled I2NSF Framework In the SFC-enabled document, the functions of DMS are extended. For the request message from SFC Catalog Manager, DMS creates additional NSF instances for load balancing and eliminates some of idle NSF instances. As mentioned above, if DMS manages the NSF's lifecycle indirectly with VNFM, it play a role of a VNFM. VNF lifecycle management includes the instantiation, creation, provisioning, scaling, monitoring, and termination of a VM as a VNF instance. Therefore, DMS corresponds to a specific VNFM. However, for the scaling performance at a network service level, the role of DMS can be a part of MANO. 7. Security Considerations This document specifies the implementation of the I2NSF framework in the NFV system, so the same security considerations for the I2NSF framework [RFC8329] can be applied to this document. This document shares all the security issues of NFV that are specified in the "Potential Areas of Concern" section of [ETSI-GS-NFV-SEC-001]. 8. Informative References [ETSI-GS-IFA-008] ETSI GS NFV-IFA 008 V2.1.1, "Network Functions Virtualisation (NFV);Management and Orchestration;Ve-Vnfm reference point - Interface andInformation Model Specification", October 2016. [ETSI-GS-NFV-003] ETSI GS NFV 002 V1.1.1, "Network Functions Virtualization (NFV); Architectural Framework", October 2013. [ETSI-GS-NFV-SEC-001] ETSI GS NFV-SEC 001 V1.1.1, "Network Functions Virtualisation (NFV); NFV Security; Problem Statement", October 2014. [I2NSF-Applicability] Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, "Applicability of Interfaces to Network Security Functions to Network-Based Security Services", draft-ietf-i2nsf- applicability-07 (work in progress), October 2018. Yang, et al. Expires May 10, 2019 [Page 12] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 [I2NSF-Terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-06 (work in progress), July 2018. [NSF-Triggered-Steering] Hyun, S., Jeong, J., Park, J., and S. Hares, "Service Function Chaining-Enabled I2NSF Architecture", draft-hyun- i2nsf-nsf-triggered-steering-06 (work in progress), July 2018. [Registration-Interface] Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", draft-ietf-i2nsf- registration-interface-dm-01 (work in progress), November 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, February 2018. Yang, et al. Expires May 10, 2019 [Page 13] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-03 The following changes have been made from draft-yang-i2nsf-nfv- architecture-03: o In Figure 1, the figure of the I2NSF Framework on NFV Reference Architecture is revised to be synchronized with I2NSF on NFV in [I2NSF-Applicability]. o In Figure 2 and Figure 3, the procedures of I2NSF framework on NFV are added to both the case of "NSF Available", and the case of "No NSF Existing". o Overall editorial errors have been corrected. Appendix B. Acknowledgements This work was supported in part by the Ministry of Science and ICT (MSIT) under the ITRC (Information Technology Research Center) support program (IITP-2018-2017-0-01633) supervised by the Institute for Information & communications Technology Promotion (IITP). Authors' Addresses Hyunsik Yang School of Electronic Engineering Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul, Seoul 06978 Republic of Korea Phone: +82 10 9005 7439 EMail: yangun@dcn.ssu.ac.kr Younghan Kim School of Electronic Engineering Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul, Seoul 06978 Republic of Korea Phone: +82 10 2691 0904 EMail: younghak@ssu.ac.kr Yang, et al. Expires May 10, 2019 [Page 14] Internet-Draft I2NSF on the NFV Reference Architecture November 2018 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 Jinyong Tim Kim Department of Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 10 8273 0930 EMail: timkim@skku.edu Yang, et al. Expires May 10, 2019 [Page 15]