Research ArticleTowards an Efficient Management and OrchestrationFramework for Virtual Network Security Functions

Ignazio Pedone , Antonio Lioy, and Fulvio Valenza

Politecnico di Torino, Dip. Automatica e Informatica, Torino, Italy

Correspondence should be addressed to Ignazio Pedone; ignazio.pedone@polito.it

Received 9 May 2019; Accepted 20 September 2019; Published 12 November 2019

Academic Editor: Prosanta Gope

Copyright © 2019 Ignazio Pedone et al. �is is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work isproperly cited.

�e recent years have witnessed a growth in the number of users connected to computer networks, due mainly to megatrends suchas Internet of �ings (IoT), Industry 4.0, and Smart Grids. Simultaneously, service providers started o�ering vertical servicesrelated to a speci�c business case (e.g., automotive, banking, and e-health) requiring more and more scalability and �exibility forthe infrastructures and their management. NFV and SDN technologies are a clear way forward to address these challenges eventhough they are still in their early stages. Security plays a central role in this scenario, mainly because it must follow the rapidevolution of computer networks and the growing number of devices.�emain issue is to protect the end-user from the increasingthreats, and for this reason, we propose in this paper a security framework compliant to the Security-as-a-Service paradigm. Inorder to implement this framework, we leverage NFV and SDN technologies, using a user-centered approach. �is allows tocustomize the security service starting from user preferences. Another goal of our work is to highlight the main relevant challengesencountered in the design and implementation of our solution. In particular, we demonstrate how signi�cant is to choose ane�cient way to con�gure the Virtual Network Security Functions in terms of performance. Furthermore, we also address thenontrivial problem of Service Function Chaining in an NFV MANO platform and we show what are the main challenges withrespect to this problem.

1. Introduction

Cybercrime has grown faster in the past years, attacks areevolving rapidly, and organizations are forced to continuouslyupdate their cybersecurity and cyberdefence techniques. Asreported in [1], in between 2014 and 2016, cyberattacks haveevolved in two directions: growing number of threats andimpact which the attack has on its target. �e Verizon reportexplicitly describes [2], nowadays, cyberattacks are verytangible threats. Actually, about 76% of breaches were �-nancially motivated (i.e., aimed at stealing secrets, intellectualproperties, personal data, and sensitive information).

�e Internet Service Providers (ISPs) that give connec-tivity to those devices are challenged by this scenario andneed to provide more and more �exible, scalable, andcustomizable security solutions to their clients for protectingtheir data and privacy.

To reduce risks, various cybersecurity components areusually adopted, such as antimalware, �rewall, virtual privatenetwork (VPN), and parental control functions. Several ISPshave started to o�er their customers security controlsimplemented at the ISP premises (e.g., data centres). Ofcourse, providing security services to hundreds of thousandsor even millions of users is a challenging task which showsseveral limitations of traditional network technologies.Network Function Virtualisation (NFV) and Software-De-�ned Networking (SDN) are technologies that grant to theISPs a reliable and scalable solution to address the end-usersecurity problem.

NFV exploits a virtual infrastructure where network andsecurity functions are implemented by software componentscalled Virtual Network Functions (VNFs). NFV decouplessoftware and hardware. For instance, VNFs can run in eithervirtual machines (VMs) or software containers, hosted on

HindawiSecurity and Communication NetworksVolume 2019, Article ID 2425983, 11 pageshttps://doi.org/10.1155/2019/2425983

standard high-volume servers (or ad hoc hardware), so thatthey can be easily deployed and removed on demand.

On another hand, the SDN paradigm provides a net-working architecture where the control and forwardingplanes are separated, and control functions are directlyprogrammable. 'is migration of traffic control, from tra-ditionally embedded and hard-wired individual networkdevices to programmable computing equipment, enables theabstraction of the communication infrastructure so thatapplications and services can be designed, implemented, anddeployed by considering the network as a logical entity. Insummary, SDN introduces unprecedented flexibility in thenetwork, in particular by allowing dynamic fine-grainedselection of arbitrary traffic flows that can be (re)routedthrough different network paths according to the controlsnap decisions when they are needed. 'ese features can beleveraged to provide each user with the required securityservices; for instance, traffic flows concerning different userscan be dynamically directed to different sets of securitycontrols.

Even if these appealing technologies offer significantadvantages in terms of flexibility, they also introduce newchallenges such as the correct configuration of the networksecurity functions [3].

Indeed, the impact of the “human error factor” oncontinuously growing networks is certainly not negligible, asseveral studies have proved. Nearly 60% of the securitybreaches, which occurred in 2015, originated from errorsmade by system and network administrators [4].

A new approach among ISPs is rising: the Security-as-a-Service (SECaaS) [5] paradigm. 'is allows to relief the userfrom complex security configurations and grants an alwaysupdated security service.

We started our work from [6], in which a complete user-centric framework was proposed to provide the personalsecurity of a user. We applied this approach to an NFVInfrastructure and implemented an evolution of thatframework. In the process, we addressed the following threemain problems: the integration of a policy manager in anNFV environment, the configuration of Virtual NetworkSecurity Functions (vNSFs), and the Service FunctionChaining in NFV Management and Orchestration (NFVMANO).

'e first problem addressed in this research is stronglyrelated to the concept of policy-based management dis-cussed in [7]. Indeed, the ETSI standards clearly express theneed for an integrated security policy manager, which de-fines the way to choose the VNFs and to link and configurethem. Our framework gives an answer to that requirementand tries to bring to light the major problems encountered inthis process of integration.

'e second problem is related to configuration. 'is is anontrivial issue considering the number of tools available onthe market and the differences between the vendors thatdevelop the VNFs. 'e choice for the most efficient andreliable tool could make the difference in contexts in whichscalability and flexibility are not expendable. We have ex-plored the major tools on the market, and we have chosenthe ones more suitable for the problem.

In the end, we addressed the last problem, which someNFV MANO platforms do not even consider (e.g., OpenBaton): the steering of the traffic leveraging Service FunctionChaining (SFC) and/or VNF Forwarding Graphs (VNFFGs).We proposed and tested a solution which integrates in ourframework this feature, giving full support for VNFFGs.

'e rest of the paper is structured as follows. Section 2briefly recalls the main works in literature that focus onSECaaS in an NFV environment, SFC, VNFFGs, and NFVMANO. Section 3 presents the proposed architecture andframework, while Section 4 discusses the configuration ofthe vNSFs and, finally, Section 5 examines the creation ofService Function Chains with these vNFSs. Finally, Section 6evaluates our framework and Section 7 concludes the paper.

2. Background and Related Work

'e focus of this paper is centered on the new NFVManagement and Orchestration technologies and the use ofthe SECaaS paradigm in order to grant security to the end-user. We start by describing the background and the relatedworks concerning those technologies and the SECaaSparadigm.

2.1. Security-as-a-Service in an NFV Environment. 'econcept of SECaaS takes place starting with another notion:the vNSF. In an NFV environment, indeed, it is possible todefine a particular VNF [8] offering security functionalities(e.g., vFW, vIDS, and vDPI) and hence called vNSFs. SECaaSis a new approach based on NFV Orchestration whichdeploys security protections by means of vNSFs.'e derivedsecurity services could offer dynamic response for a specificset of threats addressable with the available vNSFs; scalabilitybased on the enterprise capabilities; and targeted securitydata monitoring and gathering at a specific point in thenetwork for analysis and remediation.

In the literature, the SECaaS approach has been deeplyinvestigated in the last few years. For instance, some authors[9] proposed a “user-centric” approach for the provision ofvirtualised security at the network edge. In that paper, acomplete framework design is shown, in which an NFVInfrastructure is used to provide security services for theend-user terminals. 'e vNSFs, which in that case werecalled Personal Security Applications (PSAs), were driven bya policy-based management system. 'at system was incharge of gathering user policies (expressed in an high-levellanguage: the High-level Security Policy Language (HSPL))and the admin policies (expressed in a medium-level lan-guage: the Medium-level Security Policy Language (MSPL));translating those policies in a service graph, which describesthe needed PSAs and the links between them, and a set oflow-level configurations for the PSAs used; and enforcingthose low-level configurations on the PSAs deployed startingfrom the service graph provided.

Another SECaaS example is shown in [10], where theauthors provide an extensible, adaptable, fast, low-cost, andtrustworthy cybersecurity solution. 'is aims at deliveringIT security as an integrated service of virtual network

2 Security and Communication Networks

infrastructures that can be tailored for ISPs and enterpriseconsumers. In this case, vNSFs are dynamically instantiatedand configured after a malicious event or a threat. Fur-thermore, the choice of the attack remediation is driven by aData Analysis and Remediation Engine (DARE); this enginefeatures analytical components and is capable of predictingspecific vulnerabilities and attacks. 'e DARE relies oncontinuous monitoring of the network traffic, using mon-itoring vNSFs, and translates their observation into a col-lection of data capable of inferring events which a singlevNSF could not.

2.2. /reat Analysis. As specified by [11], there are manythreats that involve the NFV Infrastructure itself, at theNFVI, VNF, and NFVMANO layers, respectively. However,our approach aims at solving threats that affect user’sperspective, using a SECaaS approach. As claimed before,errors in network security configuration can create vul-nerabilities that in turn affect the overall security, decreasethe network throughput, and increase the maintenancecosts.

2.3. Service Function Chain and VNFFG. IETF defines aService Function Chain [12] as a set of abstract servicefunctions and ordering constraints that must be applied topackets and/or frames and/or flows selected as a result ofclassification. 'e classification is the process of matchingthe traffic flows against the policy for the subsequent ap-plication of the required network service functions. 'eClassifier is the element that performs the classification. Inother words, the SFC is the mechanism which allows for-warding the traffic of an end-to-end service and defining inwhich VNFs the latter must pass through.

ETSI, instead, defines a similar object called VNF For-warding Graph (VNFFG) [13], a graph whose nodes rep-resent the VNFs and the logical links define the connectionbetween them; the latter could be unidirectional, bi-directional, multicast, and/or broadcast. 'e simplest ex-ample of VNFFG is a single chain of VNFs.We have also twoadditional elements: the Forwarding Service Path (FSP) andthe Classifier; the first one is the equivalent of an SFC; thesecond is the Classifier which is associated with the FSP inorder to classify the traffic on the right path.

In [14], a use case of SFC applied to NFV and SDNtechnologies is reported. In particular, an SFC Orchestratorcapable of dynamically updating the Service Function Pathsat any time has been proposed.'e utility of this approach isclear during a fault or a decrease in the performance of aVNF. In that case, all the other VNFs in the chain suffer as faras the previous one is a bottleneck. A remediation to thisproblem is scaling out the affected VNF though we need toreconfigure also the SFPs in order to cleverly redistribute thetraffic along the new instances.

One of the challenges which we aim to address regardingthe SFC is partially discussed in [15]. Mechtri et al. proposeda new End-to-End SFC Orchestration Framework, which iscompliant with ETSI NFV MANO, in order to overcome atleast two problems: giving a harmonized service abstraction

and description languages for NFV and SDN requirementsand automating end-to-end service production for agileNFV services. 'e main reason why we consider anothersolution is because we had the aim of completely leveragingon the existing platforms that have already addressed thisproblem without implementing a new NFV MANO.

2.4. Management and Orchestration in NFV MANO.Management and Orchestration of the NFV Infrastructureplays a central role in modern computer networks. Cen-tralizing the deployment, management, and monitoring ofthe Virtual Network Functions (VNFs), which give thepossibility to have a complete end-to-end Network Service(NS), simplifies the way the service providers reach theirusers. Our focus in this paper is on the configuration of theVNFs and the support for Service Function Chaining whichan NFVMANO should provide. In the following, we analysethe main open source NFVMANO platforms on the market:

(i) Open Source MANO (OSM) (available online athttps://osm.etsi.org) is an ETSI-hosted project todevelop an Open Source NFV MANO frameworkstack aligned with ETSI NFV standards. It offers amultiple Virtual Infrastructure Manager (VIM)support, which means it could be used with multipleInfrastructure-as-a-Service technologies (e.g.,OpenStack, AWS, OpenVIM, and VMware) for theresource orchestration. OSM allows also to combinethem with different SDN Controller technologies(e.g., ONOS, floodlight, and ODL) to manage theunderlying connectivity. A monitoring system andan experimental support for VNFFG are provided aswell. In order to manage the VNFs instance, OSMadopts Juju of Canonical as VNF Manager.

(ii) Open Baton (available online at https://openbaton.github.io) is an NFV MANO solution compliantwith the ETSI NFV MANO specifications. It has amodular architecture, in which a message broker(RabbitMQ) grants the communication between aset of different orchestration and supplementaryservices. 'e main services offered are the orches-tration of resources, the monitoring system, and aset of drivers which allow to use this platform overmultiple VIM technologies. In order to extend OpenBaton for supporting other VIMs, it is required tocreate a new driver plug-in and a specific VNFM forthis technology. 'is approach gives an interestingflexibility to the VIM support; indeed, Open Batonhas been the first NFV platform to give support toDocker Engine as VIM. So far, this platform,however, does not support SFC or VNFFGsmechanisms.

(iii) OpenStack Tacker (available online at https://docs.openstack.org/tacker/latest/) is an additional servicefor the OpenStack framework (available online athttps://www.openstack.org). 'is service providesNFV Orchestration functionalities (e.g., VNFs/NSsmanagement), leveraging the services included in

Security and Communication Networks 3

the OpenStack IaaS platform (e.g., Neutron, Nova,and Heat). 'e main advantage of using this plat-form is the full support for SFC with the servicenamed networking-sfc and VNFFGs; in theNetworkService Descriptor (NSD), we could provide a high-level description of FSPs and Classifiers as well.

Although NFV MANO technologies are growing fast,there are still different challenges to address. As the authorsof [16] report, one of the most significant ones is the de-pendability level of NFV.'is depends on the NFVMANOplatform for two different reasons: the NFV MANOmanages the available resources to provide optimal service;therefore, it may be used to deal with failures of networkelements efficiently and to improve service dependability;on the other hand, since the NFV MANO maintains aglobal view of the NFV system, it may affect the entirenetwork as result of a mismanagement. Moreover, thatpaper provides a tutorial on these NFV MANO challengesand gives a clear insight into further research on how toaddress those problems. In our paper, we focused ourattention on vNSF configuration and Service FunctionChaining, so we chose the MANO platforms that betteraddress those challenges and compare them: OSM andTacker.

2.5.ConfigurationTools. We explore in this section the maintools for virtual instance configuration and give an overviewof the options available on the market:

(i) Juju (available online at https://jujucharms.com) is atool from Canonical which provides instantiation,management, monitoring, and scaling of cloudapplications in an efficient and rapid way. We couldperform those actions on different platforms (e.g.,OpenStack, AWS, Google Platform, and LXD) oreven physical machines (Metal-as-a-Service(MaaS)). 'e way Juju works is a collection ofPython or Bash scripts called “Charm.” A Charmprovides all needed information to deploy andconfigure a virtual instance and the tools for itsmonitoring. We need the Charm running on theinstance in order to configure it.

(ii) Ansible (available online at https://www.ansible.com) is a tool developed by the Ansible Commu-nity and Red Hat. It performs all the requiredoperations in order to deploy, manage, and con-figure a virtual instance via SSH, leveraging a Py-thon interpreter. 'e operation to be performed ona virtual instance could be expressed in the form of aYAML descriptor, which is called a “playbook.” Allthe operations performed by Ansible do not requireany software daemon on the instance.

(iii) Chef (available online at https://www.chef.io) isanother tool for deployment and managementautomation developed by the Chef company. 'is isone of the first tools for this purpose and is used byproviders like Facebook, AWS, and Prezi. In thiscase, we need a client daemon on the instance in

order to perform the configuration on the virtualinstance.

(iv) Puppet (available online at https://puppet.com) is atool for deployment and management automationdeveloped by Puppet Company. As in the case ofChef, it requires a software daemon on the instancein order to execute the actions.

(v) SaltStack (available online at http://www.saltstack.com) is a tool for the management of virtual in-stances as the others described above. In this case,we could have a daemon on the instance (saltminion) or not (salt ssh) depends on the version.'e features offered are the same as in Ansible, butthe support for different platforms and the power ofsyntax is better in Ansible.

Considering the listed features provided by the analysedconfiguration tools, we can conclude that Ansible is themore suitable platform for use in our case.

3. Framework Design and Architecture

Starting from the premises expressed in the last section, wenow present the whole framework architecture; this wasbuilt to provide the Network Security Service (NSS) for theend-user. 'e main aspects described in this section are asfollows:

(i) High-level architecture: an overview of the wholesolution architecture

(ii) Security Service Manager (SSM): the managementand orchestration framework for the NSS

(iii) NFV Infrastructure: the infrastructure for the vNSFdeployment

(iv) Solution workflow: a summary of the solutionworkflow based on an ISP use case

3.1. High-Level Architecture. Our high-level architecturecomposed of two main elements: the Security ServiceManager and the NFV Infrastructure (Figure 1). 'e Se-curity Service Manager is in charge of the whole NSS or-chestration. 'e starting point is given by the user, whichcould submit a specific set of high-level security policies tothe SSM. 'e latter is in charge of the translation of thosepolicies to a precise collection of configurations and anoverall description of the Network Security Service in theform of an NSD. 'e configurations are generated for adifferent set of vNSFs, which are implemented in specifictechnologies. 'e NSD, instead, is designed for the targetNFVMANO platform (in our case, OSM) and has the aim tocharacterize the vNSFs required and the links between them.After the policy translation process, a service provider coulddeploy the NSS of the specific user on its own infrastructureaccording to the given policies. 'e SSM is also in charge ofthis deployment and its management. For what concerns theinfrastructure, instead, it composed of different SecuritySites; Security Site is a generic Point-of-Presence (PoP) (e.g.,data centre), which typically consists of a VIM and different

4 Security and Communication Networks

Compute Nodes. A Security Service Manager is able tomanage different geographically distributed Security Sites;indeed, OSM offers a complete support for the multi-VIMmanagement and orchestration.

3.2. Security Service Manager. In Figure 1, the main com-ponents of the Security Service Manager are depicted: OpenSource MANO, the Security Service Controller, and PolicyServices. 'ese elements are designed and implemented to fitin a fully “containerized” environment; indeed, we adoptLXD (available online at https://linuxcontainers.org/lxd/introduction/) as virtualisation technology to deploy theservices linked to our solution. LXD is a next-generationcontainer technology based on Linux Containers and offers auser experience similar to virtual machines. 'is virtuali-sation solution provides also advanced features regardingsecurity, scalability, network management, resource control,and device management in a Linux Container context (e.g.,unprivileged containers, supports for multiple storage back-ends, and bridge creation/configuration). In our proposeddesign, the OSM Release 'ree architecture was extendedadding new containers in charge of providing each specificservice needed by our framework, forming three sets ofcontainers matching the SSM components. 'e “PolicyServices” containers handle the policy management; inparticular, it provides the following functionalities:

(i) Policy Reconciliation Service: this service providesthe aggregation of the policies from different actors(e.g., different users and admins).

(ii) Policy Refinement and Optimization: it handles thetranslation from high-level security policies tomedium-level security policies; the latter depend onthe types of vNSFs used but not on the specificvendor technologies. Besides, this service is incharge to draw up the service graph which defines

the vNSFs to use for the NSS and the links betweenthem [17, 18].

(iii) Policy Analysis Service: this module is in charge ofthe policy analysis in order to find any anomaliesamong them [6, 19].

(iv) User Policy Repository (UPR): this is the storage forall levels of policies and the service graphs.

(v) Consul and Vault: this provides service discoveryfunctionality and access control for the otherservices.

'e second set of containers is the Security ServiceController (SSC) which is in charge of giving the high-levelfunctionalities for both end-user and service provider side(e.g., policy definition and NSS deployment).'e SSC allowsto upload new security policies from the user side and, at thesame time, it manages the automatic instantiation of a newNSS for a specific user from the service provider side.

In the end, we have the last set of containers, which arelinked to OSM, providing the NFV MANO functionalities:VCA, SO, and RO. 'e VNF Configuration & Abstraction(VCA) is a VNF Manager (VNFM) abstraction; the latterprovides the life cycle management of the vNSFs leveragingJuju functionalities. 'e Resource Orchestrator (RO) is incharge of the resource orchestration (e.g., deploying vNSFsand managing the VIM).'e Service Orchestrator (SO) is thecomponent in charge to the NSS life cycle management (e.g.,launch, stop, and configure a NSS) and also performsmonitoring tasks on the Network Security Service.

3.3. NFV Infrastructure. 'e infrastructure in our solutionconsists of different Security Sites. 'is requires the possi-bility to abstract the management and orchestration layerfrom the infrastructural one. Indeed, this means we coulduse different VIM technologies at the same time. Our ar-chitecture allows to maintain this separation and use

Security ServiceManager

SecurityService

Controller

PolicyServices

Publicnetwork

NFV Infrastructure

Security Site

Security Site

ComputeNode

ComputeNode

ComputeNode

ComputeNode

VIM

VIM

Management & Orchestration

Figure 1: Framework architecture.

Security and Communication Networks 5

multiple VIMs to deploy the instances. In our framework, weimplement a test Security Site with OpenStack as VIM;OpenStack is a standard de facto for what concerns the opensource IaaS platform and almost every NFV MANOframework is compliant with it. OpenStack is also capable ofgiving every resource required by Open Source MANO (e.g.,compute, network, and storage) leveraging Nova andNeutron API.

3.4. Solution Workflow. In Figure 2, we showcase a typicaluse case consisting of an ISP which provides a NetworkSecurity Service to an end-user. All start with the user itself,during the step (1), who defines the high-level policiesthrough the Policy GUI, which is a Graphical User Interfaceexposed by SSC in order to allow the user to manage hispolicies. After this action, the high-level policies are stored inthe UPR and an ISP could start the NSS for this specific user.In order to complete this task, the ISP operates the NSSDeployer (2) which leverages the Policy Services to reconcileand refine the user policies (3). In particular, in this phase,we have the Policy Reconciliation, the translation fromHSPL to MSPL and the provision of the service graph.'ereafter, the NSS Deployer translates the service graph in aconsistent Network Service Descriptor for the NFV MANOplatform and sends it to the SO together with the MSPLpolicies.'e SO at this point (5) leverages the RO in order todeploy the virtual instance required for the NSS and thenetwork configuration for the underlying connectivity. Inthe end (6), the SO through the VCA enforces the policies onthe vNSFs and so the NSS could be defined “online.” 'etranslation in this process from MSPL to low-level config-uration is performed by the vNSF itself.

4. vNSF Configuration

One of the most relevant challenges for the NFV Orches-tration is the configuration and the life cycle management ofthe vNSFs. Since we used in our solution OSM as NFVMANO, the vNSF configuration relies on Juju as VNFManager (VNFM); adopting this solution (Juju with OSM)gives advantages in terms of flexibility for the vendor, whocould embed a series of configurations scripts called “ProxyCharms” directly in the OSM VNF Descriptor. 'e com-plication in this case lies in the overhead that is introducedby Juju in the process of vNSF creation, at least in a limitedresource scenario. We have discussed this strategy andproposed a new approach for the configuration in order toavoid this drawback: using Ansible as VNFM.

4.1. First Approach. Starting a Network Security Serviceimplies the launch of all the required vNSF instances and theproper configuration of them. In our solution, we performthis operation in two different steps:

(i) Day-0 configuration: during this step, we provide allthe software and configurations needed by the vNSFvia cloud-init technology, starting from an Ubuntucloud image; at the end of the process, we deliver a

fully working vNSF which gives the desired service.With this peculiar technology, we are able to installthe software packages required, inject the SSH keys,run arbitrary scripts, and configure the networkinterfaces of the instance.

(ii) Day-1 configuration: since the first type of config-uration stops after the initialisation of the vNSF, weneed to provide a second configuration mechanismfor the Virtual Network Security Function life cyclemanagement. In order to achieve this result, weadopted the VNFM suggested and supplied by OSMframework: Juju.

'e Day-0 configuration has been provided as a tech-nique to avoid the use of prebuilt software images. 'isapproach allows to save space on the software image re-pository since we need for this new approach just a small setof a base cloud image (e.g., Ubuntu 16.04 LTS). On top ofthem, as described before, we could configure all the soft-ware requirements and configurations via cloud-init. 'eDay-1 configuration, instead, is crucial to avoid the reini-tialisation of the vNSFs after a change in the behaviour of thesecurity service. A typical example could be a firewallreconfiguration during the life cycle of the security service.With this type of configuration, we could change the settingsof the specific vNSF, acting in this case like a firewall, withoutreinitialising neither the vNSF nor the Network SecurityService.

'e way we provide this functionality is via Juju, asdescribed before. Juju allows to perform a set of actionstriggered by OSM on every specific vNSF (e.g., start, stop,and set rules), leveraging the mechanisms of the ProxyCharm (Figure 3). A Proxy Charm is a virtual instance

SecurityService

Controller

PolicyServices

PolicyGUI

NSSDeployer

RO SO VCA

OSM

vFW vDPI vNSF

NFV Infrastructure

(1)User

Internet

ISP

(2) (3)

(4)

(5) (6)

Traf

fic fl

owSFC

Figure 2: Solution workflow related to an ISP use case.

6 Security and Communication Networks

(typically an LXD container) which is in charge of themanagement operations on the vNSF. 'is virtual instanceembeds a series of Python scripts and libraries which allow tocommunicate via SSH to the final vNSF instance and toexecute arbitrary python code in order to manage the vNSF.'e set of scripts needed from the Proxy Charm have to beloaded in advance in the VNF Descriptor (VNFD) package.With this approach, every single vNSF has his own ProxyCharm and the vendor has the flexibility to customize thevNSF configuration, without changing anything at theVNFM layer, directly in the description of the vNSF. Eventhough this approach is very flexible and scalable, it has aconsistent drawback: we need a virtual instance for eachsingle vNSF.'is requirement could be a significant obstacleespecially for NFV MANOs with limited infrastructureresources.

4.2. Evolution. 'e Juju solution for the second-step vNSFconfiguration could appear as a real breakthrough, butthe problem lies in the overhead introduced for the newinstances and their configuration. For our purpose, as inmany real use cases, it is not mandatory to adopt Juju asVNFM; this is because we need a high-level controller(the SSC) to perform automatically the actions on thevNSF after some event on the platform (e.g., remediationto an attack and change of the user policies). 'is means

we could rely on any system which allows us to configurethe instance during its life cycle (e.g., Puppet, Chef,Ansible, and SaltStack). We choose Ansible as a re-placement because it does not require a daemon on theinstance to perform the configurations; other choices(e.g., Chef and Puppet) would lead us to require thatdaemon and call for further configurations and resourcesduring the virtual instance launching process. For thisreason, we had started to explore Ansible as VNFManager evolution for our framework and we proposedand tested an alternative plug-in mechanism with Ansible“playbooks” (Figure 3).

A playbook is a file descriptor representing the lan-guage used by Ansible to describe the operations to beperformed on a virtual instance. 'e single operation iscalled task, and the playbook is essentially a collection ofthem. One of the most relevant advantages of using Ansibleis the powerful semantics given by the playbook and itstasks; they offer an easy way to install software packages, tocopy files, and to perform all the typical required opera-tions on a virtual instance in the form of a YAML de-scriptor. Besides, another advantage is no need for adedicated virtual instance for every single vNSF as the Jujucase; in that case, it was needed an LXD container perProxy Charm; now it is required only an LXD containerhosting Ansible framework. 'e only additional operationto be performed is in the upload process of a new vNSFDescriptor (e.g., a new supported vNSF) and is the loadingof the new plug-in for the vNSF in the Ansible Container.'e plug-ins we designed are a collection of playbookscapable of performing every “Day-1 configuration” neededby the vNSF.

'e Security Service Controller is in charge of calling theproper configuration through Ansible; thus, we couldreconfigure the vNSFs during their life cycle leveraging thismechanism. Ansible is also extensible for use with Docker(available online at https://www.docker.com); therefore, thissolution is also suitable in the container case. As we will seein the next section, we also addressed the problem of theautomatic traffic steering, leveraging another NFV MANOplatform rather than OSM. Even in that case, the two-stepconfiguration with cloud-init and Ansible is applicablewithout substantial changes.

5. Service Function Chaining

Another challenging problem of the NFV Orchestration isthe steering of the traffic. Many of the best known NFVplatforms (e.g., Open Baton) address the problem of theNFV Management and Orchestration without the use ofthe Service Function Chaining or the VNF ForwardingGraph. 'is means that the traffic between the vNSFs isconfigured manually in every single vNSF or at least itneeds to be provided an external controller to manage thetraffic flows. Our goal is to configure the whole securityservice starting only from the NSD; thus, the trafficsteering should be automatically configured between thevNSFs as well. Another question about the traffic steeringis the support for SFC and VNFFGs given by the NFV

NFVI

Juju Controller

ProxyCharm

ProxyCharm

ProxyCharmLXD

VCA

vFW

vDPI

vIDS

VCAAnsible

vFWplug-in

vDPIplug-in

vIDSplug-in

SSH

SSH(a)

(b)

Figure 3: VNF Managers: Juju vs. Ansible comparison.

Security and Communication Networks 7

MANO. In order to classify the different traffic flows, anNFV Orchestration framework needs to support thisfeature and the libraries offered by the specific VIMadopted. For instance, Open Source MANO gives an ex-perimental support to VNFFGs only since the OSM releaseFOUR, while other platforms like Tacker offer a morestable support for this kind of technologies. In this section,we will show how we could integrate Tacker in ourframework.

Leveraging the VNFFGs support given by Tacker, weproposed an extension of our framework which allows todefine different paths for the traffic flows. As shown inFigure 4, for example, we could replicate the scenario of theuser who needs a security service in order to access theInternet. In this scenario, we have different types of users(e.g., based on the type of access) and different types oftraffic as well (e.g., different transport or applicationprotocols). Based on this information, we can classify thetraffic flows and redirect the traffic itself only through theneeded vNSF instances. 'is approach could be a realbreakthrough in terms of flexibility in different scenarios,in particular in which the network is divided based on thetype of traffic and the specific business case (e.g., thenetwork slicing in 5G).

OpenStack Tacker is an orchestration platform that fullysupports the VNFFGs and Service Function Chaining for aspecific VIM, in this case OpenStack. Tacker leverages theOpenStack service Heat for the ResourceManagement of thevNSFs, while it uses the OpenStack service networking-sfc tosupport the VNFFG and instructs the virtual switches, whichare implemented inOpen vSwitch (OVS) technology, on howthey have to manage the traffic. Tacker also has two types ofdescriptor as the OSM case: VNF Descriptor and NS De-scriptor. In the last one, it is possible to define not only thevNSFs which are required for the service, but also the FSPsand the Classifiers for each path. Our idea is to start from thehigh-level policies and give in their translation informationabout the way we need to classify the traffic, in the form ofthe final NSD.

At the end, in this descriptor, we have all the informationabout the traffic steering, the different FSPs, and the Clas-sifiers. 'e only change to be made in our framework is thetranslation of the service graph to another NSD model. Wehave also another advantage in using Tacker: the lowerrequirements in terms of infrastructure resources. WithOSM, we need to install a complete NFV Orchestrationframework: the VNFM Juju, the monitoring services, theResource Orchestrator, and the Service Orchestrator. Allthose services rely on the specular VIM services: OpenStackNova and Heat for the resource management, Ceilometer forthe monitoring and the metrics, and networking-sfc for theService Function Chaining. Using Tacker, instead, allows toadd one only service to the OpenStack VIM platform and torely on a complete NFV MANO framework. A reason forsupporting OSM could be his potential support for differentVIMs. 'e problem until now is that the best VIM platformsupported from OSM is OpenStack, and there are still someservices (e.g., networking-sfc) for which it gives an exper-imental support.

6. Evaluation

We evaluated our framework in different scenarios, based onthe different technologies used. In particular, we have de-fined two different scenarios:

(i) VM scenario: in this scenario, we explored the in-stantiation time of the Network Security Servicedepending on the number of the required vNSFs.More specifically, we used virtual machines on KVMas virtualisation technology and OpenStack as VIM.For what concerns the configurations, we leveragedboth Day-0 and Day-1 configurations; the last onewas performed with Juju.

(ii) Container scenario: in this scenario, we still haveevaluated the time instantiation of the NSS, but usingDocker as virtualisation technology and vim-emu(available online at https://osm.etsi.org/wikipub/index.php/VIM emulator) as VIM. In particular,in this scenario, Day-0 configuration was performedwith Dockerfile and no Day-1 configurations areintended to be performed.

In these test scenarios, we used two physical machines,one acting as Security Site (VIM and Compute Node) andthe other acting as a SSM (SSC, Policy Services, and OSM).Both the machines had an Intel Core i7 (quad-core 2.6 GHz)CPU, 16GB of RAM, 512GB of SSD storage, and LinuxUbuntu server (16.04.3 LTS) as Operating System. In the firstscenario, we tested the first solution with OSM and Juju, butwe also discussed the possible result enhancement using theAnsible solution. In the second scenario, we leveraged anexperimental VIM provided by OSM as described below.

6.1. VMScenario. In this scenario, we used virtual machinesand OpenStack as VIM. We evaluated the instantiation timeof the NSS depending on the number of vNSFs required. Wealso performed the two types of configuration describedabove. We need to point out that the Day-0 configuration

Useraccess

Internet

vFW vDPI vIDS vNSF

NFVSDN

HeatNetworking-sfc Neutron

Tacker (NFV MANO)

Flow

clas

sifie

r

Flow

clas

sifie

r

OVS

Figure 4: Service Function Chaining: a SECaaS use case.

8 Security and Communication Networks

with cloud-init is mandatory in our framework due to theuse of cloud images. For this reason, we show in Figure 5 thetrend of the instantiation time according to the number ofvNSFs used in the NSS itself. 'e dotted line indicates thetime for instantiation of the resources needed by the VMsand the initialisation time of the cloud image. 'e dashedline instead shows the configuration time due to the Day-0configuration. 'e continuous line reports the total timeneeded for the security service to be at disposal. As we canunderstand from the graph, the configuration time in thiscase is in the same range (1–10 s), as the cloud-init con-figuration is performed in parallel within all the vNSFs. 'istime, depending also on the specific requirements for thevNSF, we use random vNSFs (vFW, vDPI, and vIDS) withdifferent requirements, but this finally does not depend onthe number of vNSFs instantiated. 'e time of initialisationinstead depends on the number of the vNSFs, and it is almostlinear as the number of vNSFs increases. In another scenario,we also test the deployment of the same security services ontwo different OpenStack VIMs, where the second one is anexact clone of the first described with the same physicalresources.

We experimented a constant decrease in terms of timeneeded to initialise the NSS, and it is shown in Figure 6.Withthis first configuration (Day-0), we had a complete workingNSS without the possibility to reconfigure it during its lifecycle. If we want this feature, we need to rely on somethingdifferent as the Juju. We tested this scenario evaluating thetime needed to deploy and configure the virtual instances(LXD containers) which have to run the Proxy Charm incharge of the reconfiguration of the vNSFs. As shown inFigure 7, we notice that the time needed in this case(continuous line) to instantiate the security service signifi-cantly diverges as the number of vNSFs increases. We alsoevaluated the overhead introduced by Juju (dashed line) inthe instantiation time, comparing it with the previous case(dotted line). 'e graph shows how Juju introduces a sig-nificant delay and is not the best solution for the Day-1configuration. We proposed as evolution Ansible whichneeds no instantiation time for every single vNSF and givesthe same functionality as Juju in the reconfiguration of thevNSFs. Using the framework evolution, we could save theoverhead time introduced by Juju and bring the whole in-stantiation time to the one provided in the first results withonly Day-0 configuration.

6.2. Container Scenario. With respect to the ContainerScenario, we used an experimental feature of OSM, whichwas created in order to obtain the Docker container or-chestration within OSM. We deployed a set of containerizedvNSFs and evaluated the time needed for the instantiationand the Day-0 configuration. In this case, we operated theDockerfile as Day-0 configuration and no tools in order toperform the Day-1 configuration. As shown in Figure 8, wehad a significant increase in terms of performance in theinstantiation time. 'e dashed line represents the Dockerinstantiation time while the continuous one represents theinstantiation time with the virtual machines technology. For

what concerns the Day-1 configuration, we could use twoapproaches in the future concerning the container case: thefirst approach is to restart the whole NSS due to the shortertime to instantiate the container instead the VMs, and the

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

NSS confNSS initNSS tot

VNSFs (no.)

Tim

e (s)

1112131415161718191

101111

Figure 5: NSS instantiation time: initialisation and Day-0configuration.

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29

Mono-VIMMulti-VIM

VNSFs (no.)

Tim

e (s)

1112131415161718191

101111

Figure 6: NSS instantiation time: monosite vs. multisite.

1 2 3 4 5 6 7 8 9 10

Juju overheadNSS time (init + Day-0)NSS time (init + Day-0 + Day-1)

VNSFs (no.)

Tim

e (s)

1316191

121151181211241271301331361391

Figure 7: NSS instantiation time: initialisation, Day-0 configura-tion, and Day-1 configuration.

Security and Communication Networks 9

second one is to use Ansible to reconfigure it with the sametechnique of the VM case, but leveraging theDocker DeamonAPI instead of the SSH connection to the instances. 'isscenario is experimental and represents an interestingevolution for the SECaaS paradigm on NFV technologies.'e aim of this test is to show how promising could be afuture integration and NFV Orchestration with containertechnologies.

7. Conclusions

In this paper, we have proposed a practical imple-mentation of the SECaaS paradigm, leveraging NFV andSDN technologies. 'e way we stated the main challengesand proposed solution to them supplies an improvementon the state of the art about what technologies are morereliable and useful in order to implement this approachby an ISP. Furthermore, the configuration of the vNSFsand the Service Function Chaining are two critical points,which are widely pointed out in ETSI’s standards, andthey require to be deeply investigated in the time to come.Part of this work has been focused to address thisquestion. Another contribution is about the tests madeon the framework and on the infrastructure presented inboth a virtual machine and container case scenario. 'esetests show how the adoption, or at least the partialadoption, of lightweight virtualisation could dramaticallyimprove the Network Security Service performances. Inconclusion, this paper outlines some of the futurechallenges and evolution of this work, underlining theneed for new resource optimization techniques and afurther investigation about the container configurationtechnologies.

Data Availability

No data were used to support this study.

Conflicts of Interest

'e authors declare that there are no conflicts of interestregarding the publication of this paper.

Acknowledgments

'is work has been partly supported by the SHIELD project,cofunded by the European Commission (H2020 grantagreement no. 700199).

References

[1] IBM, “IBM X-force threat intelligence index 2018 notablesecurity events of 2017, and a look ahead,” 2018, https://www.ibm.com/downloads/cas/MKJOL3DG.

[2] Kevin Townsend, “Verizon: 2019 data breach investigationsreport,” Verizon, Tech. Rep., IETF Datatracker, 2019.

[3] L. Durante, L. Seno, F. Valenza, and A. Valenzano, “A modelfor the analysis of security policies in service function chains,”in Proceedings of the 2017 IEEE Conference on NetworkSoftwarization (NetSoft), pp. 1–6, Bologna, Italy, July 2017.

[4] C. Basile, D. Canavese, A. Lioy, C. Pitscheider, and F. Valenza,“Inter-function anomaly analysis for correct SDN/NFV de-ployment,” International Journal of Network Management,vol. 26, no. 1, pp. 25–43, 2016.

[5] ETSI, “GR NFV 001—V1.2.1—network functions virtualisation(NFV); use cases,” 2017, https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx.

[6] F. Valenza, C. Basile, D. Canavese, and A. Lioy, “Classificationand analysis of communication protection policy anomalies,”IEEE/ACM Transactions on Networking, vol. 25, no. 5,pp. 2601–2614, 2017.

[7] ETSI, “GS NFV-SEC 013—V3.1.1—network functions virtu-alisation (NFV) release 3; security; security management andmonitoring specification,” 2017, https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx.

[8] ETSI, “GS NFV-SWA 001—V1.1.1—network functions vir-tualisation (NFV); virtual network functions architecture,”2014, http://portal.etsi.org/chaircor/ETSI_support.asp.

[9] D. Montero, M. Yannuzzi, A. Shaw et al., “Virtualized securityat the network edge: a user-centric approach,” IEEE Com-munications Magazine, vol. 53, no. 4, pp. 176–186, 2015.

[10] G. Gardikis, K. Tzoulas, K. Tripolitis et al., “SHIELD: A novelNFV-based cybersecurity framework,” in Proceedings of the2017 IEEE Conference on Network Softwarization (NetSoft),pp. 1–6, Bologna, Italy, July 2017.

[11] M. Pattaranantakul, R. He, A. Meddahi, and Z. Zhang,“Secmano: towards network functions virtualization (nfv)based security management and orchestration,” in Proceedingsof the 2016 IEEE Trustcom/BigDataSE/ISPA, pp. 598–605,Tianjin, China, August 2016.

[12] J. Halpern and C. Pignataro, “Service function chaining (sfc)architecture,” in Internet Requests for Comments, RFC 7665,IETF Datatracker, 2015.

[13] ETSI, “GS NFV-MAN 001—V1.1.1—network functions virtu-alisation (NFV); management and orchestration,” 2014, http://portal.etsi.org/chaircor/ETSI_support.asp.

[14] A. M. Medhat, G. A. Carella, M. Pauls, and T. Magedanz,“Orchestrating scalable service function chains in a NFVenvironment,” in Proceedings of the 2017 IEEE Conference onNetwork Softwarization (NetSoft), pp. 1–5, Bologna, Italy, July2017.

[15] M. Mechtri, C. Ghribi, O. Soualah, and D. Zeghlache, “NFVorchestration framework addressing SFC challenges,” IEEECommunications Magazine, vol. 55, no. 6, pp. 16–23, 2017.

[16] A. J. Gonzalez, G. Nencioni, A. Kamisinski, B. E. Helvik, andP. E. Heegaard, “Dependability of the NFV orchestrator: state

3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33

NSS VM (init + Day-0)NSS Docker (init + Day-0)

VNSFs (no.)

Tim

e (s)

1112131415161718191

101111

Figure 8: NSS instantiation time: virtual machines vs. containers.

10 Security and Communication Networks

of the art and research challenges,” IEEE CommunicationsSurveys & Tutorials, vol. 20, no. 4, pp. 3307–3329, 2018.

[17] C. Basile, F. Valenza, A. Lioy, D. R. Lopez, and A. P. Perales,“Adding support for automatic enforcement of securitypolicies in NFV networks,” IEEE/ACM Transactions onNetworking, vol. 27, no. 2, pp. 1–14, 2019.

[18] A. Basile, C. Pitscheider, F. Risso, F. Valenza, and M. Vallini,“Towards the dynamic provision of virtualized security ser-vices,” in Cyber Security and Privacy Forum, pp. 65–76,Springer, Berlin, Germany, 2015.

[19] F. Valenza, S. Spinoso, C. Basile, R. Sisto, and A. Lioy, “Aformal model of network policy analysis,” in Proceedings of the2015 IEEE 1st International Forum on Research and Tech-nologies for Society and Industry Leveraging a better tomorrow(RTSI), pp. 516–522, Turin, Italy, September 2015.

Security and Communication Networks 11

International Journal of

AerospaceEngineeringHindawiwww.hindawi.com Volume 2018

RoboticsJournal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Shock and Vibration

Hindawiwww.hindawi.com Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwww.hindawi.com

Volume 2018

Hindawi Publishing Corporation http://www.hindawi.com Volume 2013Hindawiwww.hindawi.com

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwww.hindawi.com Volume 2018

International Journal of

RotatingMachinery

Hindawiwww.hindawi.com Volume 2018

Modelling &Simulationin EngineeringHindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Navigation and Observation

International Journal of

Hindawi

www.hindawi.com Volume 2018

Advances in

Multimedia

Submit your manuscripts atwww.hindawi.com