idnits 2.17.1 draft-ietf-i2nsf-problem-and-use-cases-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2, 2017) is 2639 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.zarny-i2nsf-data-center-use-cases' is defined on line 1148, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track D. Lopez 5 Expires: August 6, 2017 Telefonica I+D 6 M. Zarny 7 vArmour 8 C. Jacquenet 9 France Telecom 10 R. Kumar 11 Juniper Networks 12 J. Jeong 13 Sungkyunkwan University 14 February 2, 2017 16 I2NSF Problem Statement and Use cases 17 draft-ietf-i2nsf-problem-and-use-cases-09 19 Abstract 21 This document describes the problem statement for Interface to 22 Network Security Functions (I2NSF) as well as some companion use 23 cases. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 6, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Challenges Facing Security Service Providers . . . . . . 5 63 3.1.1. Diverse Types of Security Functions . . . . . . . . . 5 64 3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 6 65 3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 7 66 3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 7 67 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 7 68 3.1.6. Lack of Characterization of NSFs and Capability 69 Exchange . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1.7. Lack of Mechanism for NSFs to Utilize External 71 Profiles . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.8. Lack of Mechanisms to Accept External Alerts to 73 Trigger Automatic Rule and Configuration Changes . . 8 74 3.1.9. Lack of Mechanism for Dynamic Key Distribution to 75 NSFs . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 10 77 3.2.1. NSFs from Heterogeneous Administrative Domains . . . 10 78 3.2.2. Today's Control Requests are Vendor Specific . . . . 11 79 3.2.3. Difficulty to Monitor the Execution of Desired 80 Policies . . . . . . . . . . . . . . . . . . . . . . 12 81 3.3. Difficulty to Validate Policies across Multiple Domains . 13 82 3.4. Software-Defined Networks . . . . . . . . . . . . . . . . 13 83 3.5. Lack of Standard Interface to Inject Feedback to NSF . . 14 84 3.6. Lack of Standard Interface for Capability Negotiation . . 14 85 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 15 87 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 16 88 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 19 89 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 19 90 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 20 91 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 20 92 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 21 93 4.4. Preventing Distributed DoS, Malware and Botnet attacks . 21 94 4.5. Regulatory and Compliance Security Policies . . . . . . . 22 95 5. Management Considerations . . . . . . . . . . . . . . . . . . 22 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 99 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 23 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 101 11. Informative References . . . . . . . . . . . . . . . . . . . 24 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 104 1. Introduction 106 This document describes the problem statement for Interface to 107 Network Security Functions (I2NSF) as well as some I2NSF use cases. 108 A summary of the state of the art in the industry and IETF which is 109 relevant to I2NSF work is documented in 110 [I-D.hares-i2nsf-gap-analysis]. 112 The growing challenges and complexity in maintaining a secure 113 infrastructure, complying with regulatory requirements, and 114 controlling costs are enticing enterprises into consuming network 115 security functions hosted by service providers. The hosted security 116 service is especially attractive to small and medium size enterprises 117 who suffer from a lack of security experts to continuously monitor 118 networks, acquire new skills and propose immediate mitigations to 119 ever increasing sets of security attacks. 121 According to [Gartner-2013], the demand for hosted (or cloud-based) 122 security services is growing. Small and medium-sized businesses 123 (SMBs) are increasingly adopting cloud-based security services to 124 replace on-premises security tools, while larger enterprises are 125 deploying a mix of traditional and cloud-based security services. 127 To meet the demand, more and more service providers are providing 128 hosted security solutions to deliver cost-effective managed security 129 services to enterprise customers. The hosted security services are 130 primarily targeted at enterprises (especially small/medium ones), but 131 could also be provided to any kind of mass-market customer. As a 132 result, the Network Security Functions (NSFs) are provided and 133 consumed in a large variety of environments. Users of NSFs may 134 consume network security services hosted by one or more providers, 135 which may be their own enterprise, service providers, or a 136 combination of both. This document also briefly describes the 137 following use cases summarized by 138 [I-D.pastor-i2nsf-merged-use-cases]: 140 o [I-D.pastor-i2nsf-access-usecases] (I2NSF-Access), 142 o [I-D.zarny-i2nsf-data-center-use-cases](I2NSF-DC), and 144 o [I-D.qi-i2nsf-access-network-usecase] (I2NSF-Mobile). 146 2. Terminology 148 AAA: Authentication, Authorization, and Account [RFC2904]. 150 ACL: Access Control List 152 B2B: Business-to-Business 154 Bespoke: Something made to fit a particular person, client or 155 company. 157 Bespoke security management: Security management which is made to 158 fit a particular customer. 160 DC: Data Center 162 FW: Firewall 164 IDS: Intrusion Detection System 166 IPS: Intrusion Protection System 168 I2NSF: Interface to Network Security Functions 170 NSF: Network Security Function. An NSF is a function that used to 171 ensure integrity, confidentiality, or availability of network 172 communication, to detect unwanted network activity, or to block or 173 at least mitigate the effects of unwanted activity. 175 Flow-based NSF: An NSF which inspects network flows according to a 176 security policy. Flow-based security also means that packets are 177 inspected in the order they are received, and without altering 178 packets due to the inspection process (e.g., MAC rewrites, TTL 179 decrement action, or NAT inspection or changes). 181 SDN: Software Defined Networking 183 Virtual NSF: An NSF which is deployed as a distributed virtual 184 resource. 186 VPN: Virtual Private Networks 188 3. Problem Space 190 The following sub-section describes the problems and challenges 191 facing customers and security service providers when some or all of 192 the security functions are no longer physically hosted by the 193 customer's adminstrative domain. 195 Security service providers can be internal or external to the 196 company. For example, an internal IT Security group within a large 197 enterprise could act as a security service provider for the 198 enterprise. In contrast, an enterprise could outsource all security 199 services to an external security service provider. In this document, 200 the security service provider function, whether it is internal or 201 external, will be denoted as "service provider". 203 The "Customer-Provider" relationship may be between any two parties. 204 The parties can be in different firms or different domains of the 205 same firm. Contractual agreements may be required in such contexts 206 to formally document the customer's security requirements and the 207 provider's guarantees to fulfill those requirements. Such agreements 208 may detail protection levels, escalation procedures, alarms 209 reporting, etc. There is currently no standard mechanism to capture 210 those requirements. 212 A service provider may be a customer of another service provider. 214 It is the objective of the I2NSF work to address these problems and 215 challenges. 217 3.1. Challenges Facing Security Service Providers 219 3.1.1. Diverse Types of Security Functions 221 There are many types of NSFs. NSFs by different vendors can have 222 different features and have different interfaces. NSFs can be 223 deployed in multiple locations in a given network, and perhaps have 224 different roles. 226 Below are a few examples of security functions and locations or 227 contexts in which they are often deployed: 229 External Intrusion and Attack Protection: Examples of this function 230 are firewall/ACL authentication, IPS, IDS, and endpoint 231 protection. 233 Security Functions in a Demilitarized Zone (DMZ): Examples of this 234 function are firewall/ACLs, IDS/IPS, one or all of AAA services 235 NAT, forwarding proxies, and application filtering. These 236 functions may be physically on-premise in a server provider's 237 network at the DMZ spots or located in a "virtual" DMZ. 239 Centralized or Distributed security functions: The security 240 functions could be deployed in a centralized fashion for ease of 241 management and network design or in a distributed fashion for 242 scaled requirement. No matter how a security function is deployed 243 and provisioned, it is desirable to have same interface to 244 provision security policies; otherwise it makes the job of 245 security administration more complex, requiring knowledge of 246 firewall and network design. 248 Internal Security Analysis and Reporting: Examples of this function 249 are security logs, event correlation, and forensic analysis. 251 Internal Data and Content Protection: Examples of this function are 252 encryption, authorization, and public/private key management for 253 internal database. 255 Security gateways and VPN concentrators: Examples of these 256 functions are; IP-sec gateways, Secure VPN concentrators that 257 handle bridging secure VPNs, and Secure VPN controllers for data 258 flows. 260 Given the diversity of security functions, the contexts in which 261 these functions can be deployed, and the constant evolution of these 262 functions, standardizing all aspects of security functions is 263 challenging, and most probably not feasible. Fortunately, it is not 264 necessary to standardize all aspects. For example, from an I2NSF 265 perspective, there is no need to standardize how every firewall's 266 filtering is created or applied. Some features in a specific 267 vendor's filtering may be unique to the vendor's product so it is not 268 necessary to standardize these features. 270 What is needed is a standardized interface to control and monitor the 271 rule sets that NSFs use to treat packets traversing through these 272 NSFs. Thus standardizing interfaces will provide an impetus for 273 standardizing established security functions. 275 I2NSF may specify some filters, but these filters will be linked to 276 specific common functionality developed by I2NSF in information 277 models or data models. 279 3.1.2. Diverse Interfaces to Control and Monitor NSFs 281 To provide effective and competitive solutions and services, Security 282 Service Providers may need to utilize multiple security functions 283 from various vendors to enforce the security policies desired by 284 their customers. 286 Since no widely accepted industry standard security interface to 287 security NSFs exists today, management of NSFs (device and policy 288 provisioning, monitoring, etc.) tends to be bespoke security 289 management offered by product vendors. As a result, automation of 290 such services, if it exists at all, is also bespoke. Thus, even in 291 the traditional way of deploying security features, there is a gap to 292 coordinate among implementations from distinct vendors. This is the 293 main reason why mono-vendor security functions are often deployed and 294 enabled in a particular network segment. 296 A challenge for monitoring is that an NSF cannot monitor what it 297 cannot view. Therefore, enabling a security function (e.g., firewall 298 [I-D.ietf-opsawg-firewalls]) does not mean that a network is 299 protected. As such, it is necessary to have a mechanism to monitor 300 and provide execution status of NSFs to security and compliance 301 management tools. There exist various network security monitoring 302 vendor-specific interfaces for forensics and troubleshooting. 304 3.1.3. More Distributed NSFs and vNSFs 306 The security functions which are invoked to enforce a security policy 307 can be located in different equipment and network locations. 309 The European Telecommunications Standards Institute (ETSI) Network 310 Functions Virtualization (NFV) initiative [ETSI-NFV] creates new 311 management challenges for security policies to be enforced by 312 distributed virtual network security functions (vNSF). 314 A vNSF has higher risk of changes to the state of network connection, 315 interfaces, or traffic as their hosting Virtual Machines (VMs) are 316 being created, moved, or decommissioned. 318 3.1.4. More Demand to Control NSFs Dynamically 320 In the advent of Software-Defined Networking (SDN)(see 321 [I-D.jeong-i2nsf-sdn-security-services]), more clients, applications 322 or application controllers need to dynamically update their security 323 policies that are enforced by NSFs. The Security Service Providers 324 have to dynamically update their decision-making process (e.g., in 325 terms of NSF resource allocation and invocation) upon receiving 326 security-related requests from their clients. 328 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 330 Service providers may need several operational units to control and 331 monitor the NSFs, especially when NSFs become distributed and 332 virtualized. 334 3.1.6. Lack of Characterization of NSFs and Capability Exchange 336 To offer effective security services, service providers need to 337 activate various security functions in NSFs or vNSFs manufactured by 338 multiple vendors. Even within one product category (e.g., firewall), 339 security functions provided by different vendors can have different 340 features and capabilities. For example, filters that can be designed 341 and activated by a firewall may or may not support IPv6 depending on 342 the firewall technology. 344 The service provider's management system (or controller) needs a way 345 to retrieve the capabilities of service functions by different 346 vendors so that it could build an effective security solution. These 347 service function capabilities can be documented in a static manner 348 (e.g., a file) or via an interface which accesses a repository of 349 security function capabilities which the NSF vendors dynamically 350 update. 352 A dynamic capability registration is useful for automation because 353 security functions may be subject to software and hardware updates. 354 These updates may have implications on the policies enforced by the 355 NSFs. 357 Today, there is no standard method for vendors to describe the 358 capabilities of their security functions. Without a common technical 359 framework to describe the capabilities of security functions, service 360 providers cannot automate the process of selecting NSFs by different 361 vendors to accommodate customer's security requirements. 363 The I2NSF work will focus on developing a standard method to describe 364 capabilities of security functions. 366 3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles 368 Many security functions depend on signature files or profiles to 369 perform (e.g., IPS/IDS signatures, DDos Open Threat Signaling (DOTS) 370 filters). Different policies might need different signatures or 371 profiles. Today, the construction and use of black list databases 372 can be a win-win strategy for all parties involved. There might be 373 Open Source-provided signature/profiles (e.g., by Snort, Suricata, 374 Bro and Kisnet) in the future. 376 There is a need to have a standard envelope (i.e., the format) to 377 allow NSFs to use external profiles. 379 3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger 380 Automatic Rule and Configuration Changes 382 NSF can ask the I2NSF security controller to alter specific rules 383 and/or configurations. For example, a Distributed Denial of Service 384 (DDoS) alert could trigger a change to the routing system to send 385 traffic to a traffic scrubbing service to mitigate the DDoS. 387 The DDoS protection has the following two parts: a) the configuration 388 of signaling of open threats and b) DDoS mitigation. DOTS controller 389 manages the signaling part of DDoS. I2NSF controller(s) would manage 390 the changing to the affected policies (e.g., forwarding and routing, 391 filtering, etc.). By monitoring the network alerts from DDoS, I2NSF 392 can feed an alerts analytics engine that could recognize attacks so 393 the I2NSF can enforce the appropriate policies. 395 DDoS mitigation is enhanced if the provider's network security 396 controller can monitor, analyze, and investigate the abnormal events 397 and provide information to the client or change the network 398 configuration automatically. 400 [I-D.zhou-i2nsf-capability-interface-monitoring] provides details on 401 how monitoring aspects of the flow-based Network Security Functions 402 (NSFs) can use the I2NSF interfaces to receive traffic reports and 403 enforce appropriate policies. 405 3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs 407 There is a need for a controller to distribute various keys to 408 distributed NSFs. To distribute various keys, the keys must be 409 created and managed. While there are many key management methods and 410 cryptographic suites (e.g., encryption algorithms, key derivation 411 functions, etc.) and other functions, there is a lack of a standard 412 interface to provision and manage security associations. 414 The keys may be used for message authentication and integrity in 415 order to protect data flows. In addition, keys may be used to secure 416 the protocol and messages in the core routing infrastructure (see 417 [RFC4948]) 419 As of now there is not much focus on an abstraction for keying 420 information that describes the interface between protocols, 421 operators, and automated key management. 423 An example of a solution may provide some insight into why the lack 424 of a mechanism is a problem. If a device had an abstract key table 425 maintained by security services, a device could use these keys for 426 routing and seurity devices. 428 What does this take? 430 Conceptually, there must be an interface defined for routing/ 431 signaling protocols to make requests for automated key management 432 when it is being used, and to notify the protocols when keys become 433 available in the key table. One potential use of such an interface 434 is to manage IPSec security associations on SDN networks. 436 An abstract key service will work under the following conditions: 438 1. I2NSF needs to design the key table abstraction, the interface 439 between key management protocols and routing/other protocols, and 440 possibly security protocols at other layers. 442 2. For each routing/other protocol, I2NSF needs to define the 443 mapping between how the protocol represents key material and the 444 protocol-independent key table abstraction. If protocols share 445 common mechanisms for authentication (e.g., TCP Authentication 446 Option), then the same mapping may be reused. 448 3. Automated Key management must support both symmetric keys and 449 group keys via the service provided by items 1 and 2. 451 3.2. Challenges Facing Customers 453 When customers invoke hosted security services, their security 454 policies may be enforced by a collection of security functions hosted 455 in different domains. Customers may not have the security skills to 456 express sufficiently precise requirements or security policies. 457 Usually, these customers express the expectations of their security 458 requirements or the intent of their security policies. These 459 expectations can be considered customer-level security expectations. 460 Customers may also desire to express guidelines for security 461 management. Examples of such guidelines include: 463 o Which critical communications are to be preserved during critical 464 events (DOTS working group is standardizing), 466 o Which hosts are to continue service even during severe security 467 attacks (DOTS working group is standardizing), 469 o Reporting of attacks to CERT (MILE working group is 470 standardizing), and 472 o Managing network connectivity of systems out of compliance (SACM 473 working gorup is standardizing). 475 3.2.1. NSFs from Heterogeneous Administrative Domains 477 Many medium and large enterprises have deployed various on-premises 478 security functions which they want to continue to deploy. These 479 enterprises want to combine local security functions with remote 480 hosted security functions to achieve more efficient and immediate 481 counter-measures to both Internet-originated attacks and enterprise 482 network-originated attacks. 484 Some enterprises may only need the hosted security services for their 485 remote branch offices where minimal security infrastructures/ 486 capabilities exist. The security solution will consist of deploying 487 NSFs on customer networks and on service provider networks. 489 3.2.2. Today's Control Requests are Vendor Specific 491 Customers may utilize NSFs provided by multiple service providers. 492 Customers need to express their security requirements, guidelines, 493 and expectations to the service providers. In turn, the service 494 providers must translate this customer information into customer 495 security policies and associated configuration tasks for the set of 496 security functions in their network. Without a standard technical 497 standard interface that provides a clear technical characterization, 498 the service provider faces many challenges: 500 No standard technical characterization and/or APIs: Even for the 501 most common security services there is no standard technical 502 characterization or APIs. Most security services are accessible 503 only through disparate, proprietary interfaces (e.g., portals or 504 APIs) in whatever format vendors choose to offer. The service 505 provider must process the customer's input with these widely 506 varying interfaces. 508 No standard interface: Without standard interfaces it is complex 509 for customers to update security policies or integrate the 510 security functions in their enterprise with the security services 511 provided by the security service providers. This complexity is 512 induced by the diversity of the configuration models, policy 513 models, and supported management interfaces. Without a standard 514 interface, new innovative security products find a large barrier 515 to entry into the market. 517 Managing by scripts de-jour: The current practices rely upon the 518 use of scripts that generate other scripts which automatically run 519 to upload or download configuration changes, log information and 520 other things. These scripts have to be adjusted each time an 521 implementation from a different vendor technology is enabled on a 522 provider side. 524 Lack of immediate feedback: Customers may also require a mechanism 525 to easily update/modify their security requirements with immediate 526 effect in the underlying involved NSFs. 528 Lack of explicit invocation request: While security agreements are 529 in place, security functions may be solicited without requiring an 530 explicit invocation means. Nevertheless, some explicit invocation 531 means may be required to interact with a service function. 533 To see how standard interfaces could help achieve faster 534 implementation time cycles, let us consider a customer who would like 535 to dynamically allow an encrypted flow with specific port, src/dst 536 addresses or protocol type through the firewall/IPS to enable an 537 encrypted video conferencing call only during the time of the call. 538 With no commonly accepted interface in place, as shown in figure 1, 539 the customer would have to learn about the particular provider's 540 firewall/IPS interface and send the request in the provider's 541 required format. 543 +------------+ 544 | security | 545 | management | 546 | system | 547 +----||------+ 548 || proprietary 549 || or I2NSF standard 550 Video: || 551 Port 10 +--------+ 552 --------| FW/IPS |------------- 553 Encrypted +--------+ 554 Video Flow 556 Figure 1: Example of non-standard vs. standard interface 558 In contrast, as figure 1 shows, if a firewall/IPS interface standard 559 exists the customer would be able to send the request to a security 560 management system without having to do the extensive preliminary 561 legwork. A standard interface also helps service providers since 562 they could now offer the same firewall/IPS interface to represent 563 firewall/IPS services for utilizing products from many vendors. The 564 result is that the service provider has now abstracted the firewall/ 565 IPS services. The standard interface also helps the firewall/IPS 566 vendors to focus on their core security functions or extended 567 features rather than the standard building blocks of a management 568 interface. 570 3.2.3. Difficulty to Monitor the Execution of Desired Policies 572 How a policy is translated into technology-specific actions is hidden 573 from the customers. However, customers still need ways to monitor 574 the delivered security service that results from the execution of 575 their desired security requirements, guidelines and expectations. 577 Today, there is no standard way for customers to get security service 578 assurance of their specified security policies properly enforced by 579 the security functions in the provider domain. The customer also 580 lacks the ability to perform "what-if" scenarios to assess the 581 efficiency of the delivered security service. 583 It is the objective of the I2NSF work to provide a standard way to 584 get security service assurance of a customers specific security 585 policies which provides enough information for customers to perform 586 "what-if" scenarios to assess efficiency of delivered security 587 services. 589 3.3. Difficulty to Validate Policies across Multiple Domains 591 One key aspect of a hosted security service with security functions 592 located at different premises is the ability to express, monitor and 593 verify security policies that combine several distributed security 594 functions. It is crucial to an effective service to be able to take 595 these actions via a standard interface. This standard interface 596 becomes more crucial to the hosted security service when NSFs are 597 instantiated in Virtual Machines which are sometimes widely 598 distributed in the network and sometimes are combined together in one 599 device to perform a set of tasks for delivering a service. 601 Without standard interfaces and security policy data models, the 602 enforcement of a customer-driven security policy remains challenging 603 because of the inherent complexity created by combining the 604 invocation of several vendor-specific security functions into a 605 multi-vendor, heterogeneous environment. Each vendor-specific 606 function may require specific configuration procedures and 607 operational tasks. 609 Ensuring the consistent enforcement of the policies at various 610 domains is also challenging. Standard data models are likely to 611 contribute to solving that issue. 613 3.4. Software-Defined Networks 615 Software-Defined Networks have changed the landscape of data center 616 designs by introducing overlay networks deployed over ToR switches 617 that connect to a hypervisor. SDN techniques are meant to improve 618 the flexibility of workload management without affecting applications 619 and how they work. Workload can thus be easily and seamlessly 620 managed across private and public clouds. SDN techniques optimize 621 resource usage and are now being deployed in various networking 622 environments, besides cloud infrastructures. Yet, such SDN-inferred 623 agility may raise specific security issues. For example a security 624 admin must make sure that a security policy can be enforced 625 regardless of the location of the workload, thereby raising concerns 626 about the ability of SDN computation logic to send security policy- 627 provisioning information to the participating NSFs. A second example 628 is workload migration to a public cloud infrastructure which may 629 raise raise additional security requirements during the migration. 631 3.5. Lack of Standard Interface to Inject Feedback to NSF 633 Today, many security functions in the NSF, such as IPS, IDS, DDoS 634 mitigation and Antivirus, depend heavily on the associated profiles. 635 NSF devices can perform more effective protection if these NSF 636 devices have the up-to-date profiles for these functions. Today 637 there is no standard interface to provide these security profiles for 638 the NSF. 640 As more sophisticated threats arise, enterprises, vendors, and 641 service providers have to rely on each other to achieve optimal 642 protection. Cyber Threat Alliance (CTA, 643 http://cyberthreatalliance.org/) is one of those initiatives that aim 644 at combining efforts conducted by multiple organizations. 646 The standrd interface to provide security profiles to the NSF should 647 interwork with the formats which exchange security profiles between 648 organizations. 650 One objective of the I2NSF work is to provide this type of standard 651 interface to security profiles. 653 3.6. Lack of Standard Interface for Capability Negotiation 655 There could be situations when the selected NSFs cannot perform the 656 policies requested by the Security Controller, due to resource 657 constraints. The customer and security service provider should 658 negotiate the appropriate resource constraints before the security 659 service begins. However, unexpected events may happen causing the 660 NSF to exhaust those negotiated resources. At this point, the NSF 661 should inform the security controller that the alloted resources have 662 been exhausted. To support the automatic control in the SDN-era, it 663 is necessary to have a set of messages for proper notification (and a 664 response to that notification) between the Security Controller and 665 the NSFs. 667 4. Use Cases 669 Standard interfaces for monitoring and controlling the behavior of 670 NSFs are essential building blocks for Security Service Providers and 671 enterprises to automate the use of different NSFs from multiple 672 vendors by their security management entities. I2NSF may be invoked 673 by any (authorized) client. Examples of authorized clients are 674 upstream applications (controllers), orchestration systems, and 675 security portals. 677 4.1. Basic Framework 679 Users request security services through specific clients (e.g., a 680 customer application, the Network Service Providers (NSP) Business 681 Support Systems/Operations Support Systems (BSS/OSS) or management 682 platform) and the appropriate NSP network entity will invoke the 683 (v)NSFs according to the user service request. This network entity 684 is denoted as the security controller in this document. The 685 interaction between the entities discussed above (client, security 686 controller, NSF) is shown in Figure 2: 688 +----------+ 689 +-------+ | | +-------+ 690 | | Interface 1 |Security | Interface 2 | NSF(s)| 691 |Client <--------------> <------------------> | 692 | | |Controller| | | 693 +-------+ | | +-------+ 694 +----------+ 696 Figure 2: Interaction between Entities 698 Interface 1 is used for receiving security requirements from a client 699 and translating them into commands that NSFs can understand and 700 execute. The security controller also passes back NSF security 701 reports (e.g., statistics) to the client which the security 702 controller has gathered from NSFs. Interface 2 is used for 703 interacting with NSFs according to commands (e.g., enact/revoke a 704 security policy, or distribute a policy), and collecting status 705 information about NSFs. 707 Client devices or applications can require the security controller to 708 add, delete or update rules in the security service function for 709 their specific traffic. 711 When users want to get the executing status of a security service, 712 they can request NSF status from the client. The security controller 713 will collect NSF information through Interface 2, consolidate it, and 714 give feedback to the client through Interface 1. This interface can 715 be used to collect not only individual service information, but also 716 aggregated data suitable for tasks like infrastructure security 717 assessment. 719 Customers may require validating NSF availability, provenance, and 720 execution. This validation process, especially relevant to vNSFs, 721 includes at least: 723 Integrity of the NSF: by ensuring that the NSF is not compromised; 724 Isolation: by ensuring the execution of the NSF is self-contained 725 for privacy requirements in multi-tenancy scenarios. 727 Provenance of NSF: Customers may need to be provided with strict 728 guarantees about the origin of the NSF, its status (e.g., 729 available, idle, down, and others), and feedback mechanisms so 730 that a customer may be able to check that a given NSF or set of 731 NSFs properly conform to the the customer's requirements and 732 subsequent configuration tasks. 734 In order to achieve this, the security controller may collect 735 security measurements and share them with an independent and trusted 736 third party (via Interface 1) in order to allow for attestation of 737 NSF functions using the third party added information. 739 This implies that there may be the following two types of clients 740 using interface 1: the end-user and and the trusted independent third 741 party. The I2NSF work may determine that interface 1 creates two 742 sub-interfaces to support these two types of clients. 744 4.2. Access Networks 746 This scenario describes use cases for users (e.g., residential user, 747 enterprise user, mobile user, and management system) that request and 748 manage security services hosted in the NSP infrastructure. Given 749 that NSP customers are essentially users of their access networks, 750 the scenario is essentially associated with their characteristics as 751 well as with the use of vNSFs. Figure 3 shows how these virtual 752 access nodes for different types of customers connect connect through 753 virtual access nodes an NSF. 755 The virtual customer premise equipment (vCPE) described in use case 756 #7 in [NFVUC] requires a model of access virtualization that includes 757 mobile and residential access networks where the operator may offload 758 security services from the customer local environment (e.g., device 759 or terminal) to its own infrastructure. 761 These use cases define the interaction between the operator and the 762 vNSFs through automated interfaces, typically by means of Business- 763 to-Business (B2B) communications. 765 Customer + Access + PoP/Datacenter 766 | | +--------+ 767 | ,-----+--. |Network | 768 | ,' | `-|Operator| 769 +-------------+ | /+----+ | |Mgmt Sys| 770 | Residential |-+------/-+vCPE+----+ +--------+ 771 +-------------+ | / +----+ | \ | : 772 | / | \ | | 773 +----------+ | ; +----+ | +----+ | 774 |Enterprise|---+---+----+ vPE+--+----+ NSF| | 775 +----------+ | : +----+ | +----+ | 776 | : | / | 777 +--------+ | : +----+ | / ; 778 | Mobile |-+-----\--+vEPC+----+ / 779 +--------+ | \ +----+ | ,-' 780 | `--. | _.-' 781 | `----+----'' 782 + + 784 vCPE - virtual customer premise equipment 785 vPE - virtual provider equipment 786 vEPC - virtual evolved packet core 787 (mobile-core network) 789 Figure 3: NSF and actors 791 Different access clients may have different service requests: 793 Residential: service requests for parental control, content 794 management, and threat management. 796 Parental control requests may include identity based filters for 797 web content or usage. Content management may include identifying 798 and blocking malicious activities from web contents, mail, or 799 files downloaded. Threat management may include identifying and 800 blocking botnets or malware. 802 Enterprise: service requests for enterprise flow security policies 803 and managed security services 805 Flow security policies include access to (or isolation from) data 806 from various internal groups, access to (or isolation from) 807 various web sites or social media applications, and encryption on 808 data transferred between corporates sites (main office, enterprise 809 branch offices, and remote campuses). Managed security services 810 may include detection and mitigation of external and internal 811 threats. External threats can include application or phishing 812 attacks, malware, botnet, DDoS, and others. Internal threats (aka 813 lateral threats) can include detecting programs moving from one 814 enterprise site to another without permission. 816 Service Provider: Service requests for policies that protect 817 service provider networks against various threats (including DDoS, 818 botnets and malware). Such policies are meant to securely and 819 reliably deliver contents (e.g., data, voice, and video) to 820 various customers, including residential, mobile and corporate 821 customers. These security policies are also enforced to guarantee 822 isolation between multiple tenants, regardless of the nature of 823 the corresponding connectivity services. 825 Mobile: service requests from interfaces which monitor and ensure 826 user quality of experience, content management, parental controls, 827 and external threat management. 829 Content management for the mobile device includes identifying and 830 blocking malicious activities from web contents, mail, files 831 uploaded/downloaded. Threat management for infrastructure 832 includes detecting and removing malicious programs such as botnet, 833 malware, and other programs that create distributed DoS attacks). 835 Some access customers may not care about which NSFs are utilized to 836 achieve the services they requested. In this case, provider network 837 orchestration systems can internally select the NSFs (or vNSFs) to 838 enforce the security policies requested by the clients. Other access 839 customers, especially some enterprise customers, may want to get 840 their dedicated NSFs (most likely vNSFs) for direct control purposes. 841 In this case, here are the steps to associate vNSFs to specific 842 customers: 844 vNSF Deployment: The deployment process consists in instantiating 845 an NSF on a Virtualization Infrastructure (NFVI), within the NSP 846 administrative domain(s) or with other external domain(s). This 847 is a required step before a customer can subscribe to a security 848 service supported in the vNSF. 850 vNSF Customer Provisioning: Once a vNSF is deployed, any customer 851 can subscribe to it. The provisioning lifecycle includes the 852 following: 854 * Customer enrollment and cancellation of the subscription to a 855 vNSF; 857 * Configuration of the vNSF, based on specific configurations, or 858 derived from common security policies defined by the NSP. 860 * Retrieval of the vNSF functionalities, extracted from a 861 manifest or a descriptor. The NSP management systems can 862 demand this information to offer detailed information through 863 the commercial channels to the customer. 865 4.3. Cloud Data Center Scenario 867 In a data center, network security mechanisms such as firewalls may 868 need to be dynamically added or removed for a number of reasons. 869 These changes may be explicitly requested by the user, or triggered 870 by a pre-agreed upon demand level in the Service Level Agreement 871 (SLA) between the user and the provider of the service. For example, 872 the service provider may be required to add more firewall capacity 873 within a set of timeframes whenever the bandwidth utilization hits a 874 certain threshold for a specified period. This capacity expansion 875 could result in adding new instances of firewalls on existing 876 machines or provisioning a completely new firewall instance in a 877 different machine. 879 The on-demand, dynamic nature of security service delivery 880 essentially encourages that the network security "devices" be in 881 software or virtual form factors, rather than in a physical appliance 882 form. This requirement is a provider-side concern. Users of the 883 firewall service are agnostic (as they should) as to whether or not 884 the firewall service is run on a VM or any other form factor. 885 Indeed, they may not even be aware that their traffic traverses 886 firewalls. 888 Furthermore, new firewall instances need to be placed in the "right 889 zone" (domain). The issue applies not only to multi-tenant 890 environments where getting the tenant in the right domain is of 891 paramount importance, but also in environments owned and operated by 892 a single organization with its own service segregation policies. For 893 example, an enterprise may mandate that firewalls serving Internet 894 traffic and B2B traffic be separated. Another example is that IPS/ 895 IDS services for investment banking and non-banking traffic may be 896 separated for regulatory reasons. 898 4.3.1. On-Demand Virtual Firewall Deployment 900 A service provider-operated cloud data center could serve tens of 901 thousands of clients. Clients' compute servers are typically hosted 902 on VMs, which could be deployed across different server racks located 903 in different parts of the data center. It is often not technically 904 and/or financially feasible to deploy dedicated physical firewalls to 905 suit each client's security policy requirements, which can be 906 numerous. What is needed is the ability to dynamically deploy 907 virtual firewalls for each client's set of servers based on 908 established security policies and underlying network topologies. 909 Figure 4 shows an example toipology of virtual firewalls within a 910 data center. 912 ---+-----------------------------+----- 913 | | 914 +---+ +-+-+ 915 |vFW| |vFW| 916 +---+ +-+-+ 917 | Client #1 | Client #2 918 ---+-------+--- ---+-------+--- 919 +-+-+ +-+-+ +-+-+ +-+-+ 920 |vM | |vM | |vM | |vM | 921 +---+ +---+ +---+ +---+ 923 Figure 4: NSF in Data Centers 925 4.3.2. Firewall Policy Deployment Automation 927 Firewall rule setting is often a time consuming, complex and error- 928 prone process even within a single organization/enterprise framework. 929 It becomes far more complex in provider-owned cloud networks that 930 serve myriads of customers. 932 Firewall rules today are highly tied with ports and addresses that 933 identify traffic. This makes it very difficult for clients of cloud 934 data centers to construct rules for their own traffic as the clients 935 only see the virtual networks and the virtual addresses. The 936 customer-visible virtual networks and addresses may be different from 937 the actual packets traversing the FWs. 939 Even though most vendors support similar firewall features, the 940 actual rule configuration keywords are different from vendors to 941 vendors, making it difficult for automation. Automation works best 942 when it can leverage a common set of standards that will work across 943 NSFs by multiple vendors. Without automation, it is virtually 944 impossible for clients to dynamically specify their desired rules for 945 their traffic. 947 Another feature that aids automation of firewalls that must be 948 covered in automation is dynamic key management. 950 4.3.3. Client-Specific Security Policy in Cloud VPNs 952 Clients of service provider-operated cloud data centers not only need 953 to secure Virtual Private Networks (VPNs), but also virtual security 954 functions that apply the clients' security policies. The security 955 policies may govern communication within the clients' own virtual 956 networks as well as communication with external networks. For 957 example, VPN service providers may need to provide firewall and other 958 security services to their VPN clients. Today, it is generally not 959 possible for clients to dynamically view (let alone change) what, 960 where and how security policies are implemented on their provider- 961 operated clouds. Indeed, no standards-based framework exists to 962 allow clients to retrieve/manage security policies in a consistent 963 manner across different providers. 965 As described above, the dynamic key management is critical for the 966 securing the VPN and the distribution of policies. 968 4.3.4. Internal Network Monitoring 970 There are many types of internal traffic monitors that may be managed 971 by a security controller. This includes a new class of services 972 referred to as Data Loss Prevention (DLP), or Reputation Protection 973 Services (RPS). Depending on the class of event, alerts may go to 974 internal administrators, or external services. 976 4.4. Preventing Distributed DoS, Malware and Botnet attacks 978 In the Internet where everything is connected, preventing unwanted 979 traffic that may cause a Denial of Service (DoS) attack or a 980 distributed DoS (DDoS) attack has become a challenge. Similarly, a 981 network could be exposed to malware attacks and become an attack 982 vector to jeopardize the operation of other networks, by means of 983 remote commands for example. Many networks such as Internet of 984 Things (IoT) networks, Information-Centric Networks (ICN), Content 985 Delivery Networks (CDN), Voice over IP packet networks (VoIP), and 986 Voice over LTE (VoLTE) are also exposed to such attacks. 988 In order for organizations to better secure their networks against 989 these kind of attacks, the I2NSF framework should provide a client- 990 side interface that is use case-independent and technology-agnostic. 991 Technology-agnostic is to is defined to be generic, technology 992 independent, and able to support multiple protocols and data models. 993 For example, such an I2NSF interface could be used to provision 994 security policy configuration information that looks for specific 995 malware signatures. Similarly, botnet attacks could be easily 996 prevented by provisioing security policies using the I2NSF client- 997 side interface that prevent access to botnet command and control 998 servers. 1000 4.5. Regulatory and Compliance Security Policies 1002 Organizations are not only supposed to protect their networks against 1003 attacks, but they should also adhere to various industry regulations: 1004 any organization that falls under a specific regulation like Payment 1005 Card Industry (PCI)-Data Security Standard (DSS) [PCI-DSS] for the 1006 payment industry or Health Insurance Portability and Accountability 1007 Act [HIPAA] for the healthcare industry must be able to isolate 1008 various kinds of traffic. They must also show records of their 1009 security policies whenever audited. 1011 The I2NSF client-side interface could be used to provision regulatory 1012 and compliance-related security policies. The security controller 1013 would keep track of when and where a specific policy is applied and 1014 if there is any policy violation; this information can be provided in 1015 the event of an audit as a proof that traffic is isolated between 1016 specific endpoints, in full compliance with the required regulations. 1018 5. Management Considerations 1020 Management of NSFs usually include the following: 1022 o Lifecycle managment and resource management of NSFs, 1024 o Device configuration, such as address configuration, device 1025 internal attributes configuration, etc., 1027 o Signaling of events, notifications and changes, and 1029 o Policy rule provisioning. 1031 I2NSF will only focus on the policy provisioning part of NSF 1032 management. 1034 6. IANA Considerations 1036 No IANA considerations exist for this document. 1038 7. Security Considerations 1040 Having a secure access to control and monitor NSFs is crucial for 1041 hosted security services. An I2NSF security controller raises new 1042 security threats. It needs to be resilient to attacks and quickly 1043 recover from attacks. Therefore, proper secure communication 1044 channels have to be carefully specified for carrying controlling and 1045 monitoring traffic between the NSFs and their management entity (or 1046 entities). 1048 In addition, the Flow security policies specified by customers can 1049 conflict with providers' internal security policies which may allow 1050 unauthorized traffic or unauthorized changes to flow polices (e.g. 1051 customers changing flow policies that do not belong to them). 1052 Therefore, it is crucial to have proper AAA [RFC2904] to authorize 1053 access to the network and access to the I2NSF management stream. 1055 8. Contributors 1057 I2NSF is a group effort. The following people actively contributed 1058 to the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra 1059 Majee (F5), Ed Lopez (Fortinet), and Robert Moskowitz (Huawei). 1061 9. Contributing Authors 1063 I2NSF has had a number of contributing authors. The following are 1064 contributing authors: 1066 o Linda Dunbar (Huawei), 1068 o Antonio Pastur (Telefonica I+D), 1070 o Mohamed Boucadair (France Telecom), 1072 o Michael Georgiades (Prime Tel), 1074 o Minpeng Qi (China Mobile), 1076 o Shaibal Chakrabarty (US Ignite), 1078 o Nic Leymann (Deutsche Telekom), 1080 o Anil Lohiya (Juniper), 1082 o David Qi (Bloomberg), 1084 o Hyoungshick Kim (Sungkyunkwan University), 1086 o Jung-Soo Park (ETRI), 1088 o Tae-Jin Ahn (Korea Telecom), and 1090 o Se-Hui Lee (Korea Telecom). 1092 10. Acknowledgements 1094 This document was supported by Institute for Information and 1095 communications Technology Promotion (IITP) funded by the Korea 1096 government (MSIP) [R0166-15-1041, Standard Development of Network 1097 Security based SDN]. 1099 11. Informative References 1101 [ETSI-NFV] 1102 ETSI GS NFV 002 V1.1.1, , "Network Functions 1103 Virtualisation (NFV); Architectural Framework", October 1104 2013. 1106 [Gartner-2013] 1107 Messmer, E., "Gartner: Cloud-based security as a service 1108 set to take off", October 2013. 1110 [HIPAA] US Congress, , "HEALTH INSURANCE PORTABILITY AND 1111 ACCOUNTABILITY ACT OF 1996 (Public Law 104-191)", August 1112 1996, . 1114 [I-D.hares-i2nsf-gap-analysis] 1115 Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee, 1116 "Analysis of Existing work for I2NSF", draft-hares-i2nsf- 1117 gap-analysis-01 (work in progress), December 2015. 1119 [I-D.ietf-opsawg-firewalls] 1120 Baker, F. and P. Hoffman, "On Firewalls in Internet 1121 Security", draft-ietf-opsawg-firewalls-01 (work in 1122 progress), October 2012. 1124 [I-D.jeong-i2nsf-sdn-security-services] 1125 Jeong, J., Kim, H., Jung-Soo, P., Ahn, T., and s. 1126 sehuilee@kt.com, "Software-Defined Networking Based 1127 Security Services using Interface to Network Security 1128 Functions", draft-jeong-i2nsf-sdn-security-services-05 1129 (work in progress), July 2016. 1131 [I-D.pastor-i2nsf-access-usecases] 1132 Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM 1133 Interface to Virtualized Security Services", draft-pastor- 1134 i2nsf-access-usecases-00 (work in progress), October 2014. 1136 [I-D.pastor-i2nsf-merged-use-cases] 1137 Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M., 1138 Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M. 1139 Georgiades, "Use Cases and Requirements for an Interface 1140 to Network Security Functions", draft-pastor-i2nsf-merged- 1141 use-cases-00 (work in progress), June 2015. 1143 [I-D.qi-i2nsf-access-network-usecase] 1144 Wang, K. and X. Zhuang, "Integrated Security with Access 1145 Network Use Case", draft-qi-i2nsf-access-network- 1146 usecase-02 (work in progress), March 2015. 1148 [I-D.zarny-i2nsf-data-center-use-cases] 1149 Zarny, M., Leymann, N., and L. Dunbar, "I2NSF Data Center 1150 Use Cases", draft-zarny-i2nsf-data-center-use-cases-00 1151 (work in progress), October 2014. 1153 [I-D.zhou-i2nsf-capability-interface-monitoring] 1154 Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The 1155 Capability Interface for Monitoring Network Security 1156 Functions (NSF) in I2NSF", draft-zhou-i2nsf-capability- 1157 interface-monitoring-00 (work in progress), October 2015. 1159 [NFVUC] ETSI GS NFV 001 V1.1.1, , "ETSI NFV Group Specification, 1160 Network Functions Virtualization (NFV) Use Cases", October 1161 2013. 1163 [PCI-DSS] PCI Security Council, , "Payment Card Industry (PCI) Data 1164 Security Standard Requirements and Security Assessment 1165 Procedures (version 3.2)", April 2016, 1166 . 1168 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1169 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1170 D. Spence, "AAA Authorization Framework", RFC 2904, 1171 DOI 10.17487/RFC2904, August 2000, 1172 . 1174 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1175 IAB workshop on Unwanted Traffic March 9-10, 2006", 1176 RFC 4948, DOI 10.17487/RFC4948, August 2007, 1177 . 1179 Authors' Addresses 1180 Susan Hares 1181 Huawei 1182 7453 Hickory Hill 1183 Saline, MI 48176 1184 USA 1186 Phone: +1-734-604-0332 1187 Email: shares@ndzh.com 1189 Diego R. Lopez 1190 Telefonica I+D 1191 Don Ramon de la Cruz, 82 1192 Madrid 28006 1193 Spain 1195 Email: diego.r.lopez@telefonica.com 1197 Myo Zarny 1198 vArmour 1199 800 El Camino Real, Suite 3000 1200 Mountain View, CA 94040 1201 USA 1203 Email: myo@varmour.com 1205 Christian Jacquenet 1206 France Telecom 1207 Rennes, 35000 1208 France 1210 Email: Christian.jacquenet@orange.com 1212 Rakesh Kumar 1213 Juniper Networks 1214 1133 Innovation Way 1215 Sunnyvale, CA 94089 1216 USA 1218 Email: rkkumar@juniper.net 1219 Jaehoon Paul Jeong 1220 Department of Software 1221 Sungkyunkwan University 1222 2066 Seobu-Ro, Jangan-Gu 1223 Suwon, Gyeonggi-Do 16419 1224 Republic of Korea 1226 Phone: +82 31 299 4957 1227 Fax: +82 31 290 7996 1228 Email: pauljeong@skku.edu 1229 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php