idnits 2.17.1 draft-hyun-i2nsf-registration-interface-im-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 7348' is mentioned on line 296, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hyun 3 Internet-Draft J. Jeong 4 Intended status: Standards Track S. Woo 5 Expires: January 4, 2018 Y. Yeo 6 Sungkyunkwan University 7 J. Park 8 ETRI 9 July 3, 2017 11 I2NSF Registration Interface Information Model 12 draft-hyun-i2nsf-registration-interface-im-02 14 Abstract 16 This document describes an information model for Interface to Network 17 Security Functions (I2NSF) Registration Interface between Security 18 Controller and Developer's Management System. The information model 19 is required for Network Security Function (NSF) instance registration 20 and dynamic life cycle management of NSF instances. This document 21 explains the procedures over I2NSF registration interface for these 22 functionalities. It also describes the detailed information which 23 should be exchanged via I2NSF registration interface. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on January 4, 2018. 48 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Life-Cycle Managment Mechanism . . . . . . . . . . . . . . 6 70 5.2. Registration Mechanism . . . . . . . . . . . . . . . . . . 6 71 5.3. NSF Access Information . . . . . . . . . . . . . . . . . . 7 72 5.4. NSF Profile (Capabilities of an NSF instance) . . . . . . 7 73 5.4.1. Packet Content-Matching Capability . . . . . . . . . . 8 74 5.4.2. Content-Matching Capability . . . . . . . . . . . . . 8 75 5.4.3. Context-Matching Capability . . . . . . . . . . . . . 8 76 5.4.4. Attack-Mitigation Capability . . . . . . . . . . . . . 9 77 5.4.5. Action Capability . . . . . . . . . . . . . . . . . . 9 78 5.4.6. Performance Capability . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Appendix A. Changes from 85 draft-hyun-i2nsf-registration-interface-im-01 . . . . 12 87 1. Introduction 89 A number of virtual network security function instances typically 90 exist in Interface to Network Security Functions (I2NSF) framework 91 [i2nsf-framework]. In this environment, it is important to 92 dynamically manage a Network Security Function (NSF) instance pool 93 for efficient resource utilization. For instance, if a certain NSF 94 instance is receiving an excessive amount of traffic beyond its 95 capacity, an additional instance for the same security function 96 should be created. If an NSF instance is idle for a period of time, 97 it would be better to destroy it to avoid resource waste. In 98 addition, the existing information model for NSF-facing interface 99 requires an NSF to trigger another type of NSF for further inspection 100 [nsf-capability-im]. In this case, if there is no available instance 101 for the latter NSF, a new NSF should be instantiated. Similarly, in 102 order to enforce a security policy from the client, all the required 103 NSF instances should be created. 105 This document describes the procedures which should be performed on 106 the registration interface between security controller and 107 developer's management system to dynamically manage a pool of NSF 108 instances. It further describes the detailed information which 109 should be exchanged between security controller and developer's 110 management system. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Terminology 120 This document uses the terminology described in 121 [i2nsf-terminology][nsf-capability-im][i2nsf-framework] 122 [nsf-triggered-steering]. 124 o Network Security Function (NSF): A function that is responsible 125 for specific treatment of received packets. A Network Security 126 Function can act at various layers of a protocol stack (e.g., at 127 the network layer or other OSI layers). Sample Network Security 128 Service Functions are as follows: Firewall, Intrusion Prevention/ 129 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 130 Application Visibility and Control (AVC), network virus and 131 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 132 Denial of Service (DDoS) mitigation and TLS proxy 133 [nsf-triggered-steering]. 135 o Advanced Inspection/Action: As like the I2NSF information model 136 for NSF-facing interface [nsf-capability-im], Advanced Inspection/ 137 Action means that a security function calls another security 138 function for further inspection based on its own inspection result 139 [nsf-triggered-steering]. 141 o Network Security Function Profile (NSF Profile): NSF Profile 142 specifies the security and performance capability of an NSF 143 instance. Each NSF instance has its own NSF Profile which 144 describes the type of security service it can provide and its 145 resource capacity. [nsf-triggered-steering]. 147 4. Objectives 149 o Efficient network resource utilization through dynamic 150 instantiation of NSFs and load balancing: In I2NSF framework, it 151 is sometimes possible that a specific NSF experiences heavy 152 traffic loads. For example, under DDoS attacks, a huge volume of 153 traffic would be delivered to DoS attack mitigator function to 154 cope with the attacks. In this case, we should allocate a large 155 portion of resources to that DoS attack mitigator function by 156 creating a sufficient number of DoS mitigator instances. In 157 addition, after the attack is terminated, we should eliminate some 158 of the instances no longer used. In this way, we can achieve 159 efficient resource utilization. For this purpose, it is essential 160 to define an information model of registration interface for 161 dynamic instantiation/elimination of NSF instances. 163 o Creating an NSF instance to serve another NSF's inspection 164 request: In I2NSF framework, an NSF can trigger another type of 165 NSF(s) for more advanced security inspection of the traffic. In 166 this case, the next NSF is determined by the current NSF's 167 inspection result and client's policy. However, if there is no 168 available NSF instance to serve the former NSF's request, we 169 should create an NSF instance by requesting Developer's Management 170 System (DMS) through registration interface. 172 o Creating NSF instances required to enforce security policy rules 173 from Client: In I2NSF framework, users decide which security 174 service is necessary in the system. If there is no NSF instances 175 to enforce the client's security policy, then we should also 176 create the required instances by requesting DMS via registration 177 interface. 179 o Registering NSF instances from Developer's Management System: 180 Depending on system's security requirements, it may require some 181 NSFs by default. In this case, DMS creates these default NSF 182 instances without the need of receiving requests from Security 183 Controller. After creating them, DMS notifies Security Controller 184 of those NSF instances via registration interface. 186 5. Information Model 188 The I2NSF registration interface was only used for registering new 189 NSF instances to Security Controller. In this document, however, we 190 extend its utilization to support dynamic NSF life cycle management 191 and describe the information that should be exchanged via the 192 registration interface for the functionality . Moreover, we also 193 define the information model of NSF Profile because, for registration 194 interface, NSF Profile (i.e., capabilities of an NSF) needs to be 195 clarified so that the components of I2NSF framework can exchange the 196 set of capabilities in a standardized manner. This is typically done 197 through the following process:: 199 1) Security Controller first recognizes the set of capabilities 200 (i.e., NSF Profile) or the signature of a specific NSF required 201 or wasted in the current system. 203 2) Developer's Management System (DMS) matches the recognized 204 information to an NSF based on the information model definition. 206 3) Developer's Management System creates or eliminates NSFs matching 207 with the above information. 209 4) Security Controller can then add/remove the corresponding NSF 210 instance to/from its list of available NSF instances in the 211 system. 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Registration Interface Information Design | 215 | | 216 | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 217 | |Life-Cycle Management| | Registration | | 218 | | Sub-Model | | Sub-Model | | 219 | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: The Registration Interface Information Model Design 224 As illustrated in Figure 1, the information model for Registration 225 Interface consists of two sub-models: life-cycle management, 226 registration sub-models. The life-cycle management functionality and 227 the registration functionality use NSF Profile to achieve their 228 goals. In this context, NSF Profile is the capability objects that 229 describe and/or prescribe inspection capability an NSF instance can 230 provide. 232 5.1. Life-Cycle Managment Mechanism 234 For the life-cycle management of NSFs, Security Controller in I2NSF 235 framework requires two types of requests: Instance Creation and 236 Elimination Request Messages. Security Controller sends the request 237 messages to DMS when required. Once receiving the request, DMS 238 conducts creating/eliminating the corresponding NSF instance and 239 responds Security Controller with the results. There are several 240 cases requiring creation of a new NSF instance which provides 241 specific security inspection functionalities and elimination of an 242 existing NSF which is unused for a period of time. For example, 244 1) When an NSF triggers an advanced inspection of the suspicious 245 traffic via another type of NSF whose instance is currently 246 unavailable in the system. 248 2) When an NSF instance undergoes an excessive amount of traffic 250 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 251 |Instance Creation| | Instance Elimination | 252 | Request Message | | Request Message | 253 +-+-+-+-^-+-+-+-+-+ +-+-+-+-+-+^+-+-+-+-+-+-+ 254 | | 255 | | 256 | | 257 | | 258 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 259 | NSF Profile | | NSF Access | 260 +-+-+-+-+-+-+-+-+ | Information | 261 +-+-+-+-+-+-+-+-+ 263 Figure 2: Life-Cycle Management Sub-Model Overview 265 5.2. Registration Mechanism 267 In order to register a new NSF instance, DMS should generate a 268 Registration Message to Security Controller. A Registration Message 269 consists of an NSF Profile and an NSF Access Information. The former 270 describes the inspection capability of the new NSF instance and the 271 latter is for enabling network access to the new instance from other 272 components. After this registration process, as explained in 273 [nsf-capability-im], the I2NSF capability interface can conduct 274 controlling and monitoring the new registered NSF instance. 276 +-+-+-+-+-+-+-+-+ 277 | Registration | 278 | Message | 279 +-+-+-+-^-+-+-+-+ 280 | 281 +-----------------------------+ 282 | | 283 | | 284 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 285 | NSF Profile | | NSF Access | 286 | | | Information | 287 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 289 Figure 3: Registration Mechanism Sub-Model Overview 291 5.3. NSF Access Information 293 NSF Access Information contains the followings that are required to 294 communicate with an NSF: IPv4 address, IPv6 address, port number, and 295 supported transport protocol(s) (e.g., Virtual Extensible LAN (VXLAN) 296 [RFC 7348], Generic Protocol Extension for VXLAN (VXLAN-GPE) 297 [nvo3-vxlan-gpe], Generic Route Encapsulation (GRE), Ethernet etc.). 298 In this document, NSF Access Information is used to identify a 299 specific NSF instance (i.e. NSF Access Information is the 300 signature(unique identifier) of an NSF instance in the overall 301 system). 303 5.4. NSF Profile (Capabilities of an NSF instance) 305 NSF Profile basically refers the inspection capabilities of an NSF 306 instance. As illustrated in Figure 4, it can be split into five 307 capabilities (Content-Matching, Context-Matching, Attack-Mitigation, 308 Action, Performance Capabilities). We share the security 309 capabilities which are defined in Section 3 (Overall Analysis of 310 Security Capability) in [nsf-capability-im] for the first five 311 capabilities and append one additional capability. 313 +-+-+-+-+-+-+-+-+ 314 | Capability | 315 | Objects | 316 +-+-+-+-^-+-+-+-+ 317 | 318 +--------------------+--------------------+-----------+ 319 | | | | 320 | | | | 321 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 322 |Content-Matching | |Content-Matching | |Context-Matching | | 323 | (Packet) | | Capability | | Capability | | 324 | Capability | | | | | | 325 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | 326 | 327 +--------------------+--------------------+-----------+ 328 | | | 329 | | | 330 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 331 |Attack Mitigation| | Action | | Performance | 332 | Capability | | Capability | | Capability | 333 +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ 335 Figure 4: NSF Profile Overview 337 5.4.1. Packet Content-Matching Capability 339 Refer to the kind of information or attributes acquired directly from 340 the packet headers or payloads that can be used in the security 341 policy. It can be any fields or attributes in the packet L2/L3/L4 342 header, or special segment of bytes in the packet payload. 343 [nsf-capability-im] 345 5.4.2. Content-Matching Capability 347 Content security is another category of security capabilities applied 348 to application layer. Through detecting the contents carried over 349 the traffic in application layer, these capabilities can realize 350 various security functions, such as defending against intrusion, 351 inspecting virus, filtering malicious URL or junk email, blocking 352 illegal web access or malicious data retrieval. [nsf-capability-im] 354 5.4.3. Context-Matching Capability 356 This capability refers to the content information for the received 357 packets. It can be User, Schedule, Region, Target, State and 358 Direction information. [nsf-capability-im] 360 5.4.4. Attack-Mitigation Capability 362 This category of security capabilities is used to detect and mitigate 363 various types of network attacks. Today's common network attacks can 364 be classified into the following sets, and each set further consists 365 of a number of specific attacks: [nsf-capability-im] 367 o DDoS attacks: 369 * Network layer DDoS attacks: Examples include SYN flood, UDP 370 flood, ICMP flood, IP fragment flood, IPv6 Routing header 371 attack, and IPv6 duplicate address detection attack; 373 * Application layer DDoS attacks: Examples include http flood, 374 https flood, cache-bypass http floods, WordPress XML RPC 375 floods, ssl DDoS. 377 o Single-packet attack: 379 * Scanning and sniffing attacks: IP sweep, port scanning, etc 381 * Malformed packet attacks: Ping of Death, Teardrop, etc 383 * Special packet attacks: Oversized ICMP, Tracert, IP timestamp 384 option packets, etc 386 5.4.5. Action Capability 388 NSFs provide security functions by executing various Actions, which 389 at least includes: [nsf-capability-im] 391 o Ingress actions, such as pass, drop, mirroring, etc; 393 o Egress actions, such as invoke signaling, tunnel encapsulation, 394 packet forwarding and/or transformation; 396 o Applying a specific Functional Profile or signature (NSF Profile) 397 - The functional profile or signature file defines the security 398 capabilities for content security control and/or attack mitigation 399 control. One goal of I2NSF is to standardize the form and 400 functional interface of those security capabilities while 401 supporting vendor-specific implementations of each. 403 5.4.6. Performance Capability 405 This information represents the processing capability of an NSF. 406 This information can be used to determine whether the NSF is in 407 congestion by comparing this with the workload that the NSF currently 408 undergoes. Moreover, this information can specify an available 409 amount of each type of resources such as processing power and memory 410 which are available on the NSF. (The registration interface can 411 control the usages and limitations of the created instance and make 412 the appropriate request according to the status.) As illustrated in 413 Figure 5, this information consists of four items: vCPUs, Disk, 414 Memory, and Bandwidth. 416 +-+-+-+-+-+-+-+-+-+ 417 | Performance | 418 | Capability | 419 +-+-+-+-^-+-+-+-+-+ 420 | 421 +--------------+-------------+----------------+ 422 | | | | 423 | | | | 424 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+ 425 | vCPU | | Disk | | Memory | | Bandwidth | 426 +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+-+ 428 Figure 5: Performance Capability Overview 430 5.4.6.1. vCPU 432 This information specifies the details of a virtual CPU (vCPU) 433 available on an NSF. With this information, it is possible to 434 configure the vCPU topology by setting the number of processing 435 cores, socket type, and the number of threads per core. This 436 information can also specify the upper limit of the processing power 437 and the minimum reserved processing power of vCPU. 439 5.4.6.2. Disk 441 This information specifies the total size of the disk (in gigabyte). 442 In addition, the capability of the disk can be expressed as the 443 number of I/O operations per second (IOPS) this disk can perform. 444 This information can also specify two attributes of the disk: disk 445 limit and disk reservation. The disk limit represents the maximum 446 limit of the disk space, and the disk reservation represents the 447 minimum guaranteed space of the disk. 449 5.4.6.3. Memory 451 This information has two attributes to describe an available memory 452 resource: memory limit and memory reservation. The memory limit 453 specifies the upper limit of an available memory in MB, and the 454 memory reservation specifies the guaranteed minimum amount of memory 455 in MB. 457 5.4.6.4. Bandwidth 459 This information specifies the networking capability of an NSF. This 460 information can have seperate attributes for each direction of 461 inbound and outbound. For each direction, this information specifies 462 the amount of traffic this NSF can send/receive per second 463 (kilobytes/sec). 465 6. Security Considerations 467 The information model of the registration interface is based on the 468 I2NSF framework without any architectural changes. Thus, this 469 document shares the security considerations of the I2NSF framwork 470 that are specified in [i2nsf-framework] for the purpose of achieving 471 secure communication between components in the proposed architecture. 473 7. Acknowledgements 475 This work was supported by Institute for Information & communications 476 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 477 (No.R-20160222-002755, Cloud based Security Intelligence Technology 478 Development for the Customized Security Service Provisioning). 480 8. References 482 8.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to 485 Indicate Requirement Levels", BCP 14, 486 RFC 2119, March 1997. 488 8.2. Informative References 490 [nsf-capability-im] Xia, L., Strassner, J., Basile, C., and D. 491 Lopez, "Information Model of NSFs 492 Capabilities", 493 draft-xibassnez-i2nsf-capability-01 (work 494 in progress), March 2017. 496 [i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., 497 Strassner, J., and R. Kumar, "Framework for 498 Interface to Network Security Functions", 499 draft-ietf-i2nsf-framework-05 (work in 500 progress), May 2017. 502 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, 503 L., and H. Birkholz, "Interface to Network 504 Security Functions (I2NSF) Terminology", 505 draft-ietf-i2nsf-terminology-03 (work in 506 progress), March 2017. 508 [nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. 509 Hares, "NSF-Triggered Traffic Steering", 510 draft-hyun-i2nsf-nsf-triggered-steering-03 511 (work in progress), July 2017. 513 [nvo3-vxlan-gpe] Maino, Ed., F., Kreeger, Ed., L., and U. 514 Elzur, Ed., "Generic Protocol Extension for 515 VXLAN", draft-ietf-nvo3-vxlan-gpe-04 (work 516 in progress), April 2017. 518 Appendix A. Changes from draft-hyun-i2nsf-registration-interface-im-01 520 The following changes are made from 521 draft-hyun-i2nsf-registration-interface-im-01: 523 o The description of NSF access information and performance 524 capability is specified in more detail than the previous version. 526 o Miscellaneous expressions in the whole descriptions are corrected. 528 Authors' Addresses 530 Sangwon Hyun 531 Department of Software 532 Sungkyunkwan University 533 2066 Seobu-Ro, Jangan-Gu 534 Suwon, Gyeonggi-Do 16419 535 Republic of Korea 537 Phone: +82 31 290 7222 538 Fax: +82 31 299 6673 539 EMail: swhyun77@skku.edu 540 URI: http://imtl.skku.ac.kr/ 541 Jaehoon Paul Jeong 542 Department of Software 543 Sungkyunkwan University 544 2066 Seobu-Ro, Jangan-Gu 545 Suwon, Gyeonggi-Do 16419 546 Republic of Korea 548 Phone: +82 31 299 4957 549 Fax: +82 31 290 7996 550 EMail: pauljeong@skku.edu 551 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 553 SangUk Woo 554 Department of Software 555 Sungkyunkwan University 556 2066 Seobu-Ro, Jangan-Gu 557 Suwon, Gyeonggi-Do 16419 558 Republic of Korea 560 Phone: +82 31 290 7222 561 Fax: +82 31 299 6673 562 EMail: suwoo@imtl.skku.ac.kr, 563 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 565 YunSuk Yeo 566 Department of Software 567 Sungkyunkwan University 568 2066 Seobu-Ro, Jangan-Gu 569 Suwon, Gyeonggi-Do 16419 570 Republic of Korea 572 Phone: +82 31 290 7222 573 Fax: +82 31 299 6673 574 EMail: yunsuk@imtl.skku.ac.kr, 575 URI: http://imtl.skku.ac.kr/index.php?mid=member_student 577 Jung-Soo Park 578 Electronics and Telecommunications Research Institute 579 218 Gajeong-Ro, Yuseong-Gu 580 Daejeon 305-700 581 Republic of Korea 583 Phone: +82 42 860 6514 584 EMail: pjs@etri.re.kr