NFVRG M-K. Shin Internet-Draft ETRI Intended status: Informational K. Nam Expires: August 7, 2015 Friesty S. Pack Korea University S. Lee ETRI Tae-wan Kim LG U+ March 7, 2015 Verification of NFV Services : Problem Statement and Challenges draft-shin-nfvrg-service-verification-01 Abstract NFV relocates network functions from dedicated hardware appliances to generic servers, so they can run in software. However, incomplete or inconsistent configuration of virtualized network functions (VNF) and forwarding graph (FG, aka service chain) could cause break-down of the supporting infrastructure. In this sense, verification is essential for network operators to check their requirements and network properties are correctly enforced in the supporting infrastructures. Recognizing these problems, we discuss key properties to be checked. Also, we present architectural framework and challenging issues for verification in NFV environments. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 7, 2015. Copyright Notice Shin et al., Expires August 2015 [Page 1] Internet-Draft Verification of NFV Services March 7, 2015 Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement : Properties to be checked . . . . . . . . 3 2.1. Dependencies of Network Service Components . . . . . . . . . 3 2.2. Loop-Free in VNF FGs . . . . . . . . . . . . . . . . . . . . 4 2.3 Load Balancing and Optimization among VNF Instances . . . . 4 2.4. Policy and State Consistency . . . . . . . . . . . . . . . . 4 2.5. Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Minimal Requirements . . . . . . . . . . . . . . . . . . . . . 5 4. Architectural Framework . . . . . . . . . . . . . . . . . . . 6 4.1. Properties and Invariants . . . . . . . . . . . . . . . . . 8 4.2. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Challenging Issues . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Shin et al., Expires August 2015 [Page 2] Internet-Draft Verification of NFV Services March 7, 2015 1. Introduction NFV is a network architecture concept that proposes using IT virtualization related technologies, to virtualize entire classes of network service functions into building blocks that may be connected, or chained, together to create network services. NFV service is defined as a composition of network functions and described by its functional and behavioral specification, where network functions (i.e., firewall, DPI, SSL, load balancer, NAT, AAA, etc.) are well- defined, hence both their functional behavior as well as their external interfaces are described in each specifications. In NFV, a VNF is a software package that implements such network functions. A VNF can be decomposed into smaller functional modules or APIs for scalability, reusability, and/or faster response [ETSI-NFV- Arch],[ETSI-NFV-MANO]. This modular updates or composition for a network function may lead to many other verification or security issues. In addition, a set of ordered network functions which build FGs may be connected, or chained, together to create an end-to-end network service. Multiple of VNFs can be composed together to reduce management and VNF FGs. While autonomic networking techniques could be used to automate the configuration process including FG updates, it is important to take into account that incomplete and/or inconsistent configuration may lead to verification issues. Moreover, automation of NFV process with integration of SDN may lead the network services to be more error-prone. In this sense, we need to identify and verify key properties to be correct before VNFs and FGs are physically placed and realized in the supporting infrastructure. 1.1. Terminology This document draws freely on the terminology defined in [ETSI-NFV- Arch]. 2. Problem Statement : Properties to be checked 2.1. Dependencies of Network Service Components In NFV, there exist several network service components including NFVI, NFVs, MANO, etc. as well as SDN controller and switches to realize end-to-end network services. Unfortunately, these components have intricate dependencies that make operation incorrect. In this case, there is inconsistency between states stored and managed in VNF FGs and network tables (e.g., flow tables), due to communication delays and/or configuration errors. For example, if a VNF is replicated into the other same one for the purpose of load balance and a new FG is established through the copied one, but all the Shin et al., Expires August 2015 [Page 3] Internet-Draft Verification of NFV Services March 7, 2015 state/DBs replication is not finished yet due to delays, this can be lead to unexpected behaviors or errors of the network service. Therefore, these dependencies make it difficult to correctly compose NFV-enabled end-to-end network services. 2.2. Loop-Free in VNF FGs In VNF FGs, an infinite loop construction should be avoided and verified. Let us consider the example. Two VNF A and VNF B locate in the same service node X whereas another VNF C resides in other service node Y [SIGCOMM-Gember]. Also, the flow direction is from X toY, and the given forwarding rule is A->C->B. In such a case, service node Y can receive two ambiguous flows from VNF A: 1) one flow processed by VNF A and 2) another flow processed by VNF A, B, and C. For the former case, the flow should be processed by VNF C whereas the latter flow should be further routed to next service nodes. If these two flows cannot be distinguished, service node Y can forward the flow to service node X even for the latter case and a loop can be formed. To avoid the infinite loop formation, the forwarding path over VNF FG should be checked in advance with the consideration of physical placement of VNF among service nodes. 2.3. Load Balancing and Optimization among VNF Instances In VNF FG, different number of VNF instances can be activated on several service nodes to carry out the given task. In such a situation, load balancing among the VNF instances is one of the most important considerations. In particular, the status in resource usage of each service node can be different and thus appropriate amount of jobs should be distributed to the VNF instances. Moreover, when VNF instances locate in physically different service nodes, simple verification of load balancing in terms of resource usage is not sufficient because different service nodes experience diverse network conditions (e.g., different levels of network congestion)[ONS- Gember]. Therefore, it is needed to monitor global network condition as well as local resource condition to achieve the network-wide load balancing in VNF FGs. 2.4. Policy and State Consistency In VNF FG, policy to specific users can be dynamically changed. For example, a DPI VNF can be applied only in the daytime in order to prohibit from watching adult contents while no DPI VNFs applied during the nighttime. When the policy is changed, the changed policy should be reconfigured in VNF service nodes as soon as possible. If the reconfiguration procedure is delayed, inconsistent policies may exist in service nodes. Consequently, policy inconsistency or confliction needs to be checked. Also in some situations, states for Shin et al., Expires August 2015 [Page 4] Internet-Draft Verification of NFV Services March 7, 2015 VNF instances may be conflicted or inconsistent. Especially when a new VNF instance is instantiated for scale-up and multiple VNF instances are running, these multiple VNF instances may have inconsistent states owing to inappropriate instantiation procedure [SIGCOMM-Gember]. In particular, since the internal states of VNF instances are not easily-visible, a new way to check the VNF internal states should be devised. 2.5. Performance In VNF FG, VNF instances can locate in different service nodes and these service nodes have different load status and network conditions. Consequently, the overall throughput of VNF FG is severely affected by the service nodes running VNF instances. For example, if a VNF instance locates in a heavily loaded service node, the service time at the service node will be increased. In addition, when a VNF FG includes a bottleneck link with network congestion, the end-to-end performance (e.g., latency and throughput) in the VNF FG can be degraded. Therefore, the identification of bottleneck link and node is the first step for performance verification or guarantee of the VNF FG [ONS-Gember]. After detecting the bottleneck link/node, the VNF requiring scale up or down can be identified and the relocation of VNF instance among service nodes can be determined 2.6. Security How to verify security holes in VNF FG is another important consideration. In terms of security services, authentication, data integrity, confidentiality, and replay protection should be provided. On the other hand, several VNFs (e.g., NAT) can modify or update packet headers and payload. In these environments, it is difficult to protect the integrity of flows traversing such VNFs. Another security concern in the VNF FG is denial of service (DoS) to a specific service node. If an attacker floods packets to a target service node, the target service node cannot perform its functions correctly. Therefore, such security attacks in the VNF FG should be detected and handled in an efficient manner. Moreover, unknown or unauthorized VNFs can run and thus how to identify those problems is another security challenge. 3. Minimal Requirements A verification architecture for NFV-based services needs to satisfy the following requirements:. o R1 : It should be able to check global and local properties and invariants. Global properties and invariants relate to the Shin et al., Expires August 2015 [Page 5] Internet-Draft Verification of NFV Services March 7, 2015 entire VNFs, and local properties and invariants relates to the specific domain or resources that some of the VNFs are using. For example, Loop-freeness and isolation between VNFs can be regarded as global. The policies that are related only to the specific network controllers or devices are local. o R2 : It should be able to access to the entire network states whenever verification tasks are started. It can directly manage the states of network and NFV-based services through databases or any solution that specializes in dealing with the network topology and configurations, or can utilize the functions provided by NFV M&O and VNFI solutions to get or set the states at any time. o R3 : It should be independent from specific solutions and frameworks, and provide standard APIs. o R4 : It should process standard protocols such as NetConf, YANG, OpenFlow, and northbound and southbound interfaces that are related network configurations, and used by OSS. 4. Architectural Framework Conceptual model for verification architecture can be described as illustrated in Figure 1. The verification architecture spreads over various places to accomplish the requirements mentioned above. The correctness of NFV- based services and their network configurations can be checked in the NFV MANO layer which has the entire states of the VNFs. Each VNFI needs to provide verification layer which composed of policy manager, network database and interfaces (e.g. REST APIs). Local properties and invariants can be verified inside the specific VNFI, and the global properties and invariants can be checked by merging local verification results from the related VNFIs. Shin et al., Expires August 2015 [Page 6] Internet-Draft Verification of NFV Services March 7, 2015 +-----------------------------------------+ +------------V-----+ +--------V-------+ |OSS/BSS[V.Service]|-----+ /-----------+ +->| [Veri. Server] | +------------------+ | |Service | | | +------------+ | +----+ +----+ +----+ | |Description| | | | APIs | | |VNF1| |... | |VNFn|-+ | +------+----+[V.M]| +------------+ | +----+ +----+ +----+ | +----------|----+ | | +------------+ | +------------------+ | | NFV MANO |<-+ | |Comp & Inter| | | NFVI | | |+-------------+| | +------------+ | | +--------------+ | | ||Orchestrator || | +------------+ | | |Virtualization| | | |+-------------|| | |Property Lib| | | +--------------+ | | |+-------------+| | +------------+ | | +--------------+ | +--|| VNF Manager || | +------------+ | | | Resources | | |+-------------+| | | Verifier | | | | +-+ +-+ +--+ | | |+-------------+| | +------------+ | | | |C| |S| |Nt| | |----|| VI Manager || | +------------+ | | | +-+ +-+ +--+ | | |+-------------+| | | Network DBs| | | +--------------+ | | | | +------------+ | +------------------+ +---------------+ +----------------+ V. Service : V.M : Veri. Server : Verification Service Verification Verification Server C : Compute Manager Comp & Inter : S : Storage Compiler & Inter- Nt : Network preter Figure 1 Conceptual Model for Verification Architecture of NFV The verification manager should process the following tasks: o Translates descriptions related to services, VNFs, and network configurations into the forms that the verification services can directly use for checking correctness. o Interfaces with VNFI and verification service through standard APIs to verify the global properties. o Constructs a global network states by taking snapshot or merging distributed local states. The verification service provides verification functions to NFV MANO, VNFI, and any other low-level modules such as SDN controllers. For the platform independency, it provides standard APIs to process the verification tasks. It also uses standard APIs provided by OSS such as OpenStack (Neutron) and Open Daylight. The compiler and interpreter translate standard description languages and protocols into the internal model which optimized to the verification tasks. It can process user-defined properties to be checked as well. The Shin et al., Expires August 2015 [Page 7] Internet-Draft Verification of NFV Services March 7, 2015 properties to be checked whether they are user-defined or pre-defined invariants are managed by property library. The verifier maintains a set of verification algorithms to check the properties. The network database inside the verification service manages the global network states directly or indirectly. A PoC can be implemented using OpenStack (Neutron) and Open Daylight. The modules related to verification framework can reside in between network virtualization framework (e.g. OpenStack Neutron) and SDN controller (e.g. Open Daylight). Neutron and Open Daylight uses standard APIs provided by verification service to accomplish verification tasks. 4.1. Properties and Invariants The verification framework should be able to check the following properties: o Infinite loop of network flows and service function chains for VNFs o Isolation between VNFs (e.g. confliction of properties or interference between VNFs) o Properties of VNFs (e.g. bandwidth, resource utilization) o Policies which VNFs and their underlying network infrastructures need to follow. o Consistent ordering of network functions chains and VNFs 4.2. APIs Verification service, verification manager and the verification layer of VNFI communicate using standard APIs to accomplish the verification tasks. The minimal APIs required are as follows: o Verification service and the verification layer of VNFIs - verify (property, virtual_network, vnf) * parameters: * returns a structure consists of verification result (true or false), and explanation or counter example in case of false o Verification manager and the verification layer of VNFIs - set_properties(properties or invariants) * It sets a list of properties to be check. After calling Shin et al., Expires August 2015 [Page 8] Internet-Draft Verification of NFV Services March 7, 2015 this API, verification tasks are automatically started whenever configurations are changed * It returns a structure consists of the result (true or false) and explanation in case of false (e.g. properties are already set, conflictions) - get_properties() returns a list of properties set in the NFV MANO - get/set_network_configuration gets or sets global network configurations required for VNFs 5. Challenging Issues There are a few challenges that the verification framework faces with: o Finding infinite loops : General solutions for the infinite loop can lead to intractable problem (e.g. the halting problem). To make the verification practical and minimize the complexity, some of the restrictions are required. Finding cycle can be processed in polynomial time but the restriction could be too much for some cases that service functions or network flows requires finite loops. o Real-time verification : It is known fact that the complexity of verification tasks for the real and big problem is high. A few invariants can be checked in real-time but it would be impossible if the size of VNFs increases or properties to be checked are complex. o Languages and their semantics For the verification, configurations and states of VNFs need to be precisely expressed using formal semantics. There are many languages and models, and it is impractical for the verification frameworks to support all of the existing languages and models. Languages and semantic models optimized to the verification framework need to selected or newly developed. 6. Security Considerations As already described in clause 2.6, how to verify security holes in VNF FG is very important consideration. In terms of security services, authentication, data integrity, confidentiality, and replay protection should be provided. On the other hand, potential security concern should be also carefully checked since several VNFs (e.g., NAT) can modify or update packet headers and payload. Shin et al., Expires August 2015 [Page 9] Internet-Draft Verification of NFV Services March 7, 2015 7. Acknowledgements The authors would like to thank formal methods lab members in Korea University for their verification theory support. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [ETSI-NFV-Arch] ETSI, "Architectural Framework v1.1.1," Oct 2013. [ETSI-NFV-MANO] ETSI, "Network Function Virtualization (NFV) Management and Orchestration,"(Work-in-Progress), 2014. [SIGCOMM-Qazi] Z. Qazi, C. Tu, L. Chiang, R. Miao, V. Sekar, and M. Yu, "SIMPLE-fying Middlebox Policy Enforcement Using SDN," in Proc. ACM SIGCOMM 2013, August 2013. [ONS-Gember] A. Gember, R. Grandl, A. Anand, T. Benson, and A. Akella, "Stratos: Virtual Middleboxes as First-Class Entities," ONS 2013 and TR. [SIGCOMM-Gember] A. Gember, R. Viswanathan, C. Prakash, R. Grandl, J. Khalid, S. Das, and A. Akella, "OpenNF: Enabling Innovation in Network Function Control," in Proc. ACM SIGCOMM 2014, August 2014. Shin et al., Expires August 2015 [Page 10] Internet-Draft Verification of NFV Services March 7, 2015 Authors' Addresses Myung-Ki Shin ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-700 Korea Phone: +82 42 860 4847 Email: mkshin@etri.re.kr Ki-Hyuk Nam Friesty Email: nam@friesty.com Sangheon Pack Korea University Email: shpack@korea.ac.kr Seungik Lee ETRI 161 Gajeong-dong Yuseng-gu Daejeon, 305-700 Korea Phone: +82 42 860 1483 Email: seungiklee@etri.re.kr Tae-wan Kim LG U+ Phone: +82 10 8080 6603 Email: dm24ks@lguplus.co.kr Shin et al., Expires August 2015 [Page 11]