idnits 2.17.1 draft-irtf-nfvrg-service-verification-05.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 13 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 494 has weird spacing: '...ecurity manag...' -- The document date (October 29, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'ETSI-NFV-Arch' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'ETSI-NFV-MANO' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'SIGCOMM-Qazi' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'HOTSDN-Ghorbani' is defined on line 661, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFV Research Group M-K. Shin, Ed. 3 Internet-Draft ETRI 4 Intended status: Informational K. Nam 5 Expires: April 29, 2018 Friesty 6 S. Pack 7 KU 8 S. Lee 9 ETRI 10 R. Krishnan 11 Dell 12 October 29, 2017 14 Verification of NFV Services : Problem Statement and Challenges 15 draft-irtf-nfvrg-service-verification-05 17 Abstract 19 NFV relocates network functions from dedicated hardware appliances to 20 generic servers, so they can run in software. However, incomplete or 21 inconsistent configuration of virtualized network functions (VNFs) 22 and forwarding graph (FG, aka service chain) could cause break-down 23 of the supporting infrastructure. In this sense, verification is 24 critical for network operators to check their requirements and 25 network properties are correctly enforced in the supporting 26 infrastructures. Recognizing these problems, we discuss key 27 properties to be checked on NFV services. Also, we present 28 challenging issues related to verification in NFV environments. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 27, 2017. 47 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Dependencies of network service components in NFV framework .3 67 2.2. Invariant and error check in VNF FGs . . . . . . . . . . . . 4 68 2.3. Load Balancing and optimization among VNF Instances . . . . 4 69 2.4. Policy and state consistency on NFV services . . . . . . . . 4 70 2.5. Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Examples - NS policy conflict with NFVI policy . . . . . . . . 6 73 4. Requirements of verification framework . . . . . . . . . . . . 7 74 5. Challenging issues . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Consistency check in distributed state . . . . . . . . . . 8 76 5.2. Intent-based service composition . . . . . . . . . . . . . . 8 77 5.3. Finding infinite loops in VNF FGs . . . . . . . . . . . . . 8 78 5.4. Complexity of live traffic verification . . . . . . . . . . 9 79 5.5. Languages and their semantics . . . . . . . . . . . . . . . 9 80 5.6. Stateful VNFs with multiple physical views . . . . . . . . . 9 81 6. Gap analysis - open source projects . . . . . . . . . . . . . .10 82 6.1. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . .10 83 6.2. ODL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 NFV is a network architecture concept that proposes using IT 93 virtualization related technologies, to virtualize entire classes of 94 network service functions into building blocks that may be connected, 95 or chained, together to create end-to-end network services. NFV 96 service is defined as a composition of network functions and 97 described by its functional and behavioral specification, where 98 network functions (i.e., firewall, DPI, SSL, load balancer, NAT, AAA, 99 etc.) are well-defined, hence both their functional behavior as well 100 as their external interfaces are described in each specifications. 102 In NFV, a VNF is a software package that implements such network 103 functions. A VNF can be decomposed into smaller functional modules or 104 APIs for scalability, reusability, and/or faster response [ETSI-NFV- 105 Arch],[ETSI-NFV-MANO]. These modular updates or composition for a 106 network function may lead to many other verification or security 107 issues. In addition, a set of ordered network functions which build 108 FGs may be connected, or chained, together to create an end-to-end 109 network service. Multiple VNFs can be composed together to reduce the 110 complexity of management and VNF FGs. While autonomic networking 111 techniques could be used to automate the configuration process 112 including FG updates, it is important to take into account that 113 incomplete and/or inconsistent configuration may lead to verification 114 issues. Moreover, automation of NFV process with integration of SDN 115 may lead the network services to be more error-prone. In this sense, 116 we need to identify and verify key properties to be correct before 117 VNFs and FGs are physically placed and realized in the supporting 118 infrastructure. 120 1.1. Terminology 122 This document draws freely on the terminology defined in [ETSI-NFV- 123 Arch]. 125 2. Problem statement 127 The verification services should be able to check the following 128 properties: 130 2.1. Dependencies of network service components in NFV framework 132 In NFV framework, there exist several network service components 133 including NFVI, VNFs, MANO, etc. as well as network controller and 134 switches to realize end-to-end network services. Unfortunately, these 135 components have intricate dependencies that make operation incorrect. 136 In this case, there is inconsistency between states stored and 137 managed in VNF FGs and network tables (e.g., flow tables), due to 138 communication delays and/or configuration errors. For example, if a 139 VNF is replicated into the other same one for the purpose of load 140 balance and a new FG is established through the copied one, but all 141 the state/DBs replication is not finished yet due to delays, this can 142 lead to unexpected behaviors or errors of the network service. 143 Therefore, these dependencies make it difficult to correctly compose 144 NFV-enabled end-to-end network services. 146 2.2. Invariant and error check in VNF FGs 148 In VNF FGs, an infinite loop construction should be avoided and 149 verified. Let us consider the example. Two VNF A and VNF B are 150 located in the same service node X whereas another VNF C resides in 151 other service node Y [SIGCOMM-Gember]. Also, the flow direction is 152 from X to Y, and the given forwarding rule is A->C->B. In such a 153 case, service node Y can receive two ambiguous flows from VNF A: 1) 154 one flow processed by VNF A and 2) another flow processed by VNF A, 155 B, and C. For the former case, the flow should be processed by VNF C 156 whereas the latter flow should be further routed to next service 157 nodes. If these two flows cannot be distinguished, service node Y can 158 forward the flow to service node X even for the latter case and a 159 loop can be formed. To avoid the infinite loop formation, the 160 forwarding path over VNF FG should be checked in advance with the 161 consideration of physical placement of VNF among service nodes. Also, 162 reactive verification may be necessary, since infinite loop formation 163 may not be preventable in cases where configuration change is 164 happening with live traffic. 166 In addition, isolation between VNFs (e.g. confliction of properties 167 or interference between VNFs) and consistent ordering of VNF FGs 168 should be always checked and maintained. 170 2.3. Load balancing among VNF instances 172 In VNF FG, different number of VNF instances can be activated on 173 several service nodes to carry out the given task. In such a 174 situation, load balancing among the VNF instances is one of the most 175 important considerations. In particular, the status in resource usage 176 of each service node can be different and thus an appropriate amount 177 of jobs should be distributed to the VNF instances. To guarantee 178 well-balanced load among VNF instances, the correctness of hash 179 functions for load balancing needs to be verified. Moreover, when VNF 180 instances locate in physically different service nodes, simple 181 verification of load balancing in terms of resource usage is not 182 sufficient because different service nodes experience diverse network 183 conditions (e.g., different levels of network congestion)[ONS- 184 Gember]. Therefore, it is needed to monitor global network condition 185 as well as local resource condition to achieve the network-wide load 186 balancing in VNF FGs. Also, whether the monitoring function for 187 network/compute/storage resources is correctly working should be 188 checked. 190 2.4. Policy and state consistency on NFV services 192 In VNF FG, policy to specific users can be dynamically changed. For 193 example, a DPI VNF can be applied only in the daytime in order to 194 prohibit from watching adult contents while no DPI VNFs applied 195 during the nighttime. When the policy is changed, the changed policy 196 should be reconfigured in VNF service nodes as soon as possible. If 197 the reconfiguration procedure is delayed, inconsistent policies may 198 exist in service nodes. Consequently, policy inconsistency or 199 confliction needs to be checked. Also in some situations, states for 200 VNF instances may be conflicted or inconsistent. Especially when a 201 new VNF instance is instantiated for scale-up and multiple VNF 202 instances are running, these multiple VNF instances may have 203 inconsistent states owing to inappropriate instantiation procedure 204 [SIGCOMM-Gember]. In particular, since the internal states of VNF 205 instances (e.g., the instantaneous state of CPU, register, and memory 206 in virtual machine) are not easily-visible, a new way to check the 207 VNF internal states should be devised. 209 2.5. Performance 211 In VNF FG, VNF instances can be located in different service nodes 212 and these service nodes have different load status and network 213 conditions. Consequently, the overall throughput of VNF FG is 214 severely affected by the service nodes running VNF instances. For 215 example, if a VNF instance locates in a heavily loaded service node, 216 the service time at the service node will be increased. In addition, 217 when a VNF FG includes a bottleneck link experiencing congestion, the 218 end-to-end performance (e.g., latency and throughput) in the VNF FG 219 can be degraded. Furthermore, policies on the performance such as 220 minimum bandwidth or latency can be given to VNFs or their FGs. 221 Therefore, the identification of bottleneck link and node is the 222 first step for performance verification or guarantee of the VNF FG 223 [ONS-Gember]. After detecting the bottleneck link/node, the VNF 224 requiring scale up or down can be identified and the relocation of 225 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 Network Service 248 (NS) policies against 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 inconsistent with 273 each other when they have contradictive resource constraints on the 274 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 The verification framework addressed in this document follows [ETSI- 325 NFV-Testing]. [ETSI-NFV-Testing] covers the following aspects of pre- 326 deployment testing: 1) assessing the performance of the NFVI and its 327 ability to fulfil the performance and reliability requirements of the 328 VNFs executing on the NFVI, 2) data and control plane testing of VNFs 329 and their interactions with the NFV Infrastructure and the NFV MANO, 330 and 3) validating the performance, reliability and scaling 331 capabilities of network services. 333 A verification framework for NFV-based services also needs to satisfy 334 the following requirements:. 336 o R1 : It should be able to check global and local properties and 337 invariants. Global properties and invariants relate to the 338 entire VNFs, and local properties and invariants relates to 339 the specific domain or resources that some of the VNFs are 340 using. For example, Loop-freeness and isolation between 341 VNFs can be regarded as global. The policies that are 342 related only to the specific network controllers or devices 343 are local. 345 o R2 : It should be able to access to information on the entire 346 network states and resource usage whenever verification 347 tasks are started. It can directly manage the states of 348 network and NFV-based services through databases or any 349 solution that specializes in dealing with the network 350 topology and configurations, or can utilize the functions 351 provided by NFV M&O and VNFI solutions to get or set the 352 states at any time. 354 o R3 : It should be independent from specific solutions and 355 frameworks, and provide standard APIs. 357 o R4 : It should able to process standard protocols such as 358 NetConf, YANG, OpenFlow, and northbound and southbound 359 interfaces that are related network configurations, and 360 used by OSS. 362 5. Challenging issues 364 There are emerging challenges that the verification services face 365 with. 367 5.1. Consistency check in distributed state 369 Basically, NFV states as well as SDN controllers are distributed. 370 Writing code that works correctly in a distributed setting is very 371 hard. Therefore, distributed state management and consistency check 372 has challenging issues. Some open source projects such as ONOS offers 373 a core set of primitives to manage this complexity. RAFT algorithm 375 [RAFT] is used for distribution and replication. Similarly, Open 376 daylight project has a clustering concept to management distributed 377 state. There is no "one-size-fits-all" solution for control plane 378 data consistency. 380 5.2. Intent-based service composition 382 Recently, Intent-based policing feature/approach/mechanism has been 383 added in open source projects [ODL],[ONOS]. The Intent allows for a 384 descriptive way to get what is desired from the infrastructure, 385 unlike the current NFV description and SDN interfaces which are based 386 on describing how to provide different services. This Intent will 387 accommodate orchestration services and network and business oriented 388 SDN/NFV applications, including OpenStack Neutron, Service Function 389 Chaining, and Group Based Policy. A Intent compiler translates and 390 compiles it into low level instructions (e.g., SDN 391 controller/OpenStack primitives) for network service components. In 392 this sense, error checking and debugging are critical for reliable 393 Intent-based service composition. 395 5.3. Finding infinite loops 397 General solutions for the infinite loop can lead to intractable 398 problem (e.g. the halting problem). To make the verification 399 practical and minimize the complexity, some restrictions are 400 required. Finding cycle can be processed in polynomial time but the 401 restriction could be too much for some cases that service functions 402 or network flows requires finite loops. 404 5.4. Complexity of live traffic verification 406 It is a known fact that the complexity of verification tasks for the 407 real and big problem is high. A few invariants can be checked in 408 real-time but it would be impossible if the size of VNFs increases or 409 properties to be checked are complex. 411 5.5. Languages and their semantics 413 For the verification, all the information on VNFs including 414 configurations, dynamic states and their temporal orderings need to 415 be precisely expressed in platform independent languages based on 416 formal semantics. The languages and their semantic models should be 417 optimized to the verification frameworks as well as the NFV 418 infrastructures. 420 5.6. Stateful VNFs with multiple physical views 422 The correctness of VNFs whose behaviors depend on the previous states 423 (packets, actions, etc) and whose physical entities are multiple 424 should be checked differently than the stateless ones. Such VNFs 425 include firewall, load balancer, NAT, flow rules with counter or soft 426 timeout. 428 o Case 1: 429 If a firewall service is implemented over two physical OpenFlow 430 switches, there could be two paths that the client-server 431 packets go through. If the packets between client and server go 432 through the same switch, the firewall functions correctly. 433 However if packets from client to server go through S1 but 434 packets from server to client come back through S2, those flows 435 could be blocked and lead to false-negative result. 437 To mitigate the situation, states of all instances for one 438 logical VNF must be considered to verify the correctness. 440 ~-----------------------~ 441 |Enterprise/private nets| 442 | +----+ | 443 +------+ |----| S1 |<--| +------+ | 444 |Server|<-+ | +----+ +--|Client| | 445 | |--+ | +----+ +->| | | 446 +------+ |--->| S2 |---| +------+ | 447 | +----+ | 448 ~-----------------------~ 450 o Case 2: 451 If there are VNFs whose behavior depend on the previous VNF, 452 those dependency must be considered as well. 454 For example, if firewall and load balancer gets packets go 455 through NAT service, they need to know the header mapping 456 information that the NAT have set to correctly process their 457 functions. If the FG consists of IPS followed by DPI and those 458 functions are connected different switches, the switch 459 connecting DPI must know if the incomming packets should be 460 forwarded to DPI or not. Port knocking is also well-known 461 example of stateful function. 463 To mitigate the situation, the states of all VNFs having 464 behavioral dependency must be considered when they are verified. 466 6. Gap analysis - open source projects 468 Recently, the Open Platform for NFV (OPNFV) community is 469 collaborating on a carrier-grade, integrated, open source platform to 470 accelerate the introduction of new NFV products and services [OPNFV]. 471 Open Daylight (ODL) is also being tightly coupled with this OPNFV 472 platform to integrate SDN controller into NFV framework [ODL]. 474 This clause analyzes the existing open source projects including 475 OPNFV and ODL related to verification of NFV services. 477 6.1. OPNFV 479 6.1.1. Doctor 481 The Doctor project provides a NFVI fault management and maintenance 482 framework on top of the virtualized infrastructure. The key feature 483 is to notify unavailability of virtualized resources and to recover 484 unavailable VNFs. 486 While the Doctor project focuses only on faults in NFVI including 487 compute, network, and storage resources, the document discusses 488 broader fault management issues such as break-down of the supporting 489 infrastructure due to incomplete or inconsistent configuration of NFV 490 services. 492 6.1.2. Moon 494 The Moon project implements a security management system for the 495 cloud computing infrastructure. The project also enforces the 496 security managers through various mechanisms, e.g., authorization for 497 access control, firewall for networking, isolation for storage, and 498 logging for tractability. 500 Note that the main interest of the Moon project is the DDoS attack to 501 a service node and the IDS management for VNFs. A wider range of 502 security issues in the NFV service verification need to be 503 discussed. 505 6.1.3 Bottlenecks 507 The Bottlenecks project aims to find system bottlenecks by testing 508 and verifying OPNFV infrastructure in a staging environment before 509 committing it to a production environment. Instead of debugging the 510 deployment in production environment, an automatic method for 511 executing benchmarks to validate the deployment during staging is 512 adopted. For example, the system measures the performance of each VNF 513 by generating workload on VNFs. The Bottlenecks project does not 514 consider incomplete or inconsistent configurations on NFV services 515 that might cause the system bottlenecks. Furthermore, the Bottlenecks 516 project aims to find system bottlenecks before committing it to a 517 production environment. Meanwhile, the draft also considers how to 518 find bottlenecks in real time. 520 6.1.4 VSPerf 522 The VSPerf projects provides an automated testing framework and 523 comprehensive test suite based on industry standards for measuring 524 data-plane performance. The architecture of VSPerf is agnostic to 525 switch and traffic generator and test scenarios can be customized. 527 The VSPerf can be used for developing switching technologies as well 528 as for evaluation and optimization of the data-path performance. 530 6.2. ODL 532 6.2.1. Network Intent Composition 534 The Network Intent Composition project enables the controller to 535 manage and direct network services and network resources based on 536 intent for network behaviors and network policies. Intents are 537 described to the controller through a new northbound interface, which 538 provides generalized and abstracted policy semantics. Also, the 539 Network Intent Composition project aims to provide advanced 540 composition logic for identifying and resolving intent conflicts 541 across the network applications. 543 When the reconfiguration upon the policy (i.e, intent) is delayed, 544 policy inconsistency in service nodes may occur after the policy is 545 applied to service nodes. While the Network Intent Composition 546 project resolves such intent conflicts only before they are 547 translated into service nodes, this document covers intent conflicts 548 and inconsistency issues in a broader sense. 550 6.2.2. Controller Shield 552 The Controller Shield project proposes to create a repository called 553 unified-security plugin (USecPlugin). The unified-security plugin is 554 a general purpose plugin to provide the controller security 555 information to northbound applications. The security information 556 could be for various purposes such as collating source of different 557 attacks reported in southbound plugins and suspected controller 558 intrusions. Information collected at this plugin can also be used to 559 configure firewalls and create IP blacklists for the network. 561 In terms of security services, the document covers authentication, 562 data integrity, confidentiality, and replay protection. However, the 563 Controller Shield project only covers authentication, data integrity, 564 and replay protection services where the confidentiality service is 565 not considered. 567 6.2.3. Defense4All 569 The Defense4All project proposes a SDN application for detecting and 570 mitigating DDoS attacks. The application communicates with ODL 571 controller via the northbound interface and performs the two main 572 tasks; 1) Monitoring behavior of protected traffic and 2) Diverting 573 attacked traffic to selected attack mitigation systems (AMSs). 575 While the Defense4All project only focuses on defense system at the 576 controller, this document includes broader defense issues at the 577 service node as well as the controller. 579 6.3. Summary 581 The verification functions should spread over the platforms to 582 accomplish the requirements mentioned in clause 3. The correctness of 583 NFV- based services and their network configurations can be checked 584 in the NFV MANO layer which has the entire states of the VNFs. Each 585 NFVI needs to provide verification layer which composed of policy 586 manager, network database and interfaces (e.g. REST APIs). Local 587 properties and invariants can be verified inside the specific NFVI, 588 and the global properties and invariants can be checked by merging 589 local verification results from the related NFVIs. 591 The verification service provides verification functions to NFV MANO, 592 NFVI, and any other low-level modules such as SDN controllers. For 593 the platform independency, it provides standard APIs to process the 594 verification tasks. It also uses standard APIs provided by OSS such 595 as OpenStack (Neutron) and Open Daylight. The compiler and 596 interpreter translate standard description languages and protocols 597 into the internal model which optimized to the verification tasks. It 598 can process user-defined properties to be checked as well. The 599 properties to be checked whether they are user-defined or pre-defined 600 invariants are managed by property library. The verifier maintains a 601 set of verification algorithms to check the properties. The network 602 database inside the verification service manages the global network 603 states directly or indirectly. 605 A PoC can be implemented using OpenStack (Neutron) and Open Daylight. 606 The modules related to verification framework can reside in between 607 network virtualization framework (e.g. OpenStack Neutron) and SDN 608 controller (e.g. Open Daylight). Neutron and Open Daylight uses 609 standard APIs provided by verification service to accomplish 610 verification tasks. The initial use case for the PoC could be, in 611 particular, any of security, performance, etc as mentioned in clause 612 2. 614 7. Security Considerations 616 As already described in clause 2.6, how to verify security holes in 617 VNF FG is very important consideration. In terms of security 618 services, authentication, data integrity, confidentiality, and replay 619 protection should be provided. On the other hand, potential security 620 concern should be also carefully checked since several VNFs (e.g., 621 NAT) can modify or update packet headers and payload. 623 8. Acknowledgements 625 The authors would like to thank formal methods lab members in Korea 626 University for their verification theory support. Also thank Jose 627 Saldana for his useful comments. 629 9. References 631 9.1. Normative References 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, March 1997. 636 9.2. Informative References 638 [ETSI-NFV-Arch] ETSI, "Network Function Virtualisation (NFV); 639 Architectural Framework," 2014. 641 [ETSI-NFV-MANO] ETSI, "Network Function Virtualiztion (NFV) 642 Management and Orchestration," 2014. 644 [ETSI-NFV-Testing] ETSI, "Network Function Virtualiztion (NFV) Pre- 645 deployment Testing; Report on Validation of NFV 646 Environments and Services," 2016. 648 [SIGCOMM-Qazi] Z. Qazi, C. Tu, L. Chiang, R. Miao, V. Sekar, and M. 649 Yu, "SIMPLE-fying Middlebox Policy Enforcement Using SDN," 650 in Proc. ACM SIGCOMM 2013, August 2013. 652 [ONS-Gember] A. Gember, R. Grandl, A. Anand, T. Benson, and A. 653 Akella, "Stratos: Virtual Middleboxes as First-Class 654 Entities," ONS 2013 and TR. 656 [SIGCOMM-Gember] A. Gember, R. Viswanathan, C. Prakash, R. Grandl, J. 657 Khalid, S. Das, and A. Akella, "OpenNF: Enabling 658 Innovation in Network Function Control," in Proc. ACM 659 SIGCOMM 2014, August 2014. 661 [HOTSDN-Ghorbani] S. Ghorbani, B. Godfrey, "Towards Correct Network 662 Virtualization", HOTSDN 2014. 664 [RAFT] https://raftconsensus.github.io/. 666 [ODL] "OpenDaylight SDN Controller, "http://www.opendaylight.org/ 668 [ONOS] "Open Network Operating System, "http://onosproject.org/ 670 [OPNFV] "Open Platform for NFV, "https://www.opnfv.org/ 672 Authors' Addresses 674 Myung-Ki Shin 675 ETRI 676 161 Gajeong-dong Yuseng-gu 677 Daejeon, 305-700 678 Korea 680 Phone: +82 42 860 4847 681 Email: mkshin@etri.re.kr 683 Ki-Hyuk Nam 684 Friesty 686 Email: nam@friesty.com 688 Sangheon Pack 689 Korea University 691 Email: shpack@korea.ac.kr 693 Seungik Lee 694 ETRI 695 161 Gajeong-dong Yuseng-gu 696 Daejeon, 305-700 697 Korea 699 Phone: +82 42 860 1483 700 Email: seungiklee@etri.re.kr 702 Ramki Krishnan 703 Dell 705 Email: Ramki_Krishnan@dell.com