idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-08.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (20 May 2022) is 706 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-i2nsf-applicability-13 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-06 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-01 Summary: 1 error (**), 0 flaws (~~), 5 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 KT 4 Intended status: Informational K. Sun 5 Expires: 21 November 2022 Y. Kim 6 Soongsil University 7 J. Jeong 8 Sungkyunkwan University 9 20 May 2022 11 I2NSF on the NFV Reference Architecture 12 draft-yang-i2nsf-nfv-architecture-08 14 Abstract 16 This document describes the integration of Interface to Network 17 Security Functions (I2NSF) Framework into the Network Functions 18 Virtualization (NFV) Reference Model. This document explains how the 19 components and interfaces in the I2NSF Framework can be placed in the 20 NFV reference architecture, and also explains the procedures of the 21 lifecycle management of Network Security Functions (NSFs) according 22 to a user's security policy specification in the I2NSF framework on 23 the NFV system. 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 21 November 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. I2NSF framework onto the NFV Reference Model . . . . . . . . 3 61 3.1. Network Security Function . . . . . . . . . . . . . . . . 5 62 3.2. Security Controller . . . . . . . . . . . . . . . . . . . 5 63 3.3. Developer's Management System . . . . . . . . . . . . . . 5 64 3.4. I2NSF Interfaces . . . . . . . . . . . . . . . . . . . . 5 65 3.4.1. Consumer-Facing Interface . . . . . . . . . . . . . . 6 66 3.4.2. NSF-Facing Interface . . . . . . . . . . . . . . . . 6 67 3.4.3. Registration Interface . . . . . . . . . . . . . . . 6 68 3.4.4. Interface for NSF Management . . . . . . . . . . . . 7 69 4. Initial Configuration Procedure in NFV Architecture . . . . . 7 70 5. Multi-site Consideration . . . . . . . . . . . . . . . . . . 10 71 6. Cloud Native NFV Architecture . . . . . . . . . . . . . . . . 11 72 6.1. The consideration of the Yang data model in the Container 73 environment . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Use Case of SFC-Enabled I2NSF Framework . . . . . . . . . . . 13 75 7.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 13 76 7.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 14 77 7.3. Developer's Management System in SFC-Enabled I2NSF 78 Framework . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.4. The consideration of SFC-enabled architecture in I2NSF 80 Framework . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. Informative References . . . . . . . . . . . . . . . . . . . 15 83 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-05 . 17 84 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The goal of Interface to Network Security Functions (I2NSF) is to 90 define a set of software interfaces and components for controlling 91 and monitoring aspects of physical and virtual Network Security 92 Functions (NSFs), with which a user can specify high-level security 93 policy. To achieve this goal, the I2NSF framework not only considers 94 physical infrastructure, but also considers a Network Functions 95 Virtualization (NFV) environment since an NSF may be provided by 96 virtualized infrastructure as a Virtual Network Function (VNF). 97 Especially, the I2NSF applicability document [I2NSF-Applicability] 98 describes the applicability of I2NSF to network-based security 99 services in an NFV environment. Although it explains how I2NSF 100 framework in an NFV environment for security services, it does not 101 explain the procedures of the lifecycle management of NSFs in detail. 102 Thus, this document explains such procedures in the I2NSF framework 103 on the NSF system along with the places of the components of the 104 I2NSF framework in the NFV system. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. This 111 document uses the terminology described in [RFC8329] 112 [I2NSF-Terminology], [I2NSF-Applicability], [ETSI-GS-NFV-003], 113 [Registration-Interface], [ETSI-GS-IFA-008], and 114 [NSF-Triggered-Steering]. 116 3. I2NSF framework onto the NFV Reference Model 118 The European Telecommunications Standards Institute (ETSI) defined 119 the components for the basic NFV architecture including the NFV 120 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 121 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO) 122 [ETSI-GS-NFV-003]. NFVI provides the virtual resources, such as a 123 Virtual Machine (VM) and a Virtual Network, which are used to create, 124 update, and delete VNFs running applications. VNFs are implemented 125 through software virtualization techniques running over the NFVI. 127 Virtualized Infrastructure Manager (VIM) has a function for 128 controlling and managing the NFVI compute, storage and network nodes, 129 within one operator's infrastructure sub-domain. It also collects 130 and forwards performance measurement data and events. 132 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 133 manages the VNF instance in the lifecycle, and the VNFM performs 134 several actions such as software update/modification, monitoring data 135 collection (e.g., fault event in the VNF, and instance termination). 137 In [RFC8329], the I2NSF framework has four components (i.e., I2NSF 138 User, Security Controller, NSF, and Developer's Management System 139 (DMS)) along with three main interfaces (i.e., Consumer-Facing 140 Interface, NSF-Facing Interface, and Registration Interface). To 141 adopt these components to the NFV reference architecture, each 142 component should be classified based on functionality. According to 143 component functionality, it would correspond to NFV reference 144 architecture components as Figure 1. 146 +--------------------+ 147 +-------------------------------------------+ | ---------------- | 148 | OSS/BSS | | | NFV | | 149 +---------+---------------------------------+ | | Orchestrator +-+| 150 | (b) | +--+-----------+ || 151 +---------|---------------------------------+ | | || 152 | +------+------+ +-----------------+ | | | || 153 | | Security | | Developer's Mgmt| | | | || 154 | | Controller +--(a)-+ System(EM) | | | | || 155 | +------+------+ +-----------------+ | | +--+---------+ || 156 | | (c) | | | | || 157 | +---+----+ +---+----+ +---+----+ +-(d)-+ VNFM | || 158 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | || 159 | | | | | | | | | +--+---------+ || 160 | +--------+ +--------+ +--------+ | | | || 161 +-------------------------------------------+ | | || 162 +-------------------------------------------+ | | || 163 | NFV Infrastructure (NFVI) | | | || 164 | +---------+ +---------+ +---------+ | | | || 165 | | Virtual | | Virtual | | Virtual | | | | || 166 | | Compute | | Storage | | Network | | | | || 167 | +---------+ +---------+ +---------+ | | +--+-----+ || 168 | +---------------------------------------+ | | | | || 169 | | Virtualization Layer | +-----+ VIM(s) +-------+| 170 | +---------------------------------------+ | | | | | 171 | +---------------------------------------+ | | +--------+ | 172 | | +---------+ +---------+ +---------+ | | | | 173 | | | Compute | | Storage | | Network | | | | | 174 | | | Hardware| | Hardware| | Hardware| | | | | 175 | | +---------+ +---------+ +---------+ | | | NFV Management | 176 | | Hardware Resources | | | and Orchestration | 177 | +---------------------------------------+ | | (MANO) | 178 +-------------------------------------------+ +--------------------+ 179 (a) = Registration Interface, (b) = Consumer-Facing Interface 180 (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface 182 Figure 1: I2NSF Framework on NFV Reference Architecture 184 3.1. Network Security Function 186 A Network Security Function (NSF) is one of the security service 187 functions. In the ETSI reference architecture, a VNF is a network 188 function which provides a specific service. Therefore, an NSF 189 corresponds to a VNF in the NFV reference architecture. 191 3.2. Security Controller 193 According to an I2NSF framework, Security Controller has a role to 194 translate an I2NSF User's high-level security policy into a low-level 195 security policy for an NSF. It also collects an NSF's capability 196 information from DMS. Based on the features of the I2NSF framework, 197 Security Controller receives a high-level security policy from an 198 I2NSF user over Consumer-Facing Interface, and after the security 199 policy translation, it can forward the corresponding low-level 200 security policy to an appropriate NSF over NSF-Facing Interface. 202 In the NFV reference architecture, Element Management (EM) has a role 203 to manage its service function (e.g., firewall, Deep Packet 204 Inspection, DDoS-attack mitigator) and collaborate with the VNF 205 Manager for the lifecycle management (e.g., the instantiation and de- 206 instantiation) of a VNF corresponding to the required security 207 function. This lifecycle management requires the exchange of 208 information regarding the NFVI resources associated with the VNF. EM 209 performs typical management functionality for its own VNFs. 211 This document proposes that Security Controller can be implemented as 212 an EM that can give a security policy to an NSF, and control the NSF. 213 Note that from the perspective of implementation, it can also be 214 configured as an independent component in the NFV system. 216 3.3. Developer's Management System 218 According to the definition of I2NSF Registration Interface, DMS 219 registers its NSF, which can be provided by a specific vendor, into 220 Security Controller along with the capability of the NSF. 222 In the NFV reference architecture, when a general VNFM creates and 223 manages an NSF, DMS can be used as an EM to manage the specific 224 function of an NSF. 226 3.4. I2NSF Interfaces 227 3.4.1. Consumer-Facing Interface 229 The Consumer-Facing Interface is an interface for communication 230 between I2NSF User and Security Controller. It is used to enable 231 different I2NSF Users in a given I2NSF system to define, manage, and 232 monitor security policies for specific flows within an administrative 233 domain. 235 In the NFV reference architecture, Operational Support Systems (OSS) 236 and Business Support Systems (BSS) are used to manipulate their 237 applications (e.g., security services) with their policies and rules. 238 OSS and BSS support a user-domain-specific system for users, such as 239 security enforcement, billing, order, and metering. 241 Although an interface is not defined between an I2NSF User and a VNF 242 in the NFV reference architecture, Consumer-Facing interface can be 243 deployed for the interaction between an I2NSF user and an VNF, as 244 illustrated in Figure 1. 246 3.4.2. NSF-Facing Interface 248 The NSF-Facing Interface is an interface for communication between 249 Security Controller and NSF. It is used to specify and monitor flow- 250 based security policies enforced by one or more NSFs. In the NFV 251 reference architecture, Software Architecture (SWA)-4 Interface is 252 defined. The interface SWA-4 is used by the EM to communicate with a 253 VNF. This management interface is used for the runtime management of 254 the VNF according to Fulfillment, Assurance, Billing, and FCAPS 255 (Fault, Configuration, Accounting, Performance, Security) network 256 management models and frameworks. Therefore, NSF-Facing Interface 257 corresponds to the SWA-4 interface. 259 3.4.3. Registration Interface 261 Registration Interface is used to register an NSF from DMS System to 262 Security Controller. An NSF's capabilities can either be pre- 263 configured or retrieved dynamically through the I2NSF Registration 264 Interface. Also, it is to search an appropriate NSF with the 265 required capability that can execute the requested security service. 267 In the NFV reference architecture, an interface is not defined 268 between EM, the registraion-interface can be deployed like a 269 Figure 1. 271 3.4.4. Interface for NSF Management 273 In this model, DMS needs to communicate with VNFM to create an NSF 274 dynamically. This interface is not defined in the I2NSF framework, 275 since it is out of the scope of the I2NSF. However, ETSI defined an 276 interface "Ve-Vnfm" between EM and VNFM [ETSI-GS-IFA-008]. 277 Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to 278 communicate with VNFM. 280 4. Initial Configuration Procedure in NFV Architecture 282 The security service procedure in the proposed architecture is as 283 follows. When an I2NSF User requests a security service to Security 284 Controller with a high-level policy, Security Controller translates 285 the high-level policy into the corresponding low-level policy. Then, 286 it searches the NSF list with capabilities for the requested security 287 service according to the low-level policy. In this step, there are 288 two use cases. 290 As shown in Figure 2, the first case is the case that when an NSF 291 with the required capability is in active state. The second case is 292 the case that when an NSF with required capability is in inactive 293 state. When the NSF is in active state, Security Controller 294 generates a low-level policy and forwards it to the NSF to set the 295 low-level policy up. On the other hand, when the NSF is in inactive 296 state, Security Controller sends an NSF initiation request message to 297 the DMS via Registration Interface and DMS analyzes the message 298 according to the vendor's configuration [Registration-Interface]. 299 After that, DMS forwards the NSF initiation request message to VNFM 300 via Ve-Vnfm Interface [ETSI-GS-IFA-008]. After the initiation of the 301 NSF, VNFM sends back an NSF initiation response message to Security 302 Controller with an NSF's access information (e.g., IP address, 303 transport-layer protocol, port number, and the NSF's name). With the 304 received NSF access information, Security Controller generates a low- 305 level policy and forwards it to the NSF to set the security policy 306 up. 308 I2NSF Security Developer's VNFM NSF 309 User Controller Mgmt System 310 | | | | | 311 | | | | | 312 |--High-level-->| | | | 313 |policy Request | | | | 314 | | | | | 315 | | | | | 316 | | | | | 317 | Translation: | | | 318 | Data Conversion | | | 319 | | | | | 320 | | | | | 321 case 1: NSFs available(activated) : Go to Policy Generation | 322 | | | | | 323 |++case 2: NSFs available(de-activated)+++++++++++++| | 324 | | | | | 325 | |-NSF initiation->| | | 326 | | Request(Reg) |-------NSF initiation----->| 327 | | | Request(Ve-Vnfm) | 328 | | | | NSF 329 | | | | Creation 330 | | | | | 331 | | |<------NSF initiation------| 332 | |<-NSF initiation-| Response(Ve-Vnfm) | 333 | | Response(Reg) | | | 334 | | | | | 335 |++case 2: NSFs available(de-activated)+++++++++++++| | 336 | | | | | 337 | Translation: | | | 338 | Policy Generation | | | 339 | | | | | 340 | | | | | 341 | |---------Low-level policy Request----------->| 342 | |<--------Low-level policy Response-----------| 343 | | | | | 344 | | | | | 345 | | | | | 346 | | | | | 347 | | | | | 348 | | | | | 349 | | | | | 350 | | | | | 352 Figure 2: Procedure of I2NSF Framework on NFV for the Case of 353 'NSF Available' 355 I2NSF Security Developer's VNFM NSF 356 User Controller Mgmt System 357 | | | | | 358 |--High-level-->| | | | 359 |policy Request | | | | 360 | | | | | 361 | Translation: | | | 362 | Data Conversion | | | 363 | | | | | 364 | Profile Entry | | | 365 | not matched | | | 366 | | | | | 367 | |Capability Query->| | | 368 | | | | | 369 |++case 1: Capability not Searched+++++++++++++++++++| | 370 | | | | | 371 | |<--No-NSF-found---| | | 372 | | Reply | | | 373 |<--High-level--| | | | 374 policy Response(failure) | | | 375 | | | | | 376 |++case 1: Capability not Searched+++++++++++++++++++| | 377 | | | | | 378 | +case 2: Capability not Searched++++++++++++++++++++++ | 379 | | | | | | 380 | | |--NSF Creation--->| | | 381 | | | Request(Reg) |-------NSF Creation------->| 382 | | | | Request(Ve-Vnfm) | 383 | | | | | NSF 384 | | | | | Creation 385 | | | | | | 386 | | | |<------NSF Creation--------| 387 | | |<--NSF Creation---| Response(Ve-Vnfm) | 388 | | | Response(Reg) | (with NSF info) | 389 | | | | | | 390 | | Translation: | | | 391 | | Policy Generation | | | 392 | | | | | | 393 | | |----------Low-level policy Request----------->| 394 | | |<---------Low-level policy Response-----------| 395 | | | | | | 396 |<--High-level--| | | | 397 policy Response(Success) | | | 398 | | | | | | 400 Figure 3: Procedure of I2NSF Framework on NFV for the Case of 'No 401 NSF Existing' 403 However, when the NSF does not exist, The procedure is as follows. 404 As shown in Figure 3, when an NSF does not exist, Security Controller 405 sends a Capability Query message to DMS to search for an NSF with the 406 requested capability. When DMS does not find such an NSF, the 407 procedure is terminated after sending Security Controller a failure 408 notification message, which means that it does not have any NSF with 409 the requested capability. On the other hand, When there exists an 410 NSF corresponding to the requested capability, DMS sends an NSF 411 creation request message to the VNFM. After the creation of the NSF 412 as a VNF, it is registered into DMS. DMS registers the NSF with 413 capability and access information into Security Controller via 414 Registration Interface. The remaining procedure is the same as the 415 previous case. 417 5. Multi-site Consideration 419 The previous section described how the I2NSF framework is plugged 420 into the NFV architecture in a single site. From the perspective of 421 NFV, when security functions are deployed, it might be deployed at a 422 single site or multiple sites. 424 Basically, the I2NSF framework only considers that a single DMS could 425 manage all its NSFs. From the perspective of ETSI reference 426 architecture, when NSFs are deployed at a multi-site environment, a 427 DMS could manage all of the NSFs in such an environment in the same 428 way of a single site. Alternatively, multiple DMSs could manage the 429 NSFs together. The I2NSF framework only considers a single Security 430 Controller that manages all the NSFs in its management domain. This 431 implies that one Security Controller as an EM should be located at 432 the domain. 434 However, from the perspective of ETSI reference architecture, an EM 435 usually is located at each site and controls a VNF which belongs to 436 that site. The I2NSF framework should consider the placement of 437 Security Controller in a multi-site environment, since there is a 438 conflict between the I2NSF framework and the ETSI NFV reference 439 architecture regarding the placement of Security Controller as an EM. 441 6. Cloud Native NFV Architecture 443 In the NFV reference architecture of the previous section, we only 444 described architecture based on VM. However, in these days, cloud- 445 native environment has been emerged that network function is 446 decomposed to multiple micro-services and running on containers as 447 VNF Components (VNFCs). In the perspective of cloud-native 448 environment, the architecture should be modified based on standard 449 document for Cloud Native architecture. ETSI defines NFV reference 450 architecture in Cloud Native environment based on [ETSI-NFV-IFA29]. 451 In addition, standardization is in progress based on 452 [ETSI-NFV-IFA40], [ETSI-NFV-IFA10] and [ETSI-NFV-IFA11] documents. 453 In their documents, they defined Container Infrastructure Service 454 Management (CISM) which is composed Managed Container Infrastructure 455 Object (MCIO) and Virtual Resource (VR) management system. Depending 456 on various deployment option for placing CISM and containerized 457 infrastructure, [ETSI-NFV-IFA29] defined 6 architectural options with 458 mapping to the NFV-MANO components. In their scenario, the CISM can 459 be embedded to VIM, deployed separately into VIM and VNFM, or running 460 independently. Also, the CISM can be deployed into VM as VNF or 461 individual component in NFV-MANO. 463 From this cloud-native perspective, NSF also can be considered to 464 deploy as cloud-native functions. In this case, I2NSF framework can 465 be provided Platfrom-as-a-Service (PaaS) model, which is agnostic to 466 hosting environment, location of NSF and underlaying network 467 topology. Figure 4 is shown an example of deploying I2NSF PaaS with 468 additional interfaces for interworking with the CISM. In this 469 scenario, the developer's management system can access the MCIO to 470 register NSF's capability and description for configuring NSF object. 471 The security controller has responsibility to modify runtime 472 environment of specific NSF via the CISM by requesting from user, and 473 also internal configuration of NSF container. The CISM recieves 474 instantiation requests from VNFM via CISM-Vnfm interface then deploys 475 NSF container via CISM-CIS interface. I2NSF consumer-facing 476 interface can be supported with extension of interface between CISM 477 and VNFM/NFV Orchestrator, which is defined in the [ETSI-NFV-IFA29] 478 as CISM northbound interface. As similar, NSF-facing interface can 479 be mapped to CISM southbound interface that creates/modify/update 480 containerized workloads. For registration interface, it is possible 481 to provide API specified to container orchestrator, such as 482 Kubernetes, between security controller and developer's managment 483 system. 485 +--------------------+ 486 +-------------------------------------------+ | ---------------+ | 487 | OSS/BSS | | | NFV | | 488 +---------+---------------------------------+ | | Orchestrator | | 489 | (b) | +--+-----------+ | 490 +---------|---------------------------------+ | | | 491 |+--------+--------------------------------+| | | | 492 || | I2NSF PaaS || | | | 493 || +------+------+ +-----------------+|| | | | 494 || | Security | | Developer's Mgmt||| | | | 495 || | Controller +--(a)-+ System ||| | | | 496 || +------+------+ +-----------------+|| | +--+---------+ | 497 || | (c) || | | | | 498 || +------+------------------------------+ |+-(d)-+ VNFM +-+ | 499 || | Consumer-NSFs | || | | | | | 500 || +-------------------------------------+ || | +--+---------+ | | 501 || +-------|-------+ +--------|------+ || | | | | 502 || | NSF Instance | | NSF Instance | || | | | | 503 || +---------------+ +---------------+ || | | | | 504 |+-----------------------------------------+| | | | | 505 +-------------------------------------------+ | |(e) | | 506 +-------------------------------------------+ | | | | 507 | +----------+ +----------+ +----------+ | | | | | 508 | | Container| | Container| | Container| | | | | | 509 | +----------+ +----------+ +----------+ | | +--+---------+ | | 510 | +---------------------------------------+ +-(f)-+ CISM | | | 511 | | Conatiner Infra Service Instance | | | +------------+ | | 512 | +---------------------------------------+ | | | | 513 | +---------------------------------------+ | | +------------+ | | 514 | | Hardware Resources | +-----+ VIM +-+ | 515 | +---------------------------------------+ | | +------------+ | 516 +-------------------------------------------+ +--------------------+ 517 (a) = Registration Interface, (b) = Consumer-Facing Interface, 518 (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface, 519 (e) = CISM-Vnfm Interface, (f) = CISM-CIS Interface 521 Figure 4: Deployment Scenario for I2NSF PaaS 523 6.1. The consideration of the Yang data model in the Container 524 environment 526 In a container environment, NSF computing resources and types of 527 functions (ex, IDS/DPI, etc.) can be described in Helm and it is used 528 in NSF's deployment. Based on this, basic components and network 529 settings defined in I2NSF are possible. 531 Network settings enable communication among each component, but 532 policies needed for NSF require separate settings using Yang data 533 model. The I2NSF defined the Yang data model for communication 534 between each component as follows. 536 * NSF Monitoring Interface YANG Data Model 538 * Network Security Function-Facing Interface YANG Data Model 540 * Consumer-Facing Interface YANG Data Model 542 * Capability YANG Data Model 544 The defined data model is referred for data transmission/reception 545 after deployment, the actual data uses a protocol such as Netconf. 546 In a container environment, the settings for Netconf can be included 547 in a basic deployment file. The data model which is used for policy 548 configurations mentioned above can be included in the existing Helm 549 chart in XML format or configured in a separate file for setting. 551 7. Use Case of SFC-Enabled I2NSF Framework 553 A service service in the I2NSF applicability in 554 [I2NSF-Applicability]> requires a forwarding mechanism for cloud- 555 based security services. Especially, a Service Function Chaining 556 (SFC)-enabled I2NSF Architecture in [NSF-Triggered-Steering] shows a 557 use case that uses SFC as a forwarding mechanism. In addition, it 558 specifies SFC components for I2NSF-based sercurity services (e.g., 559 Classifier and Service Function Forwarder (SFF)) and defines the 560 required functionality of the components. Therefore, the following 561 subsections explain the details of each component and consider how it 562 corresponds to the NFV reference architecture. 564 7.1. SFC Policy Manager 566 SFC Policy Manager is a part of Security Controller. It is 567 responsible for interpreting a high-level security policy into a low- 568 level security policy, which is given by I2NSF User. It also handles 569 the delivery of the interpreted policy to SFC Classifier(s) for 570 security function chaining. Moreover, it also generates the 571 information of the security function chaining for the requested 572 security service to SFF(s). 574 In the NFV reference architecture, Management and Orchestration 575 (MANO) performs similar functions as the SFC Policy Manager. More 576 specifically, the NFV Orchestrator (NFVO) performs on-boarding of a 577 new Network Service (NS), VNF-FG (Forwarding Graph), and VNF 578 Packages. In addition, it manages NS lifecycle (including 579 instantiation, scale-out/in, performance measurement, event 580 correlation, and termination). 582 Therefore, SFC Policy Manager corresponds to NFVO. In addition, if 583 SFC Policy Manager is a part of Security Controller, this function 584 should be separated from Security Controller, and then be placed in 585 MANO. 587 7.2. SFC Catalog Manager 589 SFC Catalog Manager is a part of Security Controller. It is 590 responsible for maintaining the information of every available SF 591 instance such as IP address, transport-layer protocol, port number, 592 service name, and load status. Moreover, it should respond to the 593 queries for available NSF instances from SFC Policy Manager in order 594 to help the generation of a forwarding table entry relevant to a 595 given SFP. It also requests DMS to dynamically instantiate 596 additional SF instances in order to avoid service congestion in an 597 NSF or the elimination of an idle NSF instance to avoid resource 598 waste. 600 In the NFV reference architecture, SFC Catalog Manager corresponds to 601 an EM since the information related to VNF capability is managed by 602 the EM. Moreover, its functions are similar to Security Controller's 603 as explained before. 605 7.3. Developer's Management System in SFC-Enabled I2NSF Framework 607 In the SFC-enabled document, the functions of DMS are extended. For 608 the request message from SFC Catalog Manager, DMS creates additional 609 NSF instances for load balancing and eliminates some of idle NSF 610 instances. 612 As mentioned above, if DMS manages the NSF's lifecycle indirectly 613 with VNFM, it play a role of a VNFM. VNF lifecycle management 614 includes the instantiation, creation, provisioning, scaling, 615 monitoring, and termination of a VM as a VNF instance. Therefore, 616 DMS corresponds to a specific VNFM. 618 However, for the scaling performance at a network service level, the 619 role of DMS can be a part of MANO. 621 7.4. The consideration of SFC-enabled architecture in I2NSF Framework 623 As mentioned above, when the I2NSF is provided in an NFV environment, 624 various use cases can be provided through SFC technology. 626 As an NFV point of view, SFC can be provided in two ways. The first 627 way is to configure the SFC between NSF through the individual SDN 628 controller, and the second is to configure the SFC through the 629 network management function in the cloud. 631 The way to provide traffic steering capabilities may vary depending 632 on the cloud environment, but the Security Controller must request 633 traffic steering to the SDN controller or network function management 634 via VNFM (using Ve-Vnfm interface). Traffic steering can be provided 635 through physical switches or Virtual Switch. 637 8. Security Considerations 639 This document specifies the implementation of the I2NSF framework in 640 the NFV system, so the same security considerations for the I2NSF 641 framework [RFC8329] can be applied to this document. 643 This document shares all the security issues of NFV that are 644 specified in the "Potential Areas of Concern" section of 645 [ETSI-GS-NFV-SEC-001]. 647 9. Informative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", RFC 2119, March 1997, 651 . 653 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 654 Kumar, "Framework for Interface to Network Security 655 Functions", RFC 8329, February 2018, 656 . 658 [I2NSF-Applicability] 659 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 660 "Applicability of Interfaces to Network Security Functions 661 to Network-Based Security Services", Work in Progress, 662 Internet-Draft, draft-ietf-i2nsf-applicability-13, June 663 2019, . 666 [NSF-Triggered-Steering] 667 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 668 Function Chaining-Enabled I2NSF Architecture", Work in 669 Progress, Internet-Draft, draft-hyun-i2nsf-nsf-triggered- 670 steering-06, July 2018, 671 . 674 [ETSI-GS-NFV-003] 675 "Network Functions Virtualization (NFV); Architectural 676 Framework", October 2013. 678 [I2NSF-Terminology] 679 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 680 Birkholz, "Interface to Network Security Functions (I2NSF) 681 Terminology", Work in Progress, Internet-Draft, draft- 682 ietf-i2nsf-terminology-06, July 2018, 683 . 686 [Registration-Interface] 687 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 688 Registration Interface YANG Data Model", Work in Progress, 689 Internet-Draft, draft-ietf-i2nsf-registration-interface- 690 dm-01, November 2018, 691 . 694 [ETSI-GS-IFA-008] 695 "Network Functions Virtualisation (NFV);Management and 696 Orchestration;Ve-Vnfm reference point - Interface 697 andInformation Model Specification", October 2016. 699 [ETSI-GS-NFV-SEC-001] 700 "Network Functions Virtualisation (NFV); NFV Security; 701 Problem Statement", October 2014. 703 [ETSI-NFV-IFA29] 704 "Network Functions Virtualisation (NFV) Release 3; 705 Architecture; Report on the Enhancements of the NFV 706 architecture towards "Cloud-native" and "PaaS"", November 707 2019. 709 [ETSI-NFV-IFA40] 710 "Network Functions Virtualisation (NFV) Release 4; 711 Management and Orchestration; Requirements for service 712 interfaces and object model for OS container management 713 and orchestration specification", March 2020. 715 [ETSI-NFV-IFA10] 716 "Network Functions Virtualisation (NFV) Release 717 3;Management and Orchestration;Functional requirements 718 specification", April 2019. 720 [ETSI-NFV-IFA11] 721 "Network Functions Virtualisation (NFV) Release 722 4;Management and Orchestration;VNF Descriptor and 723 Packaging Specification", September 2020. 725 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-05 727 The following changes have been made from draft-yang-i2nsf-nfv- 728 architecture-05: 730 * In this version, Section 6 is added. 732 Appendix B. Acknowledgements 734 This work was supported in part by the Ministry of Science and ICT 735 (MSIT) under the ITRC (Information Technology Research Center) 736 support program (IITP-2019-2017-0-01633) supervised by the Institute 737 for Information & communications Technology Promotion (IITP). 739 Authors' Addresses 741 Hyunsik Yang 742 KT 743 KT Research Center 151 744 Taebong-ro, Seocho-gu 745 Seoul 746 06763 747 Republic of Korea 748 Phone: +82 10 9777 7439 749 Email: yangun@dcn.ssu.ac.kr 751 Kyoungjae Sun 752 Soongsil University 753 369, Sangdo-ro, Dongjak-gu 754 Seoul 755 06978 756 Republic of Korea 757 Phone: +82 10 3643 5627 758 Email: gomjae@dcn.ssu.ac.kr 759 Younghan Kim 760 School of Electronic Engineering 761 Soongsil University 762 369, Sangdo-ro, Dongjak-gu 763 Seoul 764 Seoul 765 06978 766 Republic of Korea 767 Phone: +82 10 2691 0904 768 Email: younghak@ssu.ac.kr 770 Jaehoon Paul Jeong 771 Department of Software 772 Sungkyunkwan University 773 2066 Seobu-Ro, Jangan-Gu 774 Suwon 775 Gyeonggi-Do 776 16419 777 Republic of Korea 778 Phone: +82 31 299 4957 779 Email: pauljeong@skku.edu 780 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php