Verification of NFV Services : Problem Statement and Architecture
draft-shin-nfvrg-service-verification-00

NFVRG                                                           M-K. Shin
Internet-Draft                                                       ETRI
Intended status: Informational                                     K. Nam
Expires: April 25, 2015                                           Friesty
                                                                  S. Pack
                                                         Korea University
                                                                   S. Lee
                                                                     ETRI
                                                         October 25, 2014

   Verification of NFV Services : Problem Statement and Architecture
                draft-shin-nfvrg-service-verification-00

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 architecture 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 April 25, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
 

Shin et al.,               Expires April 2015                   [Page 1]
Internet-Draft        Verification of NFV Services      October 25, 2014

   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.  Proposed Architecture . . . . . . . . . . . . . . .  . . . . .  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 April 2015                   [Page 2]
Internet-Draft        Verification of NFV Services      October 25, 2014

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 [Net-Shin]

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 April 2015                   [Page 3]
Internet-Draft        Verification of NFV Services      October 25, 2014

   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 April 2015                   [Page 4]
Internet-Draft        Verification of NFV Services      October 25, 2014

   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 April 2015                   [Page 5]
Internet-Draft        Verification of NFV Services      October 25, 2014

           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. Proposed Architecture 

   Conceptual model for verification architecture can be described as
   illustrated in Figure 1. 

   The verification architeture 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 M&O 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 April 2015                   [Page 6]
Internet-Draft        Verification of NFV Services      October 25, 2014

    |VNF1| |..  | |VNFn|    |    Service    |<+   |  Verification  |
    +----+ +----+ +----+    |  Description  | |   | +------------+ |
    +------------------+    +---------------+ |   | |    APIs    | |
    |       VNFI       |    +---------------+ |   | +------------+ |
    | +--------------+ |    |    NFV MANO   | |   | +------------+ |
    | | Verification | |    |+-------------+| +-->| |Comp & Inter| |
    | |[PM][NDB][Int]|<--+  ||Orchestrator || +-->| +------------+ |
    | +--+ +---+ +---+ | |  |+-------------+| |   | +------------+ |
    | +--------------+ | |  || VNF Manager || |   | |Property Lib| |
    | |Virtualization| | |  |+-------------+| |   | +------------+ |
    | +--------------+ | +-->| Verification|<-+   | +------------+ |
    | |  Resources   | |    ||   Manager   ||     | |  Verifier  | |
    | | +-+ +-+ +--+ | |    |+-------------+|     | +------------+ |
    | | |C| |S| |Nt| | |    ||  VI Manager ||     | +------------+ |
    | | +-+ +-+ +--+ | |    |+-------------+|     | | Network DBs| |
    | +--------------+ |    |               |     | +------------+ |
    +------------------+    +---------------+     +----------------+
    PM: Policy Manager                              Comp & Inter :
    NDB : Network DB                                Compiler & Inter-
    Int : Interface (APIs)                          preter 
    C : Compute 
    S : Storage
    Nt : Network  

    Figure 1 Conceptual Model for Verification Architecture of NFV

   The verification manager in the NFV M&O 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 M&O,
   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
   properties to be checked whether they are user-defined or pre-defined
 

Shin et al.,               Expires April 2015                   [Page 7]
Internet-Draft        Verification of NFV Services      October 25, 2014

   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 in the NFV M&O 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 (NFV M&O) and the verification layer of 
      VNFIs
       - set_properties(properties or invariants)
 

Shin et al.,               Expires April 2015                   [Page 8]
Internet-Draft        Verification of NFV Services      October 25, 2014

         * It sets a list of properties to be check. After calling 
           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 M&O
       - 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 April 2015                   [Page 9]
Internet-Draft        Verification of NFV Services      October 25, 2014

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.

   [Net-Shin] M. Shin et al., "Verification for NFV-enabled Services,"
              IEEE Network Magazine (submitted), 2015.  

 

Shin et al.,               Expires April 2015                  [Page 10]
Internet-Draft        Verification of NFV Services      October 25, 2014

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

Shin et al.,               Expires April 2015                  [Page 11]