# Secure Service Implementation with Slice Isolation and WireGuard

Sondre Kielland, Ali Esmaeily, Katina Kralevska, and Danilo Gligoroski
Department of Information Security and Communication Technology
Norwegian University of Science and Technology (NTNU)
Email: {sondrki, ali.esmaeily, katinak<EMAIL_ADDRESS>
###### Abstract

Network slicing enables the provision of services for different verticals over
a shared infrastructure. Nevertheless, security is still one of the main
challenges when sharing resources. In this paper, we study how WireGuard can
provide an encrypted Virtual Private Network (VPN) tunnel as a service between
network functions in 5G setting. The open source management and orchestration
entity deploys and orchestrates the network functions into network services
and slices. We create multiple scenarios emulating a real-life cellular
network deploying VPN-as-a-Service between the different network functions to
secure and isolate network slices. The performance measurements demonstrate
from 0.8 Gbps to 2.5 Gbps throughput and below 1ms delay between network
functions using WireGuard. The performance evaluation results are aligned with
5G key performance indicators, making WireGuard suited to provide security in
slice isolation in future generations of cellular networks.

###### Index Terms:

OSM, WireGuard, VPN, NFV, 5G, Network slice, URLLC, eMBB.

##  I Introduction

The enrollment of 5G non-standalone cellular networks is already in operation
by mobile network operators. In developing Beyond 5G (B5G) networks, several
planned functionalities will enable verticals to establish their services with
diverse QoS requirements on shared physical infrastructure. Providing End-to-
End (E2E) services over isolated network slices is a key factor to empower
multiple services on a shared infrastructure. To develop agile B5G networks
for supporting applications with different QoS requirements, NFV, Software-
Defined Networking (SDN) and Multi-Access Edge Computing (MEC) are the main
enabling technologies [1, 2].

An NFV Management and Orchestration (MANO) entity connected to one or several
Virtual Infrastructure Managers (VIMs) controls and monitors the deployment of
NSs by deploying necessary infrastructure resources. For an agile network
deployment, the NFV MANO also administrates connections between VNFs,
including creation of virtual networks with the help of SDN. Therefore,
instead of manually creating and connecting the NSs together, the NFV MANO
helps operators to deploy and control Network Functions (NFs) automatically.
With its automatic and reusable functionality, a large number of NFs and NSs
can be rapidly deployed on a single or multiple VIMs.

Cloud infrastructures that can be rented or shared are necessary to utilize
resources efficiently for financial and load distribution purposes.
Introducing shared infrastructure raises further security challenges. Securing
application data transfer over shared networks is one example of such a
security challenge. A countermeasure that can be initiated against such
security concerns is operating Virtual Private Network (VPN) between NFs.
However, establishing VPN tunnels introduces additional overhead. For services
dependent on low latency or high throughput, the additional overhead may
affect their service performance.

NFV MANO can provide traffic isolation for NFs in NSs by deploying VPN
tunneling between NFs and interconnecting them [3]. In this way, the secure
tunneling isolates Network Slice Instances (NSIs) and the provided NSs via the
NSIs. Nevertheless, this approach is only feasible if the VPN does not
introduce significant overhead violating QoS requirements. The deployment of
VPN between VNFs in an automatic mode in order to provide security isolation
between slices and the effect of the introduced overhead on the performance
isolation among slices in a shared environment are still open research
questions.

In this paper, we implement and analyze the performance of WireGuard for
providing slice isolation in 5G environment. WireGuard [4] is a
straightforward yet immediate VPN solution that functions via the Linux kernel
and employs state-of-the-art cryptography approaches. Open Source MANO (OSM)
orchestrates NSs and NSIs, and establishes VPN tunnels between the VNFs. The
integrated WireGuard-OSM architecture provides: 1) secure communication
between the involved VNFs of NSs and NSIs\- slice isolation; 2) performance
isolation between the slices. The performance analysis shows that the
integrated WireGuard-OSM architecture meets the required Key Performance
Indicator (KPI) values in terms of high throughput for enhanced Mobile
Broadband (eMBB) slices and low latency for Ultra Reliable Low Latency
Communication (URLLC) slices. We make the code publicly
available111https://github.com/sondrki/TTM4905/ to the research community.

The remainder of this paper is organized as follows. Section II provides a
literature overview of practical approaches for secure isolation between
slices. Section III presents the system architecture. The implementation steps
are explained in Section IV. The performance evaluation results are presented
in Section V. Finally, Section VI concludes the paper.

##  II Related Work

The isolation concept between network slices can be studied from security,
performance, and dependability aspects [5]. In addition, the Confidentiality,
Integrity and Availability (CIA) triad is a widely used way of looking at
different security aspects. A shared infrastructure introduces security
challenges in all dimensions of the CIA triad. The key feature of shared
infrastructures is that an attack on or from another party sharing the
infrastructure should not affect the other sharing parties. This definition of
CIA is harmonic with the isolation concept in network slicing. Other parties
should also be unaffected when it comes to performance and dependability,
extending the availability dimension. The workload, the number of resources,
and hardware or software failure of another NS should not reduce the
performance of an NF in a separate NS or NSI.

While 5G intends to fix some security issues present in the previous
generations of cellular networks, it also introduces several new security
threats. Some of them are raised by providing services via network slices.
Paper [6] explores and classifies different security challenges of 5G
networks. Proper isolation of logical resources is essential to avoid
introducing several new risks. Eavesdropping and tampering with data, for
instance, are two vectors an attacker could use to interfere with security if
the application data is not properly encrypted. Hantouti et al. suggest that
operators should deploy encrypted tunnels as a way to establish trust between
SFs to provide packet integrity and prevent bypassing of policies [7].

The work in [8] proposes a novel mutual authentication and key establishment
protocol utilizing proxy re-encryption. The protocol grants specific
authentication between components of a network slice to enable secure
connection for protected key establishment among component pairs for slice
security isolation. Paper [9] offers a secure keying scheme by adopting a
multi-party computation strategy, which is appropriate for network slicing
architecture in the case that third-party applications access the slices. This
mechanism ensures the satisfaction of use cases or devices in which the data
is collected.

Both Haga et al. in [10] and Vidal et al. in [11] focus on how a VPN can be
deployed using OSM. Reference [10] demonstrates how WireGuard can be added in
VNFs and compares the performance of WireGuard and OpenVPN. This proof-of-
concept is carried out using two VNFs in a single NS with manual configuration
of peer connectivity in WireGuard. For the peer setup, keys and other
necessary information are obtained manually. Vidal et al. in [11] uses IPsec
as VPN solution to provide link-layer connectivity for multi-site deployments.
In this work, OSM deploys multiple NSs connected through one VNF at each NFV
Infrastructure (NFVI). These VNFs handle the link layer abstraction for the
other VNFs. IPsec is used to secure the connection between the link layer
providing VNFs. Keys and connection parameters are supplied by the operator
when instantiating the NSI.

To the best of our knowledge, none of the state-of-the-art works presents a
secure service automation provisioning utilizing complex and real-life NFs.
This motivates us to integrate WireGuard tunneling with OSM, which grants
secure communication between NFs in order to establish automated and realistic
network services. As a result, this system architecture guarantees security
and performance isolation between NSIs.

##  III System Architecture

Day-0, Day-1, and Day-2 operations are terminologies used in the OSM community
referring to the stages of Life-Cycle Management (LCM) of NFs. The steps in
Figure 1 are used to handle LCM of NFs via the NF onboarding process and they
link closely to Day-0 to Day-2 operations. In Figure 1,

  * •

Day-0 phase focuses on necessary instantiation, including charms and
descriptor creation/editing, validation, packaging, and emulation;

  * •

Day-1 phase concentrates on service initialization containing test, release,
and deploy;

  * •

Day-2 phase covers runtime actions comprising operate and monitor steps.

Figure 1: Steps for service lifecycle [12].

OSM has three inbuilt supporting applications for LCM [13]. Cloud-init is
responsible for the initial Day-0 operations like setting username and
password. For Day-1 operations, Helm charts or Juju charms can be used, while
Day-2 operations are also possible with Juju. The difference between Helm and
Juju is that Helm is used solely for Kubernetes-based Network Functions
(KNFs), while Juju is also usable at NS level and for VNFs that are not
Kubernetes (K8s) based [14, 15]. We have used cloud-init and Juju charms for
OSM onboarding in our implementation.

Further, Juju has two operation modes: native and proxy. Native charms run
operations directly inside a VNF. On the other hand, proxy charms use a
centrally placed controller, VNF Configuration and Abstraction (VCA), to
manage the Day-1 and Day-2 actions. The VCA connects to the VNFs through their
management interface and instructs the VNFs. The VCA-VNF connection uses the
Secure Shell (SSH) protocol by default. In the paper, we have used proxy
charms with a VCA installed co-located and integrated with OSM. Both the VCA
and OSM are, therefore, able to access the VNFs management interface to
execute their actions.

To build user-defined actions, Juju uses Python scripts. The connection to the
OSM instance is made through the description files of the VNFs, NSs, Juju
config files describing metadata, and the available Day-1 and Day-2 actions.
For the OSM integration of proxy charms, the charms.osm.sshproxy library is
provided by OSM to take care of, among other tasks, the basic Juju proxy peer
setup.

In addition to running actions in VNFs, Juju can be used to create relations
between Juju units for management, scaling, and handling dependencies across
VNFs. We use Juju relations to transfer WireGuard peer information between
VNFs.

Figure 2 illustrates how we use proxy charms and relations in Juju to create a
bridge for transferring information between VNFs. The figure shows the
architecture for the multi-site demonstration. Note that we used a single-VIM,
moving the Home Subscriber Server (HSS) into VIM 1, for the performance
evaluation results presented in Section IV. The architecture for the single-
VIM setup is as illustrated in the rightmost half of the figure showing VIM 1.

Figure 2: Interactions between elements in our Juju proxy implementation.

Key distribution is a task that often requires manual steps when establishing
a VPN tunnel. Manual setup can be time-consuming for dynamic environments or
environments with many interfaces that need to be secured. If the tenant
manager needs to do configuration, the NS is only usable after initializing
the VPN tunnels. However, if we apply the approach presented by Vidal et al.
[11] and input the necessary information, including keys, the application can
start sending data immediately after Day-1 actions have finished. Using a Key
Management System (KMS) is a similar approach. However, OSM does not provide
such functionality. To use the KMS approach additional functionality outside
of the OSM framework must be added.

To perform key management, we use a non-standard approach using Juju relations
with the requirement of using proxy charms for our VNFs. By using Juju
relations, we create new individual keys for every new deployment of an
interface and make the application of the NS usable directly after the Day-1
tasks finish. Furthermore, with our approach, the private keys are only stored
inside the VNFs. The public key and other necessary information for the peer
setup get automatically transferred to the peer.

##  IV Implementation

Figure 3: Architecture of our implementation.

To implement WireGuard in a realistic 5G environment we created a NS with
Evolved Packet System (EPS) components from OpenAirInterface (OAI) [16]. We
then added WireGuard connectivity on the different interfaces. Figure 3 shows
the deployed architecture. OSM is used to communicate with MicroStack VIM
[17]. The VIM hosts different VNFs, creates virtual networks and performs
routing of outgoing traffic from the VNFs, represented by solid blue lines.
WireGuard tunnel is created automatically between the VNFs on the interfaces
in the NS, represented by the red dotted lines. In addition to the primary
VIM, we utilized a second VIM in order to explore the EPS NS deployment in
multiple sites.

###  IV-A Development

We followed these steps to prepare the deployments: 1) compose a virtualized
EPS, 2) set up a mechanism for automatic WireGuard peering, 3) structure NSs
into Network Slice Template (NST), and lastly, 4) test the WireGuard
connectivity in a multi-site deployment. The code for the descriptors and
charms is publicly available on GitHub. In the following paragraphs, we
further describe the development steps for creating the descriptors and the
scripts.

1\. Composing a Virtualized EPS: In [18], Dreibholz implements an Evolved
Packet Core (EPC) with HSS, Mobility Management Entity (MME), and a combined
Serving Gateway (SGW) and Packet Data Network Gateway (PGW) separated in two
components, Service Packet Gateway-User plane (SPGW-U) and Service Packet
Gateway-Control plane (SPGW-C), for user- and control-plane tasks,
respectively. To extend this NS with real-life traffic, we add a virtualized
eNodeB (eNB). Further, we create an User Equipment (UE) in a Virtual Machine
(VM) kept outside the NS. The UE is still able to connect to the eNB after
instantiating the NS with manual network setup in MicroStack. To establish the
air interface, Uu, we have compiled and used OAI simulation option. When
connecting the UE to the eNB, we verify that the different EPS components
function as expected and provide service to the UE. The UE connects to an
outer network through the SPGW-U via the eNB. At this first step of
implementation, we still have not included WireGuard between the components.

We chose to build the NS by spreading the EPS components into separate VNFs.
This approach allows to split the VNFs in the VIMs. Extending it to a multi-
site environment gives us the opportunity to emulate a scenario where other
components, for instance, MEC, are deployed closer to the end-users. The VNFs
distributed to remote sites are able to communicate with the core securely
with the help of WireGuard.

2\. Automatic WireGuard Peering: Manually setting up VPN tunnels between
several interfaces can be time-consuming. Thus, we use Juju relations for
automatic peering with no extra information given to the other end of the peer
at the time of instantiating the NS. The first step in the automatic peering
is the establishment of relationships between VNFs on both sides. Then the
paired VNFs retrieve information like public key, endpoint, and listening port
to communicate with each other. Wireguard usually employs the following
cryptographic primitives: elliptic Curve25519 for key exchange, then HKDF for
the key derivation, and finally, the bulk encryption work is performed by the
symmetric primitive ChaCha20Poly1305 for Authenticated Encryption with
Associated Data (AEAD) [4]. All of these primitives have excellent performance
in software supporting the objective of NFV. Moreover, due to the lack of
considerable overhead and latency, and remarkable efficiency, ChaCha20Poly1305
AEAD performs significantly in terms of ping time and throughput for the URLLC
and eMBB slices, respectively.

To establish WireGuard connectivity on all interfaces given in Figure 3, we
changed the IP address configuration in the components. Changing the interface
addresses is necessary to route application data over the VPN tunnel and, at
the same time to ensure that applications inside the VNF have been installed
and started correctly even when waiting for the tunnel establishment. Besides,
to verify that the NS runs WireGuard, we connect the UE and observe that it
connects and gets PDN service.

Further, in order to observe how resources affect the WireGuard performance,
we have prepared a copy of the EPS NS with WireGuard connectivity with doubled
resources.

3\. NST creation: After having a working NS with WireGuard connectivity
between the interfaces, we include it in two NSTs to observe if and how the
performance is affected by providing security with WireGuard. The two NSTs
have different values of quality indicators corresponding to different 5G QoS
Identifiers (5QIs) [19]. The QoS parameters correspond to eMBB and URLLC use-
cases, respectively. Further, the NST is prepared with only the management
interfaces of the VNFs. The management interfaces are attached to the external
connection points in the NSTs.

4\. Multi-site deployment: To verify that the automatic peering setup also
works in a multi-site environment, we have separated the HSS VNF to a second
VIM. When using OpenStack/MicroStack, the external floating IP address is by
default not known inside a VM. However, the VCA can retrieve the management IP
address to perform its actions. To find the floating IP addresses of the VNFs,
we use the same function that Juju employs for its proxypeer connection
between a Juju unit at the VCA and the Virtual Deployment Unit (VDU) in the
VNF. After the endpoint IP address is found, the MME and HSS connect
automatically with WireGuard connectivity. A prerequisite for multi-site
WireGuard connectivity is to use a port opened in the firewalls.

###  IV-B Proof-of-Concept for VPN-as-a-Service

With the automatic peering, we presented a few steps to add WireGuard as a
VPN-as-a-Service (VPNaaS). Here we summarize all steps to build the proof-of-
concept.

  1. 1.

Append installation of WireGuard in cloud-init.

  2. 2.

Add name and parameters for Day-1 and Day-2 actions in the actions.yaml file.

  3. 3.

Add relations between VNFs in the metadata.yaml file.

  4. 4.

Include the Python code to append the charm script. The name of the
relationship must correspond between the name used in metadata.yaml and the
listener in the __init__ function of the Python script.

  5. 5.

Add the actions from actions.yaml into Day-1, Day-2 operations in the VNF
Descriptor (VNFD). To create the WireGuard tunnel as a Day-1 operation, the
relevant actions should be included in the initial-config-primitive section in
the VNFDs. Day-2 actions are placed in the config-primitive section.

  6. 6.

While the default implementation sets up the VPN, Day-2 actions can be used
for further configuration and maintenance, for instance, if a new connection
should be added towards a NF.

##  V Performance Evaluation

To assess the performance of WireGuard in the 5G network, we conducted
measurement tests in both the control and user plane, with and without
WireGuard capability. We utilized both arbitrary data and the UE to generate
realistic traffic in the network. We observe the impact of integrating secure
communication with Wireguard on the performance metrics that should be aligned
with the 5G KPI [20].

While producing arbitrary data for high network load, we measure the latency
and Service Response Time (SRT) in the control plane, combining multiple EPS
components. In general, the following tasks are done to test the performance
of NSs and NSIs:

  * •

Observe SRT on the MME when the UE connects;

  * •

Observe throughput and latency in the user plane with the UE over S1-U
interface;

  * •

Measure throughput and latency between components in the EPS in the control
plane over S1-C and S6a interfaces.

###  V-A Lab Environment

The primary VIM is a server running MicroStack with resources of 56 vCPUs, 126
GB RAM, and 915 GB storage. The second VIM, used for multi-site deployment,
also runs MicroStack but has fewer resources with a total of 9 vCPUs, 32 GB
RAM, and 150 GB storage. For the EPS NS a total of 14 vCPU, 27 GB RAM and 110
GB storage are utilized. According to the limiting ISP, the bandwidth between
the two NFVIs is specified to be 200 Mbps. For the VNFs to communicate
securely across the VIMs, WireGuard tunnel is established between the NFVIs.
Our measurement shows a throughput of approximately 180 Mbps between the
MicroStack instances. A nested WireGuard tunnel is used when adding WireGuard
on the S6a interface for the multi-site deployment. The internal throughput of
the NFVI where the primary VIM runs is 20 Gbps. Table I gives a summary of the
resources used for the VNFs.

TABLE I: VNF information of the OAI EPS NS. VNF | Operating System | Number of | Amount of | Storage
---|---|---|---|---
name |  | virtual CPUs | RAM (GB) | (GB)
HSS | Ubuntu18.04 | 4 | 8.0 | 20
MME | Ubuntu18.04 | 2 | 4.0 | 20
SPGWU | Ubuntu18.04 | 1 | 3.0 | 20
SPGWC | Ubuntu18.04 | 3 | 4.0 | 30
eNB | Ubuntu18.04 | 4 | 8.0 | 20
UE | Ubuntu18.04 | 2 | 4.0 | 20

###  V-B Observations

Before adding the VPN tunnels, we are able to capture connection information
such as the International Mobile Subscriber Identity (IMSI), network realms,
and hostnames at the VIM. However, after we introduce WireGuard, the only
information observable at the VIM is the use of the WireGuard protocol and
link-layer discovery messages.

For the control plane, we observe the SRT for the HSS application to a
connecting UE. When monitoring SRT of the HSS application including networking
from the MME, the NS with WireGuard has the lowest average SRT. In particular,
with ten successful connections for the UE, the average SRT of the Diameter
protocol drops from 6.156 ms for the EPS without WireGuard capability to 5.377
ms when WireGuard is added. When doubling the resources on the EPS NS with
WireGuard, SRT of 5.607 ms is measured. Based on the other measurements, it is
likely that the HSS application itself is the delaying part. With a reduced
number of connections, we have not observed a negative effect on the SRT when
using WireGuard.

A comparison of the latency measurements for different instances and
interfaces is shown in Figure 4. The red line in the figure indicates 1 ms,
representing one of the E2E KPI for URLLC applications in 5G. All single-site
instances achieve lower latency than the 1 ms. However, adding WireGuard
introduces a visible overhead when comparing the NS without WireGuard to the
other instances in Figure 4. On the other hand, we observe that the average
latencies for the S1-C interface in the eMBB and URLLC NSIs (illustrated in
grey and purple) are lower than the other two counterpart measurements. It is
worth noting that doubling the resources does not necessarily reduce the
latency, confirming that the latency depends on multiple factors such as 5QI
parameters and the workload of components in the NS.

Figure 4: Latency comparison for different interfaces with and without
WireGuard functionality.

Figure 5 compares the throughput between components with WireGuard enabled on
different interfaces across instances. The red line represents the 100 Mbps
downlink user data rate KPI. We highlight three main results from observing
the throughput. The first one is that, unlike the latency, the throughput
changes according to the available resources. When comparing the NS with
double resources to the others, the throughput is higher for the NS with the
double resources. The second observation is that the throughput over the Uu
interface is significantly lower than the other measurements. The throughput
over the Uu is around 1.7 Mbps, while the average throughput for the S1-U is
over 1 Gbps making the Uu the bottleneck of the EPS. The last observation is
about the maximum throughput when averaging over 10 minutes. For the NS with
double resources, we observe throughput of 2.2 Gbps for the S1-U. For the
other instances, a range from 770 Mbps to 1.48 Gbps is measured.

Figure 5: Throughput comparison for different interfaces with WireGuard.

Figure 6 compares the throughput in the two NSIs. We observe that the
performance over diverse interfaces differs when running each NSI alone and
when the two NSIs are running simultaneously. For instance, the throughput at
the S6a interface reaches up to 1.1 Gbps for the URLLC slice when it is
operating alone and simultaneously with the eMBB slice. However, the
throughput at the S1-U interface is 1.43 Gbps for the URLLC slice separately
and it reduces a bit to 1.41 Gbps when it is running simultaneously with the
eMBB slice. Regarding S1-C interface, the throughput reaches 1.12 Gbps for the
separate URLLC and it decreases to 0.97 Gbps when the eMBB slice is also
working. In general, the differences between the NSIs are minor, meaning that
WireGuard is a promising solution for slice isolation of eMBB and URLLC
slices.

It should be noted that we observe a total throughput of approximately 3 Gbps,
which is lower than the internal networking throughput of around 20 Gbps when
testing with a workload on the same logical interface for the two NSIs
simultaneously. As we approach the internal networking limit for the
throughput, we detect more considerable differences between the NSIs based on
their QoS parameters and the allocated resources.

Figure 6: Throughput comparison with WireGuard for NSIs - measured separately
and simultaneously.

In the multi-site deployment, we take measurements over the S6a interface,
which is the only one that differs from the other NSs and NSIs. As expected,
the throughput is lower, and the latency is higher than in the other
instances. The performance is lower even without WireGuard between the VNFs.
However, we observe that WireGuard adds overhead in this scenario as well. In
the multi-site NS, the average latency over 1000 ICMP packets increases from
18.355 ms to 19.769 ms when using WireGuard. For the average throughput, we
observe a reduction from 179 Mbps to 156 Mbps, which is expected based on the
given 200 Mbps bandwidth.

##  VI Conclusions

By using Juju relations and providing a proof of concept for using WireGuard
as VPNaaS, we showed that WireGuard can be implemented with automatic peer
setup after instantiating. The performance measurements demonstrate that
WireGuard is suitable for applications with requirements corresponding to
several of the 5G KPI values. We show that WireGuard can be used as VPNaaS in
the context of 5G networks and beyond in order to provide secure communication
and slice isolation.

Replacing the arbitrary Juju relations with a KMS, using a 5G Core network
instead of EPC components, adding multiple UEs, and evaluating scenarios in
which fulfilling service requirements (especially throughput) are beyond
WireGuard capability are potential directions for future investigation.

## References

  * [1] B. Blanco, J. O. Fajardo, I. Giannoulakis, E. Kafetzakis, S. Peng, J. Pérez-Romero, I. Trajkovska, P. Sayyad Khodashenas, L. Goratti, M. Paolino, and E. Sfakianakis, “Technology pillars in the architecture of future 5g mobile networks: Nfv, mec and sdn,” _Computer Standards and Interfaces_ , vol. 54, 01 2017.
  * [2] A. Esmaeily and K. Kralevska, “Small-scale 5g testbeds for network slicing deployment: A systematic review,” _Wireless Communications and Mobile Computing_ , vol. 2021, 2021.
  * [3] Z. Kotulski, T. Nowak, M. Sepczuk, M. Tunia, R. Artych, K. Bocianiak, T. Osko, and J.-P. Wary, “On end-to-end approach for slice isolation in 5g networks. fundamental challenges,” in _Federated Conf. on Computer Science and Information Systems (FedCSIS)_ , 2017, pp. 783–792.
  * [4] J. A. Donenfeld, “Wireguard: next generation kernel network tunnel.” in _NDSS_ , 2017, pp. 1–12.
  * [5] A. J. Gonzalez, J. Ordonez-Lucena, B. E. Helvik, G. Nencioni, M. Xie, D. R. Lopez, and P. Grønsund, “The isolation concept in the 5g network slicing,” in _2020 European Conference on Networks and Communications (EuCNC)_. IEEE, 2020, pp. 12–16.
  * [6] H. Kim, “5g core network security issues and attack classification from network protocol perspective.” _J. Internet Serv. Inf. Secur._ , vol. 10, no. 2, pp. 1–15, 2020.
  * [7] H. Hantouti, N. Benamar, and T. Taleb, “Service function chaining in 5g amp; beyond networks: Challenges and open research issues,” _IEEE Network_ , vol. 34, no. 4, pp. 320–327, 2020.
  * [8] V. N. Sathi, M. Srinivasan, P. K. Thiruvasagam, and S. R. M. Chebiyyam, “A novel protocol for securing network slice component association and slice isolation in 5g networks,” in _Proceedings of the 21st ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems_ , ser. MSWIM ’18, 2018, p. 249–253.
  * [9] P. Porambage, Y. Miche, A. Kalliola, M. Liyanage, and M. Ylianttila, “Secure keying scheme for network slicing in 5g architecture,” in _2019 IEEE Conference on Standards for Communications and Networking (CSCN)_ , 2019, pp. 1–6.
  * [10] S. Haga, A. Esmaeily, K. Kralevska, and D. Gligoroski, “5g network slice isolation with wireguard and open source mano: A vpnaas proof-of-concept,” in _2020 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN)_ , 2020, pp. 181–187.
  * [11] I. Vidal, B. Nogales, D. Lopez, J. Rodríguez, F. Valera, and A. Azcorra, “A secure link-layer connectivity platform for multi-site nfv services,” _Electronics_ , vol. 10, no. 15, 2021.
  * [12] 5G-PPP Architecture Working Group, “View on 5g architecture,” https://tinyurl.com/2p9dxph4, accessed: 07.01.2022.
  * [13] ETSI OSM, “Etsi-nfv-vnfd,” https://osm.etsi.org/docs/user-guide/05-osm-usage.html, accessed: 19.07.2022.
  * [14] ——, “Etsi-nfv-nsd,” https://tinyurl.com/26dt45xv, accessed: 19.07.2022.
  * [15] ——, “Etsi-nfv-vnfd,” https://tinyurl.com/2p9yp7cr, accessed: 19.07.2022.
  * [16] O. S. Alliance, “Openairinterface,” accessed: 04.01.2022. [Online]. Available: https://openairinterface.org/
  * [17] A. Esmaeily, K. Kralevska, and D. Gligoroski, “A cloud-based sdn/nfv testbed for end-to-end network slicing in 4g/5g,” in _2020 6th IEEE Conference on Network Softwarization (NetSoft)_ , 2020, pp. 29–35.
  * [18] T. Dreibholz, “Flexible 4g/5g testbed setup for mobile edge computing using openairinterface and open source mano,” in _Workshops of the international conference on advanced information networking and applications_. Springer, 2020, pp. 1143–1153.
  * [19] ETSI, “System architecture for the 5g system (5gs),” ETSI, Tech. Rep. TS 123 501 V16.6.0, October 2020. [Online]. Available: https://tinyurl.com/2p8392jt
  * [20] ——, “Why do we need 5g?” https://www.etsi.org/technologies/mobile/5g, accessed: 19.07.2022.