Virtualized Network Functions Security Attacks and Vulnerabilities Ahamed Aljuhani The Catholic University of America, United States University of Tabuk, Saudi Arabia
[email protected] Abstract—Network functions virtualization (NFV) is a new paradigm in the network technology domain. NFV decouples network functions (NFs) from proprietary appliances and deploys these functions into high-volume servers such as the x86. Instead of having NFs on propriety devices that are built-in software, NFV leverages virtualization to deploy NFs on highvolume servers. This will enable innovations and opportunity for industry and academia. In contrast with traditional networks, NFV reduces the capital expenditure (CAPEX) and operating expenses (OPEX). However, its security becomes crucial. Specifically, virtualized network functions (VNFs) are an important part of NFV. In this paper, we aim to investigate security issues in VNFs. Furthermore, we discuss security challenges in software defined networks (SDNs) when virtualized as VNFs. In this paper, we also highlight some important research directions in NFV that need more investigation to mitigate security attacks. Keywords—Network function virtualization; virtual network functions; NFV; security; VNF; Software Defined Network; SDN
Talal Alharbi The Catholic University of America, United States University of Jeddah, Saudi Arabia
[email protected] encourage innovation and competition in telecommunication industry and academia [5].
both
the
Another emerging network technology is the SDN, which enables networks to decouple underlying functions from the hardware into different planes such as data and control planes [11]. SDN and NFV are highly complementary and can work together, creating an interesting industry trend [12]. Consolidating SDN with NFV can be great because of the greater benefits they provide together [5]. However, SDN can stand alone, as can NFV [12]. With all due respect to NFV’s benefits, its security issues play critical roles and need to be addressed. More specifically, VNFs become a significant part of NFVs’ architecture. Therefore, VNFs can be vulnerable to diverse attacks from inside, outside and between VNFs. This paper, will investigate specific security issues in VNFs. Furthermore, we will explore and discuss security challenges in SDN as virtualized as VNFs. This paper also highlights some research directions in NFV that necessitate more study to mitigate security attacks.
I. INTRODUCTION Traditional networks operate and deploy in physical proprietary devices that have their own software running [1]. The devices usually are built-in software to provide specific network functions [2]. To provide services to consumers, the telecommunications industry must buy, store, and operate new physical devices [2]. All the traditional network requirements take long product cycles to provide service, and these requirements cause high CAPEX and OPEX [2].
This paper is structured as follow: Section II briefly outlines the architecture of NFV and SDN as VNFs. Section III discusses security issues in VNFs and SDN as VNFs. Section IV highlights some important research directions in NFV. Finally, we conclude this work in section V.
To address these issues, NFV was proposed in 2012 at the SDN & OpenFlow World Congress [3]. NFV provides a new trend for telecommunication service providers (TSPs), and changes the way traditional networks operate [3]. The idea behind NFV is to decouple NFs from the proprietary appliances’ hardware and leverage virtualization to run on high-volume servers such as the 86x [2]. To illustrate, traditional networks have implemented NFs in proprietary hardware that is limited to vendor specifications that cannot be changed [4].
A. NFV Architecture This section briefly outlines the architecture of NFV and how it works. Moreover, this section discusses SDNs as VNFs.
NFV, though, enables the network to implement NFs such as firewalls, gateways, and load balancers as virtualized software running on high-volume servers instead of proprietary hardware appliances. [4]. This process will
II. OVERVIEW
The European Telecommunication Standards Institute (ETSI) defines and produces different documents for NFV [6]. One of these documents addresses NFV’s architecture framework. Fig. 1 shows the high-level architecture of NFV, which consists of three main parts [7]:
978-1-5090-4228-9/17/$31.00 ©2017 IEEE
Fig. 3 Possible SDN resource locations in the VNF
III. VNFS SECURITY ISSUES
Fig. 1. NFV high-level architecture [7]
1) Virtualized Network Functions: Network Functions decoupled from dedicated hardware and implemented as virtualized software running over the NFVI as illustrated in fig. 1 [7]. Examples of NFs are: Evolved Packet Core (EPC), Gateways, Load Balancers, and Firewalls [7]. Fig. 2 shows the virtualization of network functions [6].
Despite all the advantages of NFV, security challenges become a major concern for both TSPs and consumers. A single attack can cause massive damage and bring the entire network down. As virtualized environment in NFV, VNFs are a significant part of NFV architecture when discussing security problem include: virtualized functions that implemented on vendor’s software, a third party involvement, and trust management between VNFs. In this section, we dive deeply into three types of attack: insider attack, outsider attack, and between VNFs attack. Also, we investigate and discuss possible security concerns on SDN as virtualized as a VNF. A. Insider Attack Insider attack occurs inside VNFs framework; attacker takes advantages of vulnerabilities in software in order to gain unauthorized access. Even worse, attacks can compromise the whole NFV components. In this subsection, we discuss deep security concerns related to VNFs software. 1) Security issues in VNFs software
Fig. 2. Virtualized Network Functions [6]
2) NFV Infrastructure (NFVI): The NFVI consists hardware resources, virtualization layer and virtualized physical resources (Compute, Storage and Network) on the top of virtualization layer; additionally, NFVI provides execution for VNFs [7]. 3) Management and Orchestration (MANO): MANO provides the lifecycle management and control of the NFV, also it provides performance analysis and it has three main components as follow [9] [10]: • Network Functions Virtualization Orchestration (NFVO). • Virtualized Infrastructure Manager (VIM). • Virtual Network Functions Manager (VNFM). B. SDN as a VNF One objective of this paper is to discuss the SDN as virtualized as a VNF. According to the ETSI document, an SDN controller can exist in many different locations in the context of NFV [13]. In another possible scenario shown in Fig. 3, the SDN exists inside a VNF framework with a switch or a router as a VNF [13]. In this paper, we discuss security concerns when SDN becomes a part of a VNF.
One of NFV advantages is to build open source software and deploy them on virtualized environments [14]. However, software is subject to diverse security attacks and caution is required before deploying any software into virtualized NFV environments. An adversary can exploit vulnerabilities in the deployed software, these vulnerabilities include implementation flaws and design flaws [15] [16]. Another related issue is dealing with a vendor who is untrustworthy, which may leads to weak security features and difficulty in communication [15]. One more security concern in deployed software is to follow up with software’s update/upgrade and make it up to date; updating software will help to fix bugs and other errors in order to keep software secured from attackers who can take advantage of vulnerabilities [17]. a) Software validation Another important part of VNFs software is validation; according to the ETSI document (ETSI GS NFV-SEC 001) a validation of VNF software has certain procedures beginning with installation and ending with launching of a VNF [16]. Validation emphasizes that the loaded code is authentic and has not been manipulated by unauthorized operation [16]. b) Software crashes In this section, we consider security issues in case of crashes; if the software operates on VM crashes, the hypervisor requires and makes sure there is no alteration to the existing authorizations. [16].
The following table summarizes security issues in VNFs software: TABLE I.
SECURITY ISSUES IN VNFS SOFTWARE
VNF Software Security Concerns
Types
Consequences
Implementation flaws and design flaws
Exploiting vulnerabilities by attackers
Software’s update/upgrade
An attacker gets advantages of bugs and errors
Software Validation [16]
Validation of VNF software
Boot integrity
Software Crashes [16]
Crash
Loss of data, unauthorized access
Security Issues in VNFs Software [15] [16]
B. Outsider Attack An outsider attack means when an entity from outside such as a third party has an access to NFVs by a remote access. In this part, we discuss possible attacks that might be caused by a third party. 1) A Third-party network VNFs infrastructure can be managed from outside access such as a third party network [18]. A third party controls the specific VNFs through a portal [15]. Therefore, significant security issues are raised not only in the VNFs themselves, but also NFV generally will suffer in terms of security threats [15]. Attacks occur when a third party is malicious; the infrastructure gets exposed by performing network attacks, such as DDOS, or even software attacks such as taking advantage of vulnerabilities in the deployed virtualization software [15]. Fig. 3 shows NFV deployment with a third party network [15].
Fig. 3 NFV deployment with a third party [15]
C. Between VNFs Attacks 1) Trust between VNFs Establishing and managing trust between VNFs is very important to provide security validation and integrity [1]. It is
also important both to provide and prevent attacks between entities such as spoofing and tampering [19]. The following are different forms of trust between VNFs [20]: • Trusting the information correctness output between software entities. •
Trusting between software entities to produce the correct operations.
•
Trusting to perform operations that have indirect influence on data.
The Virtual Network Function Component Instances (VNCIs) build the trust relationships between VNFs [20]. once the VNFs are established, they require a guarantee that other entities which they might react with can be trusted in order to execute certain operations [20]. Therefore, without trusting relationships, entities are not able to validate their own operations or other entities that they interact with. Also the SPs are not able to assure that the service which they provided will work as they expected [20]. However, establishing a longer chain of trust with additional software remains one of the security challenges [2]. 2) Sharing host Sharing underlying infrastructure among multiple hosted virtual machines is a significant security issue in VNFs. Attackers can perform malicious activities and attack the shared resources between VMs [16]. Another way if the attacker finds a way through one of the hosted VMs like a “noisy neighbor” in order to consume a large number of resources [16]. Therefore, we should isolate and protect different VMs in case if one of them has been compromised; the others should be able to work perfectly [2]. However, providing a secure isolation among shared resources is not simple [15]. D. SDN as a VNF As we stated in the overview part “section B”, there are many different positions that SDN can be located in the context of NFV framework; however, our focus was on identifying possible security issues in the case of SDN virtualized as VNFs. Now, we discuss in this subsection SDN application, SDN controller, and SDN resources. Security concerns can be related to their deployments and the communications and interfaces between them. 1) SDN application It is responsible for network resources customization including: allocation, automation, and management of the services [23]. Unauthenticated and unauthorized application or malicious application causes failure to the network. Therefore, specified and verified application should be guaranteed and checked all the time to prevent exploit of such vulnerability. 2) SDN controller This is a middle component between the applications and the network resources. It controls and relays the configuration that received from application to the network resources [23] [24]. However, compromised SDN controller might modify the
VNF forwarding graph [13]. Another security issue could be the Denial of Service attack (DoS), where the attack sends packets to consume the networking resources [25]. Integrity and confidentiality of the controller traffic should be verified. 3) SDN resources The SDN network resources are responsible for routing and packet processing. The data plane such as router and switch could be implemented as VNF. Every virtualized network resources should ensure the configurations from authentic SDN controller. 4) Interfaces SDN components: application, controller and resources communicate via standardized interfaces. This communication should be secured using resistant protocols. IV. RESEARCH DIRECTION As NFV is a new emerging technology, more studies are needed to solve the existing issues. Specifically, security concerns are a crucial part of research which need more study to improve security and make NFV more valuable to use. In this section we identify important security issues in NFV. •
Reduced isolation of NFs is one of the security challenges [18].
•
A longer chain of trust on additional software that provided from different vendors [21] [22].
• •
Sharing resources among VMs and multi tenancy cause privacy and security issues [22]. How to defend properly against DDoS remains a serious security issue in NFV [21].
[3]
[4] [5] [6] [7] [8] [9] [10] [11]
[12]
[13]
[14] [15]
[16] [17] [18]
V. CONCLUSION NFV is a new approach that introduces many benefits compared to a traditional network. However, its security issues remain significant and need further investigation. In this article we give an overview of NFV; then, we focus on VNFs which are an important part of NFV framework. This paper discusses three types of attack: insider attack, outsider attack, and between VNFs attack. Also, we mention SDN as virtualized as VNFs and discuss security issues with two possible positions: SDN controller as a VNF and SDN switch or a router as a VNF. Finally, this paper highlights future research directions in NFV, which require further study. REFERENCES [1]
[2]
F. Reynaud, F. X. Aguessy, O. Bettan, M. Bouet, and V. Conan, “Attacks against network functions virtualization and software-defined networking: state-of-the-art,” IEEE NETSOFT 2016 - 2016 IEEE NetSoft Conf. Work. Software-Defined Infrastruct. Networks, Clouds, IoT Serv., pp. 471–476, 2016. R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. De Turck, and R. Boutaba, “Network function virtualization: state-of-the-art and research
[19] [20] [21]
[22] [23] [24]
[25]
challenges,” IEEE Commun. Surv. Tutorials, vol. 18, no. 1, pp. 236–262, 2016. M. Chiosi, D. Clarke, P. Willis, A. Reid, J. Feger, M. Bugenhagen, W. Khan, M. Fargano, C. Cui, H. Deng, D. Telekom, and U. Michel, “Network functions virtualisation,an introduction, benefits, enablers, challenges & call for action,” Citeseer, no. 1, pp. 1–16, 2012. V. Network and I. Planning, “SDN-NFV reference architecture,” no. February, pp. 1–220, 2016. Y. Li, M. I. N. Chen, and S. Member, “Software-defined network function virtualization : a survey,” vol. 3, 2015. B. Chatras and F. F. Ozog, “Network functions virtualization: The portability challenge,” IEEE Netw., vol. 30, no. 4, pp. 4–8, 2016. ETSI, “Network functions virtualisation (NFV); Architectural Framework,” vol. 1, pp. 1–21, 2014. ETSI, “NFV infrastructure overview,” Etsi, vol. 1, pp. 1–59, 2015. Etsi and J. Quittek, “NFV- management and orchestration,” vol. 1, pp. 1–184, 2014. B. Thekkedath, Network functions virtualization for dummies, Hewlett Packard Enterprice, Hoboken, NJ, USA, 2016 D. B. Rawat and S. R. Reddy, “Software defined networking architecture, security and energy efficiency: a survey,” IEEE Commun. Surv. Tutorials, no. c, pp. 1–1, 2016. J. Costa-Requena, J. L. Santos, V. F. Guasch, K. Ahokas, G. Premsankar, S. Luukkainen, O. L. Pérez, M. U. Itzazelaia, I. Ahmad, M. Liyanage, M. Ylianttila, and E. M. De Oca, “SDN and NFV integration in generalized mobile network architecture,” 2015 Eur. Conf. Networks Commun. EuCNC 2015, no. November, pp. 154–158, 2015. “ETSI group specification: network functions virtualization (NFV); Ecosystem; Report in SDN usage in NFV Architecure Framework,” Dec. 2015. C. Price and S. Rivera, “Opnfv: an open platform to accelerate NFV,” White Paper, 2012. M. D. Firoozjaei, J. (Paul) Jeong, H. Ko, and H. Kim, “Security challenges with network functions virtualization,” Futur. Gener. Comput. Syst., 2016. “ETSI group specification: network functions virtualization (nfv) nfv security; problem statemetn,” Dec. 2015. “ETSI group specification: network functions virtualization (nfv) virtula network functions architecture,” Dec. 2014. Alcatel-Lucent, Providing security in nfv- challenges and opportunities, Alcatel-Lucent White Paper. Technical Report, Alcatel-Lucent, 2014. Huawei Technologies Co., “White paper - huawei observation to nfv,” p. 16, 2014. “ETSI group specification: network functions virtualization (nfv) nfv security; security and trust guidance,” Dec. 2014. W. Yang and C. Fung, “A survey on security in network functions virtualization,” IEEE NETSOFT 2016 - 2016 IEEE NetSoft Conf. Work. Software-Defined Infrastruct. Networks, Clouds, IoT Serv., pp. 15–19, 2016. J. Sen, “Security and privacy issues in cloud computing,” Archit. Protoc. Secur. Inf. Technol., no. iv, p. 42, 2013. Recommendation ITU-T Y.3300, “Framework of software-defined networking,” ITU-T, Jun. 2014. Understanding the SDN architecture - definition -. (n.d.). Retrieved Nov 09, 2016, from https://www.sdxcentral.com/resources/sdn/inside-sdnarchitecture/. S. Shin and G. Gu, “Attacking software-defined networks: a first feasibility study,” In Proceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN), pages 165– 166. ACM Press, 2013.
