idnits 2.17.1 draft-ietf-i2nsf-applicability-10.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 (May 2, 2019) is 1811 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: November 3, 2019 Chosun University 6 T. Ahn 7 Korea Telecom 8 S. Hares 9 Huawei 10 D. Lopez 11 Telefonica I+D 12 May 2, 2019 14 Applicability of Interfaces to Network Security Functions to Network- 15 Based Security Services 16 draft-ietf-i2nsf-applicability-10 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 November 3, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Time-dependent Web Access Control Service . . . . . . . . . . 7 63 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 10 64 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 12 65 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 15 66 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security 67 System . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation 69 System . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 17 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 76 11.2. Informative References . . . . . . . . . . . . . . . . . 21 77 Appendix A. Changes from draft-ietf-i2nsf-applicability-09 . . . 23 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 80 1. Introduction 82 Interface to Network Security Functions (I2NSF) defines a framework 83 and interfaces for interacting with Network Security Functions 84 (NSFs). Note that Network Security Function (NSF) is defined as 85 software that provides a set of security-related services, such as 86 (i) detecting unwanted activity, (ii) blocking or mitigating the 87 effect of such unwanted activity in order to fulfil service 88 requirements, and (iii) supporting communication stream integrity and 89 confidentiality [i2nsf-terminology]. 91 The I2NSF framework allows heterogeneous NSFs developed by different 92 security solution vendors to be used in the Network Functions 93 Virtualization (NFV) environment [ETSI-NFV] by utilizing the 94 capabilities of such NSFs through I2NSF interfaces such as Customer- 95 Facing Interface [consumer-facing-inf-dm] and NSF-Facing Interface 96 [nsf-facing-inf-dm]. In the I2NSF framework, each NSF initially 97 registers the profile of its own capabilities into the Security 98 Controller (i.e., network operator management system [RFC8329]) in 99 the I2NSF system via Registration Interface [registration-inf-dm] so 100 that each NSF can be selected and used to enforce a given security 101 policy from I2NSF User (i.e., network security administrator). Note 102 that Developer's Management System (DMS) is management software that 103 provides a vendor's security service software as a Virtual Network 104 Function (VNF) in an NFV environment (or middlebox in the legacy 105 network) as an NSF, and registers the capabilities of an NSF into 106 Security Controller via Registration Interface for a security service 107 [RFC8329]. 109 Security Controller is defined as a management component that 110 contains control plane functions to manage NSFs and facilitate 111 information sharing among other components (e.g., NSFs and I2NSF 112 User) in an I2NSF system [i2nsf-terminology]. Security Controller 113 maintains the mapping between a capability and an NSF, so it can 114 perform to translate a high-level security policy received from I2NSF 115 User to a low-level security policy configured and enforced in an NSF 116 [policy-translation]. Security Controller can monitor the states and 117 security attacks in NSFs through NSF monitoring [nsf-monitoring-dm]. 119 This document illustrates the applicability of the I2NSF framework 120 with four different scenarios: 122 1. The enforcement of time-dependent web access control. 124 2. The application of I2NSF to a Service Function Chaining (SFC) 125 environment [RFC7665]. 127 3. The integration of the I2NSF framework with Software-Defined 128 Networking (SDN) [RFC7149] to provide different security 129 functionality such as firewalls [opsawg-firewalls], Deep Packet 130 Inspection (DPI), and Distributed Denial of Service (DDoS) attack 131 mitigation. 133 4. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a 134 supporting technology. 136 The implementation of I2NSF in these scenarios has allowed us to 137 verify the applicability and effectiveness of the I2NSF framework for 138 a variety of use cases. 140 2. Terminology 142 This document uses the terminology described in [RFC7665], [RFC7149], 143 [ITU-T.Y.3300], [ONF-SDN-Architecture], [ITU-T.X.800], 145 [NFV-Terminology], [RFC8329], and [i2nsf-terminology]. In addition, 146 the following terms are defined below: 148 o Software-Defined Networking (SDN): A set of techniques that 149 enables to directly program, orchestrate, control, and manage 150 network resources, which facilitates the design, delivery and 151 operation of network services in a dynamic and scalable manner 152 [ITU-T.Y.3300]. 154 o Network Function: A funcional block within a network 155 infrastructure that has well-defined external interfaces and well- 156 defined functional behavior [NFV-Terminology]. 158 o Network Security Function (NSF): Software that provides a set of 159 security-related services. Examples include detecting unwanted 160 activity and blocking or mitigating the effect of such unwanted 161 activity in order to fulfil service requirements. The NSF can 162 also help in supporting communication stream integrity and 163 confidentiality [i2nsf-terminology]. 165 o Network Functions Virtualization (NFV): A principle of separating 166 network functions (or network security functions) from the 167 hardware they run on by using virtual hardware abstraction 168 [NFV-Terminology]. 170 o Service Function Chaining (SFC): The execution of an ordered set 171 of abstract service functions (i.e., network functions) according 172 to ordering constraints that must be applied to packets, frames, 173 and flows selected as a result of classification. The implied 174 order may not be a linear progression as the architecture allows 175 for SFCs that copy to more than one branch, and also allows for 176 cases where there is flexibility in the order in which service 177 functions need to be applied [RFC7665]. 179 o Firewall: A service function at the junction of two network 180 segments that inspects some suspicious packets that attempt to 181 cross the boundary. It also rejects any packet that does not 182 satisfy certain criteria for, for example, disallowed port numbers 183 or IP addresses. 185 o Centralized Firewall System: A centralized firewall that can 186 establish and distribute policy rules into network resources for 187 efficient firewall management. 189 o Centralized VoIP Security System: A centralized security system 190 that handles the security functions required for VoIP and VoLTE 191 services. 193 o Centralized DDoS-attack Mitigation System: A centralized mitigator 194 that can establish and distribute access control policy rules into 195 network resources for efficient DDoS-attack mitigation. 197 +------------+ 198 | I2NSF User | 199 +------------+ 200 ^ 201 | Consumer-Facing Interface 202 v 203 +-------------------+ Registration +-----------------------+ 204 |Security Controller|<-------------------->|Developer's Mgmt System| 205 +-------------------+ Interface +-----------------------+ 206 ^ 207 | NSF-Facing Interface 208 v 209 +----------------+ +---------------+ +-----------------------+ 210 | NSF-1 |-| NSF-2 |...| NSF-n | 211 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 212 +----------------+ +---------------+ +-----------------------+ 214 Figure 1: I2NSF Framework 216 3. I2NSF Framework 218 This section summarizes the I2NSF framework as defined in [RFC8329]. 219 As shown in Figure 1, an I2NSF User can use security functions by 220 delivering high-level security policies, which specify security 221 requirements that the I2NSF user wants to enforce, to the Security 222 Controller via the Consumer-Facing Interface 223 [consumer-facing-inf-dm]. 225 The Security Controller receives and analyzes the high-level security 226 policies from an I2NSF User, and identifies what types of security 227 capabilities are required to meet these high-level security policies. 228 The Security Controller then identifies NSFs that have the required 229 security capabilities, and generates low-level security policies for 230 each of the NSFs so that the high-level security policies are 231 eventually enforced by those NSFs [policy-translation]. Finally, the 232 Security Controller sends the generated low-level security policies 233 to the NSFs via the NSF-Facing Interface [nsf-facing-inf-dm]. 235 As shown in Figure 1, with a Developer's Management System (called 236 DMS), developers (or vendors) inform the Security Controller of the 237 capabilities of the NSFs through the Registration Interface 238 [registration-inf-dm] for registering (or deregistering) the 239 corresponding NSFs. Note that an inside attacker at the DMS can 240 seriously weaken the I2NSF system's security. That is, DMS can be 241 compromised to attack the Security Controller by providing the 242 Security Controller with malicious NSFs, and controlling those NSFs 243 in real time. To deal with this type of threat, the role of the DMS 244 should be restricted to providing an I2NSF system with the software 245 package/image for NSF execution, and the DMS should never be able to 246 access NSFs in online/activated status for the I2NSF system's 247 security. On the other hand, an access to active NSFs should be 248 allowed only to the Security Controller, not the DMS during the 249 provisioning time of those NSFs to the I2NSF system. However, note 250 that an inside attacker can access the active NSFs, which are being 251 executed as either VNFs or middleboxes in the I2NSF system, through a 252 back door (i.e., an IP address and a port number that are known to 253 the DMS to control an NSF). However, the Security Controller can 254 detect and prevent inside attacks by monitoring the activities of all 255 the DMSs as well as the NSFs through the I2NSF NSF monitoring 256 functionality [nsf-monitoring-dm]. Through the NSF monitoring, the 257 Security Controller can monitor the activities and states of NSFs, 258 and then can make a diagnosis to see whether the NSFs are working in 259 normal conditions or in abnormal conditions including the insider 260 threat. Note that the monitoring of the DMSs is out of scope for 261 I2NSF. 263 The Consumer-Facing Interface can be implemented as an XML file based 264 on the Consumer-Facing Interface data model [consumer-facing-inf-dm] 265 along with RESTCONF [RFC8040], which befits a web-based user 266 interface for an I2NSF User to send a Security Controller a high- 267 level security policy. Data models specified by YANG [RFC6020] 268 describe high-level security policies to be specified by an I2NSF 269 User. The data model defined in [consumer-facing-inf-dm] can be used 270 for the I2NSF Consumer-Facing Interface. Note that an inside 271 attacker at the I2NSF User can misuse the I2NSF system so that the 272 network system under the I2NSF system is vulnerable to security 273 attacks. To handle this type of threat, the Security Controller 274 needs to monitor the activities of all the I2NSF Users as well as the 275 NSFs through the I2NSF NSF monitoring functionality 276 [nsf-monitoring-dm]. Note that the monitoring of the I2NSF Users is 277 out of scope for I2NSF. 279 The NSF-Facing Interface can be implemented as an XML file based on 280 the NSF-Facing Interface YANG data model [nsf-facing-inf-dm] along 281 with NETCONF [RFC6241], which befits a command-line-based remote- 282 procedure call for a Security Controller to configure an NSF with a 283 low-level security policy. Data models specified by YANG [RFC6020] 284 describe low-level security policies for the sake of NSFs, which are 285 translated from the high-level security policies by the Security 286 Controller. The data model defined in [nsf-facing-inf-dm] can be 287 used for the I2NSF NSF-Facing Interface. 289 The Registration Interface can be implemented as an XML file based on 290 the Registration Interface YANG data model [registration-inf-dm] 291 along with NETCONF [RFC6241], which befits a command-line-based 292 remote-procedure call for a DMS to send a Security Controller an 293 NSF's capability information. Data models specified by YANG 294 [RFC6020] describe the registration of an NSF's capabilities to 295 enforce security services at the NSF. The data model defined in 296 [registration-inf-dm] can be used for the I2NSF Registration 297 Interface. 299 Also, the I2NSF framework can enforce multiple chained NSFs for the 300 low-level security policies by means of SFC techniques for the I2NSF 301 architecture [RFC7665]. 303 The following sections describe different security service scenarios 304 illustrating the applicability of the I2NSF framework. 306 4. Time-dependent Web Access Control Service 308 This service scenario assumes that an enterprise network 309 administrator wants to control the staff members' access to a 310 particular Internet service (e.g., Example.com) during business 311 hours. The following is an example high-level security policy rule 312 for a web filter that the administrator requests: Block the staff 313 members' access to Example.com from 9 AM (i.e., 09:00) to 6 PM (i.e., 314 18:00) by dropping their packets. Figure 2 is an example XML code 315 for this web filter that is sent from the I2NSF User to the Security 316 Controller via the Consumer-Facing Interface 317 [consumer-facing-inf-dm]: 319 320 321 block_website 322 323 block_website_during_working_hours 324 325 326 09:00 327 18:00 328 329 330 331 332 333 Staff_Member's_PC 334 335 336 337 338 Example.com 339 340 341 342 343 drop 344 345 346 348 Figure 2: An XML Example for Time-based Web-filter 350 The security policy name is "block_website" with the tag "policy- 351 name", and the security policy rule name is 352 "block_website_during_working_hours" with the tag "rule-name". The 353 filtering event has the time span where the filtering begin time is 354 the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the 355 filtering end time is the time "18:00" (i.e., 6:00PM) with the tag 356 "end-time". The filtering condition has the source target of 357 "Staff_Member's_PC" with the tag "src-target", the destination target 358 of a website "Example.com" with the tag "dest-target". The action is 359 to "drop" the packets satisfying the above event and condition with 360 the tag "primary-action". 362 After receiving the high-level security policy, the Security 363 Controller identifies required security capabilities, e.g., IP 364 address and port number inspection capabilities and URL inspection 365 capability. In this scenario, it is assumed that the IP address and 366 port number inspection capabilities are required to check whether a 367 received packet is an HTTP packet from a staff member. The URL 368 inspection capability is required to check whether the target URL of 369 a received packet is in the Example.com domain or not. 371 The Security Controller maintains the security capabilities of each 372 NSF running in the I2NSF system, which have been reported by the 373 Developer's Management System via the Registration interface. Based 374 on this information, the Security Controller identifies NSFs that can 375 perform the IP address and port number inspection and URL inspection 376 [policy-translation]. In this scenario, it is assumed that a 377 firewall NSF has the IP address and port number inspection 378 capabilities and a web filter NSF has URL inspection capability. 380 The Security Controller generates low-level security rules for the 381 NSFs to perform IP address and port number inspection, URL 382 inspection, and time checking. Specifically, the Security Controller 383 may interoperate with an access control server in the enterprise 384 network in order to retrieve the information (e.g., IP address in 385 use, company identifier (ID), and role) of each employee that is 386 currently using the network. Based on the retrieved information, the 387 Security Controller generates low-level security rules to check 388 whether the source IP address of a received packet matches any one 389 being used by a staff member. In addition, the low-level security 390 rules should be able to determine that a received packet is of HTTP 391 protocol. The low-level security rules for web filter check that the 392 target URL field of a received packet is equal to Example.com. 393 Finally, the Security Controller sends the low-level security rules 394 of the IP address and port number inspection to the firewall NSF and 395 the low-level rules for URL inspection to the web filter NSF. 397 The following describes how the time-dependent web access control 398 service is enforced by the NSFs of firewall and web filter. 400 1. A staff member tries to access Example.com during business hours, 401 e.g., 10 AM. 403 2. The packet is forwarded from the staff member's device to the 404 firewall, and the firewall checks the source IP address and port 405 number. Now the firewall identifies the received packet is an 406 HTTP packet from the staff member. 408 3. The firewall triggers the web filter to further inspect the 409 packet, and the packet is forwarded from the firewall to the web 410 filter. SFC technology can be utilized to support such packet 411 forwarding in the I2NSF framework [RFC7665]. 413 4. The web filter checks the target URL field of the received 414 packet, and realizes the packet is toward Example.com. The web 415 filter then checks that the current time is in business hours. 416 If so, the web filter drops the packet, and consequently the 417 staff member's access to Example.com during business hours is 418 blocked. 420 +------------+ 421 | I2NSF User | 422 +------------+ 423 ^ 424 | Consumer-Facing Interface 425 v 426 +-------------------+ Registration +-----------------------+ 427 |Security Controller|<-------------------->|Developer's Mgmt System| 428 +-------------------+ Interface +-----------------------+ 429 ^ ^ 430 | | NSF-Facing Interface 431 | |------------------------- 432 | | 433 | NSF-Facing Interface | 434 +-----v-----------+ +------v-------+ 435 | +-----------+ | ------>| NSF-1 | 436 | |Classifier | | | | (Firewall) | 437 | +-----------+ | | +--------------+ 438 | +-----+ |<-----| +--------------+ 439 | | SFF | | |----->| NSF-2 | 440 | +-----+ | | | (DPI) | 441 +-----------------+ | +--------------+ 442 | . 443 | . 444 | . 445 | +-----------------------+ 446 ------>| NSF-n | 447 |(DDoS-Attack Mitigator)| 448 +-----------------------+ 450 Figure 3: An I2NSF Framework with SFC 452 5. I2NSF Framework with SFC 454 In the I2NSF architecture, an NSF can trigger an advanced security 455 action (e.g., DPI or DDoS attack mitigation) on a packet based on the 456 result of its own security inspection of the packet. For example, a 457 firewall triggers further inspection of a suspicious packet with DPI. 458 For this advanced security action to be fulfilled, the suspicious 459 packet should be forwarded from the current NSF to the successor NSF. 460 SFC [RFC7665] is a technology that enables this advanced security 461 action by steering a packet with multiple service functions (e.g., 462 NSFs), and this technology can be utilized by the I2NSF architecture 463 to support the advanced security action. 465 Figure 3 shows an I2NSF framework with the support of SFC. As shown 466 in the figure, SFC generally requires classifiers and service 467 function forwarders (SFFs); classifiers are responsible for 468 determining which service function path (SFP) (i.e., an ordered 469 sequence of service functions) a given packet should pass through, 470 according to pre-configured classification rules, and SFFs perform 471 forwarding the given packet to the next service function (e.g., NSF) 472 on the SFP of the packet by referring to their forwarding tables. In 473 the I2NSF architecture with SFC, the Security Controller can take 474 responsibilities of generating classification rules for classifiers 475 and forwarding tables for SFFs. By analyzing high-level security 476 policies from I2NSF users, the Security Controller can construct SFPs 477 that are required to meet the high-level security policies, generates 478 classification rules of the SFPs, and then configures classifiers 479 with the classification rules over NSF-Facing Interface so that 480 relevant traffic packets can follow the SFPs. Also, based on the 481 global view of NSF instances available in the system, the Security 482 Controller constructs forwarding tables, which are required for SFFs 483 to forward a given packet to the next NSF over the SFP, and 484 configures SFFs with those forwarding tables over NSF-Facing 485 Interface. 487 To trigger an advanced security action in the I2NSF architecture, the 488 current NSF appends metadata describing the security capability 489 required for the advanced action to the suspicious packet to the 490 network service header (NSH) of the packet [RFC8300]. It then sends 491 the packet to the classifier. Based on the metadata information, the 492 classifier searches an SFP which includes an NSF with the required 493 security capability, changes the SFP-related information (e.g., 494 service path identifier and service index [RFC8300]) of the packet 495 with the new SFP that has been found, and then forwards the packet to 496 the SFF. When receiving the packet, the SFF checks the SFP-related 497 information such as the service path identifier and service index 498 contained in the packet and forwards the packet to the next NSF on 499 the SFP of the packet, according to its forwarding table. 501 +------------+ 502 | I2NSF User | 503 +------------+ 504 ^ 505 | Consumer-Facing Interface 506 v 507 +-------------------+ Registration +-----------------------+ 508 |Security Controller|<-------------------->|Developer's Mgmt System| 509 +-------------------+ Interface +-----------------------+ 510 ^ ^ 511 | | NSF-Facing Interface 512 | v 513 | +----------------+ +---------------+ +-----------------------+ 514 | | NSF-1 |-| NSF-2 |...| NSF-n | 515 | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| 516 | +----------------+ +---------------+ +-----------------------+ 517 | 518 | 519 | SDN Network 520 +--|----------------------------------------------------------------+ 521 | V NSF-Facing Interface | 522 | +----------------+ | 523 | | SDN Controller | | 524 | +----------------+ | 525 | ^ | 526 | | SDN Southbound Interface | 527 | v | 528 | +--------+ +------------+ +--------+ +--------+ | 529 | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | 530 | | | |(Classifier)| | (SFF) | | | | 531 | +--------+ +------------+ +--------+ +--------+ | 532 +-------------------------------------------------------------------+ 534 Figure 4: An I2NSF Framework with SDN Network 536 6. I2NSF Framework with SDN 538 This section describes an I2NSF framework with SDN for I2NSF 539 applicability and use cases, such as firewall, deep packet 540 inspection, and DDoS-attack mitigation functions. SDN enables some 541 packet filtering rules to be enforced in network forwarding elements 542 (e.g., switch) by controlling their packet forwarding rules. By 543 taking advantage of this capability of SDN, it is possible to 544 optimize the process of security service enforcement in the I2NSF 545 system. For example, for efficient firewall services, simple packet 546 filtering can be performed by SDN forwarding elements (e.g., 547 switches), and complicated packet filtering based on packet payloads 548 can be performed by a firewall NSF. This optimized firewall using 549 both SDN forwarding elements and a firewall NSF is more efficient 550 than a firewall where SDN forwarding elements forward all the packets 551 to a firewall NSF for packet filtering. This is because packets to 552 be filtered out can be early dropped by SDN forwarding elements 553 without consuming further network bandwidth due to the forwarding of 554 the packets to the firewall NSF. 556 Figure 4 shows an I2NSF framework [RFC8329] with SDN networks to 557 support network-based security services. In this system, the 558 enforcement of security policy rules is divided into the SDN 559 forwarding elements (e.g., switch running as either a hardware middle 560 box or a software virtual switch) and NSFs (e.g., firewall running in 561 a form of a virtual network function (VNF) [ETSI-NFV]). Note that 562 NSFs are created or removed by the NFV Management and Orchestration 563 (MANO) [ETSI-NFV-MANO], performing the life-cycle management of NSFs 564 as VNFs. Refer to Section 7 for the detailed discussion of the NSF 565 life-cycle management in the NFV MANO for I2NSF. SDN forwarding 566 elements enforce simple packet filtering rules that can be translated 567 into their packet forwarding rules, whereas NSFs enforce complicated 568 NSF-related security rules requiring the security capabilities of the 569 NSFs. Note that SDN packet forwarding rules are for packet 570 forwarding or filtering by flow table entries at SDN forwarding 571 elements, and NSF rules are for security enforcement at NSFs (e.g., 572 firewall). Thus, simple firewall rules can be enforced by SDN packet 573 forwarding rules at SDN forwarding elements (e.g., switches). For 574 the tasks for security enforcement (e.g., packet filtering), the 575 Security Controller instructs the SDN Controller via NSF-Facing 576 Interface so that SDN forwarding elements can perform the required 577 security services with flow tables under the supervision of the SDN 578 Controller. 580 As an example, let us consider two different types of security rules: 581 Rule A is a simple packet filtering rule that checks only the IP 582 address and port number of a given packet, whereas rule B is a time- 583 consuming packet inspection rule for analyzing whether an attached 584 file being transmitted over a flow of packets contains malware. Rule 585 A can be translated into packet forwarding rules of SDN forwarding 586 elements and thus be enforced by these elements. In contrast, rule B 587 cannot be enforced by forwarding elements, but it has to be enforced 588 by NSFs with anti-malware capability. Specifically, a flow of 589 packets is forwarded to and reassembled by an NSF to reconstruct the 590 attached file stored in the flow of packets. The NSF then analyzes 591 the file to check the existence of malware. If the file contains 592 malware, the NSF drops the packets. 594 In an I2NSF framework with SDN, the Security Controller can analyze 595 given security policy rules and automatically determine which of the 596 given security policy rules should be enforced by SDN forwarding 597 elements and which should be enforced by NSFs. If some of the given 598 rules requires security capabilities that can be provided by SDN 599 forwarding elements, then the Security Controller instructs the SDN 600 Controller via NSF-Facing Interface so that SDN forwarding elements 601 can enforce those security policy rules with flow tables under the 602 supervision of the SDN Controller. Or if some rules require security 603 capabilities that cannot be provided by SDN forwarding elements but 604 by NSFs, then the Security Controller instructs relevant NSFs to 605 enforce those rules. 607 The distinction between software-based SDN forwarding elements and 608 NSFs, which can both run as virtual network functions (VNFs), may be 609 necessary for some management purposes in this system. Note that an 610 SDN forwarding element (i.e., switch) is a specific type of VNF 611 rather than an NSF because an NSF is for security services rather 612 than for packet forwarding. For this distinction, we can take 613 advantage of the NFV MANO where there is a subsystem that maintains 614 the descriptions of the capabilities each VNF can offer 615 [ETSI-NFV-MANO]. This subsystem can determine whether a given 616 software element (VNF instance) is an NSF or a virtualized SDN 617 switch. For example, if a VNF instance has anti-malware capability 618 according to the description of the VNF, it could be considered as an 619 NSF. A VNF onboarding system [VNF-ONBOARDING] can be used as such a 620 subsystem that maintains the descriptions of each VNF to tell whether 621 a VNF instance is for an NSF or for a virtualized SDN switch. 623 For the support of SFC in the I2NSF framework with SDN, as shown in 624 Figure 4, network forwarding elements (e.g., switch) can play the 625 role of either SFC Classifier or SFF, which are explained in 626 Section 5. Classifier and SFF have an NSF-Facing Interface with 627 Security Controller. This interface is used to update security 628 service function chaining information for traffic flows. For 629 example, when it needs to update an SFP for a traffic flow in an SDN 630 network, as shown in Figure 4, SFF (denoted as Switch-3) asks 631 Security Controller to update the SFP for the traffic flow (needing 632 another security service as an NSF) via NSF-Facing Interface. This 633 update lets Security Controller ask Classifier (denoted as Switch-2) 634 to update the mapping between the traffic flow and SFP in Classifier 635 via NSF-Facing Interface. 637 The following subsections introduce three use cases from [RFC8192] 638 for cloud-based security services: (i) firewall system, (ii) deep 639 packet inspection system, and (iii) attack mitigation system. 641 6.1. Firewall: Centralized Firewall System 643 A centralized network firewall can manage each network resource and 644 apply common rules to individual network elements (e.g., switch). 645 The centralized network firewall controls each forwarding element, 646 and firewall rules can be added or deleted dynamically. 648 A time-based firewall can be enforced with packet filtering rules and 649 a time span (e.g., work hours). With this time-based firewall, a 650 time-based security policy can be enforced, as explained in 651 Section 4. For example, employees at a company are allowed to access 652 social networking service websites during lunch time or after work 653 hours. 655 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 657 A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE 658 flow and manage VoIP/VoLTE security rules, according to the 659 configuration of a VoIP/VoLTE security service called VoIP Intrusion 660 Prevention System (IPS). This centralized VoIP/VoLTE security system 661 controls each switch for the VoIP/VoLTE call flow management by 662 manipulating the rules that can be added, deleted or modified 663 dynamically. 665 The centralized VoIP/VoLTE security system can cooperate with a 666 network firewall to realize VoIP/VoLTE security service. 667 Specifically, a network firewall performs the basic security check of 668 an unknown flow's packet observed by a switch. If the network 669 firewall detects that the packet is an unknown VoIP call flow's 670 packet that exhibits some suspicious patterns, then it triggers the 671 VoIP/VoLTE security system for more specialized security analysis of 672 the suspicious VoIP call packet. 674 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 676 A centralized DDoS-attack mitigation can manage each network resource 677 and configure rules to each switch for DDoS-attack mitigation (called 678 DDoS-attack Mitigator) on a common server. The centralized DDoS- 679 attack mitigation system defends servers against DDoS attacks outside 680 the private network, that is, from public networks. 682 Servers are categorized into stateless servers (e.g., DNS servers) 683 and stateful servers (e.g., web servers). For DDoS-attack 684 mitigation, the forwarding of traffic flows in switches can be 685 dynamically configured such that malicious traffic flows are handled 686 by the paths separated from normal traffic flows in order to minimize 687 the impact of those malicious traffic on the servers. This flow path 688 separation can be done by a flow forwarding path management scheme 689 based on [AVANT-GUARD]. This management should consider the load 690 balance among the switches for the defense against DDoS attacks. 692 So far this section has described the three use cases for network- 693 based security services using the I2NSF framework with SDN networks. 694 To support these use cases in the proposed data-driven security 695 service framework, YANG data models described in 696 [consumer-facing-inf-dm], [nsf-facing-inf-dm], and 697 [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- 698 Facing Interface, and Registration Interface, respectively, along 699 with RESTCONF [RFC8040] and NETCONF [RFC6241]. 701 +--------------------+ 702 +-------------------------------------------+ | ---------------- | 703 | I2NSF User (OSS/BSS) | | | NFV | | 704 +------+------------------------------------+ | | Orchestrator +-+ | 705 | Consumer-Facing Interface | -----+---------- | | 706 +------|------------------------------------+ | | | | 707 | -----+---------- (a) ----------------- | | ----+----- | | 708 | | Security +-------+ Developer's | | | | | | | 709 | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | 710 | -----+---------- ----------------- | | | | | | 711 | | NSF-Facing Interface | | ----+----- | | 712 | ----+----- ----+----- ----+----- | | | | | 713 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | | 714 | ----+----- ----+----- ----+----- | | | | | 715 | | | | | | | | | 716 +------|-------------|-------------|--------+ | | | | 717 | | | | | | | 718 +------+-------------+-------------+--------+ | | | | 719 | NFV Infrastructure (NFVI) | | | | | 720 | ----------- ----------- ----------- | | | | | 721 | | Virtual | | Virtual | | Virtual | | | | | | 722 | | Compute | | Storage | | Network | | | | | | 723 | ----------- ----------- ----------- | | ----+----- | | 724 | +---------------------------------------+ | | | | | | 725 | | Virtualization Layer | +-----+ VIM(s) +------+ | 726 | +---------------------------------------+ | | | | | 727 | +---------------------------------------+ | | ---------- | 728 | | ----------- ----------- ----------- | | | | 729 | | | Compute | | Storage | | Network | | | | | 730 | | | Hardware| | Hardware| | Hardware| | | | | 731 | | ----------- ----------- ----------- | | | | 732 | | Hardware Resources | | | NFV Management | 733 | +---------------------------------------+ | | and Orchestration | 734 | | | (MANO) | 735 +-------------------------------------------+ +--------------------+ 736 (a) = Registration Interface 737 (b) = Ve-Vnfm Interface 739 Figure 5: I2NSF Framework Implementation with respect to the NFV 740 Reference Architectural Framework 742 7. I2NSF Framework with NFV 744 This section discusses the implementation of the I2NSF framework 745 using Network Functions Virtualization (NFV). 747 NFV is a promising technology for improving the elasticity and 748 efficiency of network resource utilization. In NFV environments, 749 NSFs can be deployed in the forms of software-based virtual instances 750 rather than physical appliances. Virtualizing NSFs makes it possible 751 to rapidly and flexibly respond to the amount of service requests by 752 dynamically increasing or decreasing the number of NSF instances. 753 Moreover, NFV technology facilitates flexibly including or excluding 754 NSFs from multiple security solution vendors according to the changes 755 on security requirements. In order to take advantages of the NFV 756 technology, the I2NSF framework can be implemented on top of an NFV 757 infrastructure as show in Figure 5. 759 Figure 5 shows an I2NSF framework implementation based on the NFV 760 reference architecture that the European Telecommunications Standards 761 Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as 762 virtual network functions (VNFs) in Figure 5. The Developer's 763 Management System (DMS) in the I2NSF framework is responsible for 764 registering capability information of NSFs into the Security 765 Controller. However, those NSFs are created or removed by a virtual 766 network functions manager (VNFM) in the NFV MANO that performs the 767 life-cycle management of VNFs. Note that the life-cycle management 768 of VNFs are out of scope for I2NSF. The Security Controller controls 769 and monitors the configurations (e.g., function parameters and 770 security policy rules) of VNFs via NSF-Facing Interface along with 771 NSF monitoring capability [nsf-facing-inf-dm][nsf-monitoring-dm]. 772 Both the DMS and Security Controller can be implemented as the 773 Element Managements (EMs) in the NFV architecture. Finally, the 774 I2NSF User can be implemented as OSS/BSS (Operational Support 775 Systems/Business Support Systems) in the NFV architecture that 776 provides interfaces for users in the NFV system. 778 The operation procedure in the I2NSF framework based on the NFV 779 architecture is as follows: 781 1. The VNFM has a set of virtual machine (VM) images of NSFs, and 782 each VM image can be used to create an NSF instance that provides 783 a set of security capabilities. The DMS initially registers a 784 mapping table of the ID of each VM image and the set of 785 capabilities that can be provided by an NSF instance created from 786 the VM image into the Security Controller. 788 2. If the Security Controller does not have any instantiated NSF 789 that has the set of capabilities required to meet the security 790 requirements from users, it searches the mapping table 791 (registered by the DMS) for the VM image ID corresponding to the 792 required set of capabilities. 794 3. The Security Controller requests the DMS to instantiate an NSF 795 with the VM image ID via VNFM. 797 4. When receiving the instantiation request, the VNFM first asks the 798 NFV orchestrator for the permission required to create the NSF 799 instance, requests the VIM to allocate resources for the NSF 800 instance, and finally creates the NSF instance based on the 801 allocated resources. 803 5. Once the NSF instance has been created by the VNFM, the DMS 804 performs the initial configurations of the NSF instance and then 805 notifies the Security Controller of the NSF instance. 807 6. After being notified of the created NSF instance, the Security 808 Controller delivers low-level security policy rules to the NSF 809 instance for policy enforcement. 811 We can conclude that the I2NSF framework can be implemented based on 812 the NFV architecture framework. Note that the registration of the 813 capabilities of NSFs is performed through the Registration Interface 814 and the lifecycle management for NSFs (VNFs) is performed through the 815 Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 5. 817 8. Security Considerations 819 The same security considerations for the I2NSF framework [RFC8329] 820 are applicable to this document. 822 This document shares all the security issues of SDN that are 823 specified in the "Security Considerations" section of [ITU-T.Y.3300]. 825 9. Acknowledgments 827 This work was supported by Institute for Information & communications 828 Technology Promotion (IITP) grant funded by the Korea government 829 (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence 830 Technology Development for the Customized Security Service 831 Provisioning). 833 This work has been partially supported by the European Commission 834 under Horizon 2020 grant agreement no. 700199 "Securing against 835 intruders and other threats through a NFV-enabled environment 836 (SHIELD)". This support does not imply endorsement. 838 10. Contributors 840 I2NSF is a group effort. I2NSF has had a number of contributing 841 authors. The following are considered co-authors: 843 o Hyoungshick Kim (Sungkyunkwan University) 844 o Jinyong Tim Kim (Sungkyunkwan University) 846 o Hyunsik Yang (Soongsil University) 848 o Younghan Kim (Soongsil University) 850 o Jung-Soo Park (ETRI) 852 o Se-Hui Lee (Korea Telecom) 854 o Mohamed Boucadair (Orange) 856 11. References 858 11.1. Normative References 860 [ETSI-NFV] 861 "Network Functions Virtualisation (NFV); Architectural 862 Framework", Available: 863 https://www.etsi.org/deliver/etsi_gs/ 864 nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 865 2013. 867 [ITU-T.Y.3300] 868 "Framework of Software-Defined Networking", 869 Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I, 870 June 2014. 872 [NFV-Terminology] 873 "Network Functions Virtualisation (NFV); Terminology for 874 Main Concepts in NFV", Available: 875 https://www.etsi.org/deliver/etsi_gs/ 876 NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf, 877 December 2014. 879 [ONF-SDN-Architecture] 880 "SDN Architecture (Issue 1.1)", Available: 881 https://www.opennetworking.org/wp- 882 content/uploads/2014/10/TR- 883 521_SDN_Architecture_issue_1.1.pdf, June 2016. 885 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 886 Network Configuration Protocol (NETCONF)", RFC 6020, 887 October 2010. 889 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 890 Bierman, "Network Configuration Protocol (NETCONF)", 891 RFC 6241, June 2011. 893 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 894 Networking: A Perspective from within a Service Provider 895 Environment", RFC 7149, March 2014. 897 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 898 (SFC) Architecture", RFC 7665, October 2015. 900 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 901 Protocol", RFC 8040, January 2017. 903 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 904 and J. Jeong, "Interface to Network Security Functions 905 (I2NSF): Problem Statement and Use Cases", RFC 8192, July 906 2017. 908 [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 909 Header (NSH)", RFC 8300, January 2018. 911 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 912 Kumar, "Framework for Interface to Network Security 913 Functions", RFC 8329, February 2018. 915 11.2. Informative References 917 [AVANT-GUARD] 918 Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- 919 GUARD: Scalable and Vigilant Switch Flow Management in 920 Software-Defined Networks", ACM CCS, November 2013. 922 [consumer-facing-inf-dm] 923 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 924 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 925 ietf-i2nsf-consumer-facing-interface-dm-03 (work in 926 progress), March 2019. 928 [ETSI-NFV-MANO] 929 "Network Functions Virtualisation (NFV); Management and 930 Orchestration", Available: 931 https://www.etsi.org/deliver/etsi_gs/nfv- 932 man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf, 933 December 2014. 935 [i2nsf-terminology] 936 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 937 Birkholz, "Interface to Network Security Functions (I2NSF) 938 Terminology", draft-ietf-i2nsf-terminology-07 (work in 939 progress), January 2019. 941 [ITU-T.X.800] 942 "Security Architecture for Open Systems Interconnection 943 for CCITT Applications", March 1991. 945 [nsf-facing-inf-dm] 946 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 947 "I2NSF Network Security Function-Facing Interface YANG 948 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03 949 (work in progress), March 2019. 951 [nsf-monitoring-dm] 952 Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, 953 "A YANG Data Model for Monitoring I2NSF Network Security 954 Functions", draft-ietf-i2nsf-nsf-monitoring-data-model-00 955 (work in progress), March 2019. 957 [opsawg-firewalls] 958 Baker, F. and P. Hoffman, "On Firewalls in Internet 959 Security", draft-ietf-opsawg-firewalls-01 (work in 960 progress), October 2012. 962 [policy-translation] 963 Yang, J., Jeong, J., and J. Kim, "Security Policy 964 Translation in Interface to Network Security Functions", 965 draft-yang-i2nsf-security-policy-translation-03 (work in 966 progress), March 2019. 968 [registration-inf-dm] 969 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 970 Registration Interface YANG Data Model", draft-ietf-i2nsf- 971 registration-interface-dm-02 (work in progress), March 972 2019. 974 [VNF-ONBOARDING] 975 "VNF Onboarding", Available: 976 https://wiki.opnfv.org/display/mano/VNF+Onboarding, 977 November 2016. 979 Appendix A. Changes from draft-ietf-i2nsf-applicability-09 981 The following changes have been made from draft-ietf-i2nsf- 982 applicability-09: 984 o This version has reflected the questions and comments from Roman 985 Danyliw who is a Security Area Director as follows. 987 o In Section 1, the description of I2NSF components and interfaces 988 is clarified with typo correction. 990 o In Section 2, unnecessary references are deleted, and the 991 definition of a term "NSF" is clarified with the I2NSF terminology 992 draft [i2nsf-terminology]. 994 o In Section 3, inside attacks at DMS or I2NSF User are described 995 clearly along with feasible counterattacks against those inside 996 attacks. Also, the usage of RESTCONF and NETCONF with YANG data 997 model language is clarified for three I2NSF interfaces such as the 998 Consumer-Facing Interface, NSF-Facing Interface, and Registration 999 Interface. 1001 o In Section 4, a real XML code for the time-dependent web access 1002 control is added for the Consumer-Facing Interface as an example. 1004 o In Section 5, the network service header (NSH) as a reference is 1005 added for the metadata format for I2NSF traffic steering based on 1006 SFC. 1008 o In Section 6, the definitions of an SDN forwarding element and an 1009 NSF are clarified. Also, the optimization of an SDN-and-NFV-based 1010 firewall is explained clearly in terms of delay and network 1011 bandwidth saving. 1013 Authors' Addresses 1015 Jaehoon Paul Jeong 1016 Department of Software 1017 Sungkyunkwan University 1018 2066 Seobu-Ro, Jangan-Gu 1019 Suwon, Gyeonggi-Do 16419 1020 Republic of Korea 1022 Phone: +82 31 299 4957 1023 Fax: +82 31 290 7996 1024 EMail: pauljeong@skku.edu 1025 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1026 Sangwon Hyun 1027 Department of Computer Engineering 1028 Chosun University 1029 309 Pilmun-daero, Dong-Gu 1030 Gwangju 61452 1031 Republic of Korea 1033 Phone: +82 62 230 7473 1034 EMail: shyun@chosun.ac.kr 1036 Tae-Jin Ahn 1037 Korea Telecom 1038 70 Yuseong-Ro, Yuseong-Gu 1039 Daejeon 305-811 1040 Republic of Korea 1042 Phone: +82 42 870 8409 1043 EMail: taejin.ahn@kt.com 1045 Susan Hares 1046 Huawei 1047 7453 Hickory Hill 1048 Saline, MI 48176 1049 USA 1051 Phone: +1-734-604-0332 1052 EMail: shares@ndzh.com 1054 Diego R. Lopez 1055 Telefonica I+D 1056 Jose Manuel Lara, 9 1057 Seville 41013 1058 Spain 1060 Phone: +34 682 051 091 1061 EMail: diego.r.lopez@telefonica.com