Network slicing emerges as a key technology in next generation networks, boosted by the integration of software‐defined networking and network functions virtualization. However, while allowing resource sharing among multiple tenants, such networks must also ensure the security requirements needed for the scenarios they are employed. This letter presents the leading security challenges on the use of network slices at the packet core, the solutions that academy and industry are proposing to address them, pointing out some directions that should be considered.

In this paper, we propose an architecture based on NFV and SDN which allows to balance traffic analysis techniques using a Classifier. It steers flows to the appropriate Service Function Chaining (to open traffic or not) according to network requirements (such as, effectiveness, flexibility, scalability, performance, and privacy). The SSL/TLS traffic processing is carried-out by the centerpiece of this work, the SFC-enabled MITM. A Proof-of-Concept was conducted (focusing on our SFC-enabled MITM) which showed that functionalities lost due to encryption (Content Optimization, Caching, Network Anti-virus, and Content Filter) were recovered when processing opened traffic within its Service Function Chains. We also evaluated its impact on performance. The results show that cipher suite overhead plays a role but can be mitigated, the Classifier can alleviate the performance overhead of different traffic analysis techniques, network functions have lower impact to performance, and Service Function Chaining length influences page load time.

The fact that most IoT solutions are provided by 3rd-parties, along with the pervasiveness of the collected data, raises privacy and security concerns. There is a need to verify which data is being sent to the 3rd-party, as well as preventing those channels from becoming an exploitation avenue. We propose to use existing API definition languages to create contracts which define the data that can be transmitted, in what format, and with which constraints. To verify the compliance with these contracts, we propose a converging "Multi-Access Edge Computing" architecture which validates RESTalike API requests/responses against a Swagger schema. We deal with encrypted traffic using an SFC-enabled Man-in-the-Middle, allowing us to do verifications in "real-time". We devised a Proof of Concept and shown that we were able to detect (and stop) contract violations.

The fact that most IoT solutions are provided by third parties, along with the pervasiveness of the collected data, raises privacy and security concerns. There is a need to verify which data is being sent to the third party, as well as preventing those channels from becoming an exploitation avenue. We propose to use existing API definition languages to create contracts which define the data that can be transmitted, their format and constraints. To verify the compliance with these contracts, we propose a Network Service architecture which validates REST-like API requests/responses against a Swagger schema. We deal with encrypted traffic using an Service Function Chaining (SFC)-enabled Man-in-the-Middle (MITM), allowing verifications in “real-time.” We devised a Proof of Concept and showed that we were able to detect (and stop) contract violations.

The heterogeneity of 5G requirements commands more complex network architectures, imposing the need for network orchestration. ETSI NFV MANO is the standard which defines a common framework for vendors and operators to integrate their orchestration efforts. In this paper, we evaluated how an ETSI NFV MANO compliant orchestrator (OSM) fares while orchestrating an SFC-enabled SSL/TLS encrypted traffic processing architecture, which supports both edge and cloud deployments. A quantitative evaluation was carried-out, which assessed the responsiveness and overheads of OSM, as well as the actual functionality of our SSL/TLS processing architecture (with edge computing components). A qualitative evaluation was also carried-out, providing insight into the maturity of the current OSM release, what works well, what requires workarounds, and the actual limitations. A demonstration of the architecture evaluated in this work was accepted as a contribution to the ETSI OSM PoC Framework.