- Access to this full-text is provided by Hindawi.
- Learn more
Download available
Content available from Security and Communication Networks
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 dened 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 eciently ght o cyber-attacks such as
widespread Distributed Denial of Service (DDoS) attacks. However, insucient research has been conducted in this crucial area, in
particular, few if any solutions are capable of dealing with the multiple encapsulated G trac 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 trac through an autonomic control loop featured with ecient G-aware trac
ltering. Empirical results have validated the design and implementation and demonstrated the eciency of the proposed system,
which is capable of processing thousands of G-aware trac 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,theMiraiattackintookdownmajor
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 [] dened 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 dicult 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
dicult 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 dierentiate
IoT packets in the edge access network and in the core of
the G network. Ideally, this trac 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-specic protocol, e.g., the Constrained
Application Protocol (CoAP) [], used by the aected IoT
device, among others.
Network operators should be able to oer advanced
Security-as-a-Service solutions, exploiting the exibility pro-
vided by Soware-Dened 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 trac coming from the myriad of IoT
devices.
e increasing number of technologies using network
virtualization, where trac is usually encapsulated to sup-
port multicarrier G-enabled services, raises the challenge
of managing encapsulated trac eciently. Like in LTE
and G, NB-IoT trac 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 predened
matching lters like Linux Netlter, 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 ecient trac ltering have
already been provided in the state of the art [–]. However,
there is still a lack of ltering mechanisms able to perform
trac ltering in multicarrier and mobility scenarios for IoT
trac, being able to deal with the encapsulation requirements
imposed by both edge and core network segments of the G
multitenant networks, capable of performing trac ltering
and deep packet inspection in NB-IoT trac. 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 trac ltering to the current con-
textual conditions.
Our proposed ltering mechanism in this paper allows
inspecting and analyzing trac without having to create any
tunnel interfaces to deencapsulate the trac. It allows lter-
ing beyond the rst encapsulated layer and dealing with any
packet and header of any inner encapsulated trac 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 benets are manifold,
encompassing scalability, performance, and exibility, since
there is no need to create tunnel interface to perform the
deencapsulation, and trac ltering in kernel space provides
an ecient approach.
Moreover, the proposed ltering mechanism has been
integrated into a security framework to achieve resilience and
autonomic reconguration 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 trac 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 scientic 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 eciency, 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 reconguration 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 Recong-
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 trac 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 Soware-Dened Networking for conning
trac 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 trac. For reducing
both capital and operational expenditure from the point of
view of the operators, next-generation mobile networks are
adopting sowarization 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 trac 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 oen used to
evaluate the trustworthiness of network nodes and identify
malicious IoT nodes by monitoring their trac or behavior
[, ]. Once malicious trac 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 dierent
destination. In order to acquire a signature that represents
a specic 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 eciency of trac ltering and proposed
new functional enhancements over traditional rewalls. e
work in [] applies statistics collected from policy segments
with the aim of setting up Human trees that dynami-
cally adapt to the trac 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 prelter unwanted expensive trac.
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 trac characteristic. Open vSwitch (OVS)
(Open vSwitch, http://www.openvswitch.org) is a soware
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 (Specication 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 soware 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 dierent 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
Netlter matching extension called u was added by Don
Cohen []. u allows jumping between headers and select
a specic range of bytes to be inspected. e u match
feature instructs the module to extract bits ( bytes)
from the packet at any specied 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 shied.
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
trac where a signicant number of headers are added to
the protocol stacks. Similarly, the BSD Packet Filter (BPF)
[] is a byte-matching ltering mechanism that provides
an ecient 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 conguring
Linux kernel rewall implemented within the Netlter [].
Iptables uses a set of tables to inspect, modify, forward,
redirect, and/or drop packets. e main functions of Netlter
are associated with each one of those tables. Despite the
advances in the related work, the existing tools are not able to
deal with trac ltering in virtualized G Networks, where
trac from dierent tenants (multicarriers/operators) needs
to be encapsulated to dierentiate 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 trac
according to the decisions made by the autonomic security
framework, and it is based on BPF as the underlying ltering
mechanism to handle eciently NB-IoT trac 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 specied a new cellular radio access interface called
Narrowband Internet of ings (NB-IoT), which is optimized
for machine type trac. e specication tries to be as
simple as possible to minimize energy consumption, which
is crucial for IoT scenarios, considering also diculties in
radio conditions present in these ecosystems. NB-IoT has
tight relationships with LTE specication. 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 specication 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-specic 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 Ta interface to allow the non-IP
IoT trac to be forwarded. e user plane CIoT allows
forwarding of data trac 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 eorts 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
theGinfrastructureandtheusageofCommercial-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 specications.
(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 trac 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 sowariza-
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 dierent carriers and telecommunication opera-
tors in the network imposes new requirements in the network
trac 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 Trac Filtering Requirements in 5G-Enabled
IoT Networks. ere are a number of specic requirements
for network trac ltering in G IoT networks, listed as
follows:
(i) Multitenant support: in G architectures, the net-
work functional blocks are virtualized as VNFs and
dierent network operators, carriers, and verticals
can share the physical infrastructure. e packets
need to be encapsulated (e.g., in VXLAN) to dier-
entiate the trac 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 trac
lter will need to be able to handle directly these
encapsulation headers.
(iii) Application layer ltering: the network trac 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 eciently manage the packet ltering process for
numerous devices.
(v) Dynamic management: IoT networks are volatile
and trac 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 sowarized network
management and Network Function Virtualization
(NFV) technologies for handling such adaptation.
(vi) Uplink/downlink dierentiation:Garchitectures
require having two dierent 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 trac 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 sowarized 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
congure security policies using a high-level security policy
language, to govern the conguration of the system and
network, including not only network trac ltering but also
authentication, authorization, channel protection, and trac
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
reconguration 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
renement 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
rened in specic low-level congurations according to the
selected enablers. e policy renement 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) Dene Security Policies
(ltering policies)
(2) Policy Renement
(3.1) Policy Enforcement
-deploy vFirewall-
(6) Attack conrmed (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
oll
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) Dene Securi
(1) Dene Securi
n
(lterin
g po
e
(
2
)
Pol
i
(3.1
(
(
(6) Attack conr
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 reconguration 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 dened
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 soware-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,
dierent 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 trac 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, soware 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.
trac 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 simplied 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.
soware 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 MosaicG
(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 MosaicG
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 trac 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 dierent
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 dierent 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 ecient 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 trac 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 trac 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 rened and
translated—step ()—into particular low-level
congurations according to the format required by
the specic 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 notied 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 trac is sent through the
Pub/Sub Broker.
() In case the monitoring module detects an attack
based on congured signatures, step (), it warns the
reaction module to make a decision accordingly, and
this notication 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 trac 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-recongure dynamically the
network by deploying the pertinent reaction ltering
rules using the northbound protocol, as shown in step
().
() Finally, the ltering rules are congured in the l-
tering agent through the southbound API, step ().
ese rules will consider the network trac ltering
requirements in Section .. to cope with the NB-IoT
trac, including nested encapsulation for mobility
and multitenant trac 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
ecient way of ltering packets in the kernel space and it
is being used today in hardware networking equipment and
even in virtual networking soware such as OVS, employed
mainly to overcome the limitations of OpenFlow regarding
packet classication.
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 trac, 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 Trac in 5G-Aware NB-IoT Net-
works. In addition to the network protocols specied in the
previous section, an application protocol is also considered
for ltering, since dierent network attacks are not identi-
able unless the trac 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 denes what type of trac should be
controlled and the action that needs to be enforced over such
trac. 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 reconguration and adaptation. It is important
to highlight that old common techniques have been using
static sets of ltering policies on a specic 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 dierent 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 trac 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 soware-based ltering implementations it is not feasible
to handle such large quantities of rules and massive trac in
just one rewall. Moreover, this is further complicated in light
of the complex rules dened herein that require inspecting
the packets according to multiencapsulation imposed in G-
based NB-IoT networks.
Our solution benets 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 trac 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 trac. 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
conguration 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
dierent 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 dierent 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 dierent tests have been designed in order to stress
the complexity of the ltering rules and analyze how this
complexity aects 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 dened 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 dierent tests can be applied to dierent
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-specic 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 trac ltering mechanism
to handle the trac 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 trac 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
dierent infrastructures are analyzed against three dierent
complexities in the rules, and each of these scenarios will
be ranged against the dierent 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 aect
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
dierent infrastructures presented in the testbed section.
Aer 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 Netlter (iptables) to load
the ltering rules at two dierent 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 predened predicate and produces a new
timestamp. erefore, the dierence between timestamps
gathered at hooking point and hooking point provides
the time consumed of a packet crossing the kernel network
space when dierent 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 aects the
normal trac 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 trac ltering mechanism
for NB-IoT G service-aware networks with the performance
achieved in traditional IP infrastructures, which can be han-
dled with traditional trac 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 dierent 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-awareG
Multitenant Infrastructure provides the slowest.
As can be seen in the graph, the number of rules
deployed is the predominant and critical factor that aects
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.
Aer the above analysis of the behavior of all the dierent
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,,andfocusonthemostcomplexscenario
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
dierent 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 dierent 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 insignicant
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 Dierent 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 Dierent 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 Dierent 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
signicantly.
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 conguration 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 dierent 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 signicantly reduced from the times specied above.
9. Conclusions
is paper has described a novel autonomic security frame-
work featured with an ecient network trac 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 trac
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
trac, 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 trac 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 conicts 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 Specication 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
trac 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-
Denition 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-
nicationsinGnetworks,”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
Identication 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 trac 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, “Ecientstring 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. Raq, M. W. El-Kharashi, and F. Gebali, “A
fast string search algorithm for deep packet classication,”
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, “Deating 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 trac classication,”
Journal of Network and Computer Applications,vol.,pp.–
, .
[] ONF: Open networking foundationwebsite, https://www.open-
networking.org/.
[]B.PfaandO.v.S.Commiter,http://www.openvswitch.org/
support/slides/p.pdf.
[] W. c. C . Tu, “Ooading OVS ow processing using eBPF,” http://
www.openvswitch.org/support/ovscon//-tu.pdf.
[] W. Stearns, “Netlter extensions HOWTO: New netlter
matches,” http://www.netlter.org/documentation/HOWTO/
netlter-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.: netlter/iptables project homepage -
the netlter.org “iptables” project,” http://www.netlter.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. Zamr, “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 sowarization and virtual security appliances,” Inter-
national Journal of Network Management,vol.,no.,.
[] O. Standard, “OASIS advanced message queuing protocol
(AMQP) version .”.
Available via license: CC BY
Content may be subject to copyright.
