idnits 2.17.1 draft-ietf-i2nsf-applicability-07.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 2011 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-07 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 http://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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . 10 66 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE 67 Security 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-06 . . . 21 77 1. Introduction 79 Interface to Network Security Functions (I2NSF) defines a framework 80 and interfaces for interacting with Network Security Functions 81 (NSFs). The I2NSF framework allows heterogeneous NSFs developed by 82 different security solution vendors to be used in the Network 83 Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing 84 the capabilities of such products and the virtualization of security 85 functions in the NFV platform. In the I2NSF framework, each NSF 86 initially registers the profile of its own capabilities into the 87 system in order for themselves to be available in the system. In 88 addition, the Security Controller is validated by the I2NSF Client 89 (also called I2NSF User) that the user is employing, so that the user 90 can request security services through the Security Controller. 92 This document illustrates the applicability of the I2NSF framework 93 with four different scenarios: (i) the enforcement of time-dependent 94 web access control; (ii) the application of I2NSF to a Service 95 Function Chaining (SFC) environment [RFC7665]; (iii) the integration 96 of the I2NSF framework with Software-Defined Networking (SDN) 97 [RFC7149] to provide different security functionality such as 98 firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and 99 Distributed Denial of Service (DDoS) attack mitigation; (iv) the use 100 of NFV as supporting technology. The implementation of I2NSF in 101 these scenarios has allowed us to verify the applicability and 102 effectiveness of the I2NSF framework for a variety of use cases. 104 2. Terminology 106 This document uses the terminology described in [RFC7149], 107 [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], 108 [ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology], 109 [consumer-facing-inf-im], [consumer-facing-inf-dm], 110 [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-dm], and 111 [nsf-triggered-steering]. In addition, the following terms are 112 defined below: 114 o Software-Defined Networking (SDN): A set of techniques that 115 enables to directly program, orchestrate, control, and manage 116 network resources, which facilitates the design, delivery and 117 operation of network services in a dynamic and scalable manner 118 [ITU-T.Y.3300]. 120 o Firewall: A service function at the junction of two network 121 segments that inspects every packet that attempts to cross the 122 boundary. It also rejects any packet that does not satisfy 123 certain criteria for, for example, disallowed port numbers or IP 124 addresses. 126 o Centralized Firewall System: A centralized firewall that can 127 establish and distribute policy rules into network resources for 128 efficient firewall management. 130 o Centralized VoIP Security System: A centralized security system 131 that handles the security functions required for VoIP and VoLTE 132 services. 134 o Centralized DDoS-attack Mitigation System: A centralized mitigator 135 that can establish and distribute access control policy rules into 136 network resources for efficient DDoS-attack mitigation. 138 +------------+ 139 | I2NSF User | 140 +------------+ 141 ^ 142 | Consumer-Facing Interface 143 v 144 +-------------------+ Registration +-----------------------+ 145 |Security Controller|<-------------------->|Developer's Mgmt System| 146 +-------------------+ Interface +-----------------------+ 147 ^ 148 | NSF-Facing Interface 149 v 150 +----------------+ +---------------+ +-----------------------+ 151 | NSF-1 |-| NSF-2 |...| NSF-n | 152 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 153 +----------------+ +---------------+ +-----------------------+ 155 Figure 1: I2NSF Framework 157 3. I2NSF Framework 159 This section summarizes the I2NSF framework as defined in [RFC8329]. 160 As shown in Figure 1, an I2NSF User can use security functions by 161 delivering high-level security policies, which specify security 162 requirements that the I2NSF user wants to enforce, to the Security 163 Controller via the Consumer-Facing Interface 164 [consumer-facing-inf-im][consumer-facing-inf-dm]. 166 The Security Controller receives and analyzes the high-level security 167 policies from an I2NSF User, and identifies what types of security 168 capabilities are required to meet these high-level security policies. 169 The Security Controller then identifies NSFs that have the required 170 security capabilities, and generates low-level security policies for 171 each of the NSFs so that the high-level security policies are 172 eventually enforced by those NSFs [policy-translation]. Finally, the 173 Security Controller sends the generated low-level security policies 174 to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. 176 The Security Controller requests NSFs to perform low-level security 177 services via the NSF-Facing Interface. The developers (or vendors) 178 inform the Security Controller of the capabilities of the NSFs 179 through the I2NSF Registration Interface [registration-inf-dm] for 180 registering (or deregistering) the corresponding NSFs. 182 The Consumer-Facing Interface between an I2NSF User and the Security 183 Controller can be implemented using, for example, RESTCONF [RFC8040]. 184 Data models specified by YANG [RFC6020] describe high-level security 185 policies to be specified by an I2NSF User. The data model defined in 186 [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing 187 Interface. 189 The NSF-Facing Interface between the Security Controller and NSFs can 190 be implemented using NETCONF [RFC6241]. YANG data models describe 191 low-level security policies for the sake of NSFs, which are 192 translated from the high-level security policies by the Security 193 Controller. The data model defined in [nsf-facing-inf-dm] can be 194 used for the I2NSF NSF-Facing Interface. 196 The Registration Interface between the Security Controller and the 197 Developer's Management System can be implemented by RESTCONF 198 [RFC8040]. The data model defined in [registration-inf-dm] can be 199 used for the I2NSF Registration Interface. 201 Also, the I2NSF framework can enforce multiple chained NSFs for the 202 low-level security policies by means of SFC techniques for the I2NSF 203 architecture described in [nsf-triggered-steering]. 205 The following sections describe different security service scenarios 206 illustrating the applicability of the I2NSF framework. 208 4. Time-dependent Web Access Control Service 210 This service scenario assumes that an enterprise network 211 administrator wants to control the staff members' access to a 212 particular Interner service (e.g., Example.com) during business 213 hours. The following is an example high-level security policy rule 214 that the administrator requests: Block the staff members' access to 215 Example.com from 9 AM to 6 PM. The administrator sends this high- 216 level security policy to the Security Controller, then the Security 217 Controller identifies required security capabilities, e.g., IP 218 address and port number inspection capabilities and URL inspection 219 capability. In this scenario, it is assumed that the IP address and 220 port number inspection capabilities are required to check whether a 221 received packet is an HTTP packet from a staff member. The URL 222 inspection capability is required to check whether the target URL of 223 a received packet is in the Example.com domain or not. 225 The Security Controller maintains the security capabilities of each 226 NSF running in the I2NSF system, which have been reported by the 227 Developer's Management System via the Registation interface. Based 228 on this information, the Security Controller identifies NSFs that can 229 perform the IP address and port number inspection and URL inspection 230 [policy-translation]. In this scenario, it is assumed that an NSF of 231 firewall has the IP address and port number inspection capabilities 232 and an NSF of web filter has URL inspection capability. 234 The Security Controller generates low-level security rules for the 235 NSFs to perform IP address and port number inspection, URL 236 inspection, and time checking. Specifically, the Security Controller 237 may interoperate with an access control server in the enterprise 238 network in order to retrieve the information (e.g., IP address in 239 use, company identifier (ID), and role) of each employee that is 240 currently using the network. Based on the retrieved information, the 241 Security Controller generates low-level security rules to check 242 whether the source IP address of a received packet matches any one 243 being used by a staff member. In addition, the low-level security 244 rules should be able to determine that a received packet is of HTTP 245 protocol. The low-level security rules for web filter checks that 246 the target URL field of a received packet is equal to Example.com. 247 Finally, the Security Controller sends the low-level security rules 248 of the IP address and port number inspection to the NSF of firewall 249 and the low-level rules for URL inspection to the NSF of web filter. 251 The following describes how the time-dependent web access control 252 service is enforced by the NSFs of firewall and web filter. 254 1. A staff member tries to access Example.com during business hours, 255 e.g., 10 AM. 257 2. The packet is forwarded from the staff member's device to the 258 firewall, and the firewall checks the source IP address and port 259 number. Now the firewall identifies the received packet is an 260 HTTP packet from the staff member. 262 3. The firewall triggers the web filter to further inspect the 263 packet, and the packet is forwarded from the firewall to the web 264 filter. SFC technology can be utilized to support such packet 265 forwarding in the I2NSF framework [nsf-triggered-steering]. 267 4. The web filter checks the target URL field of the received 268 packet, and realizes the packet is toward Example.com. The web 269 filter then checks that the current time is in business hours. 270 If so, the web filter drops the packet, and consequently the 271 staff member's access to Example.com during business hours is 272 blocked. 274 +------------+ 275 | I2NSF User | 276 +------------+ 277 ^ 278 | Consumer-Facing Interface 279 v 280 +-------------------+ Registration +-----------------------+ 281 |Security Controller|<-------------------->|Developer's Mgmt System| 282 +-------------------+ Interface +-----------------------+ 283 ^ ^ 284 | | NSF-Facing Interface 285 | |------------------------- 286 | | 287 | NSF-Facing Interface | 288 +-----v-----------+ +------v-------+ 289 | +-----------+ | ------>| NSF-1 | 290 | |Classifier | | | | (Firewall) | 291 | +-----------+ | | +--------------+ 292 | +-----+ |<-----| +--------------+ 293 | | SFF | | |----->| NSF-2 | 294 | +-----+ | | | (DPI) | 295 +-----------------+ | +--------------+ 296 | . 297 | . 298 | . 299 | +-----------------------+ 300 ------>| NSF-n | 301 |(DDoS-Attack Mitigator)| 302 +-----------------------+ 304 Figure 2: An I2NSF Framework with SFC 306 5. I2NSF Framework with SFC 308 In the I2NSF architecture, an NSF can trigger an advanced security 309 action (e.g., DPI or DDoS attack mitigation) on a packet based on the 310 result of its own security inspection of the packet. For example, a 311 firewall triggers further inspection of a suspicious packet with DPI. 312 For this advanced security action to be fulfilled, the suspicious 313 packet should be forwarded from the current NSF to the successor NSF. 314 SFC [RFC7665] is a technology that enables this advanced security 315 action by steering a packet with multiple service functions (e.g., 316 NSFs), and this technology can be utilized by the I2NSF architecture 317 to support the advanced security action. 319 Figure 2 shows an I2NSF framework with the support of SFC. As shown 320 in the figure, SFC generally requires classifiers and service 321 function forwarders (SFFs); classifiers are responsible for 322 determining which service function path (SFP) (i.e., an ordered 323 sequence of service functions) a given packet should pass through, 324 according to pre-configured classification rules, and SFFs perform 325 forwarding the given packet to the next service function (e.g., NSF) 326 on the SFP of the packet by referring to their forwarding tables. In 327 the I2NSF architecture with SFC, the Security Controller can take 328 responsibilities of generating classification rules for classifiers 329 and forwarding tables for SFFs. By analyzing high-level security 330 policies from I2NSF users, the Security Controller can construct SFPs 331 that are required to meet the high-level security policies, generates 332 classification rules of the SFPs, and then configures classifiers 333 with the classification rules over NSF-Facing Interface so that 334 relevant traffic packets can follow the SFPs. Also, based on the 335 global view of NSF instances available in the system, the Security 336 Controller constructs forwarding tables, which are required for SFFs 337 to forward a given packet to the next NSF over the SFP, and 338 configures SFFs with those forwarding tables over NSF-Facing 339 Interface. 341 To trigger an advanced security action in the I2NSF architecture, the 342 current NSF appends a metadata describing the security capability 343 required for the advanced action to the suspicious packet and sends 344 the packet to the classifier. Based on the metadata information, the 345 classifier searches an SFP which includes an NSF with the required 346 security capability, changes the SFP-related information (e.g., 347 service path identifier and service index [RFC8300]) of the packet 348 with the new SFP that has been found, and then forwards the packet to 349 the SFF. When receiving the packet, the SFF checks the SFP-related 350 information such as the service path identifier and service index 351 contained in the packet and forwards the packet to the next NSF on 352 the SFP of the packet, according to its forwarding table. 354 6. I2NSF Framework with SDN 356 This section describes an I2NSF framework with SDN for I2NSF 357 applicability and use cases, such as firewall, deep packet 358 inspection, and DDoS-attack mitigation functions. SDN enables some 359 packet filtering rules to be enforced in network forwarding elements 360 (e.g., switch) by controlling their packet forwarding rules. By 361 taking advantage of this capability of SDN, it is possible to 362 optimize the process of security service enforcement in the I2NSF 363 system. 365 +------------+ 366 | I2NSF User | 367 +------------+ 368 ^ 369 | Consumer-Facing Interface 370 v 371 +-------------------+ Registration +-----------------------+ 372 |Security Controller|<-------------------->|Developer's Mgmt System| 373 +-------------------+ Interface +-----------------------+ 374 ^ ^ 375 | | NSF-Facing Interface 376 | v 377 | +----------------+ +---------------+ +-----------------------+ 378 | | NSF-1 |-| NSF-2 |...| NSF-n | 379 | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| 380 | +----------------+ +---------------+ +-----------------------+ 381 | 382 | 383 | SDN Network 384 +--|----------------------------------------------------------------+ 385 | V NSF-Facing Interface | 386 | +----------------+ | 387 | | SDN Controller | | 388 | +----------------+ | 389 | ^ | 390 | | SDN Southbound Interface | 391 | v | 392 | +--------+ +------------+ +--------+ +--------+ | 393 | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | 394 | | | |(Classifier)| | (SFF) | | | | 395 | +--------+ +------------+ +--------+ +--------+ | 396 +-------------------------------------------------------------------+ 398 Figure 3: An I2NSF Framework with SDN Network 400 Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to 401 support network-based security services. In this system, the 402 enforcement of security policy rules is divided into the SDN 403 forwarding elements (e.g., switch) and NSFs. Especially, SDN 404 forwarding elements enforce simple packet filtering rules that can be 405 translated into their packet forwarding rules, whereas NSFs enforce 406 NSF-related security rules requiring the security capabilities of the 407 NSFs. For this purpose, the Security Controller instructs the SDN 408 Controller via NSF-Facing Interface so that SDN forwarding elements 409 can perform the required security services with flow tables under the 410 supervision of the SDN Controller. 412 As an example, let us consider two different types of security rules: 414 Rule A is a simple packet fltering rule that checks only the IP 415 address and port number of a given packet, whereas rule B is a time- 416 consuming packet inspection rule for analyzing whether an attached 417 file being transmitted over a flow of packets contains malware. Rule 418 A can be translated into packet forwarding rules of SDN forwarding 419 elements and thus be enforced by these elements. In contrast, rule B 420 cannot be enforced by forwarding elements, but it has to be enforced 421 by NSFs with anti-malware capability. Specifically, a flow of 422 packets is forwarded to and reassembled by an NSF to reconstruct the 423 attached file stored in the flow of packets. The NSF then analyzes 424 the file to check the existence of malware. If the file contains 425 malware, the NSF drops the packets. 427 In an I2NSF framework with SDN, the Security Controller can analyze 428 given security policy rules and automatically determine which of the 429 given security policy rules should be enforced by SDN forwarding 430 elements and which should be enforced by NSFs. If some of the given 431 rules requires security capabilities that can be provided by SDN 432 forwarding elements, then the Security Controller instructs the SDN 433 Controller via NSF-Facing Interface so that SDN forwarding elements 434 can enforce those security policy rules with flow tables under the 435 supervision of the SDN Controller. Or if some rules require security 436 capabilities that cannot be provided by SDN forwarding elements but 437 by NSFs, then the Security Controller instructs relevant NSFs to 438 enforce those rules. 440 For the support of SFC in the I2NSF framework with SDN, as shown in 441 Figure 3, network forwarding elements (e.g., switch) can play the 442 role of either SFC Classifier or SFF, which are explained in 443 Section 5. Classifier and SFF have an NSF-Facing Interface with 444 Security Controller. This interface is used to update security 445 service function chaining information for traffic flows. For 446 example, when it needs to update an SFP for a traffic flow in an SDN 447 network, as shown in Figure 3, SFF (denoted as Switch-3) asks 448 Security Controller to update the SFP for the traffic flow (needing 449 another security service as an NSF) via NSF-Facing Interface. This 450 update lets Security Controller ask Classifier (denoted as Switch-2) 451 to update the mapping between the traffic flow and SFP in Classifier 452 via NSF-Facing Interface. 454 The following subsections introduce three use cases for cloud-based 455 security services: (i) firewall system, (ii) deep packet inspection 456 system, and (iii) attack mitigation system. [RFC8192] 458 6.1. Firewall: Centralized Firewall System 460 A centralized network firewall can manage each network resource and 461 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 This work has been partially supported by the European Commission 835 under Horizon 2020 grant agreement no. 700199 "Securing against 836 intruders and other threats through a NFV-enabled environment 837 (SHIELD)". This support does not imply endorsement. 839 10. Contributors 841 I2NSF is a group effort. I2NSF has had a number of contributing 842 authors. The following are considered co-authors: 844 o Hyoungshick Kim (Sungkyunkwan University) 845 o Jinyong Tim Kim (Sungkyunkwan University) 847 o Hyunsik Yang (Soongsil University) 849 o Younghan Kim (Soongsil University) 851 o Jung-Soo Park (ETRI) 853 o Se-Hui Lee (Korea Telecom) 855 o Mohamed Boucadair (Orange) 857 11. Informative References 859 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., 860 Strassner, J., and R. Kumar, "Framework for 861 Interface to Network Security Functions", 862 RFC 8329, February 2018. 864 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 865 Language for the Network Configuration 866 Protocol (NETCONF)", RFC 6020, 867 October 2010. 869 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., 870 and A. Bierman, "Network Configuration 871 Protocol (NETCONF)", RFC 6241, June 2011. 873 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, 874 "RESTCONF Protocol", RFC 8040, 875 January 2017. 877 [consumer-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., 878 Palislamovic, S., Xia, L., and J. Jeong, 879 "Information Model for Consumer-Facing 880 Interface to Security Controller", draft- 881 kumar-i2nsf-client-facing-interface-im-07 882 (work in progress), July 2018. 884 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and 885 S. Hares, "I2NSF Consumer-Facing Interface 886 YANG Data Model", draft-ietf-i2nsf- 887 consumer-facing-interface-dm-01 (work in 888 progress), July 2018. 890 [i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. 891 Lopez, "Information Model of NSFs 892 Capabilities", 893 draft-ietf-i2nsf-capability-02 (work in 894 progress), July 2018. 896 [policy-translation] Yang, J., Jeong, J., and J. Kim, "Security 897 Policy Translation in Interface to Network 898 Security Functions", draft-yang-i2nsf- 899 security-policy-translation-01 (work in 900 progress), July 2018. 902 [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., 903 and Q. Lin, "I2NSF Network Security 904 Function-Facing Interface YANG Data Model", 905 draft-ietf-i2nsf-nsf-facing-interface-data- 906 model-01 (work in progress), July 2018. 908 [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and 909 J. Park, "I2NSF Registration Interface YANG 910 Data Model", 911 draft-hyun-i2nsf-registration-dm-06 (work 912 in progress), July 2018. 914 [nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. 915 Hares, "Service Function Chaining-Enabled 916 I2NSF Architecture", 917 draft-hyun-i2nsf-nsf-triggered-steering-06 918 (work in progress), July 2018. 920 [i2nsf-nfv-architecture] Yang, H. and Y. Kim, "I2NSF on the NFV 921 Reference Architecture", 922 draft-yang-i2nsf-nfv-architecture-02 (work 923 in progress), June 2018. 925 [RFC7149] Boucadair, M. and C. Jacquenet, "Software- 926 Defined Networking: A Perspective from 927 within a Service Provider Environment", 928 RFC 7149, March 2014. 930 [ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of 931 Software-Defined Networking", June 2014. 933 [ONF-OpenFlow] ONF, "OpenFlow Switch Specification 934 (Version 1.4.0)", October 2013. 936 [ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. 938 [ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline 939 Identity Management Terms and Definitions", 940 April 2010. 942 [ITU-T.X.800] Recommendation ITU-T X.800, "Security 943 Architecture for Open Systems 944 Interconnection for CCITT Applications", 945 March 1991. 947 [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and 948 G. Gu, "AVANT-GUARD: Scalable and Vigilant 949 Switch Flow Management in Software-Defined 950 Networks", ACM CCS, November 2013. 952 [ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions 953 Virtualization (NFV); Architectural 954 Framework", October 2013. 956 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, 957 "SDP: Session Description Protocol", 958 RFC 4566, July 2006. 960 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, 961 L., and H. Birkholz, "Interface to Network 962 Security Functions (I2NSF) Terminology", 963 draft-ietf-i2nsf-terminology-06 (work in 964 progress), July 2018. 966 [opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in 967 Internet Security", 968 draft-ietf-opsawg-firewalls-01 (work in 969 progress), October 2012. 971 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, 972 C., Kumar, R., and J. Jeong, "Interface to 973 Network Security Functions (I2NSF): Problem 974 Statement and Use Cases", RFC 8192, 975 July 2017. 977 [RFC7665] Halpern, J. and C. Pignataro, "Service 978 Function Chaining (SFC) Architecture", 979 RFC 7665, October 2015. 981 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, 982 "Network Service Header (NSH)", RFC 8300, 983 January 2018. 985 Appendix A. Changes from draft-ietf-i2nsf-applicability-06 987 The following change has been made from 988 draft-ietf-i2nsf-applicability-06: 990 o Add the acknowledgment to the EU H2020 project SHIELD. 992 Authors' Addresses 994 Jaehoon Paul Jeong 995 Department of Software 996 Sungkyunkwan University 997 2066 Seobu-Ro, Jangan-Gu 998 Suwon, Gyeonggi-Do 16419 999 Republic of Korea 1001 Phone: +82 31 299 4957 1002 Fax: +82 31 290 7996 1003 EMail: pauljeong@skku.edu 1004 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1006 Sangwon Hyun 1007 Department of Computer Engineering 1008 Chosun University 1009 309 Pilmun-daero, Dong-Gu 1010 Gwangju 61452 1011 Republic of Korea 1013 Phone: +82 62 230 7473 1014 EMail: shyun@chosun.ac.kr 1016 Tae-Jin Ahn 1017 Korea Telecom 1018 70 Yuseong-Ro, Yuseong-Gu 1019 Daejeon 305-811 1020 Republic of Korea 1022 Phone: +82 42 870 8409 1023 EMail: taejin.ahn@kt.com 1025 Susan Hares 1026 Huawei 1027 7453 Hickory Hill 1028 Saline, MI 48176 1029 USA 1031 Phone: +1-734-604-0332 1032 EMail: shares@ndzh.com 1033 Diego R. Lopez 1034 Telefonica I+D 1035 Jose Manuel Lara, 9 1036 Seville, 41013 1037 Spain 1039 Phone: +34 682 051 091 1040 EMail: diego.r.lopez@telefonica.com