Private VNFs for collaborative multi-operator service delivery: an architectural case Gergely Bicz´ ok, Bal´ azs Sonkoly, Nikolett Bereczky MTA-BME Future Internet Research Group Budapest Univ. of Technology and Economics Email: {biczok,sonkoly,nikolett.bereczky}@tmit.bme.hu Colin Boyd Department of Telematics Norwegian Univ. of Science and Technology Email: colin.boyd@item.ntnu.no Abstract—Flexible service delivery is a key requirement for 5G network architectures. This includes the support for collaborative service delivery by multiple operators, when an individual oper- ator lacks the geographical footprint or the available network, compute or storage resources to provide the requested service to its customer. Network Function Virtualisation is a key enabler of such service delivery, as network functions (VNFs) can be outsourced to other operators. Owing to the (partial lack of) contractual relationships and co-opetition in the ecosystem, the privacy of user data, operator policy and even VNF code could be compromised. In this paper, we present a case for privacy in a VNF-enabled collaborative service delivery architecture. Specifically, we show the promise of homomorphic encryption (HE) in this context and its performance limitations through a proof of concept implementation of an image transcoder network function. Furthermore, inspired by application-specific encryption techniques, we propose a way forward for private, payload-intensive VNFs. I. BACKGROUND AND MOTIVATION Proposed 5G verticals are predicted to be real value-added services. A majority of these are projected to be delivered as a service chain with multiple, independent business entities contributing; either for maintaining flexibility in resource al- location or for the lack of geographical footprint. Furthermore, users (and the market as a whole) would benefit from a streamlined, one-stop shopping experience, where the cus- tomer only has to contact a single operator for setting up a complex service; who would in turn outsource and subcontract to other operators if it lacks the footprint (similar to mobile roaming), the resource capacity or can just make a larger profit. The key enablers for such collaborative and flexible multi- operator service delivery are Software Defined Networking (SDN) and Network Function Virtualisation (NFV). NFV in particular makes it convenient for an operator to outsource network functions to another operators. The Horizon 2020 5GEx project aims at creating such a service delivery platform [3]. From the technical point of view, the 5GEx architecture enables the unified cross-domain orchestration of network and cloud resources over multiple administrative and technology domains [7]. Services are realized via Service Function Chain- ing (SFC) potentially over domains of multiple operators. In this environment, the contract structure, the lack of trust and SFC (the path and VNFs which customer data passes through) create a complex privacy situation (adding to general NFV issues [5]; see Figure 1 for an example. First, the user forms a trust relationship with its customer- facing operator (Op1) upon buying a service and signing a contract (Service Level Agreement, SLA). Given that Op1 potentially outsources some parts of the required service chain to other qualified operators (Op2 and Op3), user traffic will be steered through and potentially processed by VNFs in Op2’s and Op3’s administrative domains. Since the user does not have a trust relationship to the subcontractors Op2 and Op3, she might want to do something about the risk of Op2 or Op3 looking into her traffic. A logical step would be to apply encryption at the user side, or at the egress of Op1, before user traffic leaves the premises of the trusted domain. In this example, User 2 is the destination of User 1’s traffic, therefore he is the one to decrypt it upon arrival. Second, VNFs usually have a policy input besides the data traffic. In the given setting, it is plausible to assume that policies (firewall rules, filter expressions, coding parameters, etc.) come from Op1, while the VNF is running on the infrastructure of another operator (Op2). Now, Op1 may have a number of reasons not to expose its policies to Op2, including being competitors and hiding its cyber-defense strategies. Therefore, it could be beneficial for Op1 if encrypted policies could be interpreted by the VNF. Further complicating things, the VNF implementation could be provided by Op1, Op2 or a third-party VNF provider [2] (not depicted in Figure 1). All three cases require a different approach if Op1 wants to keep                   Figure 1. Multi-operator service delivery with SFC 978-1-5090-0223-8/16/$31.00 c  2016 IEEE