idnits 2.17.1 draft-jeong-i2nsf-sdn-security-services-03.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 (October 9, 2015) is 3121 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: April 11, 2016 J. Park 6 ETRI 7 October 9, 2015 9 Software-Defined Networking Based Security Services using Interface to 10 Network Security Functions 11 draft-jeong-i2nsf-sdn-security-services-03 13 Abstract 15 This document describes a framework, objectives, requirements, and 16 use cases for security services based on Software-Defined Networking 17 (SDN) using a common Interface to Network Security Functions (I2NSF). 18 It first proposes the framework of SDN-based security services in the 19 I2NSF framework. It then explains two use cases, such as centralized 20 firewall system and centralized DDoS-attack mitigation system. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 11, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Centralized Firewall System . . . . . . . . . . . . . . . 8 70 7.2. Centralized DDoS-attack Mitigation System . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Software-Defined Networking (SDN) is a set of techniques that enables 80 users to directly program, orchestrate, control and manage network 81 resources through software (e.g., SDN applications). It relocates 82 the control of network resources to a dedicated network element, 83 namely SDN controller. The SDN controller uses interfaces to 84 arbitrate the control of network resources in a logically centralized 85 manner. It also manages and configures the distributed network 86 resources, and provides the abstracted view of the network resources 87 to the SDN applications. The SDN applications can customize and 88 automate the operations (including management) of the abstracted 89 network resources in a programmable manner via the interfaces 90 [RFC7149][ITU-T.Y.3300][ONF-SDN-Architecture][ONF-OpenFlow]. 92 Due to the increase of sophisticated network attacks, the legacy 93 security services become difficult to cope with such network attacks 94 in an autonomous manner. SDN has been introduced to make networks 95 more controllable and manageable, and this SDN technology will be 96 promising to autonomously deal with such network attacks in a prompt 97 manner. 99 This document describes a framework, objectives and requirements to 100 support the protection of network resources through SDN-based 101 security services using a common interface to Network Security 102 Functions (NSF) [i2nsf-framework]. It uses an interface to NSF 103 (I2NSF) for such SDN-based security services that are performed in 104 virtual machines through network functions virtualization [ETSI-NFV]. 106 This document addresses the challenges of the exisiting systems for 107 security services. As feasible solutions to handle these challenges, 108 this document proposes two use cases of the security services, such 109 as centralized firewall system and centralized DDoS-attack mitigation 110 system. 112 For the centralized firewall system, this document raises limitations 113 in legacy firewalls in terms of flexibility and administration costs. 114 Since in many cases, access control management for firewall is 115 manually performed, it is difficult to add the access control policy 116 rules corresponding to new network attacks in a prompt and autonomous 117 manner. Thus, this situation requires expensive administration 118 costs. This document introduces a use case of SDN-based firewall 119 system to overcome these limitations. 121 For the centralized DDoS-attack mitigation system, this document 122 raises limitations in legacy DDoS-attack mitigation techniques in 123 terms of flexibility and administration costs. Since in many cases, 124 network configuration for the mitigation is manually performed, it is 125 difficult to dynamically configure network devices to limit and 126 control suspicious network traffic for DDoS attacks. This document 127 introduces a use case of SDN-based DDoS-attack mitigation system to 128 provide an autonomous and prompt configuration for suspicious network 129 traffic. 131 2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 3. Terminology 139 This document uses the terminology described in [RFC7149], 140 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], 141 [ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms 142 are defined below: 144 o Software-Defined Networking: A set of techniques that enables to 145 directly program, orchestrate, control, and manage network 146 resources, which facilitates the design, delivery and operation of 147 network services in a dynamic and scalable manner [ITU-T.Y.3300]. 149 o Access Control: A procedure used to determine if an entity should 150 be granted access to resources, facilities, services, or 151 information based on pre-established rules and specific rights or 152 authority associated with the requesting party [ITU-T.X.1252]. 154 o Access Control Policy: The set of rules that define the conditions 155 under which access may take place [ITU-T.X.800]. 157 o Access Control Policy Rules: Security policy rules concerning the 158 provision of the access control service [ITU-T.X.800]. 160 o Network Resources: Network devices that can perform packet 161 forwarding in a network system. The network resources include 162 network switch, router, gateway, WiFi access points, and similar 163 devices. 165 o Firewall: A firewall that is a device or service at the junction 166 of two network segments that inspects every packet that attempts 167 to cross the boundary. It also rejects any packet that does not 168 satisfy certain criteria for disallowed port numbers or IP 169 addresses. 171 o Centralized Firewall System: A centralized firewall that can 172 establish and distribute access control policy rules into network 173 resources for efficient firewall management. These rules can be 174 managed dynamically by a centralized server for firewall. SDN can 175 work as a network-based firewall system through a standard 176 interface between firewall applications and network resources. 178 o Centralized DDoS-attack Mitigation System: A centralized mitigator 179 that can establish and distribute access control policy rules into 180 network resources for efficient DDoS-attack mitigation. These 181 rules can be managed dynamically by a centralized server for DDoS- 182 attack mitigation. SDN can work as a network-based mitigation 183 system through a standard interface between DDoS-attack mitigation 184 applications and network resources. 186 4. Overview 188 This section describes the referenced architecture to support SDN- 189 based security services, such as centralized firewall system and 190 centralized DDoS-attack mitigation system. Also, it describes a 191 framework for SDN-based security services using I2NSF. 193 | 194 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | Security Functions | 196 | | (e.g., firewall, DDoS-attack mitigation, | Application 197 | | web filter, deep packet inspection) | Layer 198 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |------------------------------------------------------------ 200 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Application- 201 | | Application Support | Control Interface) 202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | Orchestration | SDN Controller 204 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Layer 205 | | Abstraction | 206 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |------------------------------------------------------------- 208 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Resource- 209 | | Control Support | Control Interface) 210 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | Data Transport and Processing | Resource Layer 212 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | 215 Figure 1: High-level Architecture for SDN-based Security Services 217 As shown in Figure 1, security functions as security services (e.g., 218 firewall, DDoS-attack mitigation, web filter, deep packet inspection) 219 run on the top of SDN controller [ITU-T.Y.3300] 220 [ONF-SDN-Architecture]. When an administrator enforces security 221 policies for such security services through an application interface, 222 SDN controller generates the corresponding access control policy 223 rules to meet such security policies in an autonomous and prompt 224 manner. According to the generated access control policy rules, the 225 network resources such as switches take an action to mitigate network 226 attacks, for example, dropping packets with suspicious patterns. 228 +------------+ 229 |Client/AppGW| 230 +------------+ 231 | 232 | Service Layer Interface 233 | 234 +-------------------+ +-------------+ 235 |Security Controller|<------------------------->|Vendor System| 236 +-------------------+ Vendor Facing Interface +-------------+ 237 | 238 | Capability Layer Interface 239 | 240 +-------------------+ +-------------------+ +-------------------+ 241 |Security Function 1|-|Security Function 2|....|Security Function n| 242 +-------------------+ +-------------------+ +-------------------+ 243 | 244 | SDN Northbound Interface 245 | 246 +-----------------+ 247 |Switch Controller| 248 +-----------------+ 249 | 250 | SDN Southbound Interface 251 | 252 +--------+ +--------+ +--------+ 253 |Switch 1|-|Switch 2|......|Switch m| 254 +--------+ +--------+ +--------+ 256 Figure 2: A Framework for SDN-based Security Services using I2NSF 258 Figure 2 shows a framework to support SDN-based security services 259 using I2NSF [i2nsf-framework]. As shown in Figure 2, client and 260 application gateway (AppGW) can use security services by delivering 261 their high-level security policies to security controller via service 262 layer interface. Security controller asks security function(s) 263 function-level security services via capability layer interface. The 264 security functions run on top of virtual machines through NFV 265 [ETSI-NFV]. Securiy functions asks switch controller to perform 266 their required security services on switches under the supervision of 267 switch controller. 269 Capability layer interface between security controller and security 270 functions can be implemented by Network Configuration Protocol 271 (NETCONF) [RFC6241] with a data modeling language called YANG 272 [RFC6020] that describes function-level security services. 274 5. Objectives 276 o Prompt reaction to new network attacks: SDN-based security 277 services allow private networks to defend themselves against new 278 sophisticated network attacks. 280 o Automatic defense from network attacks: SDN-based security 281 services identify the category of network attack (e.g., malware 282 and DDoS attacks) and take counteraction for the defense without 283 the intervention of network administrators. 285 o Network-load-aware resource allocation: SDN-based security 286 services measure the overhead of resources for security services 287 and dynamically select resources considering load balance for the 288 maximum network performance. 290 6. Requirements 292 SDN-based security services provide dynamic and flexible network 293 resource management to mitigate network attacks, such as malware and 294 DDoS attacks. In order to support this capability, the requirements 295 for SDN-based security services are described as follows: 297 o SDN-based security services are required to support the 298 programmability of network resources to mitigate network attacks. 300 o SDN-based security services are required to support the 301 orchestration of network resources and SDN applications to 302 mitigate network attacks. 304 o SDN-based security services are required to provide an application 305 interface allowing the management of access control policies in an 306 autonomous and prompt manner. 308 o SDN-based security services are required to provide a resource- 309 control interface for the control of network resources to mitigate 310 network attacks. 312 o SDN-based security services are required to provide the logically 313 centralized control of network resources to mitigate network 314 attacks. 316 7. Use Cases 318 This section introduces two use cases for security services based on 319 SDN: (i) centralized firewall system and (ii) centralized DDoS-attack 320 mitigation system. 322 7.1. Centralized Firewall System 324 For the centralized firewall system, a centralized network firewall 325 can manage each network resource and firewall rules can be managed 326 flexibly by a centralized server for firewall (called Firewall). The 327 centralized network firewall controls each switch for the network 328 resource management and the firewall rules can be added or deleted 329 dynamically. 331 The procedure of firewall operations in the centralized firewall 332 system is as follows: 334 1. Switch forwards an unknown flow's packet to SDN Controller. 336 2. SDN Controller forwards the unknown flow's packet to an 337 appropriate security service application, such as Firewall. 339 3. Firewall analyzes the headers and contents of the packet. 341 4. If Firewall regards the packet as a malware's packet with a 342 suspicious pattern, it reports the malware's packet to SDN 343 Controller. 345 5. SDN Controller installs new rules (e.g., drop packets with the 346 suspicious pattern) into switches. 348 6. The malware's packets are dropped by switches. 350 For the above centralized firewall system, the existing SDN protocols 351 can be used through standard interfaces between the firewall 352 application and switches [RFC7149][ITU-T.Y.3300] 353 [ONF-SDN-Architecture][ONF-OpenFlow]. 355 Legacy firewalls have some challenges such as the expensive cost, 356 performance, management of access control, establishment of policy, 357 and packet-based access mechanism. The proposed framework can 358 resolve these challenges through the above centralized firewall 359 system based on SDN as follows. 361 o Cost: The cost of adding firewalls to network resources such as 362 routers, gateways, and switches is substantial due to the reason 363 that we need to add firewall on each network resource. To solve 364 this, each network resource can be managed centrally such that a 365 single firewall is manipulated by a centralized server. 367 o Performance: The performance of firewalls is often slower than the 368 link speed of network interfaces. Every network resource for 369 firewall needs to check firewall rules according to network 370 conditions. Firewalls can be adaptively deployed among network 371 switches, depending on network conditions in the framework. 373 o The management of access control: Since there may be hundreds of 374 network resources in an administered network, the dynamic 375 management of access control for security services like firewall 376 is a challenge. In the framework, firewall rules can be 377 dynamically added for new malware. 379 o The establishment of policy: Policy should be established for each 380 network resource. However, it is difficult to describe what flows 381 are permitted or denied for firewall within a specific 382 organization network under management. Thus, a centralized view 383 is helpful to determine security policies for such a network. 385 o Packet-based access mechanism: Packet-based access mechanism is 386 not enough for firewall in practice since the basic unit of access 387 control is usually users or applications. Therefore, application 388 level rules can be defined and added to the firewall system 389 through the centralized server. 391 7.2. Centralized DDoS-attack Mitigation System 393 For the centralized DDoS-attack mitigation system, a centralized 394 DDoS-attack mitigation can manage each network resource and 395 manipulate rules to each switch through a centralized server for 396 DDoS-attack mitigation (called DDoS-attack Mitigator). The 397 centralized DDoS-attack mitigation system defends servers against 398 DDoS attacks outside private network, that is, from public network. 400 Servers are categorized into stateless servers (e.g., DNS servers) 401 and stateful servers (e.g., web servers). For DDoS-attack 402 mitigation, traffic flows in switches are dynamically configured by 403 traffic flow forwarding path management according to the category of 404 servers [AVANT-GUARD]. Such a managenent should consider the load 405 balance among the switches for the defense against DDoS attacks. 407 The procedure of DDoS-attack mitigation operations in the centralized 408 DDoS-attack mitigation system is as follows: 410 1. Switch periodically reports an inter-arrival pattern of a flow's 411 packets to SDN Controller. 413 2. SDN Controller forwards the flow's inter-arrival pattern to an 414 appropriate security service application, such as DDoS-attack 415 Mitigator. 417 3. DDoS-attack Mitigator analyzes the reported pattern for the flow. 419 4. If DDoS-attack Mitigator regards the pattern as a DDoS attack, it 420 computes a packet dropping probability corresponding to 421 suspiciousness level and reports this DDoS-attack flow to SDN 422 Controller. 424 5. SDN Controller installs new rules into switches (e.g., forward 425 packets with the suspicious inter-arrival pattern with a dropping 426 probability). 428 6. The suspicious flow's packets are randomly dropped by switches 429 with the dropping probability. 431 For the above centralized DDoS-attack mitigation system, the existing 432 SDN protocols can be used through standard interfaces between the 433 DDoS-attack mitigator application and switches [RFC7149] 434 [ITU-T.Y.3300][ONF-SDN-Architecture][ONF-OpenFlow]. 436 The centralized DDoS-attack mitigation system has challenges similar 437 to the centralized firewall system. The proposed framework can 438 resolve these challenges through the above centralized DDoS-attack 439 mitigation system based on SDN as follows. 441 o Cost: The cost of adding DDoS-attack mitigators to network 442 resources such as routers, gateways, and switches is substantial 443 due to the reason that we need to add DDoS-attack mitigator on 444 each network resource. To solve this, each network resource can 445 be managed centrally such that a single DDoS-attack mitigator is 446 manipulated by a centralized server. 448 o Performance: The performance of DDoS-attack mitigators is often 449 slower than the link speed of network interfaces. The checking of 450 DDoS attacks may reduce the performance of the network interfaces. 451 DDoS-attack mitigators can be adaptively deployed among network 452 switches, depending on network conditions in the framework. 454 o The management of network resources: Since there may be hundreds 455 of network resources in an administered network, the dynamic 456 management of network resources for performance (e.g., load 457 balancing) is a challenge for DDoS-attack mitigation. In the 458 framework, as dynamic network resource management, traffic flow 459 forwarding path management can handle the load balancing of 460 network switches [AVANT-GUARD]. With this management, the current 461 and near-future workload can be spread among the network switches 462 for DDoS-attack mitigation. In addition, DDoS-attack mitigation 463 rules can be dynamically added for new DDoS attacks. 465 o The establishment of policy: Policy should be established for each 466 network resource. However, it is difficult to describe what flows 467 are permitted or denied for new DDoS-attacks (e.g., DNS reflection 468 attack) within a specific organization network under management. 469 Thus, a centralized view is helpful to determine security policies 470 for such a network. 472 8. Security Considerations 474 This document shares all the security issues of SDN that are 475 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 477 9. Acknowledgements 479 This work was partly supported by the ICT R&D program of MSIP/IITP 480 [10041244, SmartTV 2.0 Software Platform] and ETRI. 482 This document has greatly benefited from inputs by Jinyong Kim, Mahdi 483 Daghmehchir-Firoozjaei, and Geumhwan Cho. 485 10. References 487 10.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to 490 Indicate Requirement Levels", BCP 14, 491 RFC 2119, March 1997. 493 [i2nsf-framework] Lopez, E., Lopez, D., Dunbar, L., Zhuang, X., 494 Parrott, J., Krishnan, R., and S. Durbha, 495 "Framework for Interface to Network Security 496 Functions", draft-merged-i2nsf-framework-02 , 497 June 2015. 499 10.2. Informative References 501 [RFC7149] Boucadair, M. and C. Jacquenet, "Software- 502 Defined Networking: A Perspective from within 503 a Service Provider Environment", RFC 7149, 504 March 2014. 506 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., 507 and A. Bierman, "Network Configuration 508 Protocol (NETCONF)", RFC 6241, June 2011. 510 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 511 Language for the Network Configuration 512 Protocol (NETCONF)", RFC 6020, October 2010. 514 [ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of 515 Software-Defined Networking", June 2014. 517 [ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. 519 [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 520 1.4.0)", October 2013. 522 [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline 523 Identity Management Terms and Definitions", 524 April 2010. 526 [ITU-T.X.800] Recommendation ITU-T X.800, "Security 527 Architecture for Open Systems Interconnection 528 for CCITT Applications", March 1991. 530 [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and G. 531 Gu, "AVANT-GUARD: Scalable and Vigilant 532 Switch Flow Management in Software-Defined 533 Networks", ACM CCS, November 2013. 535 [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions 536 Virtualisation (NFV); Architectural 537 Framework", October 2013. 539 Authors' Addresses 541 Jaehoon Paul Jeong 542 Department of Software 543 Sungkyunkwan University 544 2066 Seobu-Ro, Jangan-Gu 545 Suwon, Gyeonggi-Do 440-746 546 Republic of Korea 548 Phone: +82 31 299 4957 549 Fax: +82 31 290 7996 550 EMail: pauljeong@skku.edu 551 URI: http://cpslab.skku.edu/people-jaehoon-jeong.php 552 Hyoungshick Kim 553 Department of Software 554 Sungkyunkwan University 555 2066 Seobu-Ro, Jangan-Gu 556 Suwon, Gyeonggi-Do 440-746 557 Republic of Korea 559 Phone: +82 31 299 4324 560 Fax: +82 31 290 7996 561 EMail: hyoung@skku.edu 562 URI: http://seclab.skku.edu/people/hyoungshick-kim/ 564 Jung-Soo Park 565 Electronics and Telecommunications Research Institute 566 218 Gajeong-Ro, Yuseong-Gu 567 Daejeon, 305-700 568 Republic of Korea 570 Phone: +82 42 860 6514 571 EMail: pjs@etri.re.kr