idnits 2.17.1 draft-ietf-i2nsf-applicability-06.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 (October 22, 2018) is 2013 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: April 25, 2019 Chosun University 6 T. Ahn 7 Korea Telecom 8 S. Hares 9 Huawei 10 D. Lopez 11 Telefonica I+D 12 October 22, 2018 14 Applicability of Interfaces to Network Security Functions to Network- 15 Based Security Services 16 draft-ietf-i2nsf-applicability-06 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 April 25, 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 4. Time-dependent Web Access Control Service . . . . . . . . . . 5 63 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7 64 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 8 65 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11 66 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security 67 System . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation 69 System . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 74 11. Informative References . . . . . . . . . . . . . . . . . . . 19 75 Appendix A. Changes from draft-ietf-i2nsf-applicability-05 . . . 22 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 78 1. Introduction 80 Interface to Network Security Functions (I2NSF) defines 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 Network 84 Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing 85 the capabilities of such products and the virtualization of security 86 functions in the NFV platform. In the I2NSF framework, each NSF 87 initially registers the profile of its own capabilities into the 88 system in order for themselves to be available in the system. In 89 addition, the Security Controller is validated by the I2NSF Client 90 (also called I2NSF User) that the user is employing, so that the user 91 can request security services through the Security Controller. 93 This document illustrates the applicability of the I2NSF framework 94 with four different scenarios: (i) the enforcement of time-dependent 95 web access control; (ii) the application of I2NSF to a Service 96 Function Chaining (SFC) environment [RFC7665]; (iii) the integration 97 of the I2NSF framework with Software-Defined Networking (SDN) 98 [RFC7149] to provide different security functionality such as 99 firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and 100 Distributed Denial of Service (DDoS) attack mitigation; (iv) the use 101 of NFV as supporting technology. The implementation of I2NSF in 102 these scenarios has allowed us to verify the applicability and 103 effectiveness of the I2NSF framework for a variety of use cases. 105 2. Terminology 107 This document uses the terminology described in [RFC7149], 108 [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], 109 [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology], 110 [consumer-facing-inf-im], [consumer-facing-inf-dm], 111 [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-dm], and 112 [nsf-triggered-steering]. In addition, the following terms are 113 defined below: 115 o Software-Defined Networking (SDN): A set of techniques that 116 enables to directly program, orchestrate, control, and manage 117 network resources, which facilitates the design, delivery and 118 operation of network services in a dynamic and scalable manner 119 [ITU-T.Y.3300]. 121 o Firewall: A service function at the junction of two network 122 segments that inspects every packet that attempts to cross the 123 boundary. It also rejects any packet that does not satisfy 124 certain criteria for, for example, disallowed port numbers or IP 125 addresses. 127 o Centralized Firewall System: A centralized firewall that can 128 establish and distribute policy rules into network resources for 129 efficient firewall management. 131 o Centralized VoIP Security System: A centralized security system 132 that handles the security functions required for VoIP and VoLTE 133 services. 135 o Centralized DDoS-attack Mitigation System: A centralized mitigator 136 that can establish and distribute access control policy rules into 137 network resources for efficient DDoS-attack mitigation. 139 +------------+ 140 | I2NSF User | 141 +------------+ 142 ^ 143 | Consumer-Facing Interface 144 v 145 +-------------------+ Registration +-----------------------+ 146 |Security Controller|<-------------------->|Developer's Mgmt System| 147 +-------------------+ Interface +-----------------------+ 148 ^ 149 | NSF-Facing Interface 150 v 151 +----------------+ +---------------+ +-----------------------+ 152 | NSF-1 |-| NSF-2 |...| NSF-n | 153 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 154 +----------------+ +---------------+ +-----------------------+ 156 Figure 1: I2NSF Framework 158 3. I2NSF Framework 160 This section summarizes the I2NSF framework as defined in [RFC8329]. 161 As shown in Figure 1, an I2NSF User can use security functions by 162 delivering high-level security policies, which specify security 163 requirements that the I2NSF user wants to enforce, to the Security 164 Controller via the Consumer-Facing Interface 165 [consumer-facing-inf-im][consumer-facing-inf-dm]. 167 The Security Controller receives and analyzes the high-level security 168 policies from an I2NSF User, and identifies what types of security 169 capabilities are required to meet these high-level security policies. 170 The Security Controller then identifies NSFs that have the required 171 security capabilities, and generates low-level security policies for 172 each of the NSFs so that the high-level security policies are 173 eventually enforced by those NSFs [policy-translation]. Finally, the 174 Security Controller sends the generated low-level security policies 175 to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. 177 The Security Controller requests NSFs to perform low-level security 178 services via the NSF-Facing Interface. The developers (or vendors) 179 inform the Security Controller of the capabilities of the NSFs 180 through the I2NSF Registration Interface [registration-inf-dm] for 181 registering (or deregistering) the corresponding NSFs. 183 The Consumer-Facing Interface between an I2NSF User and the Security 184 Controller can be implemented using, for example, RESTCONF [RFC8040]. 185 Data models specified by YANG [RFC6020] describe high-level security 186 policies to be specified by an I2NSF User. The data model defined in 188 [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing 189 Interface. 191 The NSF-Facing Interface between the Security Controller and NSFs can 192 be implemented using NETCONF [RFC6241]. YANG data models describe 193 low-level security policies for the sake of NSFs, which are 194 translated from the high-level security policies by the Security 195 Controller. The data model defined in [nsf-facing-inf-dm] can be 196 used for the I2NSF NSF-Facing Interface. 198 The Registration Interface between the Security Controller and the 199 Developer's Management System can be implemented by RESTCONF 200 [RFC8040]. The data model defined in [registration-inf-dm] can be 201 used for the I2NSF Registration Interface. 203 Also, the I2NSF framework can enforce multiple chained NSFs for the 204 low-level security policies by means of SFC techniques for the I2NSF 205 architecture described in [nsf-triggered-steering]. 207 The following sections describe different security service scenarios 208 illustrating the applicability of the I2NSF framework. 210 4. Time-dependent Web Access Control Service 212 This service scenario assumes that an enterprise network 213 administrator wants to control the staff members' access to a 214 particular Interner service (e.g., Example.com) during business 215 hours. The following is an example high-level security policy rule 216 that the administrator requests: Block the staff members' access to 217 Example.com from 9 AM to 6 PM. The administrator sends this high- 218 level security policy to the Security Controller, then the Security 219 Controller identifies required security capabilities, e.g., IP 220 address and port number inspection capabilities and URL inspection 221 capability. In this scenario, it is assumed that the IP address and 222 port number inspection capabilities are required to check whether a 223 received packet is an HTTP packet from a staff member. The URL 224 inspection capability is required to check whether the target URL of 225 a received packet is in the Example.com domain or not. 227 The Security Controller maintains the security capabilities of each 228 NSF running in the I2NSF system, which have been reported by the 229 Developer's Management System via the Registation interface. Based 230 on this information, the Security Controller identifies NSFs that can 231 perform the IP address and port number inspection and URL inspection 232 [policy-translation]. In this scenario, it is assumed that an NSF of 233 firewall has the IP address and port number inspection capabilities 234 and an NSF of web filter has URL inspection capability. 236 The Security Controller generates low-level security rules for the 237 NSFs to perform IP address and port number inspection, URL 238 inspection, and time checking. Specifically, the Security Controller 239 may interoperate with an access control server in the enterprise 240 network in order to retrieve the information (e.g., IP address in 241 use, company identifier (ID), and role) of each employee that is 242 currently using the network. Based on the retrieved information, the 243 Security Controller generates low-level security rules to check 244 whether the source IP address of a received packet matches any one 245 being used by a staff member. In addition, the low-level security 246 rules should be able to determine that a received packet is of HTTP 247 protocol. The low-level security rules for web filter checks that 248 the target URL field of a received packet is equal to Example.com. 249 Finally, the Security Controller sends the low-level security rules 250 of the IP address and port number inspection to the NSF of firewall 251 and the low-level rules for URL inspection to the NSF of web filter. 253 The following describes how the time-dependent web access control 254 service is enforced by the NSFs of firewall and web filter. 256 1. A staff member tries to access Example.com during business hours, 257 e.g., 10 AM. 259 2. The packet is forwarded from the staff member's device to the 260 firewall, and the firewall checks the source IP address and port 261 number. Now the firewall identifies the received packet is an 262 HTTP packet from the staff member. 264 3. The firewall triggers the web filter to further inspect the 265 packet, and the packet is forwarded from the firewall to the web 266 filter. SFC technology can be utilized to support such packet 267 forwarding in the I2NSF framework [nsf-triggered-steering]. 269 4. The web filter checks the target URL field of the received 270 packet, and realizes the packet is toward Example.com. The web 271 filter then checks that the current time is in business hours. 272 If so, the web filter drops the packet, and consequently the 273 staff member's access to Example.com during business hours is 274 blocked. 276 +------------+ 277 | I2NSF User | 278 +------------+ 279 ^ 280 | Consumer-Facing Interface 281 v 282 +-------------------+ Registration +-----------------------+ 283 |Security Controller|<-------------------->|Developer's Mgmt System| 284 +-------------------+ Interface +-----------------------+ 285 ^ ^ 286 | | NSF-Facing Interface 287 | |------------------------- 288 | | 289 | NSF-Facing Interface | 290 +-----v-----------+ +------v-------+ 291 | +-----------+ | ------>| NSF-1 | 292 | |Classifier | | | | (Firewall) | 293 | +-----------+ | | +--------------+ 294 | +-----+ |<-----| +--------------+ 295 | | SFF | | |----->| NSF-2 | 296 | +-----+ | | | (DPI) | 297 +-----------------+ | +--------------+ 298 | . 299 | . 300 | . 301 | +-----------------------+ 302 ------>| NSF-n | 303 |(DDoS-Attack Mitigator)| 304 +-----------------------+ 306 Figure 2: An I2NSF Framework with SFC 308 5. I2NSF Framework with SFC 310 In the I2NSF architecture, an NSF can trigger an advanced security 311 action (e.g., DPI or DDoS attack mitigation) on a packet based on the 312 result of its own security inspection of the packet. For example, a 313 firewall triggers further inspection of a suspicious packet with DPI. 314 For this advanced security action to be fulfilled, the suspicious 315 packet should be forwarded from the current NSF to the successor NSF. 316 SFC [RFC7665] is a technology that enables this advanced security 317 action by steering a packet with multiple service functions (e.g., 318 NSFs), and this technology can be utilized by the I2NSF architecture 319 to support the advanced security action. 321 Figure 2 shows an I2NSF framework with the support of SFC. As shown 322 in the figure, SFC generally requires classifiers and service 323 function forwarders (SFFs); classifiers are responsible for 324 determining which service function path (SFP) (i.e., an ordered 325 sequence of service functions) a given packet should pass through, 326 according to pre-configured classification rules, and SFFs perform 327 forwarding the given packet to the next service function (e.g., NSF) 328 on the SFP of the packet by referring to their forwarding tables. In 329 the I2NSF architecture with SFC, the Security Controller can take 330 responsibilities of generating classification rules for classifiers 331 and forwarding tables for SFFs. By analyzing high-level security 332 policies from I2NSF users, the Security Controller can construct SFPs 333 that are required to meet the high-level security policies, generates 334 classification rules of the SFPs, and then configures classifiers 335 with the classification rules over NSF-Facing Interface so that 336 relevant traffic packets can follow the SFPs. Also, based on the 337 global view of NSF instances available in the system, the Security 338 Controller constructs forwarding tables, which are required for SFFs 339 to forward a given packet to the next NSF over the SFP, and 340 configures SFFs with those forwarding tables over NSF-Facing 341 Interface. 343 To trigger an advanced security action in the I2NSF architecture, the 344 current NSF appends a metadata describing the security capability 345 required for the advanced action to the suspicious packet and sends 346 the packet to the classifier. Based on the metadata information, the 347 classifier searches an SFP which includes an NSF with the required 348 security capability, changes the SFP-related information (e.g., 349 service path identifier and service index [RFC8300]) of the packet 350 with the new SFP that has been found, and then forwards the packet to 351 the SFF. When receiving the packet, the SFF checks the SFP-related 352 information such as the service path identifier and service index 353 contained in the packet and forwards the packet to the next NSF on 354 the SFP of the packet, according to its forwarding table. 356 6. I2NSF Framework with SDN 358 This section describes an I2NSF framework with SDN for I2NSF 359 applicability and use cases, such as firewall, deep packet 360 inspection, and DDoS-attack mitigation functions. SDN enables some 361 packet filtering rules to be enforced in network forwarding elements 362 (e.g., switch) by controlling their packet forwarding rules. By 363 taking advantage of this capability of SDN, it is possible to 364 optimize the process of security service enforcement in the I2NSF 365 system. 367 +------------+ 368 | I2NSF User | 369 +------------+ 370 ^ 371 | Consumer-Facing Interface 372 v 373 +-------------------+ Registration +-----------------------+ 374 |Security Controller|<-------------------->|Developer's Mgmt System| 375 +-------------------+ Interface +-----------------------+ 376 ^ ^ 377 | | NSF-Facing Interface 378 | v 379 | +----------------+ +---------------+ +-----------------------+ 380 | | NSF-1 |-| NSF-2 |...| NSF-n | 381 | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| 382 | +----------------+ +---------------+ +-----------------------+ 383 | 384 | 385 | SDN Network 386 +--|----------------------------------------------------------------+ 387 | V NSF-Facing Interface | 388 | +----------------+ | 389 | | SDN Controller | | 390 | +----------------+ | 391 | ^ | 392 | | SDN Southbound Interface | 393 | v | 394 | +--------+ +------------+ +--------+ +--------+ | 395 | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | 396 | | | |(Classifier)| | (SFF) | | | | 397 | +--------+ +------------+ +--------+ +--------+ | 398 +-------------------------------------------------------------------+ 400 Figure 3: An I2NSF Framework with SDN Network 402 Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to 403 support network-based security services. In this system, the 404 enforcement of security policy rules is divided into the SDN 405 forwarding elements (e.g., switch) and NSFs. Especially, SDN 406 forwarding elements enforce simple packet filtering rules that can be 407 translated into their packet forwarding rules, whereas NSFs enforce 408 NSF-related security rules requiring the security capabilities of the 409 NSFs. For this purpose, the Security Controller instructs the SDN 410 Controller via NSF-Facing Interface so that SDN forwarding elements 411 can perform the required security services with flow tables under the 412 supervision of the SDN Controller. 414 As an example, let us consider two different types of security rules: 415 Rule A is a simple packet fltering rule that checks only the IP 416 address and port number of a given packet, whereas rule B is a time- 417 consuming packet inspection rule for analyzing whether an attached 418 file being transmitted over a flow of packets contains malware. Rule 419 A can be translated into packet forwarding rules of SDN forwarding 420 elements and thus be enforced by these elements. In contrast, rule B 421 cannot be enforced by forwarding elements, but it has to be enforced 422 by NSFs with anti-malware capability. Specifically, a flow of 423 packets is forwarded to and reassembled by an NSF to reconstruct the 424 attached file stored in the flow of packets. The NSF then analyzes 425 the file to check the existence of malware. If the file contains 426 malware, the NSF drops the packets. 428 In an I2NSF framework with SDN, the Security Controller can analyze 429 given security policy rules and automatically determine which of the 430 given security policy rules should be enforced by SDN forwarding 431 elements and which should be enforced by NSFs. If some of the given 432 rules requires security capabilities that can be provided by SDN 433 forwarding elements, then the Security Controller instructs the SDN 434 Controller via NSF-Facing Interface so that SDN forwarding elements 435 can enforce those security policy rules with flow tables under the 436 supervision of the SDN Controller. Or if some rules require security 437 capabilities that cannot be provided by SDN forwarding elements but 438 by NSFs, then the Security Controller instructs relevant NSFs to 439 enforce those rules. 441 For the support of SFC in the I2NSF framework with SDN, as shown in 442 Figure 3, network forwarding elements (e.g., switch) can play the 443 role of either SFC Classifier or SFF, which are explained in 444 Section 5. Classifier and SFF have an NSF-Facing Interface with 445 Security Controller. This interface is used to update security 446 service function chaining information for traffic flows. For 447 example, when it needs to update an SFP for a traffic flow in an SDN 448 network, as shown in Figure 3, SFF (denoted as Switch-3) asks 449 Security Controller to update the SFP for the traffic flow (needing 450 another security service as an NSF) via NSF-Facing Interface. This 451 update lets Security Controller ask Classifier (denoted as Switch-2) 452 to update the mapping between the traffic flow and SFP in Classifier 453 via NSF-Facing Interface. 455 The following subsections introduce three use cases for cloud-based 456 security services: (i) firewall system, (ii) deep packet inspection 457 system, and (iii) attack mitigation system. [RFC8192] 459 6.1. Firewall: Centralized Firewall System 461 A centralized network firewall can manage each network resource and 462 apply common rules to individual network elements (e.g., switch). 463 The centralized network firewall controls each forwarding element, 464 and firewall rules can be added or deleted dynamically. 466 The procedure of firewall operations in this system is as follows: 468 1. A switch forwards an unknown flow's packet to one of the SDN 469 Controllers. 471 2. The SDN Controller forwards the unknown flow's packet to an 472 appropriate security service application, such as the Firewall. 474 3. The Firewall analyzes, typically, the headers and contents of the 475 packet. 477 4. If the Firewall regards the packet as a malicious one with a 478 suspicious pattern, it reports the malicious packet to the SDN 479 Controller. 481 5. The SDN Controller installs new rules (e.g., drop packets with 482 the suspicious pattern) into underlying switches. 484 6. The suspected packets are dropped by these switches. 486 Existing SDN protocols can be used through standard interfaces 487 between the firewall application and switches 488 [RFC7149][ITU-T.Y.3300][ONF-OpenFlow] [ONF-SDN-Architecture]. 490 Legacy firewalls have some challenges such as the expensive cost, 491 performance, management of access control, establishment of policy, 492 and packet-based access mechanism. The proposed framework can 493 resolve the challenges through the above centralized firewall system 494 based on SDN as follows: 496 o Cost: The cost of adding firewalls to network resources such as 497 routers, gateways, and switches is substantial due to the reason 498 that we need to add firewall on each network resource. To solve 499 this, each network resource can be managed centrally such that a 500 single firewall is manipulated by a centralized server. 502 o Performance: The performance of firewalls is often slower than the 503 link speed of network interfaces. Every network resource for 504 firewall needs to check firewall rules according to network 505 conditions. Firewalls can be adaptively deployed among network 506 switches, depending on network conditions in the framework. 508 o The management of access control: Since there may be hundreds of 509 network resources in a network, the dynamic management of access 510 control for security services like firewall is a challenge. In 511 the framework, firewall rules can be dynamically added for new 512 malware. 514 o The establishment of policy: Policy should be established for each 515 network resource. However, it is difficult to describe what flows 516 are permitted or denied for firewall within a specific 517 organization network under management. Thus, a centralized view 518 is helpful to determine security policies for such a network. 520 o Packet-based access mechanism: Packet-based access mechanism is 521 not enough for firewall in practice since the basic unit of access 522 control is usually users or applications. Therefore, application 523 level rules can be defined and added to the firewall system 524 through the centralized server. 526 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 528 A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE 529 flow and manage VoIP/VoLTE security rules, according to the 530 configuration of a VoIP/VoLTE security service called VoIP Intrusion 531 Prevention System (IPS). This centralized VoIP/VoLTE security system 532 controls each switch for the VoIP/VoLTE call flow management by 533 manipulating the rules that can be added, deleted or modified 534 dynamically. 536 The centralized VoIP/VoLTE security system can cooperate with a 537 network firewall to realize VoIP/VoLTE security service. 538 Specifically, a network firewall performs basic security checks of an 539 unknown flow's packet observed by a switch. If the network firewall 540 detects that the packet is an unknown VoIP call flow's packet that 541 exhibits some suspicious patterns, then it triggers the VoIP/VoLTE 542 security system for more specialized security analysis of the 543 suspicious VoIP call packet. 545 The procedure of VoIP/VoLTE security operations in this system is as 546 follows: 548 1. A switch forwards an unknown flow's packet to the SDN Controller, 549 and the SDN Controller further forwards the unknown flow's packet 550 to the Firewall for basic security inspection. 552 2. The Firewall analyzes the header fields of the packet, and 553 figures out that this is an unknown VoIP call flow's signal 554 packet (e.g., SIP packet) of a suspicious pattern. 556 3. The Firewall triggers an appropriate security service function, 557 such as VoIP IPS, for detailed security analysis of the 558 suspicious signal packet. In order for this triggering of VoIP 559 IPS to be served, the suspicious packet is sent to the Service 560 Function Forwarder (SFF) that is usually a switch in an SDN 561 network, as shown in Figure 3. The SFF forwards the suspicious 562 signal packet to the VoIP IPS. 564 4. The VoIP IPS analyzes the headers and contents of the signal 565 packet, such as calling number and session description headers 566 [RFC4566]. 568 5. If, for example, the VoIP IPS regards the packet as a spoofed 569 packet by hackers or a scanning packet searching for VoIP/VoLTE 570 devices, it drops the packet. In addition, the VoIP IPS requests 571 the SDN Controller to block that packet and the subsequent 572 packets that have the same call-id. 574 6. The SDN Controller installs new rules (e.g., drop packets) into 575 underlying switches. 577 7. The illegal packets are dropped by these switches. 579 Existing SDN protocols can be used through standard interfaces 580 between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] 581 [ONF-OpenFlow][ONF-SDN-Architecture]. 583 Legacy hardware based VoIP IPS has some challenges, such as 584 provisioning time, the granularity of security, expensive cost, and 585 the establishment of policy. The I2NSF framework can resolve the 586 challenges through the above centralized VoIP/VoLTE security system 587 based on SDN as follows: 589 o Provisioning: The provisioning time of setting up a legacy VoIP 590 IPS to network is substantial because it takes from some hours to 591 some days. By managing the network resources centrally, VoIP IPS 592 can provide more agility in provisioning both virtual and physical 593 network resources from a central location. 595 o The granularity of security: The security rules of a legacy VoIP 596 IPS are compounded considering the granularity of security. The 597 proposed framework can provide more granular security by 598 centralizing security control into a switch controller. The VoIP 599 IPS can effectively manage security rules throughout the network. 601 o Cost: The cost of adding VoIP IPS to network resources, such as 602 routers, gateways, and switches is substantial due to the reason 603 that we need to add VoIP IPS on each network resource. To solve 604 this, each network resource can be managed centrally such that a 605 single VoIP IPS is manipulated by a centralized server. 607 o The establishment of policy: Policy should be established for each 608 network resource. However, it is difficult to describe what flows 609 are permitted or denied for VoIP IPS within a specific 610 organization network under management. Thus, a centralized view 611 is helpful to determine security policies for such a network. 613 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 615 A centralized DDoS-attack mitigation can manage each network resource 616 and manipulate rules to each switch through a common server for DDoS- 617 attack mitigation (called DDoS-attack Mitigator). The centralized 618 DDoS-attack mitigation system defends servers against DDoS attacks 619 outside the private network, that is, from public networks. 621 Servers are categorized into stateless servers (e.g., DNS servers) 622 and stateful servers (e.g., web servers). For DDoS-attack 623 mitigation, traffic flows in switches are dynamically configured by 624 traffic flow forwarding path management according to the category of 625 servers [AVANT-GUARD]. Such a managenent should consider the load 626 balance among the switches for the defense against DDoS attacks. 628 The procedure of DDoS-attack mitigation operations in this system is 629 as follows: 631 1. A Switch periodically reports an inter-arrival pattern of a 632 flow's packets to one of the SDN Controllers. 634 2. The SDN Controller forwards the flow's inter-arrival pattern to 635 an appropriate security service application, such as DDoS-attack 636 Mitigator. 638 3. The DDoS-attack Mitigator analyzes the reported pattern for the 639 flow. 641 4. If the DDoS-attack Mitigator regards the pattern as a DDoS 642 attack, it computes a packet dropping probability corresponding 643 to suspiciousness level and reports this DDoS-attack flow to the 644 SDN Controller. 646 5. The SDN Controller installs new rules into switches (e.g., 647 forward packets with the suspicious inter-arrival pattern with a 648 dropping probability). 650 6. The suspicious flow's packets are randomly dropped by switches 651 with the dropping probability. 653 For the above centralized DDoS-attack mitigation system, the existing 654 SDN protocols can be used through standard interfaces between the 655 DDoS-attack mitigator application and switches [RFC7149] 656 [ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture]. 658 The centralized DDoS-attack mitigation system has challenges similar 659 to the centralized firewall system. The proposed framework can 660 resolve the challenges through the above centralized DDoS-attack 661 mitigation system based on SDN as follows: 663 o Cost: The cost of adding DDoS-attack mitigators to network 664 resources such as routers, gateways, and switches is substantial 665 due to the reason that we need to add DDoS-attack mitigator on 666 each network resource. To solve this, each network resource can 667 be managed centrally such that a single DDoS-attack mitigator is 668 manipulated by a centralized server. 670 o Performance: The performance of DDoS-attack mitigators is often 671 slower than the link speed of network interfaces. The checking of 672 DDoS attacks may reduce the performance of the network interfaces. 673 DDoS-attack mitigators can be adaptively deployed among network 674 switches, depending on network conditions in the framework. 676 o The management of network resources: Since there may be hundreds 677 of network resources in an administered network, the dynamic 678 management of network resources for performance (e.g., load 679 balancing) is a challenge for DDoS-attack mitigation. In the 680 framework, as dynamic network resource management, traffic flow 681 forwarding path management can handle the load balancing of 682 network switches [AVANT-GUARD]. With this management, the current 683 and near-future workload can be spread among the network switches 684 for DDoS-attack mitigation. In addition, DDoS-attack mitigation 685 rules can be dynamically added for new DDoS attacks. 687 o The establishment of policy: Policy should be established for each 688 network resource. However, it is difficult to describe what flows 689 are permitted or denied for new DDoS-attacks (e.g., DNS reflection 690 attack) within a specific organization network under management. 691 Thus, a centralized view is helpful to determine security policies 692 for such a network. 694 So far this section has described the procedure and impact of the 695 three use cases for network-based security services using the I2NSF 696 framework with SDN networks. To support these use cases in the 697 proposed data-driven security service framework, YANG data models 698 described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and 699 [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- 700 Facing Interface, and Registration Interface, respectively, along 701 with RESTCONF [RFC8040] and NETCONF [RFC6241]. 703 7. I2NSF Framework with NFV 705 This section discusses the implementation of the I2NSF framework 706 using Network Functions Virtualization (NFV). 708 +--------------------+ 709 +-------------------------------------------+ | ---------------- | 710 | I2NSF User (OSS/BSS) | | | NFV | | 711 +------+------------------------------------+ | | Orchestrator +-+ | 712 | Consumer-Facing Interface | -----+---------- | | 713 +------|------------------------------------+ | | | | 714 | -----+---------- (a) ----------------- | | ----+----- | | 715 | | Security +-------+ Developer's | | | | | | | 716 | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | 717 | -----+---------- ----------------- | | | | | | 718 | | NSF-Facing Interface | | ----+----- | | 719 | ----+----- ----+----- ----+----- | | | | | 720 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | | 721 | ----+----- ----+----- ----+----- | | | | | 722 | | | | | | | | | 723 +------|-------------|-------------|--------+ | | | | 724 | | | | | | | 725 +------+-------------+-------------+--------+ | | | | 726 | NFV Infrastructure (NFVI) | | | | | 727 | ----------- ----------- ----------- | | | | | 728 | | Virtual | | Virtual | | Virtual | | | | | | 729 | | Compute | | Storage | | Network | | | | | | 730 | ----------- ----------- ----------- | | ----+----- | | 731 | +---------------------------------------+ | | | | | | 732 | | Virtualization Layer | +-----+ VIM(s) +------+ | 733 | +---------------------------------------+ | | | | | 734 | +---------------------------------------+ | | ---------- | 735 | | ----------- ----------- ----------- | | | | 736 | | | Compute | | Storage | | Network | | | | | 737 | | | Hardware| | Hardware| | Hardware| | | | | 738 | | ----------- ----------- ----------- | | | | 739 | | Hardware Resources | | | NFV Management | 740 | +---------------------------------------+ | | and Orchestration | 741 | | | (MANO) | 742 +-------------------------------------------+ +--------------------+ 743 (a) = Registration Interface 744 (b) = Ve-Vnfm Interface 746 Figure 4: I2NSF Framework Implementation with respect to the NFV 747 Reference 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 (DMS) in the I2NSF framework is responsible for 766 registering capability information of NSFs into the Security 767 Controller. Those NSFs are created or removed by a virtual network 768 functions manager (VNFM) in the NFV architecture that performs the 769 life-cycle management of VNFs. The Security Controller controls and 770 monitors the configurations (e.g., function parameters and security 771 policy rules) of VNFs. Both the DMS and Security Controller can be 772 implemented as the Element Managements (EMs) in the NFV architecture. 773 Finally, the I2NSF User can be implemented as OSS/BSS (Operational 774 Support Systems/Business Support Systems) in the NFV architecture 775 that provides interfaces for users in the NFV system. 777 The operation procedure in the I2NSF framework based on the NFV 778 architecture is as follows: 780 1. The VNFM has a set of virtual machine (VM) images of NSFs, and 781 each VM image can be used to create an NSF instance that provides 782 a set of security capabilities. The DMS initially registers a 783 mapping table of the ID of each VM image and the set of 784 capabilities that can be provided by an NSF instance created from 785 the VM image into the Security Controller. 787 2. If the Security Controller does not have any instantiated NSF 788 that has the set of capabilities required to meet the security 789 requirements from users, it searches the mapping table 790 (registered by the DMS) for the VM image ID corresponding to the 791 required set of capabilities. 793 3. The Security Controller requests the DMS to instantiate an NSF 794 with the VM image ID via VNFM. 796 4. When receiving the instantiation request, the VNFM first asks the 797 NFV orchestrator for the permission required to create the NSF 798 instance, requests the VIM to allocate resources for the NSF 799 instance, and finally creates the NSF instance based on the 800 allocated resources. 802 5. Once the NSF instance has been created by the VNFM, the DMS 803 performs the initial configurations of the NSF instance and then 804 notifies the Security Controller of the NSF instance. 806 6. After being notified of the created NSF instance, the Security 807 Controller delivers low-level security policy rules to the NSF 808 instance for policy enforcement. 810 We can conclude that the I2NSF framework can be implemented based on 811 the NFV architecture framework. Note that the registration of the 812 capabilities of NSFs is performed through the Registration Interface 813 and the lifecycle management for NSFs (VNFs) is performed through the 814 Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 4. 815 More details about the I2NSF framework based on the NFV reference 816 architecture are described in [i2nsf-nfv-architecture]. 818 8. Security Considerations 820 The same security considerations for the I2NSF framework [RFC8329] 821 are applicable to this document. 823 This document shares all the security issues of SDN that are 824 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 826 9. Acknowledgments 828 This work was supported by Institute for Information & communications 829 Technology Promotion (IITP) grant funded by the Korea government 830 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 831 Technology Development for the Customized Security Service 832 Provisioning). 834 10. Contributors 836 I2NSF is a group effort. I2NSF has had a number of contributing 837 authors. The following are considered co-authors: 839 o Hyoungshick Kim (Sungkyunkwan University) 841 o Jinyong Tim Kim (Sungkyunkwan University) 843 o Hyunsik Yang (Soongsil University) 844 o Younghan Kim (Soongsil University) 846 o Jung-Soo Park (ETRI) 848 o Se-Hui Lee (Korea Telecom) 850 o Mohamed Boucadair (Orange) 852 11. Informative References 854 [AVANT-GUARD] 855 Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- 856 GUARD: Scalable and Vigilant Switch Flow Management in 857 Software-Defined Networks", ACM CCS, November 2013. 859 [consumer-facing-inf-dm] 860 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 861 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 862 ietf-i2nsf-consumer-facing-interface-dm-01 (work in 863 progress), July 2018. 865 [consumer-facing-inf-im] 866 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 867 S., Xia, L., and J. Jeong, "Information Model for 868 Consumer-Facing Interface to Security Controller", draft- 869 kumar-i2nsf-client-facing-interface-im-07 (work in 870 progress), July 2018. 872 [ETSI-NFV] 873 ETSI GS NFV 002 V1.1.1, "Network Functions Virtualization 874 (NFV); Architectural Framework", October 2013. 876 [i2nsf-nfv-architecture] 877 Yang, H. and Y. Kim, "I2NSF on the NFV Reference 878 Architecture", draft-yang-i2nsf-nfv-architecture-02 (work 879 in progress), June 2018. 881 [i2nsf-nsf-cap-im] 882 Xia, L., Strassner, J., Basile, C., and D. Lopez, 883 "Information Model of NSFs Capabilities", draft-ietf- 884 i2nsf-capability-02 (work in progress), July 2018. 886 [i2nsf-terminology] 887 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 888 Birkholz, "Interface to Network Security Functions (I2NSF) 889 Terminology", draft-ietf-i2nsf-terminology-06 (work in 890 progress), July 2018. 892 [ITU-T.X.1252] 893 Recommendation ITU-T X.1252, "Baseline Identity Management 894 Terms and Definitions", April 2010. 896 [ITU-T.X.800] 897 Recommendation ITU-T X.800, "Security Architecture for 898 Open Systems Interconnection for CCITT Applications", 899 March 1991. 901 [ITU-T.Y.3300] 902 Recommendation ITU-T Y.3300, "Framework of Software- 903 Defined Networking", June 2014. 905 [nsf-facing-inf-dm] 906 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 907 "I2NSF Network Security Function-Facing Interface YANG 908 Data Model", draft-ietf-i2nsf-nsf-facing-interface-data- 909 model-01 (work in progress), July 2018. 911 [nsf-triggered-steering] 912 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 913 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 914 i2nsf-nsf-triggered-steering-06 (work in progress), July 915 2018. 917 [ONF-OpenFlow] 918 ONF, "OpenFlow Switch Specification (Version 1.4.0)", 919 October 2013. 921 [ONF-SDN-Architecture] 922 ONF, "SDN Architecture", June 2014. 924 [opsawg-firewalls] 925 Baker, F. and P. Hoffman, "On Firewalls in Internet 926 Security", draft-ietf-opsawg-firewalls-01 (work in 927 progress), October 2012. 929 [policy-translation] 930 Yang, J., Jeong, J., and J. Kim, "Security Policy 931 Translation in Interface to Network Security Functions", 932 draft-yang-i2nsf-security-policy-translation-01 (work in 933 progress), July 2018. 935 [registration-inf-dm] 936 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 937 Registration Interface YANG Data Model", draft-hyun-i2nsf- 938 registration-dm-06 (work in progress), July 2018. 940 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 941 Description Protocol", RFC 4566, July 2006. 943 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 944 Network Configuration Protocol (NETCONF)", RFC 6020, 945 October 2010. 947 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 948 Bierman, "Network Configuration Protocol (NETCONF)", 949 RFC 6241, June 2011. 951 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 952 Networking: A Perspective from within a Service Provider 953 Environment", RFC 7149, March 2014. 955 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 956 (SFC) Architecture", RFC 7665, October 2015. 958 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 959 Protocol", RFC 8040, January 2017. 961 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 962 and J. Jeong, "Interface to Network Security Functions 963 (I2NSF): Problem Statement and Use Cases", RFC 8192, July 964 2017. 966 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 967 Header (NSH)", RFC 8300, January 2018. 969 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 970 Kumar, "Framework for Interface to Network Security 971 Functions", RFC 8329, February 2018. 973 Appendix A. Changes from draft-ietf-i2nsf-applicability-05 975 The following change has been made from draft-ietf-i2nsf- 976 applicability-05: 978 o In Figure 3, a separate box of SFF and the relevant interfaces 979 have been omitted to avoid misleading. Instead, SDN switches may 980 play the role of SFF and Classifier in an SDN network. 982 Authors' Addresses 984 Jaehoon Paul Jeong 985 Department of Software 986 Sungkyunkwan University 987 2066 Seobu-Ro, Jangan-Gu 988 Suwon, Gyeonggi-Do 16419 989 Republic of Korea 991 Phone: +82 31 299 4957 992 Fax: +82 31 290 7996 993 EMail: pauljeong@skku.edu 994 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 996 Sangwon Hyun 997 Department of Computer Engineering 998 Chosun University 999 309 Pilmun-daero, Dong-Gu 1000 Gwangju 61452 1001 Republic of Korea 1003 Phone: +82 62 230 7473 1004 EMail: shyun@chosun.ac.kr 1006 Tae-Jin Ahn 1007 Korea Telecom 1008 70 Yuseong-Ro, Yuseong-Gu 1009 Daejeon 305-811 1010 Republic of Korea 1012 Phone: +82 42 870 8409 1013 EMail: taejin.ahn@kt.com 1014 Susan Hares 1015 Huawei 1016 7453 Hickory Hill 1017 Saline, MI 48176 1018 USA 1020 Phone: +1-734-604-0332 1021 EMail: shares@ndzh.com 1023 Diego R. Lopez 1024 Telefonica I+D 1025 Jose Manuel Lara, 9 1026 Seville 41013 1027 Spain 1029 Phone: +34 682 051 091 1030 EMail: diego.r.lopez@telefonica.com