idnits 2.17.1 draft-shin-nfvrg-service-verification-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.) ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 461 has weird spacing: '...ecurity manag...' -- The document date (October 5, 2015) is 3097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'ETSI-NFV-Arch' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'ETSI-NFV-MANO' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'SIGCOMM-Qazi' is defined on line 602, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG M-K. Shin 3 Internet-Draft ETRI 4 Intended status: Informational K. Nam 5 Expires: May 5, 2016 Friesty 6 S. Pack 7 KU 8 S. Lee 9 ETRI 10 R. Krishnan 11 Dell 12 T. Kim 13 LG U+ 15 October 5, 2015 17 Verification of NFV Services : Problem Statement and Challenges 18 draft-shin-nfvrg-service-verification-04 20 Abstract 22 NFV relocates network functions from dedicated hardware appliances to 23 generic servers, so they can run in software. However, incomplete or 24 inconsistent configuration of virtualized network functions (VNF) and 25 forwarding graph (FG, aka service chain) could cause break-down of 26 the supporting infrastructure. In this sense, verification is 27 critical for network operators to check their requirements and 28 network properties are correctly enforced in the supporting 29 infrastructures. Recognizing these problems, we discuss key 30 properties to be checked on NFV-enabled services. Also, we present 31 challenging issues related to verification in NFV environments. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 2, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Dependencies of network service components in NFV framework .3 71 2.2. Invariant and error check in VNF FGs . . . . . . . . . . . . 4 72 2.3. Load Balancing and optimization among VNF Instances . . . . 4 73 2.4. Policy and state consistency on NFV services . . . . . . . . 4 74 2.5. Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Examples - NS policy conflict with NFVI policy . . . . . . . . 6 77 4. Requirements of verification framework . . . . . . . . . . . . 7 78 5. Challenging issues . . . . . . . . . . . . . . . . . . . . . . 8 79 5.1. Consistency check in distributed state . . . . . . . . . . 8 80 5.2. Intent-based service composition . . . . . . . . . . . . . . 8 81 5.3. Finding infinite loops in VNF FGs . . . . . . . . . . . . . 8 82 5.4. Real-time verification . . . . . . . . . . . . . . . . . . . 9 83 5.5. Languages and their semantics . . . . . . . . . . . . . . . 9 84 6. Gap analysis - open source projects . . . . . . . . . . . . . . 9 85 6.1. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.2. ODL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 NFV is a network architecture concept that proposes using IT 96 virtualization related technologies, to virtualize entire classes of 97 network service functions into building blocks that may be connected, 98 or chained, together to create network services. NFV service is 99 defined as a composition of network functions and described by its 100 functional and behavioral specification, where network functions 101 (i.e., firewall, DPI, SSL, load balancer, NAT, AAA, etc.) are well- 102 defined, hence both their functional behavior as well as their 103 external interfaces are described in each specifications. 105 In NFV, a VNF is a software package that implements such network 106 functions. A VNF can be decomposed into smaller functional modules or 107 APIs for scalability, reusability, and/or faster response [ETSI-NFV- 108 Arch],[ETSI-NFV-MANO]. This modular updates or composition for a 109 network function may lead to many other verification or security 110 issues. In addition, a set of ordered network functions which build 111 FGs may be connected, or chained, together to create an end-to-end 112 network service. Multiple of VNFs can be composed together to reduce 113 management and VNF FGs. While autonomic networking techniques could 114 be used to automate the configuration process including FG updates, 115 it is important to take into account that incomplete and/or 116 inconsistent configuration may lead to verification issues. Moreover, 117 automation of NFV process with integration of SDN may lead the 118 network services to be more error-prone. In this sense, we need to 119 identify and verify key properties to be correct before VNFs and FGs 120 are physically placed and realized in the supporting infrastructure. 122 1.1. Terminology 124 This document draws freely on the terminology defined in [ETSI-NFV- 125 Arch]. 127 2. Problem statement 129 The verification services should be able to check the following 130 properties: 132 2.1. Dependencies of network service components in NFV framework 134 In NFV framework, there exist several network service components 135 including NFVI, VNFs, MANO, etc. as well as network controller and 136 switches to realize end-to-end network services. Unfortunately, these 137 components have intricate dependencies that make operation incorrect. 138 In this case, there is inconsistency between states stored and 139 managed in VNF FGs and network tables (e.g., flow tables), due to 140 communication delays and/or configuration errors. For example, if a 141 VNF is replicated into the other same one for the purpose of load 142 balance and a new FG is established through the copied one, but all 143 the state/DBs replication is not finished yet due to delays, this can 144 be lead to unexpected behaviors or errors of the network service. 145 Therefore, these dependencies make it difficult to correctly compose 146 NFV-enabled end-to-end network services. 148 2.2. Invariant and error check in VNF FGs 150 In VNF FGs, an infinite loop construction should be avoided and 151 verified. Let us consider the example. Two VNF A and VNF B locate in 152 the same service node X whereas another VNF C resides in other 153 service node Y [SIGCOMM-Gember]. Also, the flow direction is from X 154 toY, and the given forwarding rule is A->C->B. In such a case, 155 service node Y can receive two ambiguous flows from VNF A: 1) one 156 flow processed by VNF A and 2) another flow processed by VNF A, B, 157 and C. For the former case, the flow should be processed by VNF C 158 whereas the latter flow should be further routed to next service 159 nodes. If these two flows cannot be distinguished, service node Y can 160 forward the flow to service node X even for the latter case and a 161 loop can be formed. To avoid the infinite loop formation, the 162 forwarding path over VNF FG should be checked in advance with the 163 consideration of physical placement of VNF among service nodes. Also, 164 reactive verification may be necessary, since infinite loop formation 165 may not be preventable in cases where configuration change is 166 happening with live traffic. 168 In addition, isolation between VNFs (e.g. confliction of properties 169 or interference between VNFs) and consistent ordering of VNF FGs 170 should be always checked and maintained. 172 2.3. Load balancing among VNF instances 174 In VNF FG, different number of VNF instances can be activated on 175 several service nodes to carry out the given task. In such a 176 situation, load balancing among the VNF instances is one of the most 177 important considerations. In particular, the status in resource usage 178 of each service node can be different and thus appropriate amount of 179 jobs should be distributed to the VNF instances. To guarantee well- 180 balanced load among VNF instances, the correctness of hash functions 181 for load balancing needs to be verified. Moreover, when VNF instances 182 locate in physically different service nodes, simple verification of 183 load balancing in terms of resource usage is not sufficient because 184 different service nodes experience diverse network conditions (e.g., 185 different levels of network congestion)[ONS- Gember]. Therefore, it 186 is needed to monitor global network condition as well as local 187 resource condition to achieve the network-wide load balancing in VNF 188 FGs. Also, whether the monitoring function for 189 network/compute/storage resources is correctly working should be 190 checked. 192 2.4. Policy and state consistency on NFV services 194 In VNF FG, policy to specific users can be dynamically changed. For 195 example, a DPI VNF can be applied only in the daytime in order to 196 prohibit from watching adult contents while no DPI VNFs applied 197 during the nighttime. When the policy is changed, the changed policy 198 should be reconfigured in VNF service nodes as soon as possible. If 199 the reconfiguration procedure is delayed, inconsistent policies may 200 exist in service nodes. Consequently, policy inconsistency or 201 confliction needs to be checked. Also in some situations, states for 202 VNF instances may be conflicted or inconsistent. Especially when a 203 new VNF instance is instantiated for scale-up and multiple VNF 204 instances are running, these multiple VNF instances may have 205 inconsistent states owing to inappropriate instantiation procedure 206 [SIGCOMM-Gember]. In particular, since the internal states of VNF 207 instances (e.g., the instantaneous state of CPU, register, and memory 208 in virtual machine) are not easily-visible, a new way to check the 209 VNF internal states should be devised. 211 2.5. Performance 213 In VNF FG, VNF instances can locate in different service nodes and 214 these service nodes have different load status and network 215 conditions. Consequently, the overall throughput of VNF FG is 216 severely affected by the service nodes running VNF instances. For 217 example, if a VNF instance locates in a heavily loaded service node, 218 the service time at the service node will be increased. In addition, 219 when a VNF FG includes a bottleneck link with network congestion, the 220 end-to-end performance (e.g., latency and throughput) in the VNF FG 221 can be degraded. Therefore, the identification of bottleneck link and 222 node is the first step for performance verification or guarantee of 223 the VNF FG [ONS-Gember]. After detecting the bottleneck link/node, 224 the VNF requiring scale up or down can be identified and the 225 relocation of VNF instance among service nodes can be determined 227 2.6. Security 229 How to verify security holes in VNF FG is another important 230 consideration. In terms of security services, authentication, data 231 integrity, confidentiality, and replay protection should be provided. 232 On the other hand, several VNFs (e.g., NAT) can modify or update 233 packet headers and payload. In these environments, it is difficult to 234 protect the integrity of flows traversing such VNFs. Another security 235 concern in the VNF FG is distributed denial of service (DDoS) to a 236 specific service node. If an attacker floods packets to a target 237 service node, the target service node cannot perform its functions 238 correctly. Therefore, such security attacks in the VNF FG should be 239 detected and handled in an efficient manner. In the case of DDoS, 240 adding a DDoS appliance as the first element in the service chain 241 would help alleviate the problem. Moreover, unknown or unauthorized 242 VNFs can run and thus how to identify those problems is another 243 security challenge. 245 3. Examples - NS policy conflict with NFVI policy 247 Another target of NFV verification is conflict of NS policies against 248 global network policy, called NFVI policy. 250 NFV allocates and manages NFVI resources for a network service 251 according to an NS policy given in the network service descriptor 252 (NSD), which describes how to govern NFVI resources for VNF instances 253 and VL instances to support KPIs of the network service. Example 254 factors of the NS policy are resource constraints (or deployment 255 flavor), affinity/anti-affinity, scaling, fault and performance 256 management, NS topology, etc. 258 For a network-wide (or NS-wide) management of NFVI, NFVI policy (or 259 global network policy) can be provided to describe how to govern the 260 NFVI resources for optimized use of the infrastructure resources 261 (e.g., energy efficiency and load balancing) rather than optimized 262 performance of a single network service. Example factors of the NFVI 263 policy are NFVI resource access control, reservation and/or 264 allocation policies, placement optimization based on affinity and/or 265 anti-affinity rules, geography and/or regulatory rules, resource 266 usage, etc. 268 While both of the policies define the requirements for resource 269 allocation, scheduling, and management, the NS policy is about a 270 single network service; and the NFVI policy is about the shared NFVI 271 resources, which may affect all of the given network services 272 globally. Thus, some of NS and NFVI policies may be inconsistency 273 with each other when they have contradictive resource constraints on 274 the shared NFVI resources. Examples of the policy conflicts are as 275 follows: 277 279 o NS policy of NS_A (composed of VNF_A and VNF_B) 280 - Resource constraints: 3 CPU core for VNF_A and 2 CPU core for VNF_B 281 - Affinity rule between VNF_A and VNF_B 283 o NFVI policy 284 - No more than 4 CPU cores per physical host 286 o Conflict case 287 - The NS policy cannot be met within the NFVI policy 289 291 o NS policy of NS_B (composed of VNF_A and VNF_B) 292 - Affinity rule between VNF_A and VNF_B 294 o NFVI policy 295 - Place VM whose outbound traffic is larger than 100Mbps at POP_A 296 - Place VM whose outbound traffic is smaller than 100Mbps at POP_B 298 o Conflict case 299 - If VNF_A and VNF_B generate traffic in 150Mbps and 50Mbps, 300 respectively, 301 - VNF_A and VNF_B need to be placed at POP_A and POP_B, respectively 302 according to the NFVI policy 303 - But it will violate the affinity rule given in the NS policy 305 307 o NS policy of NS_C (composed of VNF_A and VNF_B) 308 - Resource constraints: VNF_A and VNF_B exist in the same POP 309 - Auto-scaling policy: if VNF_A has more than 300K CPS, scale-out 311 o NFVI policy 312 - No more than 10 VMs per physical host in POP_A 314 o Conflict case 315 - If CPS of VNF_A in POP_A gets more than 300K CPS, 316 - and if there is no such physical host in the POP_A whose VMs are 317 smaller than 10, 318 - VNF_A need to be scaled-out to other POP than POP_A according to 319 the NFVI policy 320 - But it will violate the NS policy 322 4. Requirements of verification framework 324 A verification framework for NFV-based services needs to satisfy the 325 following requirements:. 327 o R1 : It should be able to check global and local properties and 328 invariants. Global properties and invariants relate to the 329 entire VNFs, and local properties and invariants relates to 330 the specific domain or resources that some of the VNFs are 331 using. For example, Loop-freeness and isolation between VNFs 332 can be regarded as global. The policies that are related 333 only to the specific network controllers or devices are 334 local. 336 o R2 : It should be able to access to the entire network states 337 whenever verification tasks are started. It can directly 338 manage the states of network and NFV-based services 339 through databases or any solution that specializes in 340 dealing with the network topology and configurations, or 341 can utilize the functions provided by NFV M&O and VNFI 342 solutions to get or set the states at any time. 344 o R3 : It should be independent from specific solutions and 345 frameworks, and provide standard APIs. 347 o R4 : It should process standard protocols such as NetConf, 348 YANG, OpenFlow, and northbound and southbound interfaces 349 that are related network configurations, and used by OSS. 351 5. Challenging issues 353 There are emerging challenges that the verification services face 354 with. 356 5.1. Consistency check in distributed state 358 Basically, NFV states as well as SDN controllers are distributed. 359 writing code that works correctly in a distributed setting is very 360 hard. Therefore, distributed state management and consistency check 361 has challenging issues. Some open source project such as ONOS offers 362 a core set of primitives to manage this complexity. RAFT algorithm 363 [RAFT] is used for distribution and replication. Similarly, Open 364 daylight project has a clustering concept to management distributed 365 state. There is no "one-size-fits-all" solution for control plane 366 data consistency. 368 5.2. Intent-based service composition 370 Recently, Intent-based high-level language is newly proposed and 371 discussed in open source project. The Intent allows for a descriptive 372 way to get what is desired from the infrastructure, unlike the 373 current NFV description and SDN interfaces which are based on 374 describing how to provide different services. This Intent will 375 accommodate orchestration services and network and business oriented 376 SDN/NFV applications, including OpenStack Neutron, Service Function 377 Chaining, and Group Based Policy. A Intent compiler that translates 378 and compiles it into low level instructions (e.g., SDN 379 controller/OpenStack primitives) for network service components. In 380 this sense, error checking and debugging are critical for reliable 381 Intent-based service composition. 383 5.3. Finding infinite loops 385 General solutions for the infinite loop can lead to intractable 386 problem (e.g. the halting problem). To make the verification 387 practical and minimize the complexity, some of the restrictions are 388 required. Finding cycle can be processed in polynomial time but the 389 restriction could be too much for some cases that service functions 390 or network flows requires finite loops. 392 5.4. Live traffic verification 394 It is known fact that the complexity of verification tasks for the 395 real and big problem is high. A few invariants can be checked in 396 real-time but it would be impossible if the size of VNFs increases or 397 properties to be checked are complex. 399 5.5. Languages and their semantics 401 For the verification, configurations and states of VNFs need to be 402 precisely expressed using formal semantics. There are many languages 403 and models, and it is impractical for the verification frameworks to 404 support all of the existing languages and models. Languages and 405 semantic models optimized to the verification framework need to 406 selected or newly developed. 408 6. Gap analysis - open source projects 410 Recently, the Open Platform for NFV (OPNFV) community is 411 collaborating on a carrier-grade, integrated, open source platform to 412 accelerate the introduction of new NFV products and services [OPNFV]. 413 Open Daylight (ODL) is also being tightly coupled with this OPNFV 414 platform to integrate SDN controller into NFV framework [ODL]. 416 This clause analyzes the existing open source projects including 417 OPNFV and ODL related to verification of NFV services. 419 6.1. OPNFV 421 6.1.1. Doctor 423 The Doctor project provides a NFVI fault management and maintenance 424 framework on top of the virtualized infrastructure. The key feature 425 is to notify unavailability of virtualized resources and to recover 426 unavailable VNFs. 428 While the Doctor project focuses only on faults in NFVI including 429 compute, network, and storage resources, the document discusses 430 broader fault management issues such as break-down of the supporting 431 infrastructure due to incomplete or inconsistent configuration of NFV 432 services. 434 6.1.2. Prediction 436 The Prediction project provides a data collection for failure 437 prediction framework. The failure prediction framework diagnoses or 438 verifies which entity is suspected to be progressing towards a 439 failure and which VNFs might be affected due to the predicted 440 anomaly. 442 While the Prediction project focuses only on fault prediction in NFVI 443 compute, network, and storage resources, the document includes 444 broader fault management and prediction issues such as faults in the 445 NFV service deployment and operation. 447 6.1.3. Resource Scheduler 449 The Resource Scheduler project provides an enhanced scheduler for 450 optimizing the performance of the VNFs. In particular, this project 451 supports resource isolation. For example, when a VNF strictly 452 requires low latency, strongly isolated compute resources can be 453 allocated to the VNF. 455 The Resource Scheduler project only focuses on optimizing the 456 performance of individual VNFs without considering the end-to-end 457 performance (e.g., latency and throughput) in NFV services. 459 6.1.4. Moon 461 The Moon project implements a security management system for the 462 cloud computing infrastructure. The project also enforces the 463 security managers through various mechanisms, e.g., authorization for 464 access control, firewall for networking, isolation for storage, and 465 logging for tractability. 467 Note that the main interest of the Moon project is the DDoS attack to 468 a service node and the IDS management for VNFs. A wider range of 469 security issues in the NFV service verification need to be 470 discussed. 472 6.1.5 Bottlenecks 474 The Bottlenecks project aims to find system bottlenecks by testing 475 and verifying OPNFV infrastructure in a staging environment before 476 committing it to a production environment. Instead of debugging the 477 deployment in production environment, an automatic method for 478 executing benchmarks to validate the deployment during staging is 479 adopted. For example, the system measures the performance of each VNF 480 by generating workload on VNFs. 482 The Bottlenecks project does not consider incomplete or inconsistent 483 configurations on NFV services that might cause the system 484 bottlenecks. Furthermore, the Bottlenecks project aims to find system 485 bottlenecks before committing it to a production environment. 486 Meanwhile, the draft also considers how to find bottlenecks in real 487 time. 489 6.2. ODL 491 6.2.1. Network Intent Composition 493 The Network Intent Composition project enables the controller to 494 manage and direct network services and network resources based on 495 intent for network behaviors and network policies. Intents are 496 described to the controller through a new northbound interface, which 497 provides generalized and abstracted policy semantics. Also, the 498 Network Intent Composition project aims to provide advanced 499 composition logic for identifying and resolving intent conflicts 500 across the network applications. 502 When the reconfiguration upon the policy (i.e, intent) is delayed, 503 policy inconsistency in service nodes may occur after the policy is 504 applied to service nodes. While the Network Intent Composition 505 project resolves such intent conflicts only before they are 506 translated into service nodes, this document covers intent conflicts 507 and inconsistency issues in a broader sense. 509 6.2.2. Controller Shield 511 The Controller Shield project proposes to create a repository called 512 unified-security plugin (USecPlugin). The unified-security plugin is 513 a general purpose plugin to provide the controller security 514 information to northbound applications. The security information 515 could be for various purposes such as collating source of different 516 attacks reported in southbound plugins and suspected controller 517 intrusions. Information collected at this plugin can also be used to 518 configure firewalls and create IP blacklists for the network. 520 In terms of security services, the document covers authentication, 521 data integrity, confidentiality, and replay protection. However, the 522 Controller Shield project only covers authentication, data integrity, 523 and replay protection services where the confidentiality service is 524 not considered. 526 6.2.3. Defense4All 528 The Defense4All project proposes a SDN application for detecting and 529 mitigating DDoS attacks. The application communicates with ODL 530 controller via the northbound interface and performs the two main 531 tasks; 1) Monitoring behavior of protected traffic and 2) Diverting 532 attacked traffic to selected attack mitigation systems (AMSs). 534 While the Defense4All project only focuses on defense system at the 535 controller, this document includes broader defense issues at the 536 service node as well as the controller. 538 6.3. Summary 540 The verification functions should spreads over the platforms to 541 accomplish the requirements mentioned in clause 3. The correctness of 542 NFV- based services and their network configurations can be checked 543 in the NFV MANO layer which has the entire states of the VNFs. Each 544 NFVI needs to provide verification layer which composed of policy 545 manager, network database and interfaces (e.g. REST APIs). Local 546 properties and invariants can be verified inside the specific NFVI, 547 and the global properties and invariants can be checked by merging 548 local verification results from the related NFVIs. 550 The verification service provides verification functions to NFV MANO, 551 NFVI, and any other low-level modules such as SDN controllers. For 552 the platform independency, it provides standard APIs to process the 553 verification tasks. It also uses standard APIs provided by OSS such 554 as OpenStack (Neutron) and Open Daylight. The compiler and 555 interpreter translate standard description languages and protocols 556 into the internal model which optimized to the verification tasks. It 557 can process user-defined properties to be checked as well. The 558 properties to be checked whether they are user-defined or pre-defined 559 invariants are managed by property library. The verifier maintains a 560 set of verification algorithms to check the properties. The network 561 database inside the verification service manages the global network 562 states directly or indirectly. 564 A PoC can be implemented using OpenStack (Neutron) and Open Daylight. 565 The modules related to verification framework can reside in between 566 network virtualization framework (e.g. OpenStack Neutron) and SDN 567 controller (e.g. Open Daylight). Neutron and Open Daylight uses 568 standard APIs provided by verification service to accomplish 569 verification tasks. The initial use case for the PoC could be, in 570 particular, any of security, performance, etc as mentioned in clause 571 2. 573 7. Security Considerations 575 As already described in clause 2.6, how to verify security holes in 576 VNF FG is very important consideration. In terms of security 577 services, authentication, data integrity, confidentiality, and replay 578 protection should be provided. On the other hand, potential security 579 concern should be also carefully checked since several VNFs (e.g., 580 NAT) can modify or update packet headers and payload. 582 8. Acknowledgements 584 The authors would like to thank formal methods lab members in Korea 585 University for their verification theory support. 587 9. References 589 9.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 9.2. Informative References 596 [ETSI-NFV-Arch] ETSI, "Network Function Virtualisation (NFV); 597 Architectural Framework," 2014. 599 [ETSI-NFV-MANO] ETSI, "Network Function Virtualiztion (NFV) 600 Management and Orchestration," 2014. 602 [SIGCOMM-Qazi] Z. Qazi, C. Tu, L. Chiang, R. Miao, V. Sekar, and M. 603 Yu, "SIMPLE-fying Middlebox Policy Enforcement Using SDN," 604 in Proc. ACM SIGCOMM 2013, August 2013. 606 [ONS-Gember] A. Gember, R. Grandl, A. Anand, T. Benson, and A. 607 Akella, "Stratos: Virtual Middleboxes as First-Class 608 Entities," ONS 2013 and TR. 610 [SIGCOMM-Gember] A. Gember, R. Viswanathan, C. Prakash, R. Grandl, J. 611 Khalid, S. Das, and A. Akella, "OpenNF: Enabling 612 Innovation in Network Function Control," in Proc. ACM 613 SIGCOMM 2014, August 2014. 615 [RAFT] https://raftconsensus.github.io/. 617 [ODL] "OpenDaylight SDN Controller, "http://www.opendaylight.org/ 619 [OPNFV] "Open Platform for NFV, "https://www.opnfv.org/ 621 Authors' Addresses 623 Myung-Ki Shin 624 ETRI 625 161 Gajeong-dong Yuseng-gu 626 Daejeon, 305-700 627 Korea 629 Phone: +82 42 860 4847 630 Email: mkshin@etri.re.kr 632 Ki-Hyuk Nam 633 Friesty 635 Email: nam@friesty.com 637 Sangheon Pack 638 Korea University 640 Email: shpack@korea.ac.kr 642 Seungik Lee 643 ETRI 644 161 Gajeong-dong Yuseng-gu 645 Daejeon, 305-700 646 Korea 648 Phone: +82 42 860 1483 649 Email: seungiklee@etri.re.kr 651 Ramki Krishnan 652 Dell 654 Email: Ramki_Krishnan@dell.com 656 Tae-wan Kim 657 LG U+ 659 Phone: +82 10 8080 6603 660 Email: dm24ks@lguplus.co.kr