idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Yang 3 Internet-Draft Y. Kim 4 Intended status: Informational Soongsil University 5 Expires: May 6, 2021 J. Jeong 6 Sungkyunkwan University 7 November 2, 2020 9 I2NSF on the NFV Reference Architecture 10 draft-yang-i2nsf-nfv-architecture-06 12 Abstract 14 This document describes the integration of Interface to Network 15 Security Functions (I2NSF) Framework into the Network Functions 16 Virtualization (NFV) Reference Model. This document explains how the 17 components and interfaces in the I2NSF Framework can be placed in the 18 NFV reference architecture, and also explains the procedures of the 19 lifecycle management of Network Security Functions (NSFs) according 20 to a user's security policy specification in the I2NSF framework on 21 the NFV system. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 6, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. I2NSF framework onto the NFV Reference Model . . . . . . . . 3 60 3.1. Network Security Function . . . . . . . . . . . . . . . . 4 61 3.2. Security Controller . . . . . . . . . . . . . . . . . . . 5 62 3.3. Developer's Management System . . . . . . . . . . . . . . 5 63 3.4. I2NSF Interfaces . . . . . . . . . . . . . . . . . . . . 5 64 3.4.1. Consumer-Facing Interface . . . . . . . . . . . . . . 5 65 3.4.2. NSF-Facing Interface . . . . . . . . . . . . . . . . 6 66 3.4.3. Registration Interface . . . . . . . . . . . . . . . 6 67 3.4.4. Interface for NSF Management . . . . . . . . . . . . 6 68 4. Initial Configuration Procedure in NFV Architecture . . . . . 6 69 5. Multi-site Consideration . . . . . . . . . . . . . . . . . . 10 70 6. Cloud Native NFV Architecture . . . . . . . . . . . . . . . . 10 71 7. Use Case of SFC-Enabled I2NSF Framework . . . . . . . . . . . 11 72 7.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 11 73 7.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 12 74 7.3. Developer's Management System in SFC-Enabled I2NSF 75 Framework . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.4. The consideration of SFC-enabled architecture in I2NSF 77 Framework . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 11. Informative References . . . . . . . . . . . . . . . . . . . 13 82 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-05 . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The goal of Interface to Network Security Functions (I2NSF) is to 88 define a set of software interfaces and components for controlling 89 and monitoring aspects of physical and virtual Network Security 90 Functions (NSFs), with which a user can specify high-level security 91 policy. To achieve this goal, the I2NSF framework not only considers 92 physical infrastructure, but also considers a Network Functions 93 Virtualization (NFV) environment since an NSF may be provided by 94 virtualized infrastructure as a Virtual Network Function (VNF). 95 Especially, the I2NSF applicability document [I2NSF-Applicability] 96 describes the applicability of I2NSF to network-based security 97 services in an NFV environment. Although it explains how I2NSF 98 framework in an NFV environment for security services, it does not 99 explain the procedures of the lifecycle management of NSFs in detail. 100 Thus, this document explains such procedures in the I2NSF framework 101 on the NSF system along with the places of the components of the 102 I2NSF framework in the NFV system. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. This 109 document uses the terminology described in [RFC8329], 110 [I2NSF-Applicability], [ETSI-GS-NFV-003], [Registration-Interface], 111 and [ETSI-GS-IFA-008]. 113 3. I2NSF framework onto the NFV Reference Model 115 The European Telecommunications Standards Institute (ETSI) defined 116 the components for the basic NFV architecture including the NFV 117 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 118 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO) 119 [ETSI-GS-NFV-003]. NFVI provides the virtual resources, such as a 120 Virtual Machine (VM) and a Virtual Network, which are used to create, 121 update, and delete VNFs running applications. VNFs are implemented 122 through software virtualization techniques running over the NFVI. 124 Virtualized Infrastructure Manager (VIM) has a function for 125 controlling and managing the NFVI compute, storage and network nodes, 126 within one operator's infrastructure sub-domain. It also collects 127 and forwards performance measurement data and events. 129 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 130 manages the VNF instance in the lifecycle, and the VNFM performs 131 several actions such as software update/modification, monitoring data 132 collection (e.g., fault event in the VNF, and instance termination). 134 In [RFC8329], the I2NSF framework has four components (i.e., I2NSF 135 User, Security Controller, NSF, and Developer's Management System 136 (DMS)) along with three main interfaces (i.e., Consumer-Facing 137 Interface, NSF-Facing Interface, and Registration Interface). To 138 adopt these components to the NFV reference architecture, each 139 component should be classified based on functionality. According to 140 component functionality, it would correspond to NFV reference 141 architecture components as Figure 1. 143 +--------------------+ 144 +-------------------------------------------+ | ---------------- | 145 | OSS/BSS | | | NFV | | 146 +---------+---------------------------------+ | | Orchestrator +-+| 147 | (b) | +--+-----------+ || 148 +---------|---------------------------------+ | | || 149 | +------+------+ +-----------------+ | | | || 150 | | Security | | Developer's Mgmt| | | | || 151 | | Controller +--(a)-+ System(EM) | | | | || 152 | +------+------+ +-----------------+ | | +--+---------+ || 153 | | (c) | | | | || 154 | +---+----+ +---+----+ +---+----+ +-(d)-+ VNFM | || 155 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | || 156 | | | | | | | | | +--+---------+ || 157 | +--------+ +--------+ +--------+ | | | || 158 +-------------------------------------------+ | | || 159 +-------------------------------------------+ | | || 160 | NFV Infrastructure (NFVI) | | | || 161 | +---------+ +---------+ +---------+ | | | || 162 | | Virtual | | Virtual | | Virtual | | | | || 163 | | Compute | | Storage | | Network | | | | || 164 | +---------+ +---------+ +---------+ | | +--+-----+ || 165 | +---------------------------------------+ | | | | || 166 | | Virtualization Layer | +-----+ VIM(s) +-------+| 167 | +---------------------------------------+ | | | | | 168 | +---------------------------------------+ | | +--------+ | 169 | | +---------+ +---------+ +---------+ | | | | 170 | | | Compute | | Storage | | Network | | | | | 171 | | | Hardware| | Hardware| | Hardware| | | | | 172 | | +---------+ +---------+ +---------+ | | | NFV Management | 173 | | Hardware Resources | | | and Orchestration | 174 | +---------------------------------------+ | | (MANO) | 175 +-------------------------------------------+ +--------------------+ 176 (a) = Registration Interface, (b) = Consumer-Facing Interface 177 (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface 179 Figure 1: I2NSF Framework on NFV Reference Architecture 181 3.1. Network Security Function 183 A Network Security Function (NSF) is one of the security service 184 functions. In the ETSI reference architecture, a VNF is a network 185 function which provides a specific service. Therefore, an NSF 186 corresponds to a VNF in the NFV reference architecture. 188 3.2. Security Controller 190 According to an I2NSF framework, Security Controller has a role to 191 translate an I2NSF User's high-level security policy into a low-level 192 security policy for an NSF. It also collects an NSF's capability 193 information from DMS. Based on the features of the I2NSF framework, 194 Security Controller receives a high-level security policy from an 195 I2NSF user over Consumer-Facing Interface, and after the security 196 policy translation, it can forward the corresponding low-level 197 security policy to an appropriate NSF over NSF-Facing Interface. 199 In the NFV reference architecture, Element Management (EM) has a role 200 to manage its service function (e.g., firewall, Deep Packet 201 Inspection, DDoS-attack mitigator) and collaborate with the VNF 202 Manager for the lifecycle management (e.g., the instantiation and de- 203 instantiation) of a VNF corresponding to the required security 204 function. This lifecycle management requires the exchange of 205 information regarding the NFVI resources associated with the VNF. EM 206 performs typical management functionality for its own VNFs. 208 This document proposes that Security Controller can be implemented as 209 an EM that can give a security policy to an NSF, and control the NSF. 210 Note that from the perspective of implementation, it can also be 211 configured as an independent component in the NFV system. 213 3.3. Developer's Management System 215 According to the definition of I2NSF Registration Interface, DMS 216 registers its NSF, which can be provided by a specific vendor, into 217 Security Controller along with the capability of the NSF. 219 In the NFV reference architecture, when a general VNFM creates and 220 manages an NSF, DMS can be used as an EM to manage the specific 221 function of an NSF. 223 3.4. I2NSF Interfaces 225 3.4.1. Consumer-Facing Interface 227 The Consumer-Facing Interface is an interface for communication 228 between I2NSF User and Security Controller. It is used to enable 229 different I2NSF Users in a given I2NSF system to define, manage, and 230 monitor security policies for specific flows within an administrative 231 domain. 233 In the NFV reference architecture, Operational Support Systems (OSS) 234 and Business Support Systems (BSS) are used to manipulate their 235 applications (e.g., security services) with their policies and rules. 237 OSS and BSS support a user-domain-specific system for users, such as 238 security enforcement, billing, order, and metering. 240 Although an interface is not defined between an I2NSF User and a VNF 241 in the NFV reference architecture, Consumer-Facing interface can be 242 deployed for the interaction between an I2NSF user and an VNF, as 243 illustrated in Figure 1. 245 3.4.2. NSF-Facing Interface 247 The NSF-Facing Interface is an interface for communication between 248 Security Controller and NSF. It is used to specify and monitor flow- 249 based security policies enforced by one or more NSFs. In the NFV 250 reference architecture, Software Architecture (SWA)-4 Interface is 251 defined. The interface SWA-4 is used by the EM to communicate with a 252 VNF. This management interface is used for the runtime management of 253 the VNF according to Fulfillment, Assurance, Billing, and FCAPS 254 (Fault, Configuration, Accounting, Performance, Security) network 255 management models and frameworks. Therefore, NSF-Facing Interface 256 corresponds to the SWA-4 interface. 258 3.4.3. Registration Interface 260 Registration Interface is used to register an NSF from DMS System to 261 Security Controller. An NSF's capabilities can either be pre- 262 configured or retrieved dynamically through the I2NSF Registration 263 Interface. Also, it is to search an appropriate NSF with the 264 required capability that can execute the requested security service. 266 In the NFV reference architecture, an interface is not defined 267 between EM, the registraion-interface can be deployed like a 268 Figure 1. 270 3.4.4. Interface for NSF Management 272 In this model, DMS needs to communicate with VNFM to create an NSF 273 dynamically. This interface is not defined in the I2NSF framework, 274 since it is out of the scope of the I2NSF. However, ETSI defined an 275 interface "Ve-Vnfm" between EM and VNFM [ETSI-GS-IFA-008]. 276 Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to 277 communicate with VNFM. 279 4. Initial Configuration Procedure in NFV Architecture 281 The security service procedure in the proposed architecture is as 282 follows. When an I2NSF User requests a security service to Security 283 Controller with a high-level policy, Security Controller translates 284 the high-level policy into the corresponding low-level policy. Then, 285 it searches the NSF list with capabilities for the requested security 286 service according to the low-level policy. In this step, there are 287 two use cases. 289 As shown in Figure 2, the first case is the case that when an NSF 290 with the required capability is in active state. The second case is 291 the case that when an NSF with required capability is in inactive 292 state. When the NSF is in active state, Security Controller 293 generates a low-level policy and forwards it to the NSF to set the 294 low-level policy up. On the other hand, when the NSF is in inactive 295 state, Security Controller sends an NSF initiation request message to 296 the DMS via Registration Interface and DMS analyzes the message 297 according to the vendor's configuration [Registration-Interface]. 298 After that, DMS forwards the NSF initiation request message to VNFM 299 via Ve-Vnfm Interface [ETSI-GS-IFA-008]. After the initiation of the 300 NSF, VNFM sends back an NSF initiation response message to Security 301 Controller with an NSF's access information (e.g., IP address, 302 transport-layer protocol, port number, and the NSF's name). With the 303 received NSF access information, Security Controller generates a low- 304 level policy and forwards it to the NSF to set the security policy 305 up. 307 I2NSF Security Developer's VNFM NSF 308 User Controller Mgmt System 309 | | | | | 310 | | | | | 311 |--High-level-->| | | | 312 |policy Request | | | | 313 | | | | | 314 | | | | | 315 | | | | | 316 | Translation: | | | 317 | Data Conversion | | | 318 | | | | | 319 | | | | | 320 case 1: NSFs available(activated) : Go to Policy Generation | 321 | | | | | 322 |++case 2: NSFs available(de-activated)+++++++++++++| | 323 | | | | | 324 | |-NSF initiation->| | | 325 | | Request(Reg) |-------NSF initiation----->| 326 | | | Request(Ve-Vnfm) | 327 | | | | NSF 328 | | | | Creation 329 | | | | | 330 | | |<------NSF initiation------| 331 | |<-NSF initiation-| Response(Ve-Vnfm) | 332 | | Response(Reg) | | | 333 | | | | | 334 |++case 2: NSFs available(de-activated)+++++++++++++| | 335 | | | | | 336 | Translation: | | | 337 | Policy Generation | | | 338 | | | | | 339 | | | | | 340 | |---------Low-level policy Request----------->| 341 | |<--------Low-level policy Response-----------| 342 | | | | | 343 | | | | | 344 | | | | | 345 | | | | | 346 | | | | | 347 | | | | | 348 | | | | | 349 | | | | | 351 Figure 2: Procedure of I2NSF Framework on NFV for the Case of 'NSF 352 Available' 354 I2NSF Security Developer's VNFM NSF 355 User Controller Mgmt System 356 | | | | | 357 |--High-level-->| | | | 358 |policy Request | | | | 359 | | | | | 360 | Translation: | | | 361 | Data Conversion | | | 362 | | | | | 363 | Profile Entry | | | 364 | not matched | | | 365 | | | | | 366 | |Capability Query->| | | 367 | | | | | 368 |++case 1: Capability not Searched+++++++++++++++++++| | 369 | | | | | 370 | |<--No-NSF-found---| | | 371 | | Reply | | | 372 |<--High-level--| | | | 373 policy Response(failure) | | | 374 | | | | | 375 |++case 1: Capability not Searched+++++++++++++++++++| | 376 | | | | | 377 | +case 2: Capability not Searched++++++++++++++++++++++ | 378 | | | | | | 379 | | |--NSF Creation--->| | | 380 | | | Request(Reg) |-------NSF Creation------->| 381 | | | | Request(Ve-Vnfm) | 382 | | | | | NSF 383 | | | | | Creation 384 | | | | | | 385 | | | |<------NSF Creation--------| 386 | | |<--NSF Creation---| Response(Ve-Vnfm) | 387 | | | Response(Reg) | (with NSF info) | 388 | | | | | | 389 | | Translation: | | | 390 | | Policy Generation | | | 391 | | | | | | 392 | | |----------Low-level policy Request----------->| 393 | | |<---------Low-level policy Response-----------| 394 | | | | | | 395 |<--High-level--| | | | 396 policy Response(Success) | | | 397 | | | | | | 399 Figure 3: Procedure of I2NSF Framework on NFV for the Case of 'No NSF 400 Existing' 402 However, when the NSF does not exist, The procedure is as follows. 403 As shown in Figure 3, when an NSF does not exist, Security Controller 404 sends a Capability Query message to DMS to search for an NSF with the 405 requested capability. When DMS does not find such an NSF, the 406 procedure is terminated after sending Security Controller a failure 407 notification message, which means that it does not have any NSF with 408 the requested capability. On the other hand, When there exists an 409 NSF corresponding to the requested capability, DMS sends an NSF 410 creation request message to the VNFM. After the creation of the NSF 411 as a VNF, it is registered into DMS. DMS registers the NSF with 412 capability and access information into Security Controller via 413 Registration Interface. The remaining procedure is the same as the 414 previous case. 416 5. Multi-site Consideration 418 The previous section described how the I2NSF framework is plugged 419 into the NFV architecture in a single site. From the perspective of 420 NFV, when security functions are deployed, it might be deployed at a 421 single site or multiple sites. 423 Basically, the I2NSF framework only considers that a single DMS could 424 manage all its NSFs. From the perspective of ETSI reference 425 architecture, when NSFs are deployed at a multi-site environment, a 426 DMS could manage all of the NSFs in such an environment in the same 427 way of a single site. Alternatively, multiple DMSs could manage the 428 NSFs together. The I2NSF framework only considers a single Security 429 Controller that manages all the NSFs in its management domain. This 430 implies that one Security Controller as an EM should be located at 431 the domain. 433 However, from the perspective of ETSI reference architecture, an EM 434 usually is located at each site and controls a VNF which belongs to 435 that site. The I2NSF framework should consider the placement of 436 Security Controller in a multi-site environment, since there is a 437 conflict between the I2NSF framework and the ETSI NFV reference 438 architecture regarding the placement of Security Controller as an EM. 440 6. Cloud Native NFV Architecture 442 To consider the perspective of a cloud native environment, the NFV 443 architecture for I2NSF needs to accommodate an I2NSF framework in a 444 cloud native NFV architecture. ETSI defines NFV reference 445 architecture in a cloud native environment based on [ETSI-NFV-IFA29]. 447 In addition, this standardization is in progress based on 448 [ETSI-NFV-IFA40], [ETSI-NFV-IFA10] and [ETSI-NFV-IFA11]. 450 Based on these standard documents, the functions for resource 451 management and infrastructure management in the cloud native 452 environment are defined, and various types of architectures are 453 proposed. To apply the I2NSF framework to a cloud native 454 environment, the cloud native NFV architecture needs to manage each 455 virtual resource, map it into the corresponding NSF, and register the 456 capability of such an NSF with the I2NSF framework. It also needs to 457 define the interfaces between the I2NSF framework and the cloud 458 native NFV architecture. 460 7. Use Case of SFC-Enabled I2NSF Framework 462 A service service in the I2NSF applicability in 463 [I2NSF-Applicability]> requires a forwarding mechanism for cloud- 464 based security services. Especially, a Service Function Chaining 465 (SFC)-enabled I2NSF Architecture in [I2NSF-Applicability] shows a use 466 case that uses SFC as a forwarding mechanism. In addition, it 467 specifies SFC components for I2NSF-based sercurity services (e.g., 468 Classifier and Service Function Forwarder (SFF)) and defines the 469 required functionality of the components. Therefore, the following 470 subsections explain the details of each component and consider how it 471 corresponds to the NFV reference architecture. 473 7.1. SFC Policy Manager 475 SFC Policy Manager is a part of Security Controller. It is 476 responsible for interpreting a high-level security policy into a low- 477 level security policy, which is given by I2NSF User. It also handles 478 the delivery of the interpreted policy to SFC Classifier(s) for 479 security function chaining. Moreover, it also generates the 480 information of the security function chaining for the requested 481 security service to SFF(s). 483 In the NFV reference architecture, Management and Orchestration 484 (MANO) performs similar functions as the SFC Policy Manager. More 485 specifically, the NFV Orchestrator (NFVO) performs on-boarding of a 486 new Network Service (NS), VNF-FG (Forwarding Graph), and VNF 487 Packages. In addition, it manages NS lifecycle (including 488 instantiation, scale-out/in, performance measurement, event 489 correlation, and termination). 491 Therefore, SFC Policy Manager corresponds to NFVO. In addition, if 492 SFC Policy Manager is a part of Security Controller, this function 493 should be separated from Security Controller, and then be placed in 494 MANO. 496 7.2. SFC Catalog Manager 498 SFC Catalog Manager is a part of Security Controller. It is 499 responsible for maintaining the information of every available SF 500 instance such as IP address, transport-layer protocol, port number, 501 service name, and load status. Moreover, it should respond to the 502 queries for available NSF instances from SFC Policy Manager in order 503 to help the generation of a forwarding table entry relevant to a 504 given SFP. It also requests DMS to dynamically instantiate 505 additional SF instances in order to avoid service congestion in an 506 NSF or the elimination of an idle NSF instance to avoid resource 507 waste. 509 In the NFV reference architecture, SFC Catalog Manager corresponds to 510 an EM since the information related to VNF capability is managed by 511 the EM. Moreover, its functions are similar to Security Controller's 512 as explained before. 514 7.3. Developer's Management System in SFC-Enabled I2NSF Framework 516 In the SFC-enabled document, the functions of DMS are extended. For 517 the request message from SFC Catalog Manager, DMS creates additional 518 NSF instances for load balancing and eliminates some of idle NSF 519 instances. 521 As mentioned above, if DMS manages the NSF's lifecycle indirectly 522 with VNFM, it play a role of a VNFM. VNF lifecycle management 523 includes the instantiation, creation, provisioning, scaling, 524 monitoring, and termination of a VM as a VNF instance. Therefore, 525 DMS corresponds to a specific VNFM. 527 However, for the scaling performance at a network service level, the 528 role of DMS can be a part of MANO. 530 7.4. The consideration of SFC-enabled architecture in I2NSF Framework 532 As mentioned above, when the I2NSF is provided in an NFV environment, 533 various use cases can be provided through SFC technology. 535 As an NFV point of view, SFC can be provided in two ways. The first 536 way is to configure the SFC between NSF through the individual SDN 537 controller, and the second is to configure the SFC through the 538 network management function in the cloud. 540 The way to provide traffic steering capabilities may vary depending 541 on the cloud environment, but the Security Controller must request 542 traffic steering to the SDN controller or network function management 543 via VNFM (using Ve-Vnfm interface). Traffic steering can be provided 544 through physical switches or Virtual Switch. 546 8. Security Considerations 548 This document specifies the implementation of the I2NSF framework in 549 the NFV system, so the same security considerations for the I2NSF 550 framework [RFC8329] can be applied to this document. 552 This document shares all the security issues of NFV that are 553 specified in the "Potential Areas of Concern" section of 554 [ETSI-GS-NFV-SEC-001]. 556 9. IANA Considerations 558 This document does not require any IANA actions. 560 10. Acknowledgements 562 This work was supported by the Ministry of Science and ICT (MSIT) 563 under the ITRC (Information Technology Research Center) support 564 program (IITP-2020-2017-0-01633) supervised by the Institute for 565 Information & Communications Technology Planning & Evaluation (IITP). 566 This work was supported in part by the IITP grant funded by the MSIT 567 (2020-0-00395, Standard Development of Blockchain based Network 568 Management Automation Technology). 570 11. Informative References 572 [ETSI-GS-IFA-008] 573 "Network Functions Virtualisation (NFV);Management and 574 Orchestration;Ve-Vnfm reference point - Interface 575 andInformation Model Specification", October 2016. 577 [ETSI-GS-NFV-003] 578 "Network Functions Virtualization (NFV); Architectural 579 Framework", October 2013. 581 [ETSI-GS-NFV-SEC-001] 582 "Network Functions Virtualisation (NFV); NFV Security; 583 Problem Statement", October 2014. 585 [ETSI-NFV-IFA10] 586 "Network Functions Virtualisation (NFV) Release 587 3;Management and Orchestration;Functional requirements 588 specification", April 2019. 590 [ETSI-NFV-IFA11] 591 "Network Functions Virtualisation (NFV) Release 592 4;Management and Orchestration;VNF Descriptor and 593 Packaging Specification", September 2020. 595 [ETSI-NFV-IFA29] 596 "Network Functions Virtualisation (NFV) Release 3; 597 Architecture; Report on the Enhancements of the NFV 598 architecture towards "Cloud-native" and "PaaS"", November 599 2019. 601 [ETSI-NFV-IFA40] 602 "Network Functions Virtualisation (NFV) Release 4; 603 Management and Orchestration; Requirements for service 604 interfaces and object model for OS container management 605 and orchestration specification", March 2020. 607 [I2NSF-Applicability] 608 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 609 "Applicability of Interfaces to Network Security Functions 610 to Network-Based Security Services", draft-ietf-i2nsf- 611 applicability-18 (work in progress), September 2019. 613 [Registration-Interface] 614 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 615 Registration Interface YANG Data Model", draft-ietf-i2nsf- 616 registration-interface-dm-09 (work in progress), August 617 2020. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", RFC 2119, March 1997. 622 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 623 Kumar, "Framework for Interface to Network Security 624 Functions", RFC 8329, February 2018. 626 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-05 628 The following changes have been made from draft-yang-i2nsf-nfv- 629 architecture-05: 631 o This version includes a cloud native reference architecture to 632 accommodate an I2NSF framework in Section 6. 634 Authors' Addresses 636 Hyunsik Yang 637 School of Electronic Engineering 638 Soongsil University 639 369, Sangdo-ro, Dongjak-gu 640 Seoul, Seoul 06978 641 Republic of Korea 643 Phone: +82 10 9005 7439 644 EMail: yangun@dcn.ssu.ac.kr 646 Younghan Kim 647 School of Electronic Engineering 648 Soongsil University 649 369, Sangdo-ro, Dongjak-gu 650 Seoul, Seoul 06978 651 Republic of Korea 653 Phone: +82 10 2691 0904 654 EMail: younghak@ssu.ac.kr 656 Jaehoon Paul Jeong 657 Department of Computer Science and Engineering 658 Sungkyunkwan University 659 2066 Seobu-Ro, Jangan-Gu 660 Suwon, Gyeonggi-Do 16419 661 Republic of Korea 663 Phone: +82 31 299 4957 664 Fax: +82 31 290 7996 665 EMail: pauljeong@skku.edu 666 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php