idnits 2.17.1 draft-jeong-i2nsf-security-management-automation-01.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 22, 2021) is 1157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-12 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-10 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-04 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-09 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-02 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft P. Lingga 4 Intended status: Informational Sungkyunkwan University 5 Expires: August 26, 2021 J. Park 6 ETRI 7 February 22, 2021 9 An Extension of I2NSF Framework for Security Management Automation in 10 Cloud-Based Security Services 11 draft-jeong-i2nsf-security-management-automation-01 13 Abstract 15 This document describes an extension of the framework of Interface to 16 Network Security Functions (I2NSF) for Security Management Automation 17 (SMA) in cloud-based security services. The security management 18 automation in this document deals with a security polity translation 19 and a feedback-based security service enforcement. To support these 20 two features in SMA, this document specifies an augmented 21 architecture of the I2NSF framework with a new system component and a 22 new interface. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 26, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. I2NSF Framework for Security Management Automation . . . . . 4 61 3.1. Components with I2NSF Framework for Security Management 62 Automation . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Interfaces with SMA-Based I2NSF Framework . . . . . . . . 5 64 4. Inter-Interface Automatic Policy Mapping . . . . . . . . . . 6 65 5. Security Audit System . . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 8.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 72 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 73 Appendix C. Changes from draft-jeong-i2nsf-security-management- 74 automation-00 . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 Interface to Network Security Functions (I2NSF) defines a framework 80 and interfaces for interacting with Network Security Functions (NSFs) 81 [RFC8192][RFC8329]. Note that an NSF is defined as software that 82 provides a set of security-related services, such as (i) detecting 83 unwanted activity, (ii) blocking or mitigating the effect of such 84 unwanted activity in order to fulfill service requirements, and (iii) 85 supporting communication stream integrity and confidentiality 86 [RFC8329]. The NSF can be implemented as a Virtual Network Function 87 (VNF) in a Network Functions Virtualization (NFV) environment 88 [ETSI-NFV][I-D.ietf-i2nsf-applicability]. 90 This document describes an extension of the framework of Interface to 91 Network Security Functions (I2NSF) for Security Management Automation 92 (SMA) in cloud-based security services. The security management 93 automation includes a security polity translation and a feedback- 94 based security service enforcement. This document specifies an 95 augmented architecture of the I2NSF framework for the SMA services 96 with a new system component and a new interface. 98 For reliable management for networked security services, this 99 document proposes a network management and verification facility 100 using a decentralized audit system (e.g., blockchain [Bitcoin]). 101 This audit system can facilitate the non-repudiation of configuration 102 commands and monitoring data generated in the I2NSF framework. 104 Therefore, with the security service automation, this document 105 facilitates the foundation of Intent-Based Networking (IBN) for 106 intelligent security services 107 [I-D.irtf-nmrg-ibn-concepts-definitions]. 109 2. Terminology 111 This document uses the terminology described in [RFC8329] and 112 [I-D.ietf-i2nsf-applicability]. In addition, the following terms are 113 defined below: 115 o Security Management Automation (SMA): It means that a high-level 116 security policy from a user (or administrator) is well-enforced in 117 a target I2NSF system. The high-level security policy can be 118 translated into the corresponding low-level security policy by a 119 security policy translator and dispatched to appropriate NSFs. 120 Through the monitoring of the NSFs, the activity and performace of 121 the NSFs is monitored and analyzed. If needed, the security rules 122 of the low-level security policy are augmented or new security 123 rules are generated and configured to appropriate NSFs. 125 o Security Policy Translation (SPT): It means that a high-level 126 security policy is translated to a low-level security policy that 127 can be understood and configured by an NSF for a specific security 128 service, such as firewall, web filter, deep packet inspection, 129 DDoS-attack mitigation, and anti-virus. 131 o Feedback-Based Security Management (FSM): It means that a security 132 service is evolved by updating a security policy (having security 133 rules) and adding new security rules for detected security attacks 134 by processing and analzing the monitoring data of NSFs. 136 +------------+ 137 | I2NSF User | 138 +------------+ 139 ^ 140 | Consumer-Facing Interface 141 v 142 +-------------------+ Registration +-----------------------+ 143 |Security Controller|<-------------------->|Developer's Mgmt System| 144 +-------------------+ Interface +-----------------------+ 145 ^ ^ 146 | | 147 | | Application Interface +-----------------------+ 148 | +------------------------>| I2NSF Analyzer | 149 | +-----------------------+ 150 | NSF-Facing Interface ^ ^ ^ 151 | | | | 152 | | | | 153 | +------------------------------+ | | 154 | | +-----------------------+ | 155 | | | Monitoring Interface | 156 v v v v 157 +----------------+ +---------------+ +-----------------------+ 158 | NSF-1 |-| NSF-2 |...| NSF-n | 159 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 160 +----------------+ +---------------+ +-----------------------+ 162 Figure 1: I2NSF Framework for Security Management Automation 164 3. I2NSF Framework for Security Management Automation 166 This section summarizes the I2NSF framework as defined in [RFC8329]. 167 As shown in Figure 1, an I2NSF User can use security functions by 168 delivering high-level security policies, which specify security 169 requirements that the I2NSF user wants to enforce, to the Security 170 Controller via the Consumer-Facing Interface (CFI) 171 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 173 3.1. Components with I2NSF Framework for Security Management Automation 175 The following are the system components for the SMA-based I2NSF 176 framework. 178 o I2NSF User: An entity that delivers a high-level security policy 179 to Security Controller. 181 o Security Controller: An entity that controls and manages other 182 system components in the I2NSF framework. It translates a high- 183 level security policy into the corresponding low-level security 184 policy and selects appropriate NSFs to execute the security rules 185 of the low-level security policy. 187 o Developer's Management System (DMS): An entity that provides an 188 image of of a virtualized NSF for a security service to the I2NSF 189 framework, and registers the capability and access information of 190 an NSF with Security Controller. 192 o Network Security Function (NSF): An entity that is a Virtual 193 Network Function (VNF) for a specific network security service 194 such as firewall, web filter, deep packet inspection, DDoS-attack 195 mitigation, and anti-virus. 197 o I2NSF Analyzer: An entity that collects monitoring data from NSFs 198 and analyzes such data for checking the activity and performance 199 of the NSFs using machine learning techniques (e.g., Deep Learning 200 [Deep-Learning]). If there is a suspicious attack activity for 201 the target network or NSF, I2NSF Analyzer delivers a report of the 202 augmentation or generation of secuity rules to Security 203 Controller. 205 For SMA-based security services with Feedback-Based Security 206 Management (FSM), I2NSF Analyzer as a new I2NSF component is required 207 for the legacy I2NSF framework [RFC8329] to collect monitoring data 208 of NSFs and analyzing them. 210 3.2. Interfaces with SMA-Based I2NSF Framework 212 The following are the interfaces for the SMA-based I2NSF framework. 213 Note that the interfaces are modeled with YANG [RFC6020] and security 214 policies are delivered through either RESTCONF [RFC8040] or NETCONF 215 [RFC6241]. 217 o Consumer-Facing Interface: An interface between I2NSF User and 218 Security Controller for the delivery of a high-level security 219 policy [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 221 o NSF-Facing Interface: An interface between Security Controller and 222 an NSF for the delivery of a low-level security policy 223 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 225 o Registration Interface: An interface between a DMS and Security 226 Controller for the registration of an NSF's capability and access 227 information with Secutiy Controller or the query of an NSF for a 228 required low-level security policy 229 [I-D.ietf-i2nsf-registration-interface-dm]. 231 o Monitoring Interface: An interface between an NSF and I2NSF 232 Analyzer for collecting monitoring data from an NSF to check the 233 activity and performance of an NSF for a possible malicious 234 traffic [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 236 o Application Interface: An interface between I2NSF Analyzer and 237 Security Controller for the delivery of a report of the 238 augmentation or generation of secuity rules to Security 239 Controller, which lets Security Controller apply the report for 240 security rules to its security policy management. 242 For SMA-based security services with FSM, Application Interface as a 243 new I2NSF interface is required for the legacy I2NSF framework 244 [RFC8329] to deliver a report of the augmentation or generation of 245 secuity rules to Security Controller on the basis of the analyzed 246 monitoring data of NSFs. 248 4. Inter-Interface Automatic Policy Mapping 250 To facilitate Security Policy Translation (SPT), Security Controller 251 needs to have a security policy translator that performs the 252 translation of a high-level security policy into the corresponding 253 low-level security policy. For the automatic SPT services, the I2NSF 254 framework needs to bridge a high-level YANG data model and a low- 255 level YANG data model in an automatic manner [I-D.ietf-i2nsf-applicab 256 ility][I-D.yang-i2nsf-security-policy-translation]. Note that a 257 high-level YANG data model is for the I2NSF Consumer-Facing Interface 258 [I-D.ietf-i2nsf-consumer-facing-interface-dm], and a low-level YANG 259 data model is for the I2NSF NSF-Facing Interface 260 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 262 Figure 2 shows automatic mapping of high-level and low-level data 263 models. Automatic Data Model Mapper takes a high-level YANG data 264 module for the Consumer-Facing Inteface and a low-level YANG data 265 module for the NSF-Facing Interface. It then constructs a mapping 266 table associating the data attributes (or variables) of the high- 267 level YANG data module with the corresponding data attributes (or 268 variables) of the low-level YANG data module. Also, it generates a 269 set of production rules of the grammar for the construction of an XML 270 file of low-level security policy rules. 272 Figure 3 shows high-to-low security policy translation. A security 273 policy translator is a component of Security Controller. The 274 translator consists of three components such as Policy Data 275 Extractor, Policy Attribute Mapper, and Policy Constructor. 277 High-level YANG Data Module Low-level YANG Data Model 278 | | 279 V V 280 +---------+------------------------------+---------+ 281 | Automatic Data Model Mapper | 282 +------------------------+-------------------------+ 283 | 284 V 285 Data Model Mapping Table 287 Figure 2: Automatic Mapping of High-level and Low-level Data Models 288 +--------------------------------------------------+ 289 | | 290 | I2NSF User | 291 | | 292 +------------------------+-------------------------+ 293 | Consumer-Facing Interface 294 | 295 High-level Security Policy 296 Security | 297 Controller V 298 +------------------------+-------------------------+ 299 | Security Policy | | 300 | Translator V | 301 | +---------------------+----------------------+ | 302 | | | | 303 | | +-------------------------+ | | 304 | | | Policy Data Extractor | | | 305 | | +-------------------------+ | | 306 | | | | 307 | | +-------------------------+ | | 308 | | | Policy Attribute Mapper | | | 309 | | +-------------------------+ | | 310 | | | | 311 | | +-------------------------+ | | 312 | | | Policy Constructor | | | 313 | | +-------------------------+ | | 314 | | | | 315 | +---------------------+----------------------+ | 316 | | | 317 | V | 318 +------------------------+-------------------------+ 319 | NSF-Facing Interface 320 | 321 Low-level Security Policy 322 | 323 V 324 +------------------------+-------------------------+ 325 | | 326 | NSF(s) | 327 | | 328 +--------------------------------------------------+ 330 Figure 3: High-to-Low Security Policy Translation 332 Policy Data Extractor extracts attributes related to a security 333 policy from a high-level security policy XML file that is delivered 334 from an I2NSF User to a Security Controller 335 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 337 Policy Attribute Mapper maps the attributes and their values of a 338 high-level security policy to the corresponding attributes and their 339 values of a low-level security policy. 341 Policy Constructor constructs a low-level security policy XML file 342 that is delivered from the Security Controller to an appropriate NSF 343 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 345 5. Security Audit System 347 The I2NSF framework is weak to both an inside attack and a supply 348 chain attack since it trusts in NSFs provided by Developer's 349 Management System (DMS) and assumes that NSFs work for their security 350 services appropriately. [I-D.ietf-i2nsf-applicability]. 352 To detect the malicious activity of either an insider attacker with 353 its DMS or a supply chain attacker with its compromised DMS, a 354 security audit system is required for the I2NSF framework. For this 355 audit service in the I2NSF framework, a decentralized security audit 356 system (e.g., blockchain [Bitcoin]) is required. This audit system 357 can facilitate the non-repudiation of configuration commands and 358 monitoring data generated in the I2NSF framework. 360 A security audit system has four main objectives such as follows: 362 o To check the existence of a security policy, a management system 363 and its procedures; 365 o To identify and understand the existing vulnerabilities and risks 366 of a supply chain attacker; 368 o To review existing security controls on operational, 369 administrative and managerial issues; 371 o To provide recommendations and corrective actions for further 372 improvement. 374 +-----------------------------+ +----------------+ 375 | I2NSF User | |Developer's Mgmt| 376 | +--------------+ | System | 377 +--------------+--------------+ | +--------+-------+ 378 | Consumer-Facing Interface | | 379 | | | 380 High-level Security Policy | | 381 | | | 382 | | | 383 V | V 384 +--------------+--------------+ | +---------+--------+ 385 | | V | Security | 386 | Security Controller +------------->+----->| Audit | 387 | | ^ | System | 388 +--------------+--------------+ | |(e.g., Blockchain)| 389 | NSF-Facing Interface | +---------+--------+ 390 | | ^ 391 Low-level Security Policy | | 392 | | | 393 V | | 394 +--------------+--------------+ | +--------+-------+ 395 | NSF(s) | | | I2NSF Analyzer | 396 | +--------------+ | | 397 +-----------------------------+ +----------------+ 399 Figure 4: Activity Auditing with Security Audit System 401 Figure 4 shows activity auditing with a security audit system in the 402 I2NSF framework. All the components in the I2NSF framwork report its 403 activities (such as configuration commands and monitoring data) to 404 Security Audit System (e.g., Blockchain) as transactions. The 405 security audit system can analyze the reported activities from the 406 I2NSF components to detect malicious activities such as supply chain 407 attack. 409 In order to determine a minimum set of controls required to reduce 410 the risks from a supply chain attacker, the security audit system 411 should analyze the activities of all the components in the I2NSF 412 framework periodically, evaluate possible risks, and take an action 413 to such risks since vulnerabilities and threats may change in 414 different environments over time. 416 6. Security Considerations 418 The same security considerations for the I2NSF framework [RFC8329] 419 are applicable to this document. 421 7. IANA Considerations 423 This document does not require any IANA actions. 425 8. References 427 8.1. Normative References 429 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 430 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 431 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 432 ietf-i2nsf-consumer-facing-interface-dm-12 (work in 433 progress), September 2020. 435 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 436 Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. 437 Lin, "I2NSF Network Security Function-Facing Interface 438 YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- 439 dm-10 (work in progress), August 2020. 441 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 442 Jeong, J., Lingga, P., Hares, S., Xia, L., and H. 443 Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- 444 ietf-i2nsf-nsf-monitoring-data-model-04 (work in 445 progress), September 2020. 447 [I-D.ietf-i2nsf-registration-interface-dm] 448 Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, 449 "I2NSF Registration Interface YANG Data Model", draft- 450 ietf-i2nsf-registration-interface-dm-09 (work in 451 progress), August 2020. 453 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 454 the Network Configuration Protocol (NETCONF)", RFC 6020, 455 DOI 10.17487/RFC6020, October 2010, 456 . 458 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 459 and A. Bierman, Ed., "Network Configuration Protocol 460 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 461 . 463 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 464 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 465 . 467 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 468 and J. Jeong, "Interface to Network Security Functions 469 (I2NSF): Problem Statement and Use Cases", RFC 8192, 470 DOI 10.17487/RFC8192, July 2017, 471 . 473 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 474 Kumar, "Framework for Interface to Network Security 475 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 476 . 478 8.2. Informative References 480 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 481 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 483 [Deep-Learning] 484 Goodfellow, I., Bengio, Y., and A. Courville, "Deep 485 Learning", Publisher: The MIT Press, 486 URL: https://www.deeplearningbook.org/, November 2016. 488 [ETSI-NFV] 489 "Network Functions Virtualisation (NFV); Architectural 490 Framework", Available: 491 https://www.etsi.org/deliver/etsi_gs/ 492 nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 493 2013. 495 [I-D.ietf-i2nsf-applicability] 496 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 497 "Applicability of Interfaces to Network Security Functions 498 to Network-Based Security Services", draft-ietf-i2nsf- 499 applicability-18 (work in progress), September 2019. 501 [I-D.irtf-nmrg-ibn-concepts-definitions] 502 Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, 503 "Intent-Based Networking - Concepts and Definitions", 504 draft-irtf-nmrg-ibn-concepts-definitions-02 (work in 505 progress), September 2020. 507 [I-D.yang-i2nsf-security-policy-translation] 508 Jeong, J., Yang, J., Chung, C., and J. Kim, "Security 509 Policy Translation in Interface to Network Security 510 Functions", draft-yang-i2nsf-security-policy- 511 translation-07 (work in progress), November 2020. 513 Appendix A. Acknowledgments 515 This work was supported in part by Institute of Information & 516 Communications Technology Planning & Evaluation (IITP) grant funded 517 by the Korea Ministry of Science and ICT (MSIT) (2020-0-00395, 518 Standard Development of Blockchain based Network Management 519 Automation Technology). This work was supported by the IITP grant 520 funded by the Korea MSIT (R-20160222-002755, Cloud based Security 521 Intelligence Technology Development for the Customized Security 522 Service Provisioning). 524 Appendix B. Contributors 526 This document is made by the group effort of I2NSF working group. 527 Many people actively contributed to this document, such as Linda 528 Dunbar, Yoav Nir, and Qin Wu. The authors sincerely appreciate their 529 contributions. 531 The following are co-authors of this document: 533 Yunchul Choi 534 Electronics and Telecommunications Research Institute 535 218 Gajeong-Ro, Yuseong-Gu 536 Daejeon, 34129 537 Republic of Korea 539 EMail: pjs@etri.re.kr 541 Younghan Kim 542 School of Electronic Engineering 543 Soongsil University 544 369, Sangdo-ro, Dongjak-gu 545 Seoul 06978 546 Republic of Korea 548 EMail: younghak@ssu.ac.kr 550 Appendix C. Changes from draft-jeong-i2nsf-security-management- 551 automation-00 553 The following changes are made from draft-jeong-i2nsf-security- 554 management-automation-00: 556 o In Section 5, four main objectives of a security audit system are 557 explained. 559 o In Section 5, the architecture and auditing procedure of a 560 security audit system are described along with Figure 4. 562 Authors' Addresses 564 Jaehoon (Paul) Jeong 565 Department of Computer Science and Engineering 566 Sungkyunkwan University 567 2066 Seobu-Ro, Jangan-Gu 568 Suwon, Gyeonggi-Do 16419 569 Republic of Korea 571 Phone: +82 31 299 4957 572 Fax: +82 31 290 7996 573 EMail: pauljeong@skku.edu 574 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 576 Patrick Lingga 577 Department of Electronic, Electrical and Computer Engineering 578 Sungkyunkwan University 579 2066 Seobu-Ro, Jangan-Gu 580 Suwon, Gyeonggi-Do 16419 581 Republic of Korea 583 Phone: +82 31 299 4957 584 EMail: patricklink@skku.edu 586 Jung-Soo Park 587 Electronics and Telecommunications Research Institute 588 218 Gajeong-Ro, Yuseong-Gu 589 Daejeon 305-700 590 Republic of Korea 592 Phone: +82 42 860 6514 593 EMail: pjs@etri.re.kr