idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-04.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 (November 6, 2018) is 1996 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-07 == 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 Y. Kim 4 Intended status: Informational Soongsil University 5 Expires: May 10, 2019 J. Jeong 6 J. Kim 7 Sungkyunkwan University 8 November 6, 2018 10 I2NSF on the NFV Reference Architecture 11 draft-yang-i2nsf-nfv-architecture-04 13 Abstract 15 This document describes the integration of Interface to Network 16 Security Functions (I2NSF) Framework into the Network Functions 17 Virtualization (NFV) Reference Model. This document explains how the 18 components and interfaces in the I2NSF Framework can be placed in the 19 NFV reference architecture, and also explains the procedures of the 20 lifecycle management of Network Security Functions (NSFs) according 21 to a user's security policy specification in the I2NSF framework on 22 the NFV system. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 10, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified 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 . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 5 66 3.4.2. NSF-Facing Interface . . . . . . . . . . . . . . . . 6 67 3.4.3. Registration Interface . . . . . . . . . . . . . . . 6 68 3.4.4. Interface for NSF Management . . . . . . . . . . . . 6 69 4. Initial Configuration Procedure in NFV Architecture . . . . . 6 70 5. Multi-site Consideration . . . . . . . . . . . . . . . . . . 10 71 6. Use Case of SFC-Enabled I2NSF Framework . . . . . . . . . . . 10 72 6.1. SFC Policy Manager . . . . . . . . . . . . . . . . . . . 11 73 6.2. SFC Catalog Manager . . . . . . . . . . . . . . . . . . . 11 74 6.3. Developer's Management System in SFC-Enabled I2NSF 75 Framework . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Informative References . . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-03 . 14 79 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 The goal of Interface to Network Security Functions (I2NSF) is to 85 define a set of software interfaces and components for controlling 86 and monitoring aspects of physical and virtual Network Security 87 Functions (NSFs), with which a user can specify high-level security 88 policy. To achieve this goal, the I2NSF framework not only considers 89 physical infrastructure, but also considers a Network Functions 90 Virtualization (NFV) environment since an NSF may be provided by 91 virtualized infrastructure as a Virtual Network Function (VNF). 92 Especially, the I2NSF applicability document [I2NSF-Applicability] 93 describes the applicability of I2NSF to network-based security 94 services in an NFV environment. Although it explains how I2NSF 95 framework in an NFV environment for security services, it does not 96 explain the procedures of the lifecycle management of NSFs in detail. 98 Thus, this document explains such procedures in the I2NSF framework 99 on the NSF system along with the places of the components of the 100 I2NSF framework in the NFV system. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. This 107 document uses the terminology described in [RFC8329] 108 [I2NSF-Terminology], [I2NSF-Applicability], [ETSI-GS-NFV-003], 109 [Registration-Interface], [ETSI-GS-IFA-008], and 110 [NSF-Triggered-Steering]. 112 3. I2NSF framework onto the NFV Reference Model 114 The European Telecommunications Standards Institute (ETSI) defined 115 the components for the basic NFV architecture including the NFV 116 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 117 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO) 118 [ETSI-GS-NFV-003]. NFVI provides the virtual resources, such as a 119 Virtual Machine (VM) and a Virtual Network, which are used to create, 120 update, and delete VNFs running applications. VNFs are implemented 121 through software virtualization techniques running over the NFVI. 123 Virtualized Infrastructure Manager (VIM) has a function for 124 controlling and managing the NFVI compute, storage and network nodes, 125 within one operator's infrastructure sub-domain. It also collects 126 and forwards performance measurement data and events. 128 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 129 manages the VNF instance in the lifecycle, and the VNFM performs 130 several actions such as software update/modification, monitoring data 131 collection (e.g., fault event in the VNF, and instance termination). 133 In [RFC8329], the I2NSF framework has four components (i.e., I2NSF 134 User, Security Controller, NSF, and Developer's Management System 135 (DMS)) along with three main interfaces (i.e., Consumer-Facing 136 Interface, NSF-Facing Interface, and Registration Interface). To 137 adopt these components to the NFV reference architecture, each 138 component should be classified based on functionality. According to 139 component functionality, it would correspond to NFV reference 140 architecture components as Figure 1. 142 +--------------------+ 143 +-------------------------------------------+ | ---------------- | 144 | OSS/BSS | | | NFV | | 145 +---------+---------------------------------+ | | Orchestrator +-+| 146 | (b) | +--+-----------+ || 147 +---------|---------------------------------+ | | || 148 | +------+------+ +-----------------+ | | | || 149 | | Security | | Developer's Mgmt| | | | || 150 | | Controller +--(a)-+ System(EM) | | | | || 151 | +------+------+ +-----------------+ | | +--+---------+ || 152 | | (c) | | | | || 153 | +---+----+ +---+----+ +---+----+ +-(d)-+ VNFM | || 154 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | || 155 | | | | | | | | | +--+---------+ || 156 | +--------+ +--------+ +--------+ | | | || 157 +-------------------------------------------+ | | || 158 +-------------------------------------------+ | | || 159 | NFV Infrastructure (NFVI) | | | || 160 | +---------+ +---------+ +---------+ | | | || 161 | | Virtual | | Virtual | | Virtual | | | | || 162 | | Compute | | Storage | | Network | | | | || 163 | +---------+ +---------+ +---------+ | | +--+-----+ || 164 | +---------------------------------------+ | | | | || 165 | | Virtualization Layer | +-----+ VIM(s) +-------+| 166 | +---------------------------------------+ | | | | | 167 | +---------------------------------------+ | | +--------+ | 168 | | +---------+ +---------+ +---------+ | | | | 169 | | | Compute | | Storage | | Network | | | | | 170 | | | Hardware| | Hardware| | Hardware| | | | | 171 | | +---------+ +---------+ +---------+ | | | NFV Management | 172 | | Hardware Resources | | | and Orchestration | 173 | +---------------------------------------+ | | (MANO) | 174 +-------------------------------------------+ +--------------------+ 175 (a) = Registration Interface, (b) = Consumer-Facing Interface 176 (C) = NSF-Facing Interface, (d) = Ve-Vnfm Interface 178 Figure 1: I2NSF Framework on NFV Reference Architecture 180 3.1. Network Security Function 182 A Network Security Function (NSF) is one of the security service 183 functions. In the ETSI reference architecture, a VNF is a network 184 function which provides a specific service. Therefore, an NSF 185 corresponds to a VNF in the NFV reference architecture. 187 3.2. Security Controller 189 According to an I2NSF framework, Security Controller has a role to 190 translate an I2NSF User's high-level security policy into a low-level 191 security policy for an NSF. It also collects an NSF's capability 192 information from DMS. Based on the features of the I2NSF framework, 193 Security Controller receives a high-level security policy from an 194 I2NSF user over Consumer-Facing Interface, and after the security 195 policy translation, it can forward the corresponding low-level 196 security policy to an appropriate NSF over NSF-Facing Interface. 198 In the NFV reference architecture, Element Management (EM) has a role 199 to manage its service function (e.g., firewall, Deep Packet 200 Inspection, DDoS-attack mitigator) and collaborate with the VNF 201 Manager for the lifecycle management (e.g., the instantiation and de- 202 instantiation) of a VNF corresponding to the required security 203 function. This lifecycle management requires the exchange of 204 information regarding the NFVI resources associated with the VNF. EM 205 performs typical management functionality for its own VNFs. 207 This document proposes that Security Controller can be implemented as 208 an EM that can give a security policy to an NSF, and control the NSF. 209 Note that from the perspective of implementation, it can also be 210 configured as an independent component in the NFV system. 212 3.3. Developer's Management System 214 According to the definition of I2NSF Registration Interface, DMS 215 registers its NSF, which can be provided by a specific vendor, into 216 Security Controller along with the capability of the NSF. 218 In the NFV reference architecture, when a general VNFM creates and 219 manages an NSF, DMS can be used as an EM to manage the specific 220 function of an NSF. 222 3.4. I2NSF Interfaces 224 3.4.1. Consumer-Facing Interface 226 The Consumer-Facing Interface is an interface for communication 227 between I2NSF User and Security Controller. It is used to enable 228 different I2NSF Users in a given I2NSF system to define, manage, and 229 monitor security policies for specific flows within an administrative 230 domain. 232 In the NFV reference architecture, Operational Support Systems (OSS) 233 and Business Support Systems (BSS) are used to manipulate their 234 applications (e.g., security services) with their policies and rules. 236 OSS and BSS support a user-domain-specific system for users, such as 237 security enforcement, billing, order, and metering. 239 Although an interface is not defined between an I2NSF User and a VNF 240 in the NFV reference architecture, Consumer-Facing interface can be 241 deployed for the interaction between an I2NSF user and an VNF, as 242 illustrated in Figure 1. 244 3.4.2. NSF-Facing Interface 246 The NSF-Facing Interface is an interface for communication between 247 Security Controller and NSF. It is used to specify and monitor flow- 248 based security policies enforced by one or more NSFs. In the NFV 249 reference architecture, Software Architecture (SWA)-4 Interface is 250 defined. The interface SWA-4 is used by the EM to communicate with a 251 VNF. This management interface is used for the runtime management of 252 the VNF according to Fulfillment, Assurance, Billing, and FCAPS 253 (Fault, Configuration, Accounting, Performance, Security) network 254 management models and frameworks. Therefore, NSF-Facing Interface 255 corresponds to the SWA-4 interface. 257 3.4.3. Registration Interface 259 Registration Interface is used to register an NSF from DMS System to 260 Security Controller. An NSF's capabilities can either be pre- 261 configured or retrieved dynamically through the I2NSF Registration 262 Interface. Also, it is to search an appropriate NSF with the 263 required capability that can execute the requested security service. 265 In the NFV reference architecture, an interface is not defined 266 between EM, the registraion-interface can be deployed like a 267 Figure 1. 269 3.4.4. Interface for NSF Management 271 In this model, DMS needs to communicate with VNFM to create an NSF 272 dynamically. This interface is not defined in the I2NSF framework, 273 since it is out of the scope of the I2NSF. However, ETSI defined an 274 interface "Ve-Vnfm" between EM and VNFM [ETSI-GS-IFA-008]. 275 Therefore, as an EM, DMS can use the interface "Ve-Vnfm" to 276 communicate with VNFM. 278 4. Initial Configuration Procedure in NFV Architecture 280 The security service procedure in the proposed architecture is as 281 follows. When an I2NSF User requests a security service to Security 282 Controller with a high-level policy, Security Controller translates 283 the high-level policy into the corresponding low-level policy. Then, 284 it searches the NSF list with capabilities for the requested security 285 service according to the low-level policy. In this step, there are 286 two use cases. 288 As shown in Figure 2, the first case is the case that when an NSF 289 with the required capability is in active state. The second case is 290 the case that when an NSF with required capability is in inactive 291 state. When the NSF is in active state, Security Controller 292 generates a low-level policy and forwards it to the NSF to set the 293 low-level policy up. On the other hand, when the NSF is in inactive 294 state, Security Controller sends an NSF initiation request message to 295 the DMS via Registration Interface and DMS analyzes the message 296 according to the vendor's configuration [Registration-Interface]. 297 After that, DMS forwards the NSF initiation request message to VNFM 298 via Ve-Vnfm Interface [ETSI-GS-IFA-008]. After the initiation of the 299 NSF, VNFM sends back an NSF initiation response message to Security 300 Controller with an NSF's access information (e.g., IP address, 301 transport-layer protocol, port number, and the NSF's name). With the 302 received NSF access information, Security Controller generates a low- 303 level policy and forwards it to the NSF to set the security policy 304 up. 306 I2NSF Security Developer's VNFM NSF 307 User Controller Mgmt System 308 | | | | | 309 | | | | | 310 |--High-level-->| | | | 311 |policy Request | | | | 312 | | | | | 313 | | | | | 314 | | | | | 315 | Translation: | | | 316 | Data Conversion | | | 317 | | | | | 318 | | | | | 319 case 1: NSFs available(activated) : Go to Policy Generation | 320 | | | | | 321 |++case 2: NSFs available(de-activated)+++++++++++++| | 322 | | | | | 323 | |-NSF initiation->| | | 324 | | Request(Reg) |-------NSF initiation----->| 325 | | | Request(Ve-Vnfm) | 326 | | | | NSF 327 | | | | Creation 328 | | | | | 329 | | |<------NSF initiation------| 330 | |<-NSF initiation-| Response(Ve-Vnfm) | 331 | | Response(Reg) | | | 332 | | | | | 333 |++case 2: NSFs available(de-activated)+++++++++++++| | 334 | | | | | 335 | Translation: | | | 336 | Policy Generation | | | 337 | | | | | 338 | | | | | 339 | |---------Low-level policy Request----------->| 340 | |<--------Low-level policy Response-----------| 341 | | | | | 342 | | | | | 343 | | | | | 344 | | | | | 345 | | | | | 346 | | | | | 347 | | | | | 348 | | | | | 350 Figure 2: Procedure of I2NSF Framework on NFV for the Case of 'NSF 351 Available' 353 I2NSF Security Developer's VNFM NSF 354 User Controller Mgmt System 355 | | | | | 356 |--High-level-->| | | | 357 |policy Request | | | | 358 | | | | | 359 | Translation: | | | 360 | Data Conversion | | | 361 | | | | | 362 | Profile Entry | | | 363 | not matched | | | 364 | | | | | 365 | |Capability Query->| | | 366 | | | | | 367 |++case 1: Capability not Searched+++++++++++++++++++| | 368 | | | | | 369 | |<--No-NSF-found---| | | 370 | | Reply | | | 371 |<--High-level--| | | | 372 policy Response(failure) | | | 373 | | | | | 374 |++case 1: Capability not Searched+++++++++++++++++++| | 375 | | | | | 376 | +case 2: Capability not Searched++++++++++++++++++++++ | 377 | | | | | | 378 | | |--NSF Creation--->| | | 379 | | | Request(Reg) |-------NSF Creation------->| 380 | | | | Request(Ve-Vnfm) | 381 | | | | | NSF 382 | | | | | Creation 383 | | | | | | 384 | | | |<------NSF Creation--------| 385 | | |<--NSF Creation---| Response(Ve-Vnfm) | 386 | | | Response(Reg) | (with NSF info) | 387 | | | | | | 388 | | Translation: | | | 389 | | Policy Generation | | | 390 | | | | | | 391 | | |----------Low-level policy Request----------->| 392 | | |<---------Low-level policy Response-----------| 393 | | | | | | 394 |<--High-level--| | | | 395 policy Response(Success) | | | 396 | | | | | | 398 Figure 3: Procedure of I2NSF Framework on NFV for the Case of 'No NSF 399 Existing' 401 However, when the NSF does not exist, The procedure is as follows. 402 As shown in Figure 3, when an NSF does not exist, Security Controller 403 sends a Capability Query message to DMS to search for an NSF with the 404 requested capability. When DMS does not find such an NSF, the 405 procedure is terminated after sending Security Controller a failure 406 notification message, which means that it does not have any NSF with 407 the requested capability. On the other hand, When there exists an 408 NSF corresponding to the requested capability, DMS sends an NSF 409 creation request message to the VNFM. After the creation of the NSF 410 as a VNF, it is registered into DMS. DMS registers the NSF with 411 capability and access information into Security Controller via 412 Registration Interface. The remaining procedure is the same as the 413 previous case. 415 5. Multi-site Consideration 417 The previous section described how the I2NSF framework is plugged 418 into the NFV architecture in a single site. From the perspective of 419 NFV, when security functions are deployed, it might be deployed at a 420 single site or multiple sites. 422 Basically, the I2NSF framework only considers that a single DMS could 423 manage all its NSFs. From the perspective of ETSI reference 424 architecture, when NSFs are deployed at a multi-site environment, a 425 DMS could manage all of the NSFs in such an environment in the same 426 way of a single site. Alternatively, multiple DMSs could manage the 427 NSFs together. The I2NSF framework only considers a single Security 428 Controller that manages all the NSFs in its management domain. This 429 implies that one Security Controller as an EM should be located at 430 the domain. 432 However, from the perspective of ETSI reference architecture, an EM 433 usually is located at each site and controls a VNF which belongs to 434 that site. The I2NSF framework should consider the placement of 435 Security Controller in a multi-site environment, since there is a 436 conflict between the I2NSF framework and the ETSI NFV reference 437 architecture regarding the placement of Security Controller as an EM. 439 6. Use Case of SFC-Enabled I2NSF Framework 441 A service service in the I2NSF applicability in 442 [I2NSF-Applicability]> requires a forwarding mechanism for cloud- 443 based security services. Especially, a Service Function Chaining 444 (SFC)-enabled I2NSF Architecture in [NSF-Triggered-Steering] shows a 445 use case that uses SFC as a forwarding mechanism. In addition, it 446 specifies SFC components for I2NSF-based sercurity services (e.g., 447 Classifier and Service Function Forwarder (SFF)) and defines the 448 required functionality of the components. Therefore, the following 449 subsections explain the details of each component and consider how it 450 corresponds to the NFV reference architecture. 452 6.1. SFC Policy Manager 454 SFC Policy Manager is a part of Security Controller. It is 455 responsible for interpreting a high-level security policy into a low- 456 level security policy, which is given by I2NSF User. It also handles 457 the delivery of the interpreted policy to SFC Classifier(s) for 458 security function chaining. Moreover, it also generates the 459 information of the security function chaining for the requested 460 security service to SFF(s). 462 In the NFV reference architecture, Management and Orchestration 463 (MANO) performs similar functions as the SFC Policy Manager. More 464 specifically, the NFV Orchestrator (NFVO) performs on-boarding of a 465 new Network Service (NS), VNF-FG (Forwarding Graph), and VNF 466 Packages. In addition, it manages NS lifecycle (including 467 instantiation, scale-out/in, performance measurement, event 468 correlation, and termination). 470 Therefore, SFC Policy Manager corresponds to NFVO. In addition, if 471 SFC Policy Manager is a part of Security Controller, this function 472 should be separated from Security Controller, and then be placed in 473 MANO. 475 6.2. SFC Catalog Manager 477 SFC Catalog Manager is a part of Security Controller. It is 478 responsible for maintaining the information of every available SF 479 instance such as IP address, transport-layer protocol, port number, 480 service name, and load status. Moreover, it should respond to the 481 queries for available NSF instances from SFC Policy Manager in order 482 to help the generation of a forwarding table entry relevant to a 483 given SFP. It also requests DMS to dynamically instantiate 484 additional SF instances in order to avoid service congestion in an 485 NSF or the elimination of an idle NSF instance to avoid resource 486 waste. 488 In the NFV reference architecture, SFC Catalog Manager corresponds to 489 an EM since the information related to VNF capability is managed by 490 the EM. Moreover, its functions are similar to Security Controller's 491 as explained before. 493 6.3. Developer's Management System in SFC-Enabled I2NSF Framework 495 In the SFC-enabled document, the functions of DMS are extended. For 496 the request message from SFC Catalog Manager, DMS creates additional 497 NSF instances for load balancing and eliminates some of idle NSF 498 instances. 500 As mentioned above, if DMS manages the NSF's lifecycle indirectly 501 with VNFM, it play a role of a VNFM. VNF lifecycle management 502 includes the instantiation, creation, provisioning, scaling, 503 monitoring, and termination of a VM as a VNF instance. Therefore, 504 DMS corresponds to a specific VNFM. 506 However, for the scaling performance at a network service level, the 507 role of DMS can be a part of MANO. 509 7. Security Considerations 511 This document specifies the implementation of the I2NSF framework in 512 the NFV system, so the same security considerations for the I2NSF 513 framework [RFC8329] can be applied to this document. 515 This document shares all the security issues of NFV that are 516 specified in the "Potential Areas of Concern" section of 517 [ETSI-GS-NFV-SEC-001]. 519 8. Informative References 521 [ETSI-GS-IFA-008] 522 ETSI GS NFV-IFA 008 V2.1.1, "Network Functions 523 Virtualisation (NFV);Management and Orchestration;Ve-Vnfm 524 reference point - Interface andInformation Model 525 Specification", October 2016. 527 [ETSI-GS-NFV-003] 528 ETSI GS NFV 002 V1.1.1, "Network Functions Virtualization 529 (NFV); Architectural Framework", October 2013. 531 [ETSI-GS-NFV-SEC-001] 532 ETSI GS NFV-SEC 001 V1.1.1, "Network Functions 533 Virtualisation (NFV); NFV Security; Problem Statement", 534 October 2014. 536 [I2NSF-Applicability] 537 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 538 "Applicability of Interfaces to Network Security Functions 539 to Network-Based Security Services", draft-ietf-i2nsf- 540 applicability-07 (work in progress), October 2018. 542 [I2NSF-Terminology] 543 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 544 Birkholz, "Interface to Network Security Functions (I2NSF) 545 Terminology", draft-ietf-i2nsf-terminology-06 (work in 546 progress), July 2018. 548 [NSF-Triggered-Steering] 549 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 550 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 551 i2nsf-nsf-triggered-steering-06 (work in progress), July 552 2018. 554 [Registration-Interface] 555 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 556 Registration Interface YANG Data Model", draft-ietf-i2nsf- 557 registration-interface-dm-01 (work in progress), November 558 2018. 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", RFC 2119, March 1997. 563 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 564 Kumar, "Framework for Interface to Network Security 565 Functions", RFC 8329, February 2018. 567 Appendix A. Changes from draft-yang-i2nsf-nfv-architecture-03 569 The following changes have been made from draft-yang-i2nsf-nfv- 570 architecture-03: 572 o In Figure 1, the figure of the I2NSF Framework on NFV Reference 573 Architecture is revised to be synchronized with I2NSF on NFV in 574 [I2NSF-Applicability]. 576 o In Figure 2 and Figure 3, the procedures of I2NSF framework on NFV 577 are added to both the case of "NSF Available", and the case of "No 578 NSF Existing". 580 o Overall editorial errors have been corrected. 582 Appendix B. Acknowledgements 584 This work was supported in part by the Ministry of Science and ICT 585 (MSIT) under the ITRC (Information Technology Research Center) 586 support program (IITP-2018-2017-0-01633) supervised by the Institute 587 for Information & communications Technology Promotion (IITP). 589 Authors' Addresses 591 Hyunsik Yang 592 School of Electronic Engineering 593 Soongsil University 594 369, Sangdo-ro, Dongjak-gu 595 Seoul, Seoul 06978 596 Republic of Korea 598 Phone: +82 10 9005 7439 599 EMail: yangun@dcn.ssu.ac.kr 601 Younghan Kim 602 School of Electronic Engineering 603 Soongsil University 604 369, Sangdo-ro, Dongjak-gu 605 Seoul, Seoul 06978 606 Republic of Korea 608 Phone: +82 10 2691 0904 609 EMail: younghak@ssu.ac.kr 610 Jaehoon Paul Jeong 611 Department of Software 612 Sungkyunkwan University 613 2066 Seobu-Ro, Jangan-Gu 614 Suwon, Gyeonggi-Do 16419 615 Republic of Korea 617 Phone: +82 31 299 4957 618 Fax: +82 31 290 7996 619 EMail: pauljeong@skku.edu 620 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 622 Jinyong Tim Kim 623 Department of Computer Engineering 624 Sungkyunkwan University 625 2066 Seobu-Ro, Jangan-Gu 626 Suwon, Gyeonggi-Do 16419 627 Republic of Korea 629 Phone: +82 10 8273 0930 630 EMail: timkim@skku.edu