idnits 2.17.1 draft-jeong-i2nsf-sdn-security-services-04.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 (March 16, 2016) is 2956 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) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft H. Kim 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: September 17, 2016 J. Park 6 ETRI 7 T. Ahn 8 S. Lee 9 Korea Telecom 10 March 16, 2016 12 Software-Defined Networking Based Security Services using Interface to 13 Network Security Functions 14 draft-jeong-i2nsf-sdn-security-services-04 16 Abstract 18 This document describes a framework, objectives, requirements, and 19 use cases for security services based on Software-Defined Networking 20 (SDN) using a common Interface to Network Security Functions (I2NSF). 21 It first proposes the framework of SDN-based security services in the 22 I2NSF framework. It then explains three use cases, such as a 23 centralized firewall system, centralized DDoS-attack mitigation 24 system, and centralized VoIP/VoLTE security system. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 17, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Centralized Firewall System . . . . . . . . . . . . . . . 8 74 7.2. Centralized DDoS-attack Mitigation System . . . . . . . . 10 75 7.3. Centralized VoIP/VoLTE Security System . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Appendix A. Changes from 82 draft-jeong-i2nsf-sdn-security-services-03 . . . . . 14 84 1. Introduction 86 Software-Defined Networking (SDN) is a set of techniques that enables 87 users to directly program, orchestrate, control and manage network 88 resources through software (e.g., SDN applications). It relocates 89 the control of network resources to a dedicated network element, 90 namely SDN controller. The SDN controller uses interfaces to 91 arbitrate the control of network resources in a logically centralized 92 manner. It also manages and configures the distributed network 93 resources, and provides the abstracted view of the network resources 94 to the SDN applications. The SDN applications can customize and 95 automate the operations (including management) of the abstracted 96 network resources in a programmable manner via the interfaces 97 [RFC7149][ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture]. 99 Due to the increase of sophisticated network attacks, the legacy 100 security services become difficult to cope with such network attacks 101 in an autonomous manner. SDN has been introduced to make networks 102 more controllable and manageable, and this SDN technology will be 103 promising to autonomously deal with such network attacks in a prompt 104 manner. 106 This document describes a framework, objectives and requirements to 107 support the protection of network resources through SDN-based 108 security services using a common interface to Network Security 109 Functions (NSF) [i2nsf-framework]. It uses an interface to NSF 110 (I2NSF) for such SDN-based security services that are performed in 111 virtual machines through network functions virtualization [ETSI-NFV]. 113 This document addresses the challenges of the exisiting systems for 114 security services. As feasible solutions to handle these challenges, 115 this document proposes three use cases of the security services, such 116 as a centralized firewall system, centralized DDoS-attack mitigation 117 system, and centralized VoIP/VoLTE security system. 119 For the centralized firewall system, this document raises limitations 120 in the legacy firewalls in terms of flexibility and administration 121 costs. Since in many cases, access control management for firewall 122 is manually performed, it is difficult to add the access control 123 policy rules corresponding to new network attacks in a prompt and 124 autonomous manner. Thus, this situation requires expensive 125 administration costs. This document introduces a use case of SDN- 126 based firewall system to overcome these limitations. 128 For the centralized DDoS-attack mitigation system, this document 129 raises limitations in the legacy DDoS-attack mitigation techniques in 130 terms of flexibility and administration costs. Since in many cases, 131 network configuration for the mitigation is manually performed, it is 132 difficult to dynamically configure network devices to limit and 133 control suspicious network traffic for DDoS attacks. This document 134 introduces a use case of SDN-based DDoS-attack mitigation system to 135 provide an autonomous and prompt configuration for suspicious network 136 traffic. 138 For the centralized VoIP/VoLTE security system, this documents raises 139 challenges in the legacy VoIP/VoLTE security system in terms of 140 provisioning time, the granularity of security, cost, and the 141 establishment of policy. This document shows a use case of SDN-based 142 VoIP/VoLTE security system to resolve these challenges along in the 143 I2NSF framework. 145 2. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 3. Terminology 153 This document uses the terminology described in [RFC7149], 154 [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], 155 [ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms 156 are defined below: 158 o Software-Defined Networking: A set of techniques that enables to 159 directly program, orchestrate, control, and manage network 160 resources, which facilitates the design, delivery and operation of 161 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 163 o Access Control: A procedure used to determine if an entity should 164 be granted access to resources, facilities, services, or 165 information based on pre-established rules and specific rights or 166 authority associated with the requesting party [ITU-T.X.1252]. 168 o Access Control Policy: The set of rules that define the conditions 169 under which access may take place [ITU-T.X.800]. 171 o Access Control Policy Rules: Security policy rules concerning the 172 provision of the access control service [ITU-T.X.800]. 174 o Network Resources: Network devices that can perform packet 175 forwarding in a network system. The network resources include 176 network switch, router, gateway, WiFi access points, and similar 177 devices. 179 o Firewall: A firewall that is a device or service at the junction 180 of two network segments that inspects every packet that attempts 181 to cross the boundary. It also rejects any packet that does not 182 satisfy certain criteria for disallowed port numbers or IP 183 addresses. 185 o Centralized Firewall System: A centralized firewall that can 186 establish and distribute access control policy rules into network 187 resources for efficient firewall management. These rules can be 188 managed dynamically by a centralized server for firewall. SDN can 189 work as a network-based firewall system through a standard 190 interface between firewall applications and network resources. 192 o Centralized DDoS-attack Mitigation System: A centralized mitigator 193 that can establish and distribute access control policy rules into 194 network resources for efficient DDoS-attack mitigation. These 195 rules can be managed dynamically by a centralized server for DDoS- 196 attack mitigation. SDN can work as a network-based mitigation 197 system through a standard interface between DDoS-attack mitigation 198 applications and network resources. 200 o Centralized VoIP/VoLTE Security System: A centralized security 201 system that handles the security issues related to VoIP and VoLTE 202 services. SDN can work as a network-based security system through 203 a standard interface between VoIP/VoLTE security applications and 204 network resources. 206 4. Overview 208 This section describes the referenced architecture to support SDN- 209 based security services, such as centralized firewall system and 210 centralized DDoS-attack mitigation system. Also, it describes a 211 framework for SDN-based security services using I2NSF. 213 As shown in Figure 1, security functions as security services (e.g., 214 firewall, DDoS-attack mitigation, VoIP/VoLTE, web filter, and deep 215 packet inspection) run on the top of SDN controller [ITU-T.Y.3300] 216 [ONF-SDN-Architecture]. When an administrator enforces security 217 policies for such security services through an application interface, 218 SDN controller generates the corresponding access control policy 219 rules to meet such security policies in an autonomous and prompt 220 manner. According to the generated access control policy rules, the 221 network resources such as switches take an action to mitigate network 222 attacks, for example, dropping packets with suspicious patterns. 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Security Functions | 226 | (e.g., firewall, DDoS-attack mitigation, | Application 227 |VoIP/VoLTE, web filter, deep packet inspection)| Layer 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 -------------------------------------------------------------------- 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Application- 231 | Application Support | Control Interface) 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Orchestration | Switch Controller 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Layer 235 | Abstraction | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 -------------------------------------------------------------------- 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Resource- 239 | Control Support | Control Interface) 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Data Transport and Processing | Resource Layer 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: High-level Architecture for SDN-based Security Services 246 Figure 2 shows a framework to support SDN-based security services 247 using I2NSF [i2nsf-framework]. As shown in Figure 2, client and 248 application gateway (AppGW) can use security services by delivering 249 their high-level security policies to security controller via service 250 layer interface. Security controller asks security function(s) 251 function-level security services via capability layer interface. The 252 security functions run on top of virtual machines through NFV 253 [ETSI-NFV]. Securiy functions asks switch controller to perform 254 their required security services on switches under the supervision of 255 switch controller. 257 Capability layer interface between security controller and security 258 functions can be implemented by Network Configuration Protocol 259 (NETCONF) [RFC6241] with a data modeling language called YANG 260 [RFC6020] that describes function-level security services. 262 5. Objectives 264 o Prompt reaction to new network attacks: SDN-based security 265 services allow private networks to defend themselves against new 266 sophisticated network attacks. 268 o Automatic defense from network attacks: SDN-based security 269 services identify the category of network attack (e.g., malware 270 and DDoS attacks) and take counteraction for the defense without 271 the intervention of network administrators. 273 o Network-load-aware resource allocation: SDN-based security 274 services measure the overhead of resources for security services 275 and dynamically select resources considering load balance for the 276 maximum network performance. 278 +------------+ 279 |Client/AppGW| 280 +------------+ 281 | 282 | Service Layer Interface 283 | 284 +-------------------+ +-------------+ 285 |Security Controller|<------------------------->|Vendor System| 286 +-------------------+ Vendor Facing Interface +-------------+ 287 | 288 | Capability Layer Interface 289 | 290 +-------------------+ +-------------------+ +-------------------+ 291 |Security Function 1|-|Security Function 2|....|Security Function n| 292 +-------------------+ +-------------------+ +-------------------+ 293 | 294 | SDN Northbound Interface 295 | 296 +-----------------+ 297 |Switch Controller| 298 +-----------------+ 299 | 300 | SDN Southbound Interface 301 | 302 +--------+ +--------+ +--------+ 303 |Switch 1|-|Switch 2|......|Switch m| 304 +--------+ +--------+ +--------+ 306 Figure 2: A Framework for SDN-based Security Services using I2NSF 308 6. Requirements 310 SDN-based security services provide dynamic and flexible network 311 resource management to mitigate network attacks, such as malware and 312 DDoS attacks. In order to support this capability, the requirements 313 for SDN-based security services are described as follows: 315 o SDN-based security services are required to support the 316 programmability of network resources to mitigate network attacks. 318 o SDN-based security services are required to support the 319 orchestration of network resources and SDN applications to 320 mitigate network attacks. 322 o SDN-based security services are required to provide an application 323 interface allowing the management of access control policies in an 324 autonomous and prompt manner. 326 o SDN-based security services are required to provide a resource- 327 control interface for the control of network resources to mitigate 328 network attacks. 330 o SDN-based security services are required to provide the logically 331 centralized control of network resources to mitigate network 332 attacks. 334 o SDN-based security services are required to support the seamless 335 services to mitigate network attacks. 337 o SDN-based security services are required to provide the dynamic 338 control of network resources to mitigate network attacks. 340 7. Use Cases 342 This section introduces three use cases for security services based 343 on SDN: (i) centralized firewall system, (ii) centralized DDoS-attack 344 mitigation system, and (iii) centralized VoIP/VoLTE security system. 346 7.1. Centralized Firewall System 348 For the centralized firewall system, a centralized network firewall 349 can manage each network resource and firewall rules can be managed 350 flexibly by a centralized server for firewall (called Firewall). The 351 centralized network firewall controls each switch for the network 352 resource management and the firewall rules can be added or deleted 353 dynamically. 355 The procedure of firewall operations in the centralized firewall 356 system is as follows: 358 1. Switch forwards an unknown flow's packet to Switch Controller. 360 2. Switch Controller forwards the unknown flow's packet to an 361 appropriate security service application, such as Firewall. 363 3. Firewall analyzes the headers and contents of the packet. 365 4. If Firewall regards the packet as a malware's packet with a 366 suspicious pattern, it reports the malware's packet to Switch 367 Controller. 369 5. Switch Controller installs new rules (e.g., drop packets with the 370 suspicious pattern) into switches. 372 6. The malware's packets are dropped by switches. 374 For the above centralized firewall system, the existing SDN protocols 375 can be used through standard interfaces between the firewall 376 application and switches [RFC7149][ITU-T.Y.3300][ONF-OpenFlow] 377 [ONF-SDN-Architecture]. 379 Legacy firewalls have some challenges such as the expensive cost, 380 performance, management of access control, establishment of policy, 381 and packet-based access mechanism. The proposed framework can 382 resolve these challenges through the above centralized firewall 383 system based on SDN as follows: 385 o Cost: The cost of adding firewalls to network resources such as 386 routers, gateways, and switches is substantial due to the reason 387 that we need to add firewall on each network resource. To solve 388 this, each network resource can be managed centrally such that a 389 single firewall is manipulated by a centralized server. 391 o Performance: The performance of firewalls is often slower than the 392 link speed of network interfaces. Every network resource for 393 firewall needs to check firewall rules according to network 394 conditions. Firewalls can be adaptively deployed among network 395 switches, depending on network conditions in the framework. 397 o The management of access control: Since there may be hundreds of 398 network resources in an administered network, the dynamic 399 management of access control for security services like firewall 400 is a challenge. In the framework, firewall rules can be 401 dynamically added for new malware. 403 o The establishment of policy: Policy should be established for each 404 network resource. However, it is difficult to describe what flows 405 are permitted or denied for firewall within a specific 406 organization network under management. Thus, a centralized view 407 is helpful to determine security policies for such a network. 409 o Packet-based access mechanism: Packet-based access mechanism is 410 not enough for firewall in practice since the basic unit of access 411 control is usually users or applications. Therefore, application 412 level rules can be defined and added to the firewall system 413 through the centralized server. 415 7.2. Centralized DDoS-attack Mitigation System 417 For the centralized DDoS-attack mitigation system, a centralized 418 DDoS-attack mitigation can manage each network resource and 419 manipulate rules to each switch through a centralized server for 420 DDoS-attack mitigation (called DDoS-attack Mitigator). The 421 centralized DDoS-attack mitigation system defends servers against 422 DDoS attacks outside private network, that is, from public network. 424 Servers are categorized into stateless servers (e.g., DNS servers) 425 and stateful servers (e.g., web servers). For DDoS-attack 426 mitigation, traffic flows in switches are dynamically configured by 427 traffic flow forwarding path management according to the category of 428 servers [AVANT-GUARD]. Such a managenent should consider the load 429 balance among the switches for the defense against DDoS attacks. 431 The procedure of DDoS-attack mitigation operations in the centralized 432 DDoS-attack mitigation system is as follows: 434 1. Switch periodically reports an inter-arrival pattern of a flow's 435 packets to Switch Controller. 437 2. Switch Controller forwards the flow's inter-arrival pattern to an 438 appropriate security service application, such as DDoS-attack 439 Mitigator. 441 3. DDoS-attack Mitigator analyzes the reported pattern for the flow. 443 4. If DDoS-attack Mitigator regards the pattern as a DDoS attack, it 444 computes a packet dropping probability corresponding to 445 suspiciousness level and reports this DDoS-attack flow to Switch 446 Controller. 448 5. Switch Controller installs new rules into switches (e.g., forward 449 packets with the suspicious inter-arrival pattern with a dropping 450 probability). 452 6. The suspicious flow's packets are randomly dropped by switches 453 with the dropping probability. 455 For the above centralized DDoS-attack mitigation system, the existing 456 SDN protocols can be used through standard interfaces between the 457 DDoS-attack mitigator application and switches [RFC7149] 458 [ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture]. 460 The centralized DDoS-attack mitigation system has challenges similar 461 to the centralized firewall system. The proposed framework can 462 resolve these challenges through the above centralized DDoS-attack 463 mitigation system based on SDN as follows: 465 o Cost: The cost of adding DDoS-attack mitigators to network 466 resources such as routers, gateways, and switches is substantial 467 due to the reason that we need to add DDoS-attack mitigator on 468 each network resource. To solve this, each network resource can 469 be managed centrally such that a single DDoS-attack mitigator is 470 manipulated by a centralized server. 472 o Performance: The performance of DDoS-attack mitigators is often 473 slower than the link speed of network interfaces. The checking of 474 DDoS attacks may reduce the performance of the network interfaces. 475 DDoS-attack mitigators can be adaptively deployed among network 476 switches, depending on network conditions in the framework. 478 o The management of network resources: Since there may be hundreds 479 of network resources in an administered network, the dynamic 480 management of network resources for performance (e.g., load 481 balancing) is a challenge for DDoS-attack mitigation. In the 482 framework, as dynamic network resource management, traffic flow 483 forwarding path management can handle the load balancing of 484 network switches [AVANT-GUARD]. With this management, the current 485 and near-future workload can be spread among the network switches 486 for DDoS-attack mitigation. In addition, DDoS-attack mitigation 487 rules can be dynamically added for new DDoS attacks. 489 o The establishment of policy: Policy should be established for each 490 network resource. However, it is difficult to describe what flows 491 are permitted or denied for new DDoS-attacks (e.g., DNS reflection 492 attack) within a specific organization network under management. 493 Thus, a centralized view is helpful to determine security policies 494 for such a network. 496 7.3. Centralized VoIP/VoLTE Security System 498 For the centralized VoIP/VoLTE security system, a centralized VoIP/ 499 VoLTE security system can monitor each VoIP/VoLTE flow and manage 500 VoIP/VoLTE security rules controlled by a centralized server for 501 VoIP/VoLTE security service (called VoIP IPS). The VoIP/VoLTE 502 security system controls each switch for the VoIP/VoLTE call flow 503 management by manipulating the rules that can be added, deleted or 504 modified dynamically. 506 The procedure of VoIP/VoLTE security operations in the centralized 507 VoIP/VoLTE security system is as follows: 509 1. A switch forwards an unknown call flow's signal packet (e.g., SIP 510 packet) to Switch Controller. Also, if the packet belongs to a 511 matched flow's packet related to SIP (called matched SIP packet), 512 Switch forwards the packet to Switch Controller so that the 513 packet can be checked by a security function for VoIP (i.e., VoIP 514 IPS) via Switch Controller, which monitors the behavior of its 515 SIP call. 517 2. Switch Controller forwards the unknown flow's packet or the 518 matched SIP packet to an appropriate security service function, 519 such as VoIP IPS. 521 3. VoIP IPS analyzes the headers and contents of the signal packet, 522 such as IP address, calling number, and session description 523 [RFC4566]. 525 4. If VoIP IPS regards the packet as a spoofed packet by hackers or 526 a scanning packet searching for VoIP/VoLTE devices, it requests 527 the Switch Controller to block that packet and the subsequent 528 packets that have the same call-id. 530 5. Switch Controller installs new rules (e.g., drop packets) into 531 switches. 533 6. The illegal packets are dropped by switches. 535 For the above centralized VoIP/VoLTE security system, the existing 536 SDN protocols can be used through standard interfaces between the 537 VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] 538 [ONF-OpenFlow][ONF-SDN-Architecture]. 540 Legacy hardware based VoIP IPSes have some challenges, such as 541 provisioning time, the granularity of security, expensive cost, and 542 the establishment of policy. The proposed framework can resolve 543 these challenges through the above centralized VoIP/VoLTE security 544 system based on SDN as follows: 546 o Provisioning: The provisioning time of setting up a legacy VoIP 547 IPS to network is substantial because it takes from some hours to 548 some days. By managing the network resources centrally, VoIP IPS 549 can provide more agility in provisioning both virtual and physical 550 network resources from a central location. 552 o The granularity of security: The security rules of a legacy VoIP 553 IPS are compounded considering the granularity of security. The 554 proposed framework can provide more granular security by 555 centralizing security control into a switch controller. The VoIP 556 IPS can effectively manage security rules throughout the network. 558 o Cost: The cost of adding VoIP IPS to network resources, such as 559 routers, gateways, and switches is substantial due to the reason 560 that we need to add VoIP IPS on each network resource. To solve 561 this, each network resource can be managed centrally such that a 562 single VoIP IPS is manipulated by a centralized server. 564 o The establishment of policy: Policy should be established for each 565 network resource. However, it is difficult to describe what flows 566 are permitted or denied for VoIP IPS within a specific 567 organization network under management. Thus, a centralized view 568 is helpful to determine security policies for such a network. 570 8. Security Considerations 572 This document shares all the security issues of SDN that are 573 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 575 9. Acknowledgements 577 This document was supported by Institute for Information & 578 communications Technology Promotion (IITP) grant funded by the Korea 579 government (MSIP) [10041244, Smart TV 2.0 Software Platform] and by 580 MSIP/IITP [R0166-15-1041, Standard Development of Network Security 581 based SDN]. 583 This document has greatly benefited from inputs by Jinyong Kim, 584 Daeyoung Hyun, Mahdi Daghmehchir-Firoozjaei, and Geumhwan Cho. 586 10. References 588 10.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to 591 Indicate Requirement Levels", BCP 14, 592 RFC 2119, March 1997. 594 [i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L., Zhuang, X., 595 Parrott, J., Krishnan, R., and S. Durbha, 596 "Framework for Interface to Network Security 597 Functions", draft-merged-i2nsf-framework-02 , 598 June 2015. 600 10.2. Informative References 602 [RFC7149] Boucadair, M. and C. Jacquenet, "Software- 603 Defined Networking: A Perspective from within 604 a Service Provider Environment", RFC 7149, 605 March 2014. 607 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., 608 and A. Bierman, "Network Configuration 609 Protocol (NETCONF)", RFC 6241, June 2011. 611 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 612 Language for the Network Configuration 613 Protocol (NETCONF)", RFC 6020, October 2010. 615 [ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of 616 Software-Defined Networking", June 2014. 618 [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 619 1.4.0)", October 2013. 621 [ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. 623 [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline 624 Identity Management Terms and Definitions", 625 April 2010. 627 [ITU-T.X.800] Recommendation ITU-T X.800, "Security 628 Architecture for Open Systems Interconnection 629 for CCITT Applications", March 1991. 631 [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and G. 632 Gu, "AVANT-GUARD: Scalable and Vigilant 633 Switch Flow Management in Software-Defined 634 Networks", ACM CCS, November 2013. 636 [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions 637 Virtualisation (NFV); Architectural 638 Framework", October 2013. 640 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, 641 "SDP: Session Description Protocol", 642 RFC 4566, July 2006. 644 Appendix A. Changes from draft-jeong-i2nsf-sdn-security-services-03 646 The following changes were made from 647 draft-jeong-i2nsf-sdn-security-services-03: 649 o A new use case is added for a centralized VoIP/VoLTE security 650 system. 652 o For the use case of the centralized VoIP/VoLTE security system, 653 two new requirements are added. First, SDN-based security 654 services are required to support the seamless services to mitigate 655 network attacks. Second, SDN-based security services are required 656 to provide the dynamic control of network resources to mitigate 657 network attacks. 659 Authors' Addresses 661 Jaehoon Paul Jeong 662 Department of Software 663 Sungkyunkwan University 664 2066 Seobu-Ro, Jangan-Gu 665 Suwon, Gyeonggi-Do 16419 666 Republic of Korea 668 Phone: +82 31 299 4957 669 Fax: +82 31 290 7996 670 EMail: pauljeong@skku.edu 671 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 673 Hyoungshick Kim 674 Department of Software 675 Sungkyunkwan University 676 2066 Seobu-Ro, Jangan-Gu 677 Suwon, Gyeonggi-Do 16419 678 Republic of Korea 680 Phone: +82 31 299 4324 681 Fax: +82 31 290 7996 682 EMail: hyoung@skku.edu 683 URI: http://seclab.skku.edu/people/hyoungshick-kim/ 685 Jung-Soo Park 686 Electronics and Telecommunications Research Institute 687 218 Gajeong-Ro, Yuseong-Gu 688 Daejeon 305-700 689 Republic of Korea 691 Phone: +82 42 860 6514 692 EMail: pjs@etri.re.kr 693 Tae-Jin Ahn 694 Korea Telecom 695 70 Yuseong-Ro, Yuseong-Gu 696 Daejeon 305-811 697 Republic of Korea 699 Phone: +82 42 870 8409 700 EMail: taejin.ahn@kt.com 702 Se-Hui Lee 703 Korea Telecom 704 70 Yuseong-Ro, Yuseong-Gu 705 Daejeon 305-811 706 Republic of Korea 708 Phone: +82 42 870 8162 709 EMail: sehuilee@kt.com