idnits 2.17.1 draft-ietf-i2nsf-applicability-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 date (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Informational S. Hyun 5 Expires: January 3, 2019 Chosun University 6 T. Ahn 7 Korea Telecom 8 S. Hares 9 Huawei 10 D. Lopez 11 Telefonica I+D 12 July 2, 2018 14 Applicability of Interfaces to Network Security Functions to Network- 15 Based Security Services 16 draft-ietf-i2nsf-applicability-03 18 Abstract 20 This document describes the applicability of Interface to Network 21 Security Functions (I2NSF) to network-based security services in 22 Network Functions Virtualization (NFV) environments, such as 23 firewall, deep packet inspection, or attack mitigation engines. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Time-dependent Web Access Control Service . . . . . . . . 5 63 4. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7 64 5. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9 65 5.1. Firewall: Centralized Firewall System . . . . . . . . . . 11 66 5.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security 67 System . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.3. Attack Mitigation: Centralized DDoS-attack Mitigation 69 System . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 74 10. Informative References . . . . . . . . . . . . . . . . . . . 19 75 Appendix A. Changes from draft-ietf-i2nsf-applicability-02 . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 78 1. Introduction 80 Interface to Network Security Functions (I2NSF) defined a framework 81 and interfaces for interacting with Network Security Functions 82 (NSFs). The I2NSF framework allows heterogeneous NSFs developed by 83 different security solution vendors to be used in the NFV environment 84 by utilizing the capabilities of such products and the virtualization 85 of security functions in the NFV platform. In the I2NSF framework, 86 each NSF initially registers the profile of its own capabilities into 87 the system in order for themselves to be available in the system. In 88 addition, the Security Controller registers itself to the I2NSF user 89 so that the user can request security services to the Security 90 Controller. 92 This document describes the applicability of I2NSF framework to 93 network-based security services with a use case of time-dependent web 94 access control. This document also describes integrating I2NSF 95 framework with Software-Defined Networking (SDN) technology for 96 efficient security services and use cases, such as firewall 98 [opsawg-firewalls], Deep Packet Inspection (DPI), and Distributed 99 Denial of Service (DDoS) attack mitigation. We implemented the I2NSF 100 framework based on SDN for these use cases, and the implementation 101 successfully verified the effectiveness of the I2NSF framework. 103 2. Terminology 105 This document uses the terminology described in [RFC7149], 106 [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], 107 [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology], 108 [consumer-facing-inf-im], [consumer-facing-inf-dm], 109 [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-im], 110 [registration-inf-dm], and [nsf-triggered-steering]. In addition, 111 the following terms are defined below: 113 o Software-Defined Networking (SDN): A set of techniques that 114 enables to directly program, orchestrate, control, and manage 115 network resources, which facilitates the design, delivery and 116 operation of network services in a dynamic and scalable manner 117 [ITU-T.Y.3300]. 119 o Firewall: A service function at the junction of two network 120 segments that inspects every packet that attempts to cross the 121 boundary. It also rejects any packet that does not satisfy 122 certain criteria for, for example, disallowed port numbers or IP 123 addresses. 125 o Centralized Firewall System: A centralized firewall that can 126 establish and distribute policy rules into network resources for 127 efficient firewall management. These rules can be managed 128 dynamically by a centralized server for firewall. SDN can work as 129 a network-based firewall system through a standard interface 130 between an SDN switch and a firewall function as a vitual network 131 function (VNF). 133 o Centralized VoIP Security System: A centralized security system 134 that handles the security functions required for VoIP and VoLTE 135 services. SDN can work as a network-based security system through 136 a standard interface between an SDN switch and a VoIP/VoLTE 137 security function as a VNF. 139 o Centralized DDoS-attack Mitigation System: A centralized mitigator 140 that can establish and distribute access control policy rules into 141 network resources for efficient DDoS-attack mitigation. These 142 rules can be managed dynamically by a centralized server for DDoS- 143 attack mitigation. The SDN controller and switches can 144 cooperatively work as a network-based firewall system through a 145 standard interface between an SDN switch and a firewall function 146 as a VNF running in the SDN controller. 148 3. I2NSF Framework 150 This section describes an I2NSF framework and its use case. Figure 1 151 shows an I2NSF framework [RFC8329] to support network-based security 152 services. As shown in Figure 1, I2NSF User can use security 153 functions by delivering high-level security policies, which specify 154 security requirements the I2NSF user wants to enforce, to the 155 Security Controller via the Consumer-Facing Interface 156 [consumer-facing-inf-im][consumer-facing-inf-dm]. 158 The Security Controller receives and analyzes the high-level security 159 policies from an I2NSF User, and identifies what types of security 160 capabilities are required to meet these high-level security policies. 161 The Security Controller then identifies NSFs that have the required 162 security capabilities, and generates low-level security policies for 163 each of the NSFs so that the high-level security policies are 164 eventually enforced by those NSFs. Finally, the Security Controller 165 sends the generated low-level security policies to the NSFs 166 [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. 168 The Security Controller requests NSFs to perform low-level security 169 services via the NSF-Facing Interface. The NSFs are enabled as 170 Virtual Network Functions (VNFs) on top of virtual machines through 171 Network Functions Virtualization (NFV) [ETSI-NFV]. In addition, the 172 Security Controller uses the I2NSF Registration Interface 173 [registration-inf-im][registration-inf-dm] to communicate with 174 Developer's Management System (called Developer's Mgmt System) for 175 registering (or deregistering) the developer's NSFs into (or from) 176 the NFV system using the I2NSF framework. 178 The Consumer-Facing Interface between an I2NSF User and the Security 179 Controller can be implemented using, for example, RESTCONF [RFC8040]. 180 Data models specified by YANG [RFC6020] describe high-level security 181 policies to be specified by an I2NSF User. The data model defined in 182 [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing 183 Interface. 185 +------------+ 186 | I2NSF User | 187 +------------+ 188 ^ 189 | Consumer-Facing Interface 190 v 191 +-------------------+ Registration +-----------------------+ 192 |Security Controller|<-------------------->|Developer's Mgmt System| 193 +-------------------+ Interface +-----------------------+ 194 ^ 195 | NSF-Facing Interface 196 v 197 +----------------+ +---------------+ +-----------------------+ 198 | NSF-1 |-| NSF-2 |...| NSF-n | 199 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 200 +----------------+ +---------------+ +-----------------------+ 202 Figure 1: I2NSF Framework 204 The NSF-Facing Interface between Security Controller and NSFs can be 205 implemented using NETCONF [RFC6241]. YANG data models describe low- 206 level security policies for the sake of NSFs, which are translated 207 from the high-level security policies by the Security Controller. 208 The data model defined in [nsf-facing-inf-dm] can be used for the 209 I2NSF NSF-Facing Interface. 211 The Registration Interface between the Security Controller and the 212 Developer's Mgmt System can be implemented by RESTCONF [RFC8040]. 213 The data model defined in [registration-inf-dm] can be used for the 214 I2NSF Registration Interface. 216 Also, the I2NSF framework can enforce multiple chained NSFs for the 217 low-level security policies by means of service function chaining 218 (SFC) techniques for the I2NSF architecture described in 219 [nsf-triggered-steering]. 221 The following describes a security service scenario using the I2NSF 222 framework. 224 3.1. Time-dependent Web Access Control Service 226 This service scenario assumes that an enterprise network 227 administrator wants to control the staff members' access to Facebook 228 during business hours. The following is an example high-level 229 security policy rule that the administrator requests: Block the staff 230 members' access to Facebook from 9 am to 6 pm. The administrator 231 sends this high-level security policy to the security controller, 232 then the security controller identifies required secuity 233 capabilities, e.g., IP address and port number inspection 234 capabilities and URL inspection capability. In this scenario, it is 235 assumed that the IP address and port number inspection capabilities 236 are required to check whether a received packet is an HTTP packet 237 from a staff member. The URL inspection capability is required to 238 check whether the target URL of a received packet is facebook.com or 239 not. 241 The Security Controller maintains the security capabilities of each 242 NSF running in the I2NSF system, which have been reported by the 243 Developer's Management System via the Registation interface. Based 244 on this information, the Security Controller identifies NSFs that can 245 perform the IP address and port number inspection and URL inspection. 246 In this scenario, it is assumed that an NSF of firewall has the IP 247 address and port number inspection capabilities and an NSF of web 248 filter has URL inspection capability. 250 The Security Controller generates low-level security rules for the 251 NSFs to perform IP address and port number inspection, URL 252 inspection, and time checking. Specifically, the Security Controller 253 may interoperate with an access control server in the enterprise 254 network in order to retrieve the information (e.g., IP address in 255 use, company identifier (ID), and role) of each employee that is 256 currently using the network. Based on the retrieved information, the 257 Security Controller generates low-level security rules to check 258 whether the source IP address of a received packet matches any one 259 being used by a staff member. In addition, the low-level security 260 rules should be able to determine that a received packet is of HTTP 261 protocol. The low-level security rules for web filter checks that 262 the target URL field of a received packet is equal to facebook.com. 263 Finally, the Security Controller sends the low-level security rules 264 of the IP address and port number inspection to the NSF of firewall 265 and the low-level rules for URL inspection to the NSF of web filter. 267 The following describes how the time-dependent web access control 268 service is enforced by the NSFs of firewall and web filter. 270 1. A staff member tries to access Fackbook.com during business 271 hours, e.g., 10 am. 273 2. The packet is forwarded from the staff member's device to the 274 firewall, and the firewall checks the source IP address and port 275 number. Now the firewall identifies the received packet is an 276 HTTP packet from the staff member. 278 3. The firewall triggers the web filter to further inspect the 279 packet, and the packet is forwarded from the firewall to the web 280 filter. Service Function Chaining (SFC) technology can be 281 utilized to support such packet forwarding in the I2NSF framework 282 [nsf-triggered-steering]. 284 4. The web filter checks the target URL field of the received 285 packet, and realizes the packet is toward Facebook.com. The web 286 filter then checks that the current time is in business hours. 287 If so, the web filter drops the packet, and consequently the 288 staff member's access to Facebook during business hours is 289 blocked. 291 4. I2NSF Framework with SFC 293 In the I2NSF architecture, an NSF can trigger an advanced security 294 action (e.g., DPI and DDoS attack mitigation) on a packet based on 295 the result of its own security inspection of the packet. For 296 example, a firewall triggers further inspection of a suspicious 297 packet with DPI. For this advanced security action to be fulfilled, 298 the suspicious packet should be forwarded from the current NSF to the 299 successor NSF. Service Function Chaining (SFC) [RFC7665] is a 300 technology that enables this advanced security action by steering a 301 packet with multiple service functions (e.g., NSFs), and this 302 technology can be utilized by the I2NSF architecture to support the 303 advanced security action. 305 SFC generally requires classifiers and service function forwarders 306 (SFFs); classifiers are responsible for determining which service 307 function path (SFP) (i.e., an ordered sequence of service functions) 308 a given packet should pass through, according to pre-configured 309 classification rules, and SFFs perform forwarding the given packet to 310 the next service function (e.g., NSF) on the SFP of the packet by 311 referring to their forwarding tables. In the I2NSF architecture with 312 SFC, the security controller can take responsibilities of generating 313 classification rules for classifiers and forwarding tables for SFFs. 314 In particular, by analyzing high-level security policies from I2NSF 315 users, the security controller can construct SFPs that are required 316 to meet the high-level security policies, generates classification 317 rules of the SFPs, and then configures classifiers with the 318 classification rules so that relevant traffic packets can follow the 319 SFPs. Also, based on the global view of NSF instances available in 320 the system, the security controller can construct forwarding tables 321 required for SFFs to forward a given packet to the next NSF over the 322 SFP. 324 +------------+ 325 | I2NSF User | 326 +------------+ 327 ^ 328 | Consumer-Facing Interface 329 v 330 +-------------------+ Registration +-----------------------+ 331 |Security Controller|<-------------------->|Developer's Mgmt System| 332 +-------------------+ Interface +-----------------------+ 333 ^ ^ 334 | | NSF-Facing Interface 335 | |------------------------- 336 | | 337 +-+-+-v-+-+-+-+-+-+ +------v-------+ 338 | +-----------+ | ------>| NSF-1 | 339 | |Classifier | | | | (Firewall) | 340 | +-----------+ | | +--------------+ 341 | +-----+ |<-----| +--------------+ 342 | | SFF | | |----->| NSF-2 | 343 | +-----+ | | | (DPI) | 344 +-+-+-+-+-+-+-+-+-+ | +--------------+ 345 | . 346 | . 347 | . 348 | +-----------------------+ 349 ------>| NSF-n | 350 |(DDoS-Attack Mitigator)| 351 +-----------------------+ 353 Figure 2: An I2NSF Framework with SFC 355 To trigger an advanced security action in the I2NSF architecture, the 356 current NSF appends a metadata describing the security capability 357 required for the advanced action to the suspicious packet and sends 358 the packet to the classifier. Based on the metadata information, the 359 classifier searches an SFP which includes an NSF with the required 360 security capability, changes the SFP-related information (e.g., 361 service path identifier and service index [RFC8300]) of the packet 362 with the new SFP that has been found, and then forwards the packet to 363 the SFF. When receiving the packet, the SFF checks the SFP-related 364 information such as the service path identifier and service index 365 contained in the packet and forwards the packet to the next NSF on 366 the SFP of the packet, according to its forwarding table. 368 5. I2NSF Framework with SDN 370 This section describes an I2NSF framework with SDN for I2NSF 371 applicability and use cases, such as firewall, deep packet 372 inspection, and DDoS-attack mitigation functions. SDN enables some 373 packet filtering rules to be enforced in the network switches by 374 controlling their packet forwarding rules. By taking advantage of 375 this capability of SDN, it is possible to optimize the process of 376 security service enforcement in the I2NSF system. 378 Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to 379 support network-based security services. In this system, the 380 enforcement of security policy rules is divided into the SDN switches 381 and NSFs. Especially, SDN switches enforce simple packet filtering 382 rules that can be translated into their packet forwarding rules, 383 whereas NSFs enforce NSF-related security rules requiring the 384 security capabilities of the NSFs. For this purpose, the Security 385 Controller instructs the Switch Controller via NSF-Facing Interface 386 so that SDN switches can perform the required security services with 387 flow tables under the supervision of the Switch Controller (i.e., SDN 388 Controller). 390 As an example, let us consider two different types of security rules: 391 Rule A is a simple packet fltering rule that checks only the IP 392 address and port number of a given packet, whereas rule B is a time- 393 consuming packet inspection rule for analyzing whether an attached 394 file being transmitted over a flow of packets contains malware. Rule 395 A can be translated into packet forwarding rules of SDN switches and 396 thus be enforced by the switches. In contrast, rule B cannot be 397 enforced by switches, but it can be enforced by NSFs with anti- 398 malware capability. Specifically, a flow of packets is forwarded to 399 and reassembled by an NSF to reconstruct the attached file stored in 400 the flow of packets. The NSF then analyzes the file to check the 401 existence of malware. If the file contains malware, the NSF drops 402 the packets. 404 In an I2NSF framework with SDN, the Security Controller can analyze 405 given security policy rules and automatically determine which of the 406 given security policy rules should be enforced by SDN switches and 407 which should be enforced by NSFs. If some of the given rules 408 requires security capabilities that can be provided by SDN switches, 409 then the Security Controller instructs the Switch Controller via NSF- 410 Facing Interface so that SDN switches can enforce those security 411 policy rules with flow tables under the supervision of the Switch 412 Controller (i.e., SDN Controller). Or if some rules require security 413 capabilities that can be provided by not SDN switches but NSFs, then 414 the Security Controller instructs relevant NSFs to enforce those 415 rules. 417 +------------+ 418 | I2NSF User | 419 +------------+ 420 ^ 421 | Consumer-Facing Interface 422 v 423 +-------------------+ Registration +-----------------------+ 424 |Security Controller|<-------------------->|Developer's Mgmt System| 425 +-------------------+ Interface +-----------------------+ 426 ^ ^ 427 | | NSF-Facing Interface 428 | v 429 | +----------------+ +---------------+ +-----------------------+ 430 | | NSF-1 |-| NSF-2 |...| NSF-n | 431 | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| 432 | +----------------+ +---------------+ +-----------------------+ 433 | ^ 434 | | 435 | v 436 | +--------+ 437 | | SFF | 438 | +--------+ 439 | ^ 440 | | 441 | V SDN Network 442 +--|----------------------------------------------------------------+ 443 | V NSF-Facing Interface | 444 | +-----------------+ | 445 | |Switch Controller| | 446 | +-----------------+ | 447 | ^ | 448 | | SDN Southbound Interface | 449 | v | 450 | +--------+ +--------+ +--------+ +--------+ | 451 | |Switch 1|-|Switch 2|-|Switch 3|......|Switch m| | 452 | +--------+ +--------+ +--------+ +--------+ | 453 +-------------------------------------------------------------------+ 455 Figure 3: An I2NSF Framework with SDN Network 457 The following subsections introduce three use cases for cloud-based 458 security services: (i) firewall system, (ii) deep packet inspection 459 system, and (iii) attack mitigation system. [RFC8192] 461 5.1. Firewall: Centralized Firewall System 463 A centralized network firewall can manage each network resource and 464 firewall rules can be managed flexibly by a centralized server for 465 firewall (called Firewall). The centralized network firewall 466 controls each switch for the network resource management and the 467 firewall rules can be added or deleted dynamically. 469 The procedure of firewall operations in this system is as follows: 471 1. A switch forwards an unknown flow's packet to one of the Switch 472 Controllers. 474 2. The Switch Controller forwards the unknown flow's packet to an 475 appropriate security service application, such as the Firewall. 477 3. The Firewall analyzes, typically, the headers and contents of the 478 packet. 480 4. If the Firewall regards the packet as a malicious one with a 481 suspicious pattern, it reports the malicious packet to the Switch 482 Controller. 484 5. The Switch Controller installs new rules (e.g., drop packets with 485 the suspicious pattern) into underlying switches. 487 6. The suspected packets are dropped by these switches. 489 Existing SDN protocols can be used through standard interfaces 490 between the firewall application and switches 491 [RFC7149][ITU-T.Y.3300][ONF-OpenFlow] [ONF-SDN-Architecture]. 493 Legacy firewalls have some challenges such as the expensive cost, 494 performance, management of access control, establishment of policy, 495 and packet-based access mechanism. The proposed framework can 496 resolve the challenges through the above centralized firewall system 497 based on SDN as follows: 499 o Cost: The cost of adding firewalls to network resources such as 500 routers, gateways, and switches is substantial due to the reason 501 that we need to add firewall on each network resource. To solve 502 this, each network resource can be managed centrally such that a 503 single firewall is manipulated by a centralized server. 505 o Performance: The performance of firewalls is often slower than the 506 link speed of network interfaces. Every network resource for 507 firewall needs to check firewall rules according to network 508 conditions. Firewalls can be adaptively deployed among network 509 switches, depending on network conditions in the framework. 511 o The management of access control: Since there may be hundreds of 512 network resources in a network, the dynamic management of access 513 control for security services like firewall is a challenge. In 514 the framework, firewall rules can be dynamically added for new 515 malware. 517 o The establishment of policy: Policy should be established for each 518 network resource. However, it is difficult to describe what flows 519 are permitted or denied for firewall within a specific 520 organization network under management. Thus, a centralized view 521 is helpful to determine security policies for such a network. 523 o Packet-based access mechanism: Packet-based access mechanism is 524 not enough for firewall in practice since the basic unit of access 525 control is usually users or applications. Therefore, application 526 level rules can be defined and added to the firewall system 527 through the centralized server. 529 5.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 531 A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE 532 flow and manage VoIP/VoLTE security rules controlled by a centralized 533 server for VoIP/VoLTE security service called VoIP Intrusion 534 Prevention System (IPS). The VoIP/VoLTE security system controls 535 each switch for the VoIP/VoLTE call flow management by manipulating 536 the rules that can be added, deleted or modified dynamically. 538 A centralized VoIP/VoLTE security system can cooperate with a network 539 firewall to realize VoIP/VoLTE security service. Specifically, a 540 network firewall performs basic security checks of an unknown flow's 541 packet observed by a switch. If the network firewall detects that 542 the packet is an unknown VoIP call flow's packet that exhibits some 543 suspicious patterns, then it triggers the VoIP/VoLTE security system 544 for more specialized security analysis of the suspicious VoIP call 545 packet. 547 The procedure of VoIP/VoLTE security operations in this system is as 548 follows: 550 1. A switch forwards an unknown flow's packet to the Switch 551 Controller, and the Switch Controller further forwards the 552 unknown flow's packet to the Firewall for basic security 553 inspection. 555 2. The Firewall analyzes the header fields of the packet, and 556 figures out that this is an unknown VoIP call flow's signal 557 packet (e.g., SIP packet) of a suspicious pattern. 559 3. The Firewall triggers an appropriate security service function, 560 such as VoIP IPS, for detailed security analysis of the 561 suspicious signal packet. That is, the firewall sends the packet 562 to the Service Function Forwarder (SFF) in the I2NSF framework 563 [nsf-triggered-steering], as shown in Figure 3. The SFF forwards 564 the suspicious signal packet to the VoIP IPS. 566 4. The VoIP IPS analyzes the headers and contents of the signal 567 packet, such as calling number and session description headers 568 [RFC4566]. 570 5. If, for example, the VoIP IPS regards the packet as a spoofed 571 packet by hackers or a scanning packet searching for VoIP/VoLTE 572 devices, it drops the packet. In addition, the VoIP IPS requests 573 the Switch Controller to block that packet and the subsequent 574 packets that have the same call-id. 576 6. The Switch Controller installs new rules (e.g., drop packets) 577 into underlying switches. 579 7. The illegal packets are dropped by these switches. 581 Existing SDN protocols can be used through standard interfaces 582 between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] 583 [ONF-OpenFlow][ONF-SDN-Architecture]. 585 Legacy hardware based VoIP IPS has some challenges, such as 586 provisioning time, the granularity of security, expensive cost, and 587 the establishment of policy. The I2NSF framework can resolve the 588 challenges through the above centralized VoIP/VoLTE security system 589 based on SDN as follows: 591 o Provisioning: The provisioning time of setting up a legacy VoIP 592 IPS to network is substantial because it takes from some hours to 593 some days. By managing the network resources centrally, VoIP IPS 594 can provide more agility in provisioning both virtual and physical 595 network resources from a central location. 597 o The granularity of security: The security rules of a legacy VoIP 598 IPS are compounded considering the granularity of security. The 599 proposed framework can provide more granular security by 600 centralizing security control into a switch controller. The VoIP 601 IPS can effectively manage security rules throughout the network. 603 o Cost: The cost of adding VoIP IPS to network resources, such as 604 routers, gateways, and switches is substantial due to the reason 605 that we need to add VoIP IPS on each network resource. To solve 606 this, each network resource can be managed centrally such that a 607 single VoIP IPS is manipulated by a centralized server. 609 o The establishment of policy: Policy should be established for each 610 network resource. However, it is difficult to describe what flows 611 are permitted or denied for VoIP IPS within a specific 612 organization network under management. Thus, a centralized view 613 is helpful to determine security policies for such a network. 615 5.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 617 A centralized DDoS-attack mitigation can manage each network resource 618 and manipulate rules to each switch through a centralized server for 619 DDoS-attack mitigation (called DDoS-attack Mitigator). The 620 centralized DDoS-attack mitigation system defends servers against 621 DDoS attacks outside private network, that is, from public network. 623 Servers are categorized into stateless servers (e.g., DNS servers) 624 and stateful servers (e.g., web servers). For DDoS-attack 625 mitigation, traffic flows in switches are dynamically configured by 626 traffic flow forwarding path management according to the category of 627 servers [AVANT-GUARD]. Such a managenent should consider the load 628 balance among the switches for the defense against DDoS attacks. 630 The procedure of DDoS-attack mitigation operations in this system is 631 as follows: 633 1. A Switch periodically reports an inter-arrival pattern of a 634 flow's packets to one of the Switch Controllers. 636 2. The Switch Controller forwards the flow's inter-arrival pattern 637 to an appropriate security service application, such as DDoS- 638 attack Mitigator. 640 3. The DDoS-attack Mitigator analyzes the reported pattern for the 641 flow. 643 4. If the DDoS-attack Mitigator regards the pattern as a DDoS 644 attack, it computes a packet dropping probability corresponding 645 to suspiciousness level and reports this DDoS-attack flow to 646 Switch Controller. 648 5. The Switch Controller installs new rules into switches (e.g., 649 forward packets with the suspicious inter-arrival pattern with a 650 dropping probability). 652 6. The suspicious flow's packets are randomly dropped by switches 653 with the dropping probability. 655 For the above centralized DDoS-attack mitigation system, the existing 656 SDN protocols can be used through standard interfaces between the 657 DDoS-attack mitigator application and switches [RFC7149] 658 [ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture]. 660 The centralized DDoS-attack mitigation system has challenges similar 661 to the centralized firewall system. The proposed framework can 662 resolve the challenges through the above centralized DDoS-attack 663 mitigation system based on SDN as follows: 665 o Cost: The cost of adding DDoS-attack mitigators to network 666 resources such as routers, gateways, and switches is substantial 667 due to the reason that we need to add DDoS-attack mitigator on 668 each network resource. To solve this, each network resource can 669 be managed centrally such that a single DDoS-attack mitigator is 670 manipulated by a centralized server. 672 o Performance: The performance of DDoS-attack mitigators is often 673 slower than the link speed of network interfaces. The checking of 674 DDoS attacks may reduce the performance of the network interfaces. 675 DDoS-attack mitigators can be adaptively deployed among network 676 switches, depending on network conditions in the framework. 678 o The management of network resources: Since there may be hundreds 679 of network resources in an administered network, the dynamic 680 management of network resources for performance (e.g., load 681 balancing) is a challenge for DDoS-attack mitigation. In the 682 framework, as dynamic network resource management, traffic flow 683 forwarding path management can handle the load balancing of 684 network switches [AVANT-GUARD]. With this management, the current 685 and near-future workload can be spread among the network switches 686 for DDoS-attack mitigation. In addition, DDoS-attack mitigation 687 rules can be dynamically added for new DDoS attacks. 689 o The establishment of policy: Policy should be established for each 690 network resource. However, it is difficult to describe what flows 691 are permitted or denied for new DDoS-attacks (e.g., DNS reflection 692 attack) within a specific organization network under management. 693 Thus, a centralized view is helpful to determine security policies 694 for such a network. 696 So far this document has described the procedure and impact of the 697 three use cases for network-based security services using the I2NSF 698 framework with SDN networks. To support these use cases in the 699 proposed data-driven security service framework, YANG data models 700 described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and 701 [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- 702 Facing Interface, and Registration Interface, respectively, along 703 with RESTCONF [RFC8040] and NETCONF [RFC6241]. 705 6. I2NSF Framework with NFV 707 This section discusses the implementation of the I2NSF framework with 708 Network Functions Virtualization (called NFV). 710 +--------------------+ 711 +-------------------------------------------+ | ---------------- | 712 | I2NSF User (OSS/BSS) | | | NFV | | 713 +------+------------------------------------+ | | Orchestrator +-+ | 714 | Consumer-Facing Interface | ---+------------ | | 715 +------|------------------------------------+ | | | | 716 | ----+-------------------------------- | | | | | 717 | | Security Controller(EM) | | | | | | 718 | ----+-------------+-------------+---- | | ---+---------- | | 719 | | NSF-Facing Interface | |(a)-| Developer's| | | 720 | ----+---- ----+---- ----+---- | | Mgmt System| | | 721 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| |(b)-| (VNFM) | | | 722 | ----+---- ----+---- ----+---- | | ---+---------- | | 723 | | | | | | | | | 724 +------|-------------|-------------|--------+ | | | | 725 | | | | | | | 726 +------+-------------+-------------+--------+ | | | | 727 | NFV Infrastructure (NFVI) | | | | | 728 | ----------- ----------- ----------- | | | | | 729 | | Virtual | | Virtual | | Virtual | | | | | | 730 | | Compute | | Storage | | Network | | | | | | 731 | ----------- ----------- ----------- | | ---+------ | | 732 | +---------------------------------------+ | | | | | | 733 | | Virtualization Layer | |--|-| VIM(s) +-------- | 734 | +---------------------------------------+ | | | | | 735 | +---------------------------------------+ | | ---------- | 736 | | ----------- ----------- ----------- | | | | 737 | | | Compute | | Storage | | Network | | | | | 738 | | | hardware| | hardware| | hardware| | | | | 739 | | ----------- ----------- ----------- | | | | 740 | | Hardware resources | | | NFV Management | 741 | +---------------------------------------+ | | and Orchestration | 742 +-------------------------------------------+ +--------------------+ 743 (a) = Registration Interface 744 (b) = Ve-Vnfm Interface 746 Figure 4: I2NSF Framework Implementation in NFV Reference 747 Architectural Framework 749 NFV is a promising technology for improving the elasticity and 750 efficiency of network resource utilization. In NFV environments, 751 NSFs can be deployed in the forms of software-based virtual instances 752 rather than physical appliances. Virtualizing NSFs makes it possible 753 to rapidly and flexibly respond to the amount of service requests by 754 dynamically increasing or decreasing the number of NSF instances. 755 Moreover, NFV technology facilitates flexibly including or excluding 756 NSFs from multiple security solution vendors according to the changes 757 on security requirements. In order to take advantages of the NFV 758 technology, the I2NSF framework can be implemented on top of an NFV 759 infrastructure as show in Figure 4. 761 Figure 4 shows an I2NSF framework implementation based on the NFV 762 reference architecture that the European Telecommunications Standards 763 Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as 764 virtual network functions (VNFs) in Figure 4. The Developer's 765 Management System in the I2NSF framework is responsible for creating 766 or removing NSF instances, and can be implemented as the virtual 767 network functions manager (VNFM) in the NFV architecture that 768 performs the life-cycle management of VNFs. The Security Controller 769 can be implemented as the Element Management (EM) in the NFV 770 architecture that controls and monitors the configurations (e.g., 771 function parameters and security policy rules) of VNFs. Finally, the 772 I2NSF User can be implemented as OSS/BSS (Operational Support 773 Systems/Business Support Systems) in the NFV architecture that 774 provides interfaces for users in the NFV system. 776 The operation procedure in the I2NSF framework based on the NFV 777 architecture is as follows: 779 1. The Developer's Mgmt System (DMS) has a set of virtual machine 780 (VM) images of NSFs, and each VM image can be used to create an 781 NSF instance that provides a set of security capabilities. The 782 DMS initially registers a mapping table of the ID of each VM 783 image and the set of capabilities that can be provided by an NSF 784 instance created from the VM image into the Security Controller. 786 2. If the Security Controller does not have any instantiated NSF 787 that has the set of capabilities required to meet the security 788 requirements from users, it searches the mapping table 789 (registered by the DMS) for the VM image ID corresponding to the 790 required set of capabilities. 792 3. The Security Controller requests the DMS to instantiate an NSF 793 with the VM image ID. 795 4. When receiving the instantiation request, the DMS first asks the 796 NFV orchestrator for the permission required to create the NSF 797 instance, requests the VIM to allocate resources for the NSF 798 instance, and finally creates the NSF instance based on the 799 allocated resources. 801 5. Once the NSF instance has been created, the DMS performs the 802 initial configurations of the NSF instance and then notifies the 803 Security Controller of the NSF instance. 805 6. After being notified of the created NSF instance, the Security 806 Controller delivers low-level security policy rules to the NSF 807 instance for policy enforcement. 809 The I2NSF framework can be implemented based on the NFV architecture. 810 Note that the registration of the capabilities of NSFs is performed 811 through the Registration Interface and the life-cycle management for 812 NSFs (VNFs) is performed through the Ve-Vnfm interface, as shown in 813 Figure 4. More details about the I2NSF framework based on the NFV 814 reference architecture are described in [i2nsf-nfv-architecture]. 816 7. Security Considerations 818 The I2NSF framework with SDN networks in this document is derived 819 from the I2NSF framework [RFC8329], so the security considerations of 820 the I2NSF framework should be included in this document. Therefore, 821 proper secure communication channels should be used the delivery of 822 control or management messages among the components in the proposed 823 framework. 825 This document shares all the security issues of SDN that are 826 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 828 8. Acknowledgments 830 This work was supported by Institute for Information & communications 831 Technology Promotion (IITP) grant funded by the Korea government 832 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 833 Technology Development for the Customized Security Service 834 Provisioning). 836 9. Contributors 838 I2NSF is a group effort. I2NSF has had a number of contributing 839 authors. The following are considered co-authors: 841 o Hyoungshick Kim (Sungkyunkwan University) 843 o Jinyong Tim Kim (Sungkyunkwan University) 844 o Hyunsik Yang (Soongsil University) 846 o Younghan Kim (Soongsil University) 848 o Jung-Soo Park (ETRI) 850 o Se-Hui Lee (Korea Telecom) 852 o Mohamed Boucadair (Orange) 854 10. Informative References 856 [AVANT-GUARD] 857 Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- 858 GUARD: Scalable and Vigilant Switch Flow Management in 859 Software-Defined Networks", ACM CCS, November 2013. 861 [consumer-facing-inf-dm] 862 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 863 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 864 ietf-i2nsf-consumer-facing-interface-dm-01 (work in 865 progress), July 2018. 867 [consumer-facing-inf-im] 868 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 869 S., Xia, L., and J. Jeong, "Information Model for 870 Consumer-Facing Interface to Security Controller", draft- 871 kumar-i2nsf-client-facing-interface-im-06 (work in 872 progress), July 2018. 874 [ETSI-NFV] 875 ETSI GS NFV 002 V1.1.1, "Network Functions Virtualization 876 (NFV); Architectural Framework", October 2013. 878 [i2nsf-nfv-architecture] 879 Yang, H. and Y. Kim, "I2NSF on the NFV Reference 880 Architecture", draft-yang-i2nsf-nfv-architecture-02 (work 881 in progress), June 2018. 883 [i2nsf-nsf-cap-im] 884 Xia, L., Strassner, J., Basile, C., and D. Lopez, 885 "Information Model of NSFs Capabilities", draft-ietf- 886 i2nsf-capability-02 (work in progress), July 2018. 888 [i2nsf-terminology] 889 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 890 Birkholz, "Interface to Network Security Functions (I2NSF) 891 Terminology", draft-ietf-i2nsf-terminology-05 (work in 892 progress), January 2018. 894 [ITU-T.X.1252] 895 Recommendation ITU-T X.1252, "Baseline Identity Management 896 Terms and Definitions", April 2010. 898 [ITU-T.X.800] 899 Recommendation ITU-T X.800, "Security Architecture for 900 Open Systems Interconnection for CCITT Applications", 901 March 1991. 903 [ITU-T.Y.3300] 904 Recommendation ITU-T Y.3300, "Framework of Software- 905 Defined Networking", June 2014. 907 [nsf-facing-inf-dm] 908 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 909 "I2NSF Network Security Function-Facing Interface YANG 910 Data Model", draft-ietf-i2nsf-nsf-facing-interface-data- 911 model-01 (work in progress), July 2018. 913 [nsf-triggered-steering] 914 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 915 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 916 i2nsf-nsf-triggered-steering-06 (work in progress), July 917 2018. 919 [ONF-OpenFlow] 920 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 921 October 2013. 923 [ONF-SDN-Architecture] 924 ONF, "SDN Architecture", June 2014. 926 [opsawg-firewalls] 927 Baker, F. and P. Hoffman, "On Firewalls in Internet 928 Security", draft-ietf-opsawg-firewalls-01 (work in 929 progress), October 2012. 931 [registration-inf-dm] 932 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 933 Registration Interface YANG Data Model", draft-hyun-i2nsf- 934 registration-dm-04 (work in progress), July 2018. 936 [registration-inf-im] 937 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 938 Registration Interface Information Model", draft-hyun- 939 i2nsf-registration-interface-im-05 (work in progress), 940 July 2018. 942 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 943 Description Protocol", RFC 4566, July 2006. 945 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 946 Network Configuration Protocol (NETCONF)", RFC 6020, 947 October 2010. 949 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 950 Bierman, "Network Configuration Protocol (NETCONF)", 951 RFC 6241, June 2011. 953 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 954 Networking: A Perspective from within a Service Provider 955 Environment", RFC 7149, March 2014. 957 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 958 (SFC) Architecture", RFC 7665, October 2015. 960 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 961 Protocol", RFC 8040, January 2017. 963 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 964 and J. Jeong, "Interface to Network Security Functions 965 (I2NSF): Problem Statement and Use Cases", RFC 8192, July 966 2017. 968 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 969 Header (NSH)", RFC 8300, January 2018. 971 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 972 Kumar, "Framework for Interface to Network Security 973 Functions", RFC 8329, February 2018. 975 Appendix A. Changes from draft-ietf-i2nsf-applicability-02 977 The following changes have been made from draft-ietf-i2nsf- 978 applicability-02: 980 o In Section 4, it is explained how the I2NSF framework and SFC can 981 be combined to support chaining NSFs. 983 o In Section 6, it is explained how the I2NSF framework can be 984 implemented based on the NFV reference architecture. 986 Authors' Addresses 988 Jaehoon Paul Jeong 989 Department of Software 990 Sungkyunkwan University 991 2066 Seobu-Ro, Jangan-Gu 992 Suwon, Gyeonggi-Do 16419 993 Republic of Korea 995 Phone: +82 31 299 4957 996 Fax: +82 31 290 7996 997 EMail: pauljeong@skku.edu 998 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1000 Sangwon Hyun 1001 Department of Computer Engineering 1002 Chosun University 1003 309 Pilmun-daero, Dong-Gu 1004 Gwangju 61452 1005 Republic of Korea 1007 Phone: +82 62 230 7473 1008 EMail: shyun@chosun.ac.kr 1010 Tae-Jin Ahn 1011 Korea Telecom 1012 70 Yuseong-Ro, Yuseong-Gu 1013 Daejeon 305-811 1014 Republic of Korea 1016 Phone: +82 42 870 8409 1017 EMail: taejin.ahn@kt.com 1018 Susan Hares 1019 Huawei 1020 7453 Hickory Hill 1021 Saline, MI 48176 1022 USA 1024 Phone: +1-734-604-0332 1025 EMail: shares@ndzh.com 1027 Diego R. Lopez 1028 Telefonica I+D 1029 Jose Manuel Lara, 9 1030 Seville 41013 1031 Spain 1033 Phone: +34 682 051 091 1034 EMail: diego.r.lopez@telefonica.com