ArticlePDF Available

5G NB-IoT: Efficient Network Traffic Filtering for Multitenant IoT Cellular Networks

Authors:

Abstract and Figures

Internet of Things (IoT) is a key business driver for the upcoming fifth-generation (5G) mobile networks, which in turn will enable numerous innovative IoT applications such as smart city, mobile health, and other massive IoT use cases being defined in 5G standards. To truly unlock the hidden value of such mission-critical IoT applications in a large scale in the 5G era, advanced self-protection capabilities are entailed in 5G-based Narrowband IoT (NB-IoT) networks to efficiently fight off cyber-attacks such as widespread Distributed Denial of Service (DDoS) attacks. However, insufficient research has been conducted in this crucial area, in particular, few if any solutions are capable of dealing with the multiple encapsulated 5G traffic for IoT security management. This paper proposes and prototypes a new security framework to achieve the highly desirable self-organizing networking capabilities to secure virtualized, multitenant 5G-based IoT traffic through an autonomic control loop featured with efficient 5G-aware traffic filtering. Empirical results have validated the design and implementation and demonstrated the efficiency of the proposed system, which is capable of processing thousands of 5G-aware traffic filtering rules and thus enables timely protection against large-scale attacks.
This content is subject to copyright. Terms and conditions apply.
Research Article
5G NB-IoT: Efficient Network Traffic Filtering for
Multitenant IoT Cellular Networks
Pablo Salva-Garcia ,1Jose M. Alcaraz-Calero ,1Qi Wang ,1
Jorge Bernal Bernabe ,2and Antonio Skarmeta 2
1University of the West of Scotland, UK
2University of Murcia (UMU), Spain
Correspondence should be addressed to Pablo Salva-Garcia; pablo.salva-garcia@uws.ac.uk
Received 31 May 2018; Revised 7 November 2018; Accepted 19 November 2018; Published 10 December 2018
Academic Editor: Petros Nicopolitidis
Copyright ©  Pablo Salva-Garcia et al. is is an open access article distributed under the Creative Commons Attribution
License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly
cited.
Internet of ings (IoT) is a key business driver for the upcoming h-generation (G) mobile networks, which in turn will enable
numerous innovative IoT applications such as smart city, mobile health, and other massive IoT use cases being dened in G
standards. To truly unlock the hidden value of such mission-critical IoT applications in a large scale in the G era, advanced self-
protection capabilities are entailed in G-based Narrowband IoT (NB-IoT) networks to eciently ght o cyber-attacks such as
widespread Distributed Denial of Service (DDoS) attacks. However, insucient research has been conducted in this crucial area, in
particular, few if any solutions are capable of dealing with the multiple encapsulated G trac for IoT security management. is
paper proposes and prototypes a new security framework to achieve the highly desirable self-organizing networking capabilities
to secure virtualized, multitenant G-based IoT trac through an autonomic control loop featured with ecient G-aware trac
ltering. Empirical results have validated the design and implementation and demonstrated the eciency of the proposed system,
which is capable of processing thousands of G-aware trac ltering rules and thus enables timely protection against large-scale
attacks.
1. Introduction
Internet of ings (IoT) applications are widely envisioned
as a major use case in the forthcoming h-generation (G)
mobile networks and would account for one-quarter of the
global  million G connections in  []. Meanwhile,
security is a top concern for large-scale IoT deployment,
which is subject to new, disparate kind of threats and attacks.
e constrained nature of IoT devices in terms of memory,
computation, and power, as well as the unattended, pervasive
and dynamic network environment, makes them appealing
to attackers. Diverse types of evolved cyber-attacks, for
instance, Distributed Denial of Service (DDoS) attacks, which
rely on infected bots, are starting to appear in IoT [, ].
Forexample,theMiraiattackintookdownmajor
websites via massive DDoS using hundreds of thousands
of compromised IoT devices []. Low-Power Wide-Area
Network (LPWAN) protocols employed in IoT scenarios,
such as NB-IoT [] dened in GPP  release [], are not
ideal environments to perpetrate DDoS based on high-rate
brute force attacks, due to their associated low bit rate (kpps
uplink). Nonetheless, variants of DDoS attacks, based on
low-rate methods [], t perfectly in these environments,
since they exploit techniques such as sending partial HTTP
requests, sending small packets, or keeping sessions open
from going to idle time-out.
Similarly, some other kinds of attacks, e.g., those based
on unauthorized access, or data leakage, are dicult to
detect and mitigate. Infected IoT devices might disclose
private personal data of their owners, such as localization,
owner identity data, or even video from their featured video
cameras. Unfortunately, security andprivacy mechanisms are
dicult to enforce in the nal device, and therefore, the
network infrastructure should be ready to self-protect the
whole network and system, without involving necessarily the
potential malicious IoT device.
Hindawi
Security and Communication Networks
Volume 2018, Article ID 9291506, 21 pages
https://doi.org/10.1155/2018/9291506
Security and Communication Networks
us, in order to counter dynamically and on demand
those cyber-threats in a G-enabled IoT network, the network
operator might need to lter, mirror, divert, and dierentiate
IoT packets in the edge access network and in the core of
the G network. Ideally, this trac control and management
should be performed accordingly at any packet encapsula-
tion level required in LTE/G Networks. is may include
multiencapsulation required to support user mobility and
carrier-isolation, any eld of the inner packet headers, the
tenant the IoT device is associated with, or even any eld
of a particular IoT-specic protocol, e.g., the Constrained
Application Protocol (CoAP) [], used by the aected IoT
device, among others.
Network operators should be able to oer advanced
Security-as-a-Service solutions, exploiting the exibility pro-
vided by Soware-Dened Networking (SDN) and Network
Function Virtualization (NFV) to detect dynamically cyber-
threats, and react accordingly, enforcing proper and timely
countermeasures, either at the core or at the edge of the
network, including dynamic enforcing of pertinent ltering
rules to drop malicious trac coming from the myriad of IoT
devices.
e increasing number of technologies using network
virtualization, where trac is usually encapsulated to sup-
port multicarrier G-enabled services, raises the challenge
of managing encapsulated trac eciently. Like in LTE
and G, NB-IoT trac might require to cope with smart
objects mobility, which involves dealing with another level of
encapsulation, e.g., through the General Packet Radio Service
(GPRS) Tunneling Protocol (GTP).
In a basic network environment, and using predened
matching lters like Linux Netlter, each packet will traverse
all the ltering rules until matching a rule. at will cover
layer- and layer- headers and also application layer pay-
load, when l-lter is used. Indeed, diverse researches on
functional enhancements for ecient trac ltering have
already been provided in the state of the art [–]. However,
there is still a lack of ltering mechanisms able to perform
trac ltering in multicarrier and mobility scenarios for IoT
trac, being able to deal with the encapsulation requirements
imposed by both edge and core network segments of the G
multitenant networks, capable of performing trac ltering
and deep packet inspection in NB-IoT trac. Moreover,
there is a lack of security frameworks that can assist the
security management in order to provide self-healing and
self-repairing capabilities to the NB-IoT networks, adapting
dynamically the network trac ltering to the current con-
textual conditions.
Our proposed ltering mechanism in this paper allows
inspecting and analyzing trac without having to create any
tunnel interfaces to deencapsulate the trac. It allows lter-
ing beyond the rst encapsulated layer and dealing with any
packet and header of any inner encapsulated trac to cope
with mobility and multitenancy requirements of virtualized
G networks. e ltering predicates allow classifying packets
in Linux kernel space based on any packet elds in any
header and encapsulated packet. e benets are manifold,
encompassing scalability, performance, and exibility, since
there is no need to create tunnel interface to perform the
deencapsulation, and trac ltering in kernel space provides
an ecient approach.
Moreover, the proposed ltering mechanism has been
integrated into a security framework to achieve resilience and
autonomic reconguration of the ltering rules in order to
counter cyber-attacks as low-rate DDoS.
e contributions of this paper are manifold:
(i) A new security framework is presented with an
autonomic control loop to enable self-organizing
networking based self-protection.
(ii)ispaperfocusesonanencapsulation-awaretrac
ltering approach especially devised for virtualized,
multicarrier, narrowband, and G-aware IoT net-
works.
(iii) A prototype of a deep packet inspection method is
presented, using a kernel space mechanism in order
to have full control of encapsulated trac required in
virtualized NB-IoT networks.
(iv) e ltering mechanism has been integrated in the
autonomic and security management architecture
devised in a joint collaboration between two EU
H projects: Anastacia (in IoT security) []
(H Anastacia: http://anastacia-h.eu/) and
SELFNET (in G management) [] (H SELF-
NET: https://selfnet-g.eu/).
(v) Empirical performance evaluation of the proposed
system is presented and analyzed, over a realistic G-
compliant virtualized NB-IoT network infrastruc-
ture.
e rest of the paper is organized as follows. In Section 
we analyze the background on ltering techniques as well
as scientic related work in the research eld. Section 
introduces NB-IoT leveraged in virtualized G architectures
and laid out ltering requirements for multicarrier and vir-
tualized G-enabled NB-IoT networks. Section  overviews
the management framework. Implementation and testbed are
presented in Section . Section  reports the experimental
results in terms of eciency, suitability, and scalability. Con-
clusions and future research activities are drawn in Section .
2. Background and Related Work
Despite the considerable number of related work in the area
of IoT security, there is still no solution from the G data
path perspective, where the novel technological advancement
of this new paradigm enforces to have mechanisms able to
deal with nested encapsulation. Furthermore, as explained in
the previous Section , the G PPP working group also high-
lights the capability of self-adapting the whole network in a
dynamic way as one of their main features. us, providing
a dynamic management and reconguration of the system
is a feature that very few studies have taken it into account,
and even fewer have studied a framework with an automatic
control loop for organizing security policies. References [–
] are the only studies in this state of the art where a
G nested encapsulation has been achieved by using ker-
nel ltering techniques, programmable hardware interfaces,
Security and Communication Networks
T : Related Works.
Wor k
Dynamic
Management
and Recong-
uration.
Cognitive
Management
Framework
5G RAN and
Edge-Core
Implementation
Setup
Classical
IP
Support
5G
Multi-
tenant
Support
5G
Mobility
Support
Application
Layer
Support
IoT
Support
VNF
Solution
Scalable
Approach
[] ∙∙ ∙
[] ✓∙ ✓
[] ✓∙ ✓
[] ∙∙ ✓
[] ∙∙ ∙
[] ✓✓ ∙
[] ∙∙ ✓
[] ∙∙ ✓
[] ✓∙ ✓
Our con-
tribution ✓✓ ✓
and an extended Intrusion Detection System (IDS) version,
respectively. However, those studies are far away from the
IoT perspective and no cognitive management framework
has been presented. Other studies, such as [], have used
decapsulation and reencapsulation techniques for ltering
inner layers of the trac produced by LTE and G networks.
Nevertheless, that approach removes the device mobility sup-
port through the infrastructure, although mobility support
is indispensable for G mobile networks. e work in [] is
one of those infrequent studies about security in IoT where a
framework using Soware-Dened Networking for conning
trac ows of devices is presented. However, although
this work implements automated techniques for identifying
vulnerable devices and isolating them from the rest of the
users devices by generating OpenFlow enforcement rules
(OF-rule), it does not have the G capability for dealing
with multitenant and mobile-device trac. For reducing
both capital and operational expenditure from the point of
view of the operators, next-generation mobile networks are
adopting sowarization and virtualization technologies. In
this way, deployment and service creation becomes exible
and agile. is feature becomes extremely important when
the aim is to provide a scalable approach. In [] authors
present a G platform for IoT applications, and the platform is
able for deploying Virtualized Multiaccess Edge Computing
(vMEC) when required. In [], a hierarchical IoT structure
is set up by using several cluster heads that can handle
several sensor nodes. A cluster head is assumed to have
more computational power and energy resources than a node.
In such a case, a sensor node transmits trac data to the
corresponding cluster head at rst, and then the cluster head
forwards the data to the central server. From Table , none
of the related work presented has managed to accomplish
multitenant support, mobility support, IoT support, appli-
cation layer ltering, and a dynamic management based on
an autonomic framework at the same time. None of them
has considered nested encapsulation to be able to create
security IoT ltering rules in the edge/core of the network.
To the best of our knowledge, this contribution is the rst
one to be able to provide these capabilities simultaneously
and to deploy ne-grained actions for dealing with this kind
of complex attacks in the edge/core of a G network due
to the advanced transversal ltering capabilities supported.
In conventional network scenarios, IDSs are oen used to
evaluate the trustworthiness of network nodes and identify
malicious IoT nodes by monitoring their trac or behavior
[, ]. Once malicious trac is detected, several ltering
techniques can be used for acting as a rewall.
2.1. Filtering Techniques. e complexity of the nature of
the G networks requires a deep packet inspection (DPI)
for going further into the packet structure. DPI allows an
application to look into the data payload when packets
are passing an inspection point. erefore, a noncompliant
protocol, viruses, spam, or another kind of useful information
in the payload can be found and then it is decided whether the
packet should pass or not or should be routed to a dierent
destination. In order to acquire a signature that represents
a specic network application, tools and techniques have
relied on simple mechanisms that basically compare the
content of the packet payload with a set of strings [–
]. Later, DPI techniques replaced string sets with regular
expressions for fasting packet inspection processing [,
]. A comprehensive literature review and comparison
on the tools and techniques necessary to develop modern
DPI systems is presented in []. Additional research work
has studied the eciency of trac ltering and proposed
new functional enhancements over traditional rewalls. e
work in [] applies statistics collected from policy segments
with the aim of setting up Human trees that dynami-
cally adapt to the trac statistics and ultimately improve
the average ltering time. Other techniques rely on early
packet rejection to enhance the performance such as the
oneproposedby[].Itcanbedeployedontopofany
ltering mechanism to prelter unwanted expensive trac.
Some other work such as [] perform reordering of rules
and rules elds based on the calculation of the histograms
of packet matching rules. In [], a splay tree rewall is
Security and Communication Networks
proposed to handle packet rejection and acceptance and
can perform splay lters reordering based on a statistical
model that utilizes trac characteristic. Open vSwitch (OVS)
(Open vSwitch, http://www.openvswitch.org) is a soware
switch responsible for providing network connectivity to
virtual machines. Since it is programmable, it brings the
possibility of applying ltering rules by using standard pro-
tocols such as OpenFlow (Specication of Open Networking
Foundation cite []) and therefore achieving a separation of
the data plane from the control plane. As a drawback, OVS
only supports a limited number of protocols. Although every
new release of this soware adds support for new elds or
protocols, each version requires changes throughout and con-
sequently a new building, distributing, and installing process
is needed. at is the reason why new approaches such as the
one presented in [] and Tu William et al. [] have a goal
to reduce compatibility problems between dierent kernel
versions and OVS versions and provide support for new pro-
tocols without recompiling. To this end, a high-level language
for programming protocol-independent packet processing
such as P (P Language Consortium, https://p.org/) is pro-
posed and OVS datapath is implemented entirely using
the Enhanced Berkeley Filter (eBPF) for decoupling OVS
datapath functionalities from kernel versions. erefore, by
using a compiler that accepts P and emits eBPF, generation
of new elds/protocols without imposing the necessity to
change the OVS version would be feasible. Another ltering
approach is to employ byte-matching techniques. In order
to allow dynamic inspection of message payloads, a new
Netlter matching extension called u was added by Don
Cohen []. u allows jumping between headers and select
a specic range of bytes to be inspected. e u match
feature instructs the module to extract  bits ( bytes)
from the packet at any specied location and compares it
with a given value. If the eld that needs to be extracted is
fewer than  bits, the extracted data is masked and shied.
Additionally, it also includes a technique to calculate variable
header lengths to overcome the problem of dynamic size
headers in protocols such as IP or TCP. As a drawback,
u just allows no more than  characters per predicate,
which is a high limitation when dealing with encapsulated
trac where a signicant number of headers are added to
the protocol stacks. Similarly, the BSD Packet Filter (BPF)
[] is a byte-matching ltering mechanism that provides
an ecient way of ltering packets in the kernel space. BPF
is available on most Unix operating systems and it provides
a similar functionality to the u module but without its
ltering size restrictions. BPF is also available by using the
user-space program called iptables which allows conguring
Linux kernel rewall implemented within the Netlter [].
Iptables uses a set of tables to inspect, modify, forward,
redirect, and/or drop packets. e main functions of Netlter
are associated with each one of those tables. Despite the
advances in the related work, the existing tools are not able to
deal with trac ltering in virtualized G Networks, where
trac from dierent tenants (multicarriers/operators) needs
to be encapsulated to dierentiate their users, and mobility
scenarios impose another level of encapsulation to be handled
in the rewall. e ltering management solution proposed
in this paper enables handling dynamically G network trac
according to the decisions made by the autonomic security
framework, and it is based on BPF as the underlying ltering
mechanism to handle eciently NB-IoT trac in G-enabled
networks. It is important to highlight that although BPF is
a well-known mechanism, the way how it is used in this
publication stresses its capabilities for dealing with the most
complex packet structure that it can be seen over the new G
mobile network infrastructures.
3. NB-IoT Networks in Virtualized and
Multitenant 5G Deployments
3.1. NB-IoT Preliminaries. e GPP, in release  [, ],
has specied a new cellular radio access interface called
Narrowband Internet of ings (NB-IoT), which is optimized
for machine type trac. e specication tries to be as
simple as possible to minimize energy consumption, which
is crucial for IoT scenarios, considering also diculties in
radio conditions present in these ecosystems. NB-IoT has
tight relationships with LTE specication. Indeed it has been
integrated into the LTE standard, and therefore, it can be
also integrated with virtualized and multitenant G-aware
architectures as it will be shown in the next section.
e NB-IoT specication minimizes the radio overhead,
and it is able to deliver IP and non-IP data. As it can be
seen in Figure , NB-IoT introduces two new optimizations
over the traditional LTE network for the cellular Internet of
ings (CIoT), namely, the user plane CIoT (continuous lines
in the gure) and the control plane CIoT (dotted lines in the
gure). e control plane adds the new IoT-specic Service
Capability Exposure Function (SCEF) to deliver non-IP data
over the control plane and provides an abstract interface for
the network services such as authentication, Access Control
or discovery. To allow this, the Mobility Management Entity
existing in traditional LTE to deal with user mobility is
extended with the new Ta interface to allow the non-IP
IoT trac to be forwarded. e user plane CIoT allows
forwarding of data trac as in traditional LTE, through the
Serving Gateway (SGW) and PDN Gateway (PGW).
NB-IoT technology uses licensed band within the fre-
quency band of  kHz, adopting one resource block (either
in guard-band or in-band) of LTE transmissions. It allows
up to / (DL/UL) Kbps maximum user rate. NB-IoT
lacks handover support in the connected state, and only
cell reselection in the idle state is supported. It is intended
to provide network connectivity to Cat-M devices, which
send a small amount of data and are not sensitive to delays.
erefore, it does not support QoS directly. e devices
aresupposedtobeactiveforawhileandthengoidle
using Power Saving Mode (PSM) in order to save battery. It
supports Access Stratum (AS) optimization called RRC which
allows reducing to the minimum the signalling needed to
suspend/resume user plane connection.
3.2. NB-IoT Integration in Virtualized 5G Architectures.
Figure  depicted the envisaged NB-IoT functional architec-
ture integrated into the upcoming G GPP releases. Due to
Security and Communication Networks
CIoT SGN
BBU
HSS
Internet
T6a
SGi
SGi
S1-AP
S1-U
S11
S6a
MME
CIoT DU
(RRH)
SCEF
NB-IoT
Devices
SGW/
PGW
F : NB-IoT general functional architecture.
CIoT SGN
NG10
CU
(BBU)
AMF
(MME)
UDM
(HSS)
AUSF
(HSS)
Internet
T6a
NG6
NG6
NG4
NG11
NG8
NG12
NG2
NG3
CIoT DU
(RRH)
SMF
(MME)
UPF
(SGW)
SCEF
NB-IoT
Devices
F : Envisaged NB-IoT functional architecture in upcoming G GPP releases.
the novel nature of the proposed G architecture, the gure
shows in parenthesis the relationship between the novel G
architectural components and the existing LTE components.
It has been tailored based on the analysis of all the on-going
standardization eorts coming from NB-IoT, G RAN, G
architecture, and a natural way to join them together.
It is also worth mentioning that G proposes a ne-
grain functional separation of the required functionality of
theGinfrastructureandtheusageofCommercial-o-the-
Shelf computers, rather than specialized hardware in order
to minimize capital and operational costs. e envisioned
architecture is composed of the following architectural com-
ponents:
(i) Distributed Unit (DU) and Centralized Unit (DU)
are the architectural components of the Radio Access
Network (RAN) and they present an analogy in terms
of functionality to the existing LTE RRH (Remote
Radio Head) and Base Band Unit (BBU), respectively.
G proposes a functional segregation of the RAN,
fostering the dynamic separation of layers in the RAN
stack. It is achieved through the deployment of the
protocols of the stack in two architectural compo-
nents DU and CU, according to the requirements
of the deployment and the use case addressed. It is
noted that CIoT indicates support for the radio access
interface of the NB-IoT specications.
(ii) Access and Mobility Function (AMF) provides User
Equipment (UE) authentication, authorization, and
mobility management.
(iii) Session Management Function (SMF) is in charge
of managing sessions and allocates IP addresses to
UEs. It is also responsible for selecting and manning
the User Plane Forwarding Function (UPF) for data
transfer.
(iv) Authentication Server Function (AUSF) stores data
for the authentication of UE.
(v) User data Management (UDM) stores data about the
subscription of UE.
(vi) User Plane Forwarding (UPF) is the mobility anchor
for the UE mobility and is in charge of forwarding the
UE trac back and forward to the Internet.
(vii) Service Capability Exposure Function (SCEF) deliv-
ers non-IP data over the control plane and provides
an abstract interface for the network services such as
authentication, Access Control, or discovery.
Another key aspect of G architecture is the sowariza-
tion and the usage of multitenancy shared resources in
Security and Communication Networks
a secure way, fostering the reduction of both capital and
operational costs. However, this mobility and multitenancy
support for dierent carriers and telecommunication opera-
tors in the network imposes new requirements in the network
trac ltering and it has been the main motivation of this
contribution.
It is noted that a comprehensive explanation of all the G
architectural elements and its reference points is provided in
[].
3.2.1. Network Trac Filtering Requirements in 5G-Enabled
IoT Networks. ere are a number of specic requirements
for network trac ltering in G IoT networks, listed as
follows:
(i) Multitenant support: in G architectures, the net-
work functional blocks are virtualized as VNFs and
dierent network operators, carriers, and verticals
can share the physical infrastructure. e packets
need to be encapsulated (e.g., in VXLAN) to dier-
entiate the trac among them, for management and
security reasons. e ltering system needs to deal
with this encapsulation.
(ii) Mobility support: LTE and G networks are subject
to the mobility of the UE and, in this case, the
mobility of the IoT devices. Although in NB-IoT
handover is not supported in a connected stage, cell
reselection is supported in the idle state. Mobility
in G architectures means that packets need to be
encapsulated towards the mobility anchor component
(UPF in G), e.g., using the GTP protocol. e trac
lter will need to be able to handle directly these
encapsulation headers.
(iii) Application layer ltering: the network trac l-
tering system should allow ltering packets for any
header/eld of any protocol of the OSI stack, includ-
ing IoT application layer protocols such as CoAP [].
(iv) Scalability: despite that NB-IoT is a Low-Power
Wide-Area Network (LPWAN) protocol that requires
low bit data rate, the CIoT-RAN and the core of the G
network will need to cope with the packets of massive
IoT devices. erefore, the network lter(s) will need
to eciently manage the packet ltering process for
numerous devices.
(v) Dynamic management: IoT networks are volatile
and trac is subject to changing security condi-
tions. erefore, the management framework needs
to automatically adapt the security ltering policies,
by enforcing and decommissioning dynamically the
rules according to the actual context obtained from
real-time monitoring. is dynamic and intelligent
management requires relying on sowarized network
management and Network Function Virtualization
(NFV) technologies for handling such adaptation.
(vi) Uplink/downlink dierentiation:Garchitectures
require having two dierent Tunnel Endpoint Identi-
ers (TEIDs) per user, which needs to be handled by
the management framework and the ltering agent.
(vii) Nested encapsulation: the ltering agent needs to
support nested encapsulation for handling simultane-
ously the trac encapsulation for both mobility and
multitenancy.
4. Cognitive NB-IoT Management Framework
e proposed architecture relies on SDN and NFV technolo-
gies, monitoring and reaction tools, cognitive components
as well as diverse security enablers and agents to ensure
self-protection, self-healing, and self-repairing capabilities
in IoT networks and systems. It follows a policy-based
security management approach to provide interoperability
and higher exibility to manage security controls over het-
erogeneous networks, including G-compliant IoT networks.
e required security actions can be enforced either directly
in physical IoT networks or virtual and sowarized appli-
ances. Figure  shows the proposed security management
architecture.
e Admin Plane features pertinent APIs, tools, and
graphical interfaces to support administrators on specifying
high-level intents about security policies. e policy edi-
tor allocated in the plane provides a user-friendly tool to
congure security policies using a high-level security policy
language, to govern the conguration of the system and
network, including not only network trac ltering but also
authentication, authorization, channel protection, and trac
management actions.
e security orchestration plane is in charge of deploy-
ing and enforcing the security policies on policy-aware
security enablers and components, providing a run-time
reconguration and adaptation of security enablers, whereby
the framework is endowed with dynamism and intelligence
required for self-healing and self-repairing capabilities. e
orchestrator provides autonomic adaptation according to the
decisions received from the reaction component.
e Policy Interpreter module plays a key role in the
renement of security policies. e high-level policies are
rst translated into a medium-level security policy language,
which allows specifying work-ows related to security proce-
dures in a technology-agnostic way. en, these policies are
rened in specic low-level congurations according to the
selected enablers. e policy renement process is detailed
in our previous paper [].
e monitoring component gathers real-time information
including security reports, regarding the underlying managed
infrastructure, both physical and virtualized. It aims to alert
the reaction module when something is malfunctioning.
Security probes such as IDS and ow and resource mon-
itoring probes are deployed into the SDN, NFV, and IoT
infrastructure domain to give feedback to the monitoring
services.
en, the reaction component is in charge of providing
appropriate countermeasures, according to the system model
status and monitoring information from the monitoring
component. It features a cognitive engine in charge of
providing intelligence to the management framework, e.g., by
selecting adaptation policies or intents stored in the relevant
Security and Communication Networks
VNF Domain
Virtualization layer
Infrastructure Layer
IoT Controller
NB-IoT Network
Monitoring
Module Reaction Module Security
Orchestrator
Security Enforcement Plane
Security Orchestration Plane Policy Interpreter
System Model
Admin Plane Policy Editor
NFV
Orchestrator
VNF Manager
VIM
NFV MANO
Control and Management Domain
(1) Dene Security Policies
(ltering policies)
(2) Policy Renement
(3.1) Policy Enforcement
-deploy vFirewall-
(6) Attack conrmed (7) Countermeasure, enforce
ltering rules
CIoT
DU-RAN
AMF-AUSF
(MME)
CU-RAN
SMF-UDM
(HSS)
UPF
(SGW)
(3.2) & (8) Policy Enforcement
-apply ltering rules-
Network
Policy
Enforcer
(5) Monitor network
(4) (9) Add/update ltering rules
Filtering
Agent
Monitoring
Agent
SDN
Controller
VNF
Do
mai
n
Virtua
l
ization
l
a
y
e
r
IoT Contr
er
NB-
IoT
Ne
t
w
o
r
k
M
onitorin
g
Module
Rea
ction
Mod
ule
S
ecurity
O
rc
h
estrato
r
e
curit
y
Enforcement Plan
e
c
urity Orchestration Plan
e
Po
l
ic
y
Interpre
t
Sys
tem Mode
l
dm
in
Pla
ne
P
o
l
icy
E
d
it
o
Control a
n
(1) Dene Securi
(1) Dene Securi
n
(lterin
g po
e
(
2
)
Pol
i
(3.1
(
(
(6) Attack conr
med
(
7
)
Countermeasure, enforce
l
terin
g
ru
l
es
C
Io
T
DU-RAN
U-R
D
AMF-AUSF
(MME
)
CU-RAN
SMF-UDM
(
HSS
)
UPF
(
SG
W)
(3.2) & (8) Poli
cy E
nforcement
()() y
i
f
-apply ltering rules-
e
r
Network
Network
Polic
y
er
Enforcer
y
(4) (9) Add/update lterin
g
rule
s
Filter
ing
Age
n
t
Monitoring
Ag
e
nt
S
DN
Con
tro
lle
r
F : Network management architecture for G-enabled IoT networks.
repository and by requiring reconguration of the security
enablers to cope with the detected attack/threat.
e Security Orchestrator supervises the orchestration
of the security enablers to be deployed into the Security
Enforcement Plane (to be introduced), according to the
policy requirements. In addition, at run-time, it analyzes the
reaction outcomes and orchestrates the corresponding coun-
termeasures. In this manner, the overall framework aims to
achieve self-healing and resilience capabilities, by constantly
ensuring the satisfaction of the security requirements dened
in the end-user policies.
e Security Enforcement Plane is split into three main
domains. e control and management domain supervises
the use of resources and run-time operations of security
enablers deployed over soware-based and IoT networks. e
SDN controllers are in charge of communicating with the
SDN-enabled network elements to manage connectivity in
the underneath virtual and physical infrastructure. In this
sense, the Network Policy Enforcer is in charge of connecting
through a southbound API with the Agents deployed in
the network, e.g., to enforce ltering rules with a particular
ltering agent or a virtual rewall (vFirewall). e Orches-
trator is NFV ETSI MANO-compliant to provide support
for the secure placement and management of virtual security
functions over the virtualized infrastructure. In addition,
dierent IoT controllers are used to managing IoT devices
and low-power and lossy networks LoWPANs and LPWANs.
ese IoT controllers can be deployed at the edge of the
network to deploy and enforce Network Security Functions
(NSFs) in IoT domains.
e Infrastructure and Virtualization Infrastructure
domain encompasses both physical machines in charge of
holding and supporting storage, computing and networking
infrastructure, and the virtualization technologies, to provide
Infrastructures as a Service (IaaS). is domain comprises
the network elements needed for trac management (e.g.,
forwarding, divert, routing etc.), according to the SDN
controller rules, as well as the security probes for data
gathering needed by the monitoring services.
e VNF domain refers to the virtualization infrastruc-
ture that holds VNFs deployed to enforce the G network
functional blocks as well as any Virtual Network Security
Function (vNSF) to be deployed by the orchestration plane,
such as virtual rewall, vIDS/IPS, vChannelProtection, etc.
It is able to provide the defense mechanisms and threat
countermeasures requested by security policies.
IoT domain comprises the NB-IoT network (including
the CIoT-RAN) as well as the IoT devices to be controlled.
is encompasses security enablers, soware agents, and
actuators required to enforce the security instructions com-
manded by the orchestration plane. Namely, the ltering
agent is deployed in the CIoT-RAN in order to control the
Security and Communication Networks
PGW
HSS MME
SGW SGW
MME HSS
PGW
OPERATOR
(1) OPERATOR
(2)
BBU BBU
CIoT DU
OPERATOR (1) OPERATOR (2)
INTERNET
Radio Components
(RAN)
Managing
Components (EPC)
A
B
B
C
B
B
A
A
B B
A
C
CIoT DU
NB-IoT
Devices NB-IoT
Devices
F : NB-IoT ltering scenario in virtualized and multitenant G Infrastructure.
trac between the particular NB-IoT network according to
the ltering rules received dynamically by the Network Policy
Enforcer.
5. Virtualized and Multitenant
NB-IoT Infrastructure
is section describes an experimental deployment based
on a virtualized NB-IoT LTE infrastructure that is deployed
in our labs, with several G features already supported.
For simplicity, Figure  provides a simplied view of our
deployed infrastructure, where the management plane is
omitted. Our infrastructure is composed of  computers
with an Ubuntu . and an OpenStack Mitaka release.
e deployment employs Neutron and OpenDayLight as
SDN controller running the NetVirt Neutron northbound
interface provided by OpenDayLight. OpenDayLight utilizes
OpenFlow and OVSDB to control the Open vSwitch v.
soware used to control the data path of the virtual machines.
In the gure, only one edge and one core PCs are shown for
simplicity, although our lab has two edge nodes and eight core
nodes. Every one of the boxes labeled as operator X represents
a tenant administrative domain. Each of the tenants has
deployed a complete set of VNFs to run the G network.
To carry out the deployment of the VNFs, the MosaicG
(http://mosaic-g.io/) (evolution of the OpenAirInterface
project) infrastructure has been deployed in each of the ten-
ants of the infrastructure. e current version of MosaicG
allows functional disaggregation of DU and CU although still
using the G spectrum. Moreover, for the core, the current
release still uses MME, HSS, and SGW/PGW terminology;
however, it is fully virtualized and running in VNFs. is
scenario allows us to have a realistic infrastructure to explore
and analyze the NB-IoT trac along all the network seg-
ments.
It is noted that the switches labeled with A in Figure
represent the control points used in OpenStack in order to
enforce tenant isolation by mean of VLAN, Virtual eXtensible
Local Area (VXLAN), or GRE encapsulation. e dierent
points in the data path labeled with B in Figure  represent
the NB-IoT data plane (using IP connectivity) where GTP
encapsulation is present to handle mobility in the devices.
Packets owing across the infrastructure shown in
Figure  can be encapsulated into dierent encapsulation
protocols depending on the network segment. e points
in the data path labeled with C are a subset of the points
labeled with B representing the more complex encapsulation
segment for the NB-IoT infrastructure and, at the same
time, one of the most ecient ones to apply ltering policies
due to the closeness to the hardware (running in physical
machines rather than in VNFs). It is especially important
when trac coming from very dense deployments, with
potentially hundreds of thousands of NB-IoT devices, need
to be handled.
6. Traffic Filtering Process Design
6.1. Filtering Process. e network trac ltering process
is accomplished according to the steps depicted in the
architecturalFigure.estepsaredetailedbelow:
() Firstly, in step () of Figure , the administrator
denesproactivelyhissecuritypolicyintents,e.g.,
the ltering policies, employing an interoperable
Security and Communication Networks
GTP/IP /UDP/
DEVICE
MOBILITY
VXLAN/ MAC / IP/ UDP /
TENANT/TELCO
MAC/ IP / UDP/
PHYSICAL
MACHINE
APP HEADER + APP PAYLOAD
APPLICATION
F : Hierarchical encapsulation.
language, such as MSPL considered in the EU H
ANASTACIA project.
() ose interoperable policies are rened and
translated—step ()—into particular low-level
congurations according to the format required by
the specic ltering agent deployed in the network,
such as the one shown in our previous work in the
context of the Anastasia project [] or the one in
our previous work in the context of the SELFNET
project [].
() e Security Orchestrator is notied of the deploy-
ment of the rules. Optionally, it might contact the
NFV Mano—step (.)—to deploy (if not deployed
yet) as a VNF the ltering agent acting as a vFirewall,
either in the CIoT-RAN or in the core of the network.
en, in step (.) it contacts either the SDN Con-
troller or the Network Policy Enforcer to enforce the
ltering rules through the northbound API.
() e Network Policy Enforcer contacts the ltering
agent using a southbound API, e.g., Netconf, in
step () to enforce the ltering rules. e proposed
ltering mechanism is able to deploy the rules in
Filtering Agents deployed either in the CIoT-RAN or
in vFirewall deployed in the VNF domain of the core
of the virtualized G Network.
()Aerwards,onceinrun-time,themonitoringagent
starts providing monitoring information through
probes to the monitoring module, step (). In this
regard, this monitoring trac is sent through the
Pub/Sub Broker.
() In case the monitoring module detects an attack
based on congured signatures, step (), it warns the
reaction module to make a decision accordingly, and
this notication is done using IODEF or IDEMEF
standards.
() e reaction module component, based on its rule
engine, makes a decision to take a proper counter-
measure to mitigate the attack, step (). It might imply
adding, for instance, new ltering rules to drop, or
divert the trac coming from a particular infected bot
IoT device that is performing a low-rate DDoS attack.
is reaction outcome can be done either using a
standard such as OpenC or by means of tailored
mechanisms, as proposed in our proposal in the next
section.
() e Security Orchestrator contacts again the Network
Policy Enforcer to self-recongure dynamically the
network by deploying the pertinent reaction ltering
rules using the northbound protocol, as shown in step
().
() Finally, the ltering rules are congured in the l-
tering agent through the southbound API, step ().
ese rules will consider the network trac ltering
requirements in Section .. to cope with the NB-IoT
trac, including nested encapsulation for mobility
and multitenant trac ltering support.
6.2. Pattern Matching Filtering Mechanism. is subsection
describes in detail the steps indicated in the previous sub-
section related to the enforcing on the ltering rules into the
managed elements.
Our network ltering mechanism is based on BPF []
to enforce the ltering rules. is ltering mechanism is an
ecient way of ltering packets in the kernel space and it
is being used today in hardware networking equipment and
even in virtual networking soware such as OVS, employed
mainly to overcome the limitations of OpenFlow regarding
packet classication.
Indeed, BPF is used in many management utilities such
as tcpdump, libpcap, iptables, ebtables, etc. BPF is in fact
not only a language to express ltering policies using a user-
friendly high-level descriptive language, but also a built-in
compiler (and optimizer) that translates from the high-level
BPF program into compiled BPF x bytecode.
erefore, BPF allows system administrators to select and
control packets using high-level packet ltering expressions.
e following illustrates an example of lter expression using
a tcpdump style syntax which will be compiled in a BPF
program later on.
$ iptables -m bpf --bytecode $ (nbpf compile
proto[Start:End] & Mask = Value)$
e mechanisms used in this paper is based on this
approach but using a match with more complex matching
rules where the complexity of the frames crossing the
infrastructure is taken into account, as described in the next
subsection.
6.3. Hierarchical Encapsulation. Figure  illustrates an exam-
ple of the most complex hierarchical encapsulation available
in the NB-IoT multitenant G infrastructure, corresponding
to the capture of packets in the control points labeled as C in
Figure .
e rst group of headers is related to the communica-
tion between physical machines including Medium Access
Control(MAC),IPandUDPheaders.esecondgroupof
headersincludesaVXLAN,MAC,IP,andUDP,inserted
to isolate tenant trac, especially for a telecommunication
operator sharing the same physical G infrastructure as a
 Security and Communication Networks
0321
01098765432109876543210987654321
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| |IDMessage|Code|TKL|T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...bytes)TKLany,(ifToken
| ...any)(ifOptions
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 ...any)(ifPayload1|111111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F : CoAP message format [].
tenant. is paper proposes to employ the VXLAN protocol
to achieve that tenant isolation as an example but other
alternative protocols can be used for the same purpose. e
next group of headers including GTP, IP, UDP, Application
(APP) HEADER, and APP PAYLOAD is used to allow NB-
IoT device mobility. GTP is the tunneling protocol employed
in NB-IoT and G infrastructures to establish the data path
forIoTdeviceswithfeaturessuchasmobility,admission
control, etc. Finally, the application header and payload
represent the data being sent/received by the devices.
It is noted that a normal IP network uses a very limited
subset of these headers, for instance, MAC/IP/UDP /APP-
HEADER/APP-PAYLOAD. Compared with that simple case,
several additional headers have been added to achieve both
multitenancy and mobility of NB-IoT devices.
6.4. Filtering Rules for IoT Trac in 5G-Aware NB-IoT Net-
works. In addition to the network protocols specied in the
previous section, an application protocol is also considered
for ltering, since dierent network attacks are not identi-
able unless the trac lter matches particular elds at the
application layer. In this sense, nowadays, the prominent IoT
application protocol is CoAP []. It is a lightweight protocol
that follows a REST model especially devised for constrained
IoT devices (cat-M) required in NB-IoT. Figure  shows the
packet structure of the CoAP protocol [].
7. Implementation and Validation
7.1. Implementing Filtering Rules in Kernel Space. e pro-
posed implementation has been carried out by a ltering
agent prototyped in Python using Pika as a library to expose
a northbound interfaces receiving intents using the AMPQ
protocol []. An intent denes what type of trac should be
controlled and the action that needs to be enforced over such
trac. is approach ts perfectly into the novel cognitive
NB-IoT Management framework presented in Section ,
and in this way the security orchestration plane is able to
deploy and enforce the network security policies, providing
a run-time reconguration and adaptation. It is important
to highlight that old common techniques have been using
static sets of ltering policies on a specic rule-based system
(e.g., OVS). is work adds dynamicity in terms of creating
new ltering rules on demand and using a rule-based ltering
system that can be included as a plug-in in the ltering
agent. e same intent message will be used as input in the
northbound interface of the ltering agent regardless of the
Network
policy
enforcer
intent
Paser from
Intent to high
level BPF
syntax Plug-in
netlink
xt_bpf compiler
iptables
module
Kernel
Hooking
Point
Plug-in (b) Plug-in (c)
F : Filtering agent architecture.
plug-in required, thereby using a common way of deploying
ltering rules in dierent ltering systems.
As an example, let us assume that the ltering agent is
deployed in both points labeled with C in Figure  and that
the trac needs to be dropped in order to mitigate low-
rate DDoS attacks. e intent for this example under such
assumptions is depicted in Figure .
Security and Communication Networks 
T : Encapsulation groups, purpose, and interested elds to be matched.
GROUP PURPOSE PROTOCOLS FIELDS TO BE MATCHED
GROUP 1 PHYSICAL
COMMUNICATION
IP
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
PROTOCOL
UDP SOURCE PORT
DESTINATION PORT
GROUP 2 TENANT ISOLATION
VXLAN
MAC
IP
VNID
MAC SOURCE ADDRESS
MAC DESTINATION
ADDRESS
TYPE
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
PROTOCOL
UDP SOURCE PORT
DESTINATION PORT
GROUP 3 DEVICE MOBILITY
GTP TUNNEL IDENTIFIER
IP
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
PROTOCOL
UDP SOURCE PORT
DESTINATION PORT
GROUP 4 NB-IoT APPLICATION COAP
CODE
VERSION
MESSAGE ID
e Filter Agent is able to add/update/delete intents
coming from the Network Policy Enforcer component of the
architecture presented in Section . e ltering agent will
receive intents and then select among all the possible plug-
ins registered as interface providers, in order to transform
theintentinanimplementableandanexecutablerule.
Several plug-ins are supported; for prototyping purposes,
this research work has employed a ltering plug-in based
on the Linux kernel space using BPF rules. is plug-in
converts intents into high-level BPF syntax. An example of
a high-level BPF rule is also shown in Figure . en, the
high-level BPF syntax is sent to the iptables module named
xt bpf compiler. is module compiles the high-level BFP
syntax into executable bytecode in the kernel space. is
executable bytecode is associated with a hooking point into
the Linux networking subsystem (NetFilter) by using the
netlink API, so that when packets transverse such hooking
point, the bytecode is executed. An example of the compiled
BPF bytecode is shown in Figure .
7.2. Distributed and Scalable Virtual Firewalls. NB-IoT net-
works are expected to deal with up to , devices per cell
[], meaning that, even with low-rate packets per second, the
ltering system will need to scale up properly to handle a huge
amount of packets in the mobile backhaul. In the worst case
there could be a ltering rule per device; however, with cur-
rent soware-based ltering implementations it is not feasible
to handle such large quantities of rules and massive trac in
just one rewall. Moreover, this is further complicated in light
of the complex rules dened herein that require inspecting
the packets according to multiencapsulation imposed in G-
based NB-IoT networks.
Our solution benets from leveraging NFV and cloud-
computing technologies to deploy dynamically in the RAN
backhaul, on demand, virtual Network Security Functions
(vNSFs), in the format of distributed vFirewalls. Each vFire-
wall is in charge of dealing with a subset of the rules according
to a network segmentation addressed in a particular RAN.
A rst ltering agent acts as a load balancer redirecting
the trac quickly to the pertinent vFirewall responsible for
handling a subset of rules. e network segmentation and
forwarding in the load balancer can be achieved with just
one rule per deployed subsequent vFirewall, inspecting the
inner IP packet of the encapsulated trac. Alternatively, this
can be done per tenant, by looking into the VXLAN header.
is scalable approach enables the deployment of additional
vFirewalls according to the network conditions, while our
cognitive management framework allows the autonomous
conguration of the rules for those vFirewalls.
7. 3 . E x p e r i me n t D e s i g n . Table  provides an example of the
dierent headers explained in Section . together with all
elds that will be matched in our experiments per each
of the headers. It is noted that CoAP has been used as
the layer  protocol as the prominent protocol in NB-IoT
deployments.
 Security and Communication Networks
T : Selected elds of the tests carried out using dierent Infrastructures.
PROTOCOL FIELDS BITS TEST 1 TEST 2 TEST 3
IP
src ip  ✓✓
GROUP 
dst ip  ✓✓
protocol 
UDP src port  ✓✓✓
dst port  ✓✓
TOTAL SIZE:   
VXLAN vni  ✓✓✓
GROUP 
MAC
src mac  ✓✓✓
dst mac  ✓✓
type 
IP
src ip  ✓✓
dst ip  ✓✓
protocol 
UDP src port  ✓✓✓
dst port  ✓✓
TOTAL SIZE:   
GTP teid  ✓✓✓
GROUP 
IP
src ip  ✓✓
dst ip  ✓✓
protocol 
UDP src port  ✓✓✓
dst port  ✓✓
TOTAL SIZE:   
CoAP
code ✓✓
GROUP 
version  ✓✓
message id 
TOTAL SIZE:   
ree dierent tests have been designed in order to stress
the complexity of the ltering rules and analyze how this
complexity aects the scalability in NB-IoT deployments.
Each of the tests is related to the number of elds that are
matched on each of the protocols available in the payload
being ltered. e tests are dened as follows:
() Test  evaluates rules with predicates for matching up
to one eld per protocol.
() Test  evaluates rules with predicates for matching up
to two elds per protocol where possible.
() Test  evaluates rules with predicates for matching up
to three elds per protocol where possible.
ese three dierent tests can be applied to dierent
infrastructures. Firstly, these tests can be applied over a
classical IP-based infrastructure in order to have a reference
point in terms of performance and to be able to evaluable the
overhead and complexity imposed by the infrastructure. It
will require the use of only the Group  of headers (associated
with physical communication) indicated in Table . Secondly,
the tests can also be applied over a Multitenant Infrastructure
to evaluate the overhead related to tenant isolation and user-
ltering in such an environment. It will require the usage of
the Group  and Group  of headers (associated with physical
communication and tenant isolation) indicated in Table .
irdly, the tests can be further applied over an NB-IoT
Multitenant Infrastructure where both tenant isolation and
NB-IoT mobility need to be handled. It will require the usage
of the Group , Group , and Group  of headers (associated
with physical communication, tenant isolation, and device
mobility) indicated in Table . Finally, the tests can also be
applied over a Service-aware NB-IoT Multitenant Infrastruc-
ture, where not only tenant isolation and NB-IoT mobility
need to be handled, but also application-specic ltering
for NB-IoT protocols are required. It imposes headers from
Group , Group , Group , and Group  (associated with
physical communication, tenant isolation, device mobility,
and NB-IoT Application), as indicated in Table .
Table  illustrates the combination of the selected elds
of the matching rules, grouped according to the protocols
available in the three infrastructures analyzed in the three
tests carried out in each of these infrastructures. e table
contains the size in bytes that need to be matched by the
rules for each of the groups. It allows the reader to analyze
the increasing complexity of each test compared with the
previous one. It is noted that these sizes are cumulative since
the usage of Group  headers implies the usage of the header
of Group  and so on and so forth.
Security and Communication Networks 
e set of experiments indicated in Table  aims to vali-
date the feasibility of the proposed trac ltering mechanism
to handle the trac coming from thousands of NB-IoT
devices in the core of a multitenant G-network simulating
alow-rateDDoSattackthatmightsendpacketseverysto
keep connection/sessions open to collapse the target service.
To this end, each of the experiment ranges exponentially
(power ) the number of ltering rules being loaded from
(,,,,,,,,,,,,,,
, and ) according to the packets per seconds that
arrive to the ltering agent. In the worst case in terms of
scalability, the administrator would need the most nest grain
of details in the control of the trac and thus considering
one rule per each of the services being running in each
of the NB-IoT devices of the infrastructure. Usually, one
NB-IoT device hosts one service. erefore, a : match
correspondence between the number of ltering rules and
devices can be assumed in the experiments. In summary, four
dierent infrastructures are analyzed against three dierent
complexities in the rules, and each of these scenarios will
be ranged against the dierent number of rules previously
described.
7.4. Hardware Infrastructure. e deployment presented in
Figure  matches the deployment carried out in our premises
with some assumptions. Firstly, one operator has been
deployed in our infrastructure and one CU and DU pair
is currently deployed. Second, two LTE-based sensors have
been simultaneously connected to our testbed in order to
reproduce a packet trace in the data path, completely accurate
to the NB-IoT devices. is has been required since our
LTE stack based on G OpenAirInterface currently does not
provide support for the NB-IoT radio interface. However, the
main limitations as indicated in the previous sections are in
the radio access side and those assumptions do not aect
the quality of the results presented herein since the packet
encapsulation stack being evaluated is equivalent. e com-
plete infrastructure has been deployed in OpenStack Mitaka
to allow tenant isolation. is deployment has allowed us to
gather Packet Captures (PCAP) les of the communication
between the IoT device and the SGW and PCAPs of the four
dierent infrastructures presented in the testbed section.
Aer the PCAP les have been gathered for one device,
they have been processed in order to generate derivate PCAP
les where there are as many ows as devices analyzed in the
scenario. As mentioned, there is a : match between devices,
ows, and rules. en, these les are used in the experiments
associated with the same number of rules/devices.
erefore, a testbed has been set up to measure matching
times and scalability of the ltering mechanisms proposed
and to validate its feasibility into large-scale NB-IoT change
deployments. Figure  shows a logical layout of the com-
ponents deployed in the physical computer used to execute
the experiments for performance evaluation. e testbed
machine has installed an Ubuntu . Xenial -bit oper-
ating system and is equipped with  GiB RAM, a  core
Intel Xeon CPU E- v @.GHz processor, and TB
optical hard disk plus a GB solid-state hard disk. Each of
the VMs employed for the deployment of vFirewall where the
experiments have been carried out has been deployed KVM
with Gb RAM,  vCores, and G HDD.
Firstly, the ltering agent receives an intent and uses
the user-space tool provided by Netlter (iptables) to load
the ltering rules at two dierent points of the frame-
work NF IP PRE ROUTING and NF IP LOCAL IN, hook-
ing points  and , respectively (see A in Figure ). Secondly,
an external process replays the PCAP le generated for this
experiment from the location indicated by label B in Figure .
When the rst packet from the network interface matches
at hooking point  shown as label C shown in Figure , a
timestamp value is produced and such information is saved.
Finally, packets cross the hooking point  labeled as D in
Figure  where all the set of rules are already deployed (from
 to , depending on the scenario). Only the last rule
contains the lter predicate that perfectly matches the ow.
All the rules are homogeneous in complexity and all the
packets must be matched against all the rules. is approach
is a very pessimistic approach since it assumes always the
worst-case scenario. However, if scalability is proven for
this worst-case scenario, it will continue to be valid for less
extreme conditions. Once the rst packet reaches the last
rule, it matches the predened predicate and produces a new
timestamp. erefore, the dierence between timestamps
gathered at hooking point  and hooking point  provides
the time consumed of a packet crossing the kernel network
space when dierent rules have been applied. is allows us
to measure performance results related to the complexity and
the number of the predicates in the rule, and how it aects the
normal trac of the network in terms of delay.
8. Performance Evaluation
is section evaluates the impact of dealing with complex
rules that requires deep inspection of the packets to support
nested encapsulation originated by multitenancy and mobil-
ity of G-enabled NB-IoT networks. e testbed estimates
the advisable maximum number of complex ltering rules
that can be enforced in one vFirewall without incurring
packet loss, taking into account the nest grained conditions
(i.e., one rule per NB-IoT device). In addition, it evaluates
the scalability and performance in terms of jitter, overhead
times, matching ltering rules times, and management times
(ushing and loading of rules).
To this end, for each of those evaluations, the paper
compares the performance of our trac ltering mechanism
for NB-IoT G service-aware networks with the performance
achieved in traditional IP infrastructures, which can be han-
dled with traditional trac ltering methods. Figure  shows
the four infrastructures previously presented in Section .,
which will be analyzed along this section.
() Classical IP Infrastructure.
() User-aware Multitenant Infrastructure, where there is
tenant isolation and virtualization.
() G NB-IoT device mobility, multitenant infrastruc-
ture, where there is tenant isolation, virtualization and
device mobility.
 Security and Communication Networks
NETWORK INTERFACE DRIVERS
User
Space
Kernel
Space
Local processes iptables
1Route
NF_IP_PRE_ROUTING
2
NF_IP_LOCAL_IN
3
NF_IP_FORWARD
4
NF_IP_POST_ROUTING
5
Route
NF_IP_LOCAL_OUT
Netlink
Netfilter
framework
C
B
A
Filtering
Agent
Intent
D
F : Performance evaluation testbed.
Classical
IP
Multi-Tenant User
Awa re
NB-IoT 5G Device
Mobility Aware
NB-IoT 5G service-
Awa re
Physical Layer
Network Layer
Transport Layer
Physical Layer
Network Layer
Transport Layer
Multi-Tenant
Encapsulation
Physical Layer
Network Layer
Transport Layer
Physical Layer
Network Layer
Tra nsp ort L ayer
Multi-Tenant
Encapsulation
Physical Layer
Network Layer
Tra nsp ort L ayer
Device-Mobility
Encapsulation
Network Layer
Tra nsp ort L ayer
Physical Layer
Network Layer
Tra nsp ort L ayer
Multi-Tenant
Encapsulation
Physical Layer
Network Layer
Tra nsp ort L ayer
Device-Mobility
Encapsulation
Network Layer
Tra nsp ort L ayer
Application LayerGROUP 4
GROUP 3
GROUP 2
GROUP 1
F : Analyzed infrastructures.
Security and Communication Networks 
Classical IP
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
# Infrastructures / Rules
Averaged Matching Times
1-Field Test
2-Field Test
3-Field Test
Multi-TenantUser-Aware
0
5
10
15
20
25
30
35
40
Time (milliseconds)
F : Average rule matching time per number of rules and analyzed infrastructure.
() NB-IoT Service-aware G Multitenant Infrastructure,
where there is tenant isolation, virtualization and
device mobility and NB-IoT service-level ltering
support.
Figure  represents the empirical results in terms of
performance times over analyzed infrastructures. e X-axis
follows an exponential function, increasing the number of
devices/rules in order to show how the proposed ltering
approach scales according to the number of devices. It is
noted that NB-IoT deployments should deal with thousands
of devices. is is why the largest scenario analyzed uses this
level of scalability to prove the feasibility of the proposed
approach at production-grade. e Y-axis is the average time
in milliseconds taken to process a packet that transverses all
the rules loaded.
e three series represent the three dierent tests pre-
viously indicated. e rules matching time grows according
to the increasing complexity of the infrastructures deployed
and the services provided by the infrastructure. is further
leads to more complex ltering rules that need to be applied.
us, the Classical IP Infrastructure provides the fastest
performanceresultswhiletheNB-IoTService-awareG
Multitenant Infrastructure provides the slowest.
As can be seen in the graph, the number of rules
deployed is the predominant and critical factor that aects
the scalability. In addition, the complexity of the supporting
infrastructure (scenario) also has an impact on time. For the
largest deployment with , devices, the time consumed
in a Classical IP Infrastructure scenario is around ms.
is case can be considered as the reference best scenario
as this is the simplest infrastructure. e other three scenar-
ios analyzed are User-aware Multitenant Infrastructure (or
simply referred to as Multitenant) and G NB-IoT device
mobility/multitenant infrastructure (NB-IoT Multitenant) as
well as G NB-IoT device mobility/multitenant infrastructure
(Service-aware NB-IoT Multitenant) exposing an increasing
overhead with respect to the classical IP scenario. Finally, the
complexity of the rules available in each of the scenarios for
each of the infrastructure seems to be a factor incurring less
delay.
In addition, the classical ltering method by using just IP
protocol inspection is around % for the -eld test, % for
-eld test, and % for -elds faster than the Service-aware
NB-IoT Multitenant scenario and when thousands of rules
are applied in the vFirewall.
Moreover, the largest NB-IoT scenario with ,
rules/devices being ltered simultaneously requires ms for
 Security and Communication Networks
Classical IP
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
0 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
# Infrastructures / Rules
Averaged Matching Times
0.0150625
0.030125
0.06025
0.1205
0.241
0.482
0.964
1.928
3.856
7.712
15.424
30.848
Time (milliseconds) - Exponential Axis
1-Field Test
2-Field Test
3-Field Test
F : Performance of matching ltering rules using a logarithmic scale.
matching, which is clearly in the boundaries of the tolerable
delays indicated by the NB-IoT and LTE-M standards.
Figure  illustrates the same results plotted in Figure 
yet in an exponential scale (log base, Y-axis) in terms of time
overhead and an exponential scale in the number of devices
(X-axis). Despite the exponential nature of both scales, the
plot shows a close to linear trend as the number of devices
grows, which validates the good scalability performance
of the proposed approach when scaling the number of
rules/devices.
Aer the above analysis of the behavior of all the dierent
rule complexities, a deeper analysis has been carried out by
stressing the infrastructure to gather results of the system
regarding scalability in terms of the number of simultaneous
devices performing a low-rate DDoS attack. To this end,
Figures,,andfocusonthemostcomplexscenario
where all the headers’ elds are matched (-eld test). ese
gures analyze the behavior of the system when ,, ,
and , devices are sending low-rate packets every s,
which simulates the behavior of a low-rate DDoS attack. It
leads to , , and  packets/s, respectively, as indicated
in the legend of these gures.
Figure  shows how the system is stable for the three
dierent number of devices analyzed until , rules where
the overhead time is close to seconds. Beyond that point, the
system is still stable for , rules for a scenario with  PPS
(Packets Per Second) (i.e.,  devices) for all infrastructures
analyzed, including NB-IoT G service-aware infrastructure
where the average overhead time is around ms. However,
the system becomes unstable when , rules are facing a
higher volume of attack,  PPS (i.e.,  devices). is
threshold determines the boundaries of the scalability in
terms of devices supported by a given virtual rewall.
Figure  shows an analysis of the packet loss and reas-
sures the previous results shown in Figure . ere is no
packet loss for the three dierent number of devices analyzed
until , rules. en, the system is still close to % packet
loss for , rules for a scenario with  PPS (i.e., 
devices).Aerthispoint,thenumberoflostpacketsstartsto
increase dramatically, showing a similar behavior to the one
plotted in Figure . e Service-aware NB-IoT Multitenant
scenario with , devices ( PPS) and , rules shows
an unacceptable packet loss rate of around %.
Figure  shows the behavior of the jitter when ranging
the number of devices and rules. Jitter is almost insignicant
and close to us, up to , rules. en, it is still acceptable
for a scenario with  PPS (i.e., , devices) where the
jitter is around -us, depending on the infrastructure
Security and Communication Networks 
Classical IP
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
0 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
3-Field Test
Overhead Times for Dierent Packets Per Second (PPS) Scenarios
NB-IoT 5G Device Mobility
0
5
10
15
20
25
Time (seconds)
137 pps
274 pps
546 pps
F : Overhead time with respect to a -rule scenario according to both number of rules and infrastructure analyzed.
Classical IP
NB-IoT 5G Service-Aware
Multi-Tenant User-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
0 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
3-Field Test
% Packet Loss for Dierent Packets Per Second (PPS) Scenarios
NB-IoT 5G Device Mobility
0
10
20
30
40
50
60
70
80
90
100
Time (seconds)
137 pps
274 pps
546 pps
F : Packet loss according to both number of rules and infrastructure analyzed.
 Security and Communication Networks
Classical IP
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
Classical IP
Multi-Tenant User-Aware
NB-IoT 5G Device Mobility
NB-IoT 5G Service-Aware
0 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768
3-Field Test
Jitter for Dierent Packets Per Second (PPS) Scenarios
NB-IoT 5G Device Mobility
137 pps
274 pps
546 pps
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
Time (seconds)
F : Jitter according to both number of rules and infrastructure analyzed.
analyzed. Beyond that number of devices, the jitter increases
signicantly.
It can be concluded that the scalability boundaries of the
proposed architecture are set to , NB-IoT devices per
virtual rewall, where each of such devices has associated
a rule to control an NB-IoT service. Our testbed has the
capability to run eight VMs for , devices, which is far
beyond the expected . per cell indicated in the NB-IoT
standard []. is result successfully validates the suitability
of the proposed approach.
Figures  and  illustrate results on ushing and loading
times of rules, respectively, in order to analyze the manage-
ment plane of the proposed approach. From the management
plane’s perspective, ushing, and loading times gives critical
information about how long it takes for the management
system to reset the vFirewall when suddenly around up to
, devices attack the system simultaneously. Cleaning the
last conguration and loading a completely new one would
take about .ms and s, respectively. In other words, the
proposed system would be ready for controlling thousands
of completely dierent NB-IoT devices in s. It should be
noticed that these ne-grain rules are NB-IoT service-aware,
and it is worth clarifying that, by using a more generic rule
such as ltering bytenant or using amask in the IP addresses,
multiple ows could be stopped just by using one rule and all
the processes including ushing, loading, and matching will
be signicantly reduced from the times specied above.
9. Conclusions
is paper has described a novel autonomic security frame-
work featured with an ecient network trac ltering system
for virtualized and multitenant G-enabled NB-IoT net-
works, which relies on a cognitive management framework
for delivering autonomic self-protection capabilities to the
network.
Our proposed security framework and ltering system
are ready for mitigating an attack by deploying and loading
dynamically, thousands of ltering rules in the vFirewall,
corresponding to thousands of NB-IoT devices. e ltering
mechanism is able to process encapsulated G network trac
in the core and in the edge of the virtualized G network
simultaneously, with multitenancy, mobility, and DPI sup-
port. e complex ltering rules, capable of handling such
trac, are evaluated in the kernel space by our ltering agent
with minimal overhead in the vFirewall, which demonstrates
the feasibility and performance of the proposed security
framework and ltering system.
As future work, we plan to investigate mechanisms that
increase the intelligence of our management framework to
Security and Communication Networks 
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
Classical IP Multi-Tenant User-Aware NB-IoT 5G Device Mobility NB-IoT 5G Service-Aware
# Rules / Infrastructures
Rule Flushing Time
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0.09
Time (seconds)
1-Field Test
2-Field Test
3-Field Test
F : Flushing times of cleaning NB-IoT Service-aware G Multitenant Infrastructure rules.
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
16
32
64
128
256
512
1024
2048
4096
8192
Classical IP Multi-Tenant User-Aware NB-IoT 5G Device Mobility NB-IoT 5G Service-Aware
# Rules/Infrastructures
Rule Loading Time
1-Field Test
2-Field Test
3-Field Test
0.01
0.1
1
10
Time (seconds)
F : Loading time of adding NB-IoT Service-aware G Multitenant Infrastructure rules.
 Security and Communication Networks
increase scalability and speed up, even more, the performance
of the trac ltering mechanism. We also envisage extending
the security capabilities of the framework, by exploring the
autonomic deployment and management of other kinds of
virtual Network Security Functions, such as vAAA or vChan-
nelProtection, to cope with the challenging requirements of
IoT scenarios.
Data Availability
No external data were used to support this study. All network
packet’s captures and derived data sets have been generated
in our infrastructure.
Conflicts of Interest
e authors declare that they have no conicts of interest.
Acknowledgments
is work has been partially funded by “Fundacion Seneca-
Agencia de Ciencia y Tecnologia de la Region de Mur-
cia”, under the program “Jimenez de la Espada de Movil-
idad Investigadora, Cooperacion e Internacionalizacion”
stay (/EE/). e paper is the result of a joint col-
laboration partially funded by two EU H projects:
SLICENET, Grant Agreement H-ICT--/ and
EU ANASTACIA, Grant Agreement no. . In addition,
it has been supported by a postdoctoral INCIBE grant
Ayudas para la Excelencia de los Equipos de Investigaci´
on
Avanzada en Ciberseguridad” Program, with Code INCIBEI-
-.
References
[] M. Hatton, Machina research predicts 10 million 5g internet of
things connections in 2024, , https://machinaresearch.com/
report/g-will-account-for--million-cellular-iot-connections-
in-/.
[]M.DeDonno,N.Dragoni,A.Giaretta,andA.Spognardi,
“DDoS-Capable IoT Malwares: Comparative Analysis and
Mirai Investigation,Security and Communication Networks,
vol.,pp.,.
[] Y. Gao, Y. Peng, F. Xie et al., “Analysis of security threats and
vulnerability for cyber-physical systems,” in Proceedings of 2013
3rd International Conference on Computer Science and Network
Tech n o l og y , pp. –, October .
[] Major DDoS Attacks Involving IoT Devices, , https://www
.enisa.europa.eu/publications/info-notes/major-ddos-attacks-
involving-iot-devices.
[] Y. E. Wang, X. Lin, A. Adhikary et al., “A Primer on GPP Nar-
rowband Internet of ings, IEEE Communications Magazine,
vol.,no.,pp.,.
[] Technical Specication Group GSM/EDGE Radio Access Net-
work, “Cellular system support for ultra-low complexity and
low throughput Internet of ings (CIoT) (Release ),” Tech.
Rep. . V.., rd Generation Partnership Project, Jan-
uary .
[]L.Zhou,M.Liao,C.Yuan,andH.Zhang,“Low-RateDDoS
Attack Detection Using Expectation of Packet Size,Security
and Communication Networks,vol.,.
[] Z. Shelby, K. Hartke, and C. Bormann, “e constrained
application protocol (CoAP),IETF, Article ID RFC , .
[] A. El-Atawy, T. Samak, E. Al-Shaer, and L. Hong, “Using online
trac statistical matching for optimizing packet ltering per-
formance,” in Proceedings of the IEEE International Conference
on Computer Communications (INFOCOM ’07), pp. –,
Anchorage, Alaska, USA, .
[] A. El-Atawy and E. Al-Shaer, “Adaptive early packet ltering
for defending rewalls against DoS attacks,” in Proceedings of
the IEEE Conference on Computer Communications (INFOCOM
’09),pp.,RiodeJaneiro,Brazil,.
[]Z.Trabelsi,L.Zhang,andS.Zeidan,“Dynamicruleand
rule-eld optimisation for improving rewall performance and
security,IET Information Security,vol.,no.,pp.,
.
[] Z. Trabelsi, S. zeidan, M. M. Masud, and K. Ghoudi, “Statistical
dynamic splay tree lters towards multilevel rewall packet
ltering enhancement,Computers & Security,vol.,pp.
, .
[] S. Ziegler, A. Skarmeta, J. Bernal, E. E. Kim, and S. Bianchi,
Anastacia: Advanced networked agents for security and trust
assessment in CPS IoT architectures,” in Proceedings of the
Global Internet of ings Summit, GIoTS 2017,pp.,Switzer-
land, .
[] P. Neves, R. Cal´e, M. R. Costa et al., “e SELFNET Approach
for Autonomic Management in an NFV/SDN Networking
Paradigm,” International Journal ofDistributed Sensor Networks,
vol. , no. , .
[] P. Salva-Garcia, J. M. Alcaraz-Calero, R. M. Alaez, E. Chirivella-
Perez, J. Nightingale, and Q. Wang, “G-UHD: Design, pro-
totyping and empirical evaluation of adaptive Ultra-High-
Denition video streaming based on scalable H. in virtu-
alised G networks,Computer Communications,vol.,pp.
–, .
[] R. Ricart-Sanchez, P. Malagon, P. Salva-Garcia, E. C. Perez,
Q. Wang, and J. M. Alcaraz Calero, “Towards an FPGA-
Accelerated programmable data path for edge-to-core commu-
nicationsinGnetworks,Journal of Network and Computer
Applications,vol.,pp.,.
[] A. Serrano Mamolar, Z. Pervez, J. M. Alcaraz Calero, and A. M.
Khattak, “Towards the transversal detection of DDoS network
attacks in G multi-tenant overlay networks,Computers &
Security,vol.,pp.,.
[] M.-A. Kourtis, H. Koumaras, G. Xilouris, and F. Liberal, “An
NFV-Based Video Quality Assessment Method over G Small
Cell Networks,IEEE MultiMedia,vol.,no.,pp.,.
[] M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A.-R. Sadeghi,
and S. Tarkoma, “IoT SENTINEL: Automated Device-Type
Identication for Security Enforcement in IoT,” in Proceedings
of the IEEE International Conference on Distributed Computing
Systems, ICDCS 2017,pp. –, USA, .
[] H. Hsieh, J. Chen, and A. Benslimane, “G Virtualized Multi-
access Edge Computing Platform for IoT Applications,Journal
of Network and Computer Application s,vol.,pp.,.
[] W. Meng, “Intrusion detection in the era of IoT: Building trust
via trac ltering and sampling, e Computer Journal,vol.,
no. , pp. –, .
[] N. Pandeeswari and G. Kumar, “Anomaly Detection System
in Cloud Environment Using Fuzzy Clustering Based ANN,
Security and Communication Networks 
Mobile Networks and Applications,vol.,no.,pp.,
.
[]C.Modi,D.Patel,B.Borisaniya,H.Patel,A.Patel,andM.
Rajarajan, “A surve y of intrusion detection techniques in cloud,
Journal of Network and Computer Applications,vol.,no.,pp.
–, .
[] A. V. Aho and M. J. Corasick, “Ecientstring matching: an aid
to bibliographic search,Communications of the ACM,vol.,
pp. –, .
[] R. S. Boyer and J. Strother Moore, AFastStringSearching
Algorithm, Palo Alto Research Center, Palo Alto, California,
USA, .
[] A. N. M. E. Raq, M. W. El-Kharashi, and F. Gebali, “A
fast string search algorithm for deep packet classication,
Computer Communications,vol.,no.,pp.,.
[] S. Kumar, S. Dharmapurikar, F. Yu, P. Crowley, and J. Turner,
Algorithms to accelerate multiple regular expressions matching
for deep packet inspection,SIGCOMM Computer Communica-
tion Review,vol.,no.,pp.,.
[] R. Smith, C. Estan, S. Jha, and S. Kong, “Deating the big bang:
Fast and scalable deep packet inspection with extended nite
automata,SIGCOMM Computer Communication Review,vol.
,no.,pp.,.
[] T.Bujlow,V.Carela-Espa˜nol, and P. Barlet-Ros, “Independent
comparison of popular DPI tools for trac classication,
Journal of Network and Computer Applications,vol.,pp.
, .
[] ONF: Open networking foundationwebsite, https://www.open-
networking.org/.
[]B.PfaandO.v.S.Commiter,http://www.openvswitch.org/
support/slides/p.pdf.
[] W. c. C . Tu, “Ooading OVS ow processing using eBPF,” http://
www.openvswitch.org/support/ovscon//-tu.pdf.
[] W. Stearns, “Netlter extensions HOWTO: New netlter
matches,” http://www.netlter.org/documentation/HOWTO/
netlter-extensions-HOWTO-.html.
[] S. McCanne and V. Jacobson, “e bsd packet lter: A new
architecture for user-level packet capture,” in Proceedings of the
USENIX Winter 1993 Conference Proceedings onUSENIX Winter
1993 Conference, pp. -, USENIX Association, .
[] “Harald Welte, P.N.A.: netlter/iptables project homepage -
the netlter.org “iptables” project,” http://www.netlter.org/
projects/iptables/index.html.
[] J. Schlienz and D. Raddino, “Narrowband internet of things
whitepaper,IEEE Microwave Magazine,vol.,no.,pp.,
.
[] C. Mysirlidis, A. Lykoyrgiotis, T. Dagiuklas, I. Politis, and S.
Kotsopoulos, “Media-aware proxy: Application layer ltering
and L mobility for media streaming optimization,” in Proceed-
ings of the IEEE International Conference on Communications,
ICC 2015,pp.,UK,.
[] A. Stanciu, T.-C. Balan, C. Gerigan, and S. Zamr, “Securing the
IoT gateway based on the hardware implementation of a multi
pattern search algorithm,” in Proceedings of the International
Conference on Optimization of Electrical and Electronic Equip-
ment, OPTIM 2017 and Intl Aegean Conference on Electrical
Machines and Power Electronics, ACEMP 2017, pp. –,
Romania, .
[] J. Kima, D. Kimb, and S. Choi, “gpp sa architecture and
functions for g mobile communication,” ICT Express,vol.,
no.,pp.,.
[] A. Molina Zarca, J. Bernal Bernabe, I. Farris, Y. Khettab,
T. Taleb, a n d A . S k a r meta, “Enha n c i n g IoT sec u r ity throu g h
network sowarization and virtual security appliances,Inter-
national Journal of Network Management,vol.,no.,.
[] O. Standard, “OASIS advanced message queuing protocol
(AMQP) version .”.
... In [20] it presents a routing attack due to the dynamic infrastructure of the IoT network, analyzes and proposes measures to counteract the sinkhole and selective forwarding. An important effort is the analysis in [28,29] to avoid the denial attack of service (DoS). In [18], it mentions a considerable contribution in defining possible security attacks and services based on the new service requirements and 5G network uses (Table 6). ...
... The application layer [16], [29] is the one that stays the services for the end-user and its security is focused on software attacks, among which are the attack that involves the end-user to obtain their passwords, passwords through emails or web pages, malicious virus that obtain or modify confidential data and malicious scripts that spoil the functions of the IoT network. ...
... To mitigate the attacks that occur in the 5G -IoT network, solutions are proposed in [18], [23], [29], [33], [18], [20], [26], [27], [ 29] - [31], [34], [16], [23], [25] - [27], [30], [17], [20], [23], [24], [30] focused on architectures, protocols, mechanisms and algorithms, among the most relevant to solve security problems are the blockchain [33] that allows red interoperability, privacy, traceability and reliability through a distributed environment and, as a mechanism, propose crowdsourcing [ 22] to mitigate local and remote attacks; The authors also present authentication, encryption and algorithm systems that complement the security frameworks. ...
Chapter
Full-text available
Fifth generation (5G) wireless technologies satisfies the growing demand for the Internet of Things (IoT), however, IoT devices are vulnerable to security threats due to the simplicity of their hardware and communication protocols, which imply possible attacks and security challenges. In this work we propose to conduct a systematic review of literature that relates 5G technologies to the internet of things and approach the security that the 5G network for IoT must provide. The Torres – Carrión method is used, raising four research questions: a) information security services, b) types of attacks in 5G-IoT, c) security in the layers of the IoT network architecture, d) strategies for 5G-IoT network security. Semantic search criteria were applied, in the Scopus database, obtaining 23 articles from 18 journals, the main studies were collected, it is evident that the blockchain is an efficient security mechanism that merits further study, that the physical layer is the one that receives the most active and passive attacks, such as denial of service (DoS) that is studied by several authors, together with mechanisms, architectures, protocols and algorithms that provide the security services of a mobile network.
... Furthermore, the different IoT protocols should be more equated in terms of open systems interconnection (OSI) layers-although the OSI model (see Figure 9) may not be truly accurate for all of these IoT wireless technologies and some terminology might change, it serves as a reference [40][41][42][43][44][45][46]. In the tests performed within this work, we evaluated the following technologies at different layers: Nonetheless, using the aforementioned layers is significative for IoT wireless technologies characterisation, as they are those of the most used layers in each technology. ...
Article
Full-text available
IoT applications rely strongly on the performance of wireless communication networks. There is a wide variety of wireless IoT technologies and choosing one over another depends on the specific use case requirements—be they technical, implementation-related or functional factors. Among the technical factors, latency, error rate and stability are the main parameters that affect communication reliability. In this work, we present the design, development and validation of a Universal Testbed to experimentally measure these parameters, abstracting them from the wireless IoT technology protocols and hardware platforms. The Testbed setup, which is based on a Raspberry Pi 4, only requires the IoT device under test to have digital inputs. We evaluate the Testbed’s accuracy with a temporal characterisation—accumulated response delay—showing an error less than 290 µs, leading to a relative error around 3% for the latencies of most IoT wireless technologies, the latencies of which are usually on the order of tens of milliseconds. Finally, we validate the Testbed’s performance by comparing the latency, error and stability measurements with those expected for the most common IoT wireless technologies: 6LoWPAN, LoRaWAN, Sigfox, Zigbee, Wi-Fi, BLE and NB-IoT.
... Currently, NB-IoT is leading the course of the technologies for MTC in the licensed spectrum [13] [14], and it is expected to be the major player for the support of massive MTC in the future. However, accommodating a massive number of MTC devices imposes new technical challenges on the PHY and MAC layers, such as the need for advanced access schemes, control overhead reduction mechanisms, energy efficiency, coverage enhancements, cost-effectiveness, and security [15] [16]. ...
Article
Full-text available
The technology of Narrow Band Internet of Things (NB-IoT) is expected to contribute towards the support of massive Machine Type Communications (mMTC), i.e., one of the fundamental performance objectives of 5G networks. However, that call for massiveness, requests a thorough revisit on the NB-IoT access procedure. Considering this, the performance of the NB-IoT access procedure is analysed under different network densities and for various combinations of the related configuration parameters. The analysis led to a useful reference table with 3GPP compliant configurations that maximize the access success probability in an NB-IoT system. The table enables an adaptive access mechanism, where the access parameters are adjusted according to the expected network density. The evaluation results quantify the gain that adaptiveness can provide to the performance of the access procedure.
... Network slicing has now become a key technology to ensure certain levels of well-performing services. Nowadays, there are multiple research and developments in the state of the art leveraging network slicing to guarantee QoS levels among heterogeneous use cases such as the Internet of Things (IoT) [9], Smart Grids [10], Smart Cities [11], eHealth [12], or Intelligent Transport, Education and Media and Entertainment [13], among others. ...
... A software-based data plane programmability approach is followed by Salva-Garcia et al. [14] to perform network traffic filtering for multi-tenant 5G IoT networks in kernel space. Like in our work, they follow an intent-based and SDN model for adaptive, flexible and network filtering in massive MTC scenarios demanded by IoT. ...
Article
Full-text available
The Fifth Generation (5G) mobile networking coupled with Internet of Things (IoT) can provide innovative solutions for a wide range of uses cases. The flexibility of virtualized, softwarized and multi-tenant infrastructures and the high performance promised by 5G technology are key to cope with the deployment of the IoT use cases demanded by various vertical businesses. Such 5G IoT use cases incur challenging Quality of Service (QoS) requirements especially connectivity for millions of IoT devices to achieve massive Machine-Type Communication (mMTC). In addition, network slicing is a key enabling technology in 5G multi-tenant networks to create logical virtualized networks for delivering customised solutions to meet diverse QoS requirements. This work presents a 5G IoT framework with network slicing capabilities able to manage a vast number of heterogeneous IoT network slices dynamically on demand. The proposed solution has been empirically tested and validated in five realistic vertical-oriented IoT use cases. The achieved results demonstrate a excellent stability, isolation and scalability while being able to meet extreme QoS requirements even in the most congested and stressful scenarios.
... Moreover, authors of [107] integrated SDN and NFV concepts to design an automated deployment of virtual firewalls to protect NB-IoT communications. Besides, in [108] an efficient traffic filtering approach for encapsulated traffic was proposed in order to address mobility requirements of 5G networks based on NB-IoT devices. ...
Article
Full-text available
The convergence of the Internet of Things (IoT) and 5G will open a range of opportunities for the deployment of enhanced sensing, actuating and interactive systems as well as the development of novel services and applications in a plethora of fields. Given the processing and communication limitations of both IoT devices and the most novel IoT transmission technologies, namely, Low Power Wide Area Network (LPWAN), there are notable concerns regarding certain security issues to be overcome in order to achieve a successful integration of LPWAN systems within 5G architectures. In this survey work, we analyze the main security characteristics of LPWANs, specially focusing on network access, and contrast them with 5G security requirements and procedures. Besides, we present a comprehensive review and analysis of research works proposing security solutions for the 5G-LPWAN integration. Finally, we explore open issues and challenges in the field and draw future research directions. From our analysis, it is evident that many efforts are being devoted from the academia, industry and Standards Developing Organizations (SDOs) for achieving the desired confluence of IoT and 5G worlds. We envision a successful integration of both ecosystems by exploiting novel lightweight security schemes addressing the stringent security requirements of 5G while being assumable by constrained IoT devices.
Chapter
A great deal of IoT solutions require low-power long-range coverage that is not typically supported in most WPAN deployments. LPWAN technologies address this need by providing proprietary mechanisms that can integrate with core IP networks to provide hybrid IoT solutions. This chapter explores a wide range of standards that include LoRa, SigFox, D7AP, and Weightless. NB-IoT and other relevant mobile IoT technologies including latest development associated with 5G are detailed. In general, these technologies are presented from a performance and security perspective including a description of their stacks.
Chapter
NB-IoT is the most suitable mobile network technology for IoT applications that require exceptionally extensive coverage added with extremely low power consumption, since these applications will generally be characterized by low data rates and moderate reaction times, usually in a few seconds, enabling the creation and development of solutions aimed at smart cities and smart environments. The NB-IoT technology can be characterized as a cellular LPWAN technology operating in a downlink within a bandwidth of 180 kHz and a sub-carrier space of 15 kHz and in the uplink, in general with a single tone transmission ranging between 3.75 kHz or 15 kHz, using coverage enhancement techniques, with characteristics of battery life for more than a decade and with specific battery-saving features. The ease that technological solutions of internet of things (IoT) make available through applications connected through intelligent sensors in traffic lights and parking lots; city pollution sensors; meters for energy, water, and sewage in cities, among other possibilities make systems more efficient, considering NB-IoT connectivity in relation to the treatment of information collected by devices allowing applications to be developed to address market needs. Therefore, this chapter aims to provide an updated discussion on narrowband technologies in the context of the IoT, showing and approaching its success, with a concise bibliographic background, categorizing and synthesizing the technological potential.
Chapter
It is expected that internet of things (IoT) will deal with the major activities in the connected living environment as well as the industrial processes. All these aspects are going to be real in the frameworks of the fifth-generation (5G) mobile networks. 5G-based narrowband IoT (NB-IoT) networks have the capability to serve various innovative IoT applications at a great extent. NB-IoT is third generation partnership project (3GPP) standardized low power wide area (LPWA) technology which is designed for IoT devices requiring long battery life, low cost, worldwide coverage, and high system capacity. To improve the performance, 3GPP has agreed that the NB-IoT will continue evolving as part of the 5G specifications. NB-IoT along with 5G will work in several connected living applications. This combination will also be very useful in the industrial environments which need high data rates and low latency. All these features will be supported by 5G in the future. Similarly, applications with low data rates in the IoT world will be supported by NB-IoT. So 5G and NB-IoT are going to be a popular combination for several new applications.
Article
Full-text available
The Internet of Things (IoT) revolution has not only carried the astonishing promise to interconnect a whole generation of traditionally “dumb” devices, but also brought to the Internet the menace of billions of badly protected and easily hackable objects. Not surprisingly, this sudden flooding of fresh and insecure devices fueled older threats, such as Distributed Denial of Service (DDoS) attacks. In this paper, we first propose an updated and comprehensive taxonomy of DDoS attacks, together with a number of examples on how this classification maps to real-world attacks. Then, we outline the current situation of DDoS-enabled malwares in IoT networks, highlighting how recent data support our concerns about the growing in popularity of these malwares. Finally, we give a detailed analysis of the general framework and the operating principles of Mirai, the most disruptive DDoS-capable IoT malware seen so far.
Article
Full-text available
Low-rate Distributed Denial-of-Service (low-rate DDoS) attacks are a new challenge to cyberspace, as the attackers send a large amount of attack packets similar to normal traffic, to throttle legitimate flows. In this paper, we propose a measurement—expectation of packet size—that is based on the distribution difference of the packet size to distinguish two typical low-rate DDoS attacks, the constant attack and the pulsing attack, from legitimate traffic. The experimental results, obtained using a series of real datasets with different times and different tolerance factors, are presented to demonstrate the effectiveness of the proposed measurement. In addition, extensive experiments are performed to show that the proposed measurement can detect the low-rate DDoS attacks not only in the short and long terms but also for low packet rates and high packet rates. Furthermore, the false-negative rates and the adjudication distance can be adjusted based on the detection sensitivity requirements.
Article
The Fifth-Generation (5G) networks, as the emerging next generation mobile networks, are adopting softwarization and virtualization technologies as the cornerstones for the network operators to gain significant competitive advantages by reducing both capital and operational expenditure, enabling agile and flexible service creation and deployment, among others. Meanwhile, a virtualized and softwarized 5G network would suffer from downgraded system performance due to this unprecedented paradigm shift towards software-based networking. Addressing one of the top challenges in this context, this paper focuses on improving the performance of the data plane from the edge to the core network segment (backhaul) in a 5G multi-tenant network by leveraging and exploring the programmability introduced by software-based networking. A fully functional prototype has been designed and implemented utilizing a Field Programmable Gate Arrays (FPGAs) acceleration-based platform, and the prototyped system has been empirically tested and evaluated to demonstrate the superior performance enhancements. The proposed solution can effectively support 5G networks in delivering mission-critical or time-sensitive applications such as ultra-high definition video use cases as experimentally validated and shown in this paper, by fulfilling the strict Quality of Service (QoS) requirements imposed to the data plane.
Article
Currently, there is no any effective security solution which can detect cyber-attacks against 5G networks where multitenancy and user mobility are some unique characteristics that impose significant challenges over such security solutions. This paper focuses on addressing a transversal detection system to be able to protect at the same time, infrastructures, tenants and 5G users in both edge and core network segments of the 5G multi-tenant infrastructures. A novel approach which significantly extends the capabilities of a commonly used IDS, to accurately identify attacking nodes in a 5G network, regardless of multiple network traffic encapsulations, has been proposed in this paper. The proposed approach is suitable to be deployed in almost all 5G network segments including the Mobile Edge Computing. Both architectural design and data models are described in this contribution. Empirical experiments have been carried out a realistic 5G multi-tenant infrastructures to intensively validate the design of the proposed approach regarding scalability and flexibility.
Article
In the Internet of Things (IoT) era, the number of connected devices and subnets of devices is rapidly increasing. Yet, it remains a challenge for intrusion detection mechanisms to build a trust map among various IoT devices because of the devices’ large quantity and dynamic nature. Through a case study, the author highlights the importance of traffic filtration and sampling in evaluating trustworthiness among IoT devices.