This article describes a novel mechanism for the automated establishment of dynamic Virtual Private Networks (VPN) in the application domain of Network Function Virtualization (NFV). Each hop in an NFV Service Function Chain (SFC) lacks the capability of per-flow encryption, that makes the traffic flow in federated NFV environments vulnerable for eavesdropping. Due to the possible lack of bidirectional data plane communication channels between VNFs in an SFC, the Internet Security Key Exchange protocol (IPsec-IKE) is not applicable inside a VNF. Hence, this article introduces an alternative to IPsec-IKE that is specifically designed for NFV environments. This component is named Software Defined Security Associations (SD-SA), which is shown through a proof of concept evaluation to perform better than IPsec-IKE with respect to bandwidth and resource consumption.

Introduction

The security mechanisms in Software Defined Networks (SDN) and NFV lack the capability to encrypt and isolate the end-user traffic between VNFs. Fig. 1 exemplifies the problem by describing a typical VNF Service Function Chain (SFC), where the network traffic traverses multiple VNFs located at multiple service providers, while earlier work [1–۳] shows that the current NFV standardization attempts from ETSI [4] and IETF [5] do not take VNF isolation into account in the SFC design. Accordingly, an end-user who subscribes to VNF services from multiple services providers: • Cannot end-to-end encrypt traffic, since the VNFs require to have access in order to manipulate this traffic. • Is not aware and in control of which service providers having access to the data traffic, can potentially eavesdrop traffic and manipulate the route tables. • Does not know if the VNFs are shared network services with other users, who can as such access private data. Earlier work [1,2], showed that these problems could be resolved by introducing hop-by-hop encryption per IP flow or per group of IP flows. This is enabled by deploying an encryption application in front of every VNF within an SFC (Fig. 1). We showed that this encryption application is typically a Virtual Machine attached to the Virtual Link [6], particularly assigned for this function. These underlying encryption functions [1] can also be perceived as regular VNFs. Furthermore, earlier work also showed an additional problem with such an architecture. A service chain, following the NSH and SFC specification [6], can have a different service path than the reverse service path. Consequently, a pair of encrypting and decrypting VNFs in a service chain, do not necessarily have a bidirectional communication channel on the data plane, where they can exchange keys.